OpenID4VCI
OpenID4VCI copied to clipboard
openid
Credential Issuance: Generalize specification so it works with generalized forms of Identities
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1377
Original Reporter: bellebaum
Moved to here from Github.
The draft only covers the case where credentials are issued to humans.
It would not take "much" to extend the possibilities of issuance to other identities, such as device identities.
I would like to collect some opinions on whether this is out of scope or could be addressed by this draft.
Main necessary changes:
-
Relax the notion of the User to a more generic term like Subject
-
Relax the authorization mechanism requirements to allow for other mechanisms ensuring the subject's consent.
- An example: For devices registered as clients to the OP, a possibility would be to use the plain OAuth
client_credentialsflow with an appropriate authentication mechanism, such as JWT Bearers.
- An example: For devices registered as clients to the OP, a possibility would be to use the plain OAuth
-
Do not require user interaction during
dynamicinput credential presentation.- This could be achieved for example via changes in OIDC4VP, or
- via the proposal in #1376
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
Issue #1359 is related to this
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
I was asked to provide a concrete use case in last week’s SIOP call:
We have a few projects where we have devices that need assertions of claims (essentially Device Credentials) which they should be able to hold, and which they can provide to other devices upon request. We need a (preferably) standardized way to issue them.
Requirements include:
- The devices must be able to authenticate using the OAuth2
client_credentialsflow, or another flow that does not involve a UI. - Credentials must be issued as W3C Verifiable Credentials
- For some issuance flows, devices need to be able to provide Verifiable Presentations as proof of their eligibility to receive a Credential
- Deferred credential issuance may be highly beneficial, if manual work is required on the Issuer’s side
The current draft seems well-suited for most of these requirements, with the notable exception of being able to execute the flow without human interaction
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
Discussed on 2022-01-20 SIOP call
Requested a deeper explanation of the use-case. agreed to continue discussion in the issue
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
I think what you describe is basically feasible with the current design. Can you please describe how the device is authenticated in your current solution?
Imported from AB/Connect bitbucket - Original Commenter: mbj
As noted in the 20-Jan-22 call, this would be a significant increase of scope, which we should explicitly decide whether to do.
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
@{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} Currently, devices are authenticating themselves in a client_credentials flow with signed JWT Bearers as Client Assertions using pre-registered keys.
To give a concrete example of where the current draft is not supporting this use case:
From the description of the Authorization endpoint:
Authentication Requests are made as defined in Section 3.1.2.1 of [@!OpenID.Core], except that it MUST include the claims parameter defined in section 5.5 of [@!OpenID.Core] with a new top-level element credentials.
There is currently nothing similar for the Token endpoint.
@{5cfe3bb9febd110bc78a8e6b} I agree. While I do think that many of the necessary changes (see e.g. issue description and the above) are somewhat straight forward, broadening the scope will likely impact security considerations. Do you think addressing such use cases in another context/draft/wg/organization would make more sense?
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
You basically use pre-registered keys to directly authenticate the subject of the credential to be issued, correct? Do you use the client id of the device as subject identifier in your credential? Can you share an example?
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
Essentially yes, the subject identifiers will either be the the client IDs directly or derivations thereof, to fit the format (e.g. W3C VCs require URIs as subject identifiers). Should that pose a problem, it is not however a strict requirement.
Here is an illustration using DIDs:
client_id: 3F:56:45:[...]:57:C3 (guaranteed to be globally unique by OOB mechanisms)
resulting subject identifier: did:something:3F:56:45:[...]:57:C3 (Can be resolved to a DID document under the device’s control)
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
Thanks for the explanation. I just wanted to find out what is the client and what is the subject of the credential, since those roles are typically taken by different entities. They fall together in your use case.
So basically what this use case wold require is a way to obtain an access token for credential issuance based on a JWT Bearer grant. That would mean to send the parameters we have defined for the authentication request with a token request. Right?
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
Yes, if I have not overlooked anything, that would pretty much cover the use case.
Questions we would then have to ask include:
-
Would the terminology of a
userbe confusing ifclientscan receive credentials? -
Is there support for the dynamic Credential Input approach?
- Not necessary for the use case and I am not aware of any other use cases reliant on the dynamic approach.
- Workaround, should we want to support something remotely similar: Issue 1376 is an extension to the static approach, which can be implemented alongside the dynamic OIDC4VP approach:
If the Issuer is not given enough attestations for the user,
it could return a special error containing machine readable instructions for what additional credentials are required by the user.
A wallet would then ask the user to select the additional credentials to send along and subsequently start the AuthZ over using the static credential input approach including all relevant credentials.
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
On dynamic credential input: wouldn’t vp_token support in the token request solve that problem?
Imported from AB/Connect bitbucket - Original Commenter: bellebaum
I think we might read “dynamic credential input” differently there. My understanding was that when using dynamic input, the Issuer is able to determine necessary presentations based on the authentication and previously received VPs by the user, which it can only do after those (and consequently the initial authorization/token request) have already happened. In my mind, providing vp_token with the initial request would correspond to the “static” approach. Please correct me, if I have misunderstood something there.
Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt
You are right :wink: vp_token is part of the "static" approach.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I would assume basing credential issuance flow on OAuth as opposed to OIDC does not solve this issue?
Imported from AB/Connect bitbucket - Original Commenter: mbj
Kristina, I believe you’re right that the switch to OAuth doesn’t change things with respect to this issue. I believe that it’s orthogonal.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I think defining Pre-authorized Code flow addressed second and third bullet points?
re first one, we could make a change User -> subject, since there are legal entity use-cases emerging..
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
coming back to this issue after a year and having heard more feedback asking for server-to-server based credential issuance, I would love to bring this up in a WG call and see if this can be ready for PR. Torsten already summarized it pretty well above but I think what needs to be done is adding a section (either adding one more section in section 3 with a sequence diagram, or a section in the implementation considerations) outlining that
- client can authenticate at the token endpoint using client_credentials_grant
- client will use scope value to communicate to the issuer which credential it wants to be issued. I don’t think it is unrealistic since client will already have a client secret from the issuer.
I'd like to bring this discussion up at some point in the future. I don't think it's a super pressing matter but now that ID1 is underway, it might be a good time to re-visit this imho.
My initial idea would be to open up the Token endpoint to allow other OAuth grant types (like client credentials, but most likely something like a client attestation/assertion would make sense in the long run as well). Imho, this should be purely optional for wallets and issuers. That way it can be ignored for the smartphone wallet use-cases, but can be leveraged if necessary.
in our implementation, we are using VCI to issue VCs to legal entities using pre-auth code flow without any changes to the specification. legal entity gets checked by the issuer that they are a valid entity, receive pre-auth code into their cloud wallet, and do a pre-auth code flow. it works nicely.
My initial idea would be to open up the Token endpoint to allow other OAuth grant types
I think using client credential grant with VCI is already totally valid. the only limitation is that if one needs credential offer for client credentials grant (not sure you would), the structure is not defined.
so maybe one paragraph clarifying how the issuance of VCs to the legal entity is possible would be beneficial.
