Credential Issuance: Generalize specification so it works with generalized forms of Identities

[Thomas 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_credentials flow with an appropriate authentication mechanism, such as JWT Bearers.

• 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

‌

[Thomas Bellebaum]

Issue #1359 is related to this

[Thomas 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_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

[Kristina Yasuda]

Discussed on 2022-01-20 SIOP call

Requested a deeper explanation of the use-case. agreed to continue discussion in the issue

[Torsten Lodderstedt]

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?

[Michael Jones]

As noted in the 20-Jan-22 call, this would be a significant increase of scope, which we should explicitly decide whether to do.

[Thomas Bellebaum]

@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?

[Torsten Lodderstedt]

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?

[Thomas 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)

[Torsten Lodderstedt]

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?

[Thomas 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 user be confusing if clients 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.

‌

[Torsten Lodderstedt]

On dynamic credential input: wouldn’t vp_token support in the token request solve that problem?

[Thomas 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.

[Torsten Lodderstedt]

You are right vp_token is part of the "static" approach.

[Kristina Yasuda]

I would assume basing credential issuance flow on OAuth as opposed to OIDC does not solve this issue?

[Michael Jones]

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.

[Kristina Yasuda]

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..

[Kristina Yasuda]

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.

‌

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI