- marked as enhancement
- edited description
Credential Issuance: Generalize specification so it works with generalized forms of Identities
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_credentials
flow 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
dynamic
input credential presentation.- This could be achieved for example via changes in OIDC4VP, or
- via the proposal in
#1376
Comments (21)
-
reporter -
reporter Issue #1359 is related to this
-
reporter - edited description
-
reporter - changed component to Credential Issuance
-
reporter 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_credentials
flow, 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
- The devices must be able to authenticate using the OAuth2
-
- changed status to open
Discussed on 2022-01-20 SIOP call
Requested a deeper explanation of the use-case. agreed to continue discussion in the issue
-
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?
-
As noted in the 20-Jan-22 call, this would be a significant increase of scope, which we should explicitly decide whether to do.
-
reporter @Torsten Lodderstedt 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.
@Michael Jones 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?
-
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?
-
reporter 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) -
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?
-
reporter 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
user
be confusing ifclients
can 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.
- Would the terminology of a
-
On dynamic credential input: wouldn’t
vp_token
support in the token request solve that problem? -
reporter 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. -
You are right
vp_token
is part of the "static" approach. -
I would assume basing credential issuance flow on OAuth as opposed to OIDC does not solve this issue?
-
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.
-
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.. -
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.
-
- changed status to resolved
Migrated to GitHub
- Log in to comment