[oidc4vci] role of the ID Token

[Kristina Yasuda]

During 2022-Feb-10 call, it has been pointed out that in some use-cases the issuer of a VC does not have a clear identifier on the user. Can the ephemeral identifier be used in the sub of an ID Token? Should ID Token itself be optional in OIDC4VCI?

Would be great to hear how people are / intending to use ID Token in OIDC4VCI protocol flows.

https://bitbucket.org/openid/connect/pull-requests/124#comment-278938304

‌

[Mark Haine]

Section 17.3 of OIDC Core relating to PPID springs to mind here

[Torsten Lodderstedt]

I see some utility in an ID token in the issuance flow for:

• personalization of the UX in the wallet and
• obtaining a user handle that can be used in sub-sequent issuance transactions to refer to “the same user” again using the id_token_hint

However, this all feels rather optional. As already brought in the meeting, we should discuss whether the ID token needs to be a mandatory or optional part of the flow. If the latter is the case, we should transform the base issuance protocol into an OAuth based flow.

We initially decided to build it on top of OIDC in order to be able to use OIDC features like the claims parameter. With a OAuth flow, one could utilize authorization_details for the same purpose.

AS OAuth and OIDC go together very well, interested parties could optionally turn on the OIDC part in order to be able to obtain/provide an ID token.

‌

[Tobias Looker]

The more I think about this the more I am inclined to believe it is better suited as an extension of OAuth2.0 because the core flow is really about obtaining authorization to a new type of resource “a credential”, including the capability to keep this credential current and or request multiple copies of it. Decoupling the protocol from OIDC would not exclude it from being used in conjunction with it, just make it optional as torsten has pointed out above. In regards to using the id_token to inform the UX in the wallet, while I see the appeal I think there are other techniques better suited here (e.g a metadata layer around the credential returned from the /credential endpoint).

‌

‌

[Kristina Yasuda]

Smart Health Card (SHC) is a use-case where a similar issuance API has been defined OAuth based. the motivation was because there were already existing mandatory OAuth APIs for EHR (electronic health records) vendors. There are usages for ID Tokens too - for example allowing to log in to the health apps using EHR system as IdP.

https://spec.smarthealth.cards/#via-fhir-health-cards-issue-operation

[Kristina Yasuda]

2022-Mar-10 Connect call, we agreed this idea makes sense and should be explored - PR needed probably.

It was pointed out that this flow is different from JWT assertion, because in this flow, Access Token is opaque to the Client.

[Kristina Yasuda]

PR #149