Credential Issuance: Remove the reliance on OIDC4VP

[Thomas Bellebaum]

Moved to here from Github.

Currently, the draft relies on OIDC4VP (and, realistically, SIOP), which may be a high bar to clear for some OPs and clients,
as it requires the OP to act as a client as well, and the client to act as an OP.
For clients, this is probably not much of a concern to a wallet which want to utilize OIDC4VP anyway to present their VCs,
but if other means for exchanging VPs are used, this may become a burden.

TODO maybe there are even some security policies against this? I am unsure.

Therefore I propose an alternative for discussion:

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.

Pros:

• No direct reliance on OIDC4VP
• The OP needs to keep less state (like accepted VPs), as every auth request contains either all necessary credentials, or can be rejected.

• If a client already knows it belongs to a subset of users for which additional credentials are required, it can send them along in the first request, thus reducing the number of round trips.

  • This would however need to be mentioned in the privacy considerations, as by the principle of data minimization the client needs to be reasonably sure that all sent credentials are required.

• ...

Cons:

• Hard to make error responses as expressive as OIDC4VP
• Strictly speaking this would extend the capabilities of error responses
• ...

‌

[Torsten Lodderstedt]

Your proposal would mean to solely rely on presentation at authorization request. I’m not fully convinced of this part of the protocol since it makes it much more complex (obtain nonce, prepare presentation, …) since it turns around the credential presentation process. To me calling back to the wallet seems to be more natural.

Can you please explain why you think using OIDC4VP would be a burden for the issuer? A lot of OPs today use OIDC or SAML to obtain identity data from other sources. I see this as a variant of this pattern.

We have both options in the draft in order to let implementers experiment and decide what is the best way but ultimately would like to get rid of one option in order to simplify the protocol.

Do you think that will be possible?

[Jeremie Miller]

Could all of this be moved out of scope of the credential issuance draft, and it can focus on just the issuance?

A separate profile of OIDC4VP+SIOP can be built to document a presentation flow for issuers that require it. I don’t see it as necessary to be included/embedded in the issuance draft any more than OIDC defined how an OP gets consent.

I would prefer a KISS approach that could lead to consensus on a core/simple credential issuance spec much faster.

[Torsten Lodderstedt]

Issuing credentials based on existing credentials is an important use case. The reason why we included mechanisms to present credentials in this draft is the relationship between the acting parties.

If the issuance request comes from a certain wallet, subsequent requests for credential presentations will most likely go to the same wallet. Carrying the identity (issuer url) of that wallet therefore seems to be a good idea.

I understand that from a conceptual perspective, it would be possible to move that to a different spec. However, I see a value yet. To the contrary that would increase fragmentation of the SIOP/SSI landscape and make our life as editors harder.

I would rather keep it as is and evolve the draft (based on implementation experience) until we better understand the problem space.

[Thomas Bellebaum]

If the issuance request comes from a certain wallet, subsequent requests for credential presentations will most likely go to the same wallet.

May we assume that the issuer knows whether the presentations reside in the same wallet?

Carrying the identity (issuer url) of that wallet therefore seems to be a good idea.

More of a side note: This could of course also be communicated in a separate presentation flow.

‌

Could all of this be moved out of scope of the credential issuance draft, and it can focus on just the issuance?
A separate profile of OIDC4VP+SIOP can be built to document a presentation flow for issuers that require it. I don’t see it as necessary to be included/embedded in the issuance draft any more than OIDC defined how an OP gets consent.

From a conceptual perspective, this would also resolve (or at least make easier) many of the problems in issue #1377 .

[Kristina Yasuda]

resolved in PR #138 and PR #134