Feature Request
In the current implementation, IdentityHub has an interface ScopeToCriterionTransformer, which transforms scopes into Criterion objects to perform database queries.
For multi-dataspace support we need this to be more dynamic, so that one particular scope prefix (e.g. org.my.dataspace.vc.type) corresponds to a JSON-LD namespace (e.g. my.dataspace.com/namespace/v1.0/credentials). That way, every scope string can be uniquely mapped onto credentials (namespace + type)
Which Areas Would Be Affected?
Presentation Query handling
Why Is the Feature Desired?
In multi-dataspace deployments each dataspace has its own scope prefix. Filtering based on the scope prefix is necessary to avoid returning wrong credentials, if the type exists in > 1 dataspaces.
Solution Proposal
Implement a generic ScopeToCriterionTransformer, that parses a map of scope-prefix-to-namespace entries and resolves the correct one. There are several solution possibilities to achieve this:
-
provide the mapping via a ScopePrefixMappingRegistry and pre-fill it from configuration. Easy to implement, follows known patterns (registries) and can be dynamically mutated, e.g. through an API.
-
provide the scope prefix when requesting credential issuance. Currently, the CredentialRequestDto contains format, type and id for each requested credential. We could add a scopePrefix parameter there and build a dynamic map that way. This would not work with issuer-initiated credential offers though.
As a third, slightly more involved approach, we could look at this:
Provide a mapping mechanism from scope discriminator to fully-qualified credential type. For example, there is dataspace X and dataspace Y, both define a MembershipCredential. Let their respective JSON-LD context be http://dataspacex.com/jsonld/v1 and http://dataspacey.com/context, then their fully-qualified credential types would be constructed as:
http://dataspacex.com/jsonld/v1#MembershipCredentialhttp://dataspacey.com/context#MembershipCredential
either of those fully-qualified credential types would then map to a scope discriminator, e.g. org.eclipse.dspace.dcp.vc.type:MembershipCredentialX:read or org.eclipse.dspace.dcp.vc.type:MembershipCredentialY:read
edit: a solution proposal for variant 3 is here: https://github.com/paullatzelsperger/IdentityHub/tree/feat/fully-qualified-credential-type
Feature Request
In the current implementation, IdentityHub has an interface
ScopeToCriterionTransformer, which transforms scopes intoCriterionobjects to perform database queries.For multi-dataspace support we need this to be more dynamic, so that one particular scope prefix (e.g.
org.my.dataspace.vc.type) corresponds to a JSON-LD namespace (e.g.my.dataspace.com/namespace/v1.0/credentials). That way, every scope string can be uniquely mapped onto credentials (namespace + type)Which Areas Would Be Affected?
Presentation Query handling
Why Is the Feature Desired?
In multi-dataspace deployments each dataspace has its own scope prefix. Filtering based on the scope prefix is necessary to avoid returning wrong credentials, if the type exists in > 1 dataspaces.
Solution Proposal
Implement a generic
ScopeToCriterionTransformer, that parses a map of scope-prefix-to-namespace entries and resolves the correct one. There are several solution possibilities to achieve this:provide the mapping via a
ScopePrefixMappingRegistryand pre-fill it from configuration. Easy to implement, follows known patterns (registries) and can be dynamically mutated, e.g. through an API.provide the scope prefix when requesting credential issuance. Currently, the
CredentialRequestDtocontainsformat,typeandidfor each requested credential. We could add ascopePrefixparameter there and build a dynamic map that way. This would not work with issuer-initiated credential offers though.As a third, slightly more involved approach, we could look at this:
Provide a mapping mechanism from scope discriminator to fully-qualified credential type. For example, there is dataspace X and dataspace Y, both define a MembershipCredential. Let their respective JSON-LD context be
http://dataspacex.com/jsonld/v1andhttp://dataspacey.com/context, then their fully-qualified credential types would be constructed as:http://dataspacex.com/jsonld/v1#MembershipCredentialhttp://dataspacey.com/context#MembershipCredentialeither of those fully-qualified credential types would then map to a scope discriminator, e.g.
org.eclipse.dspace.dcp.vc.type:MembershipCredentialX:readororg.eclipse.dspace.dcp.vc.type:MembershipCredentialY:readedit: a solution proposal for variant 3 is here: https://github.com/paullatzelsperger/IdentityHub/tree/feat/fully-qualified-credential-type