[OID4VCI] Realm based scope credential approach #39265
Replies: 4 comments 2 replies
-
|
My understanding about the discussion is that it pushes for having a client scope as the single source of truth for defining and configuring issuable credentials, which totally makes sense in my opinion as well. I would just want to recall some issues were once raised about enforcing a specific |
Beta Was this translation helpful? Give feedback.
-
Yes, that is exactly what I meant. Would have been a good idea to state this out more clearly :-) So thanks for doing it :-)
I actually do not want to enforce a protocol but basically allow a pseudo-protocol. A new protocol must be attached to the client implementation which was the reason for the original design. |
Beta Was this translation helpful? Give feedback.
-
|
If you move the realm attributes to the client scope configuration, does that mean that the VCI metadata needs to be fetched from the client scope configuration then? Will all client scope definitions for OpenID4VC then be used as the source for the VCI metadata ( See: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that is the intention. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, just verified that when you are creating client scope and you select Also regarding UI, it may be needed to have some "dynamicity" in the rendering of client scopes similarly like we have for some other things (EG. clients, identity providers etc), so that some client scope attributes are hidden for certain protocols. For example the existing attribute |
Beta Was this translation helpful? Give feedback.
-
|
I will create some tickets now ans ask Ingrid to add them to the draft-15 epic. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I would like to discuss the current approach of the OpenID4VCI scope based approach with the realm configuration.
The as is state:
We need to update the realms configuration by adding additional attributes that define a specific credential:
next: we need to define the scope that represents the credential:
only this combination together exposes the credential with its
credential_configuration_idat thecredential-issuer-endpoint.I would like to share a few thoughts on this approach, which I will outline below:
Why don't we allow the protocol 'oid4vc' for scopes? Like this we can distinguishe between openid-scopes and openid4vci-credentials. This would also be very obviously displayed within the UI:
Currently, the attempt to define a scope with protocol
oid4vcresults in aBadRequest.lf we follow step 1 we should be able to shift the configuration that is currently added to the realm-attributes directly to the scope itself. We can add attributes there like
vct,credential-identifier, etc.How this will eventually look in the UI still needs to be discussed.
Doing this will solve another problem with the
Authorization Code Flow-support. When addressing theAuthorizationEndpointfor credential issuance it is necessary to identify the request by either ascope-value or theauthorization_details-parameter fromRich Authorization Requests. If we determine specificscopesto be of protocoloid4vcwe can easily determine if the request is done to issue a cr 10000 edential even with aRich Authorization Requestbecause we can more easily determine which sopes we are allowed to use to satisfy the request.We need a concept for
credential_identifiers. I wouldn't like the idea putting this into the realms configuration, instead I would like to allow parent-child relationships betweenoid4vc-scopes. If we use the exampleUniversityDegreeCredentialwe could havePhysicsMasterDegreeCredentialor aInformaticsDiplomDegreeCredentialfor example. Both would probably share some common attributes inherited by the parent-credentialUniversityDegreeCredentialas well as some extra attributes only defined for the specific credential. Outsourcing this concept in bidirectional logic betweenrealm-configuration andscope-configuration would greatly intensify the complexity and usability of this feature.Beta Was this translation helpful? Give feedback.
All reactions