Class OID4VCSubjectIdMapper
java.lang.Object
org.keycloak.protocol.oid4vc.issuance.mappers.OID4VCMapper
org.keycloak.protocol.oid4vc.issuance.mappers.OID4VCSubjectIdMapper
- All Implemented Interfaces:
OID4VCEnvironmentProviderFactory,ProtocolMapper,ConfiguredProvider,EnvironmentDependentProviderFactory,Provider,ProviderFactory<ProtocolMapper>
Sets an ID for the credential subject, either from User ID or by attribute mapping
A Verifiable Credential (VC) is often bound to a Holder's Digital Identity (DID).
The Holder's DID is in turn bound to Key Material that the Issuer + Verifier can discover from the DID Document.
In case of "did:key:..." the Public Key is already encoded in the DID.
Here, we make sure that the default UserProfile has a 'did' attribute when --feature=oid4vc-vci is enabled.
Conceptually, it is however debatable whether the Issuer should know even one of the Holder's DIDs
In future, it may be possible that ...
* The Holder communicates the DID at the time of Authorization
* The Issuer then verifies Holder possession of the associated Key Material
* The Issuer then somehow associates the AuthorizationRequest with a registered User
* The VC is then issued to the Holder without the Issuer needing to remember that Holder DID
This kind of Authorization protocol is for example required by EBSI, which we aim to become compatible with.
https:*hub.ebsi.eu/conformance/build-solutions/issue-to-holder-functional-flows
Note, that current EBSI Compatibility Tests use the Holder's DID as OIDC client_id in the AuthorizationRequest.
That is something we need to work with, but I don't think we should model it like that in our realm config.
Here the attribute definition that we add by default (when not defined already)
{
"name": "did",
"displayName": "DID",
"permissions": {
"view": ["admin", "user"],
"edit": ["admin", "user"]
},
"validations": {
"pattern": {
"pattern": "^did:.+:.+$",
"error-message": "Value must start with 'did:scheme:'"
}
}
}
- Author:
- Stefan Wiedemann
-
Field Summary
FieldsFields inherited from class org.keycloak.protocol.oid4vc.issuance.mappers.OID4VCMapper
CLAIM_NAME, format, mapperModel, USER_ATTRIBUTE_KEY -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionstatic ProtocolMapperModelcreate(KeycloakSession session) getId()protected List<ProviderConfigProperty>voidsetClaim(Map<String, Object> claims, UserSessionModel userSessionModel) Set the claims to the credential subject.voidsetClaim(VerifiableCredential verifiableCredential, UserSessionModel userSessionModel) Set the claims to credential, like f.e.Methods inherited from class org.keycloak.protocol.oid4vc.issuance.mappers.OID4VCMapper
close, getAttributePrefix, getConfigProperties, getDisplayCategory, getMetadataAttributePath, getProtocol, includeInMetadata, init, postInit, setClaimWithMetadataPrefix, setMapperModelMethods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, waitMethods inherited from interface org.keycloak.provider.ConfiguredProvider
getConfigMethods inherited from interface org.keycloak.protocol.oid4vc.OID4VCEnvironmentProviderFactory
isSupportedMethods inherited from interface org.keycloak.protocol.ProtocolMapper
getEffectiveModel, getPriority, validateConfigMethods inherited from interface org.keycloak.provider.ProviderFactory
dependsOn, getConfigMetadata, order
-
Field Details
-
MAPPER_ID
- See Also:
-
-
Constructor Details
-
OID4VCSubjectIdMapper
public OID4VCSubjectIdMapper()
-
-
Method Details
-
create
-
getIndividualConfigProperties
- Specified by:
getIndividualConfigPropertiesin classOID4VCMapper
-
setClaim
Description copied from class:OID4VCMapperSet the claims to credential, like f.e. the context- Specified by:
setClaimin classOID4VCMapper
-
setClaim
Description copied from class:OID4VCMapperSet the claims to the credential subject.- Specified by:
setClaimin classOID4VCMapper
-
getDisplayType
-
getHelpText
-
create
-
getId
-