add an option to use credential_configuration_id in credential request

[Sakurann]

Closes one remaining item from PR #294 as agreed on May 29th 2024 call.
Closes #132
Closes #175

enables to use credential_configuration_id in the credential request.

I am increasingly in favor of dropping an option to use format + type in authorization request and credential request, and instead clarify that implementations that do not use issuer metadata should define the mapping between scope (optionally), format, type and credential_configuration_id out of band? #234 is the related issue though it proposes a different solution. (probably needs discussion with torsten on the call)

also resolves #342

[paulbastian]

My understanding from the discussion around #294 was that credential_configuration_idoption replaces the format option. I would rather replace an option than adding a third one. Apart from them, everything seems fine to me.

[paulbastian]

This is missing an entry for the document history

[Sakurann]

My understanding from the discussion around #294 was that credential_configuration_idoption replaces the format option. I would rather replace an option than adding a third one.

I don't think we can do it without removing format option in authorization request

[Sakurann]

discussed in the WG call, ask the ML if implementers using format + type would be against removing that option in favor of using credential_configuration_id only.

and that does not necessarily mean that implementations that do not use issuer metadata are not allowed because we could say that implementations that do not use issuer metadata should define the mapping between scope (optionally), format, type and credential_configuration_id out of band.

@pmhsfelix pointed out that after ID-1 we have already made a change that prohibited using format + type with RAR.

[jogu]

discussed in the WG call, ask the ML if implementers using format + type would be against removing that option in favor of using credential_configuration_id only.

Email sent to mailing list requesting feedback within the next week: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20240923/000455.html

[babisRoutis]

I think that

• credential_configuration_id should replace format + format specific attributes, in the credential request.
• Keep in the authorization_details only the credential_configuration_id and remove the format (in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-using-authorization-details)

[paulbastian]

I think that

• credential_configuration_id should replace format + format specific attributes, in the credential request.
• Keep in the authorization_details only the credential_configuration_id and remove the format (in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-using-authorization-details)

I couldn't agree more

[awoie]

Wasn't the format option demonstrated in the POTENTIAL interop event and therefore there are existing implementations that have support for this (also including our own implementation)?

[awoie]

I think that

• credential_configuration_id should replace format + format specific attributes, in the credential request.
• Keep in the authorization_details only the credential_configuration_id and remove the format (in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-using-authorization-details)

I couldn't agree more

I would suggest creating a particular issue for removing the format option and keep it separate from this PR.

[babisRoutis]

Wasn't the format option demonstrated in the POTENTIAL interop event and therefore there are existing implementations that have support for this (also including our own implementation)?

Good morning, @awoie

For every feature/option removed there was an implementation.

• There was support for CWT proofs.
• There were implementations of Batch Endpoint
• There is support for obtaining c_nonce from token endpoint etc.

The credential_configuration_id is a simpler & format-agnostic way to uniquely identify a credential configuration compared to format.
Perhaps, the only feature that could be added to the former would be the option to use format-specific claims attribute to control the attributes issued (this is the case for authorization_details, if I am not mistaken).

[Sakurann]

@babisRoutis @paulbastian i am repeating myself, but what you are suggesting needs to be done in conjunction with the changes to the format+type option in the authorization request and text explaining how the protocol works without issuer metadata, for example by saying that implementations that do not use issuer metadata should define the mapping between scope (optionally), format, type and credential_configuration_id out of band.

[paulbastian]

@babisRoutis @paulbastian i am repeating myself, but what you are suggesting needs to be done in conjunction with the changes to the format+type option in the authorization request and text explaining how the protocol works without issuer metadata, for example by saying that implementations that do not use issuer metadata should define the mapping between scope (optionally), format, type and credential_configuration_id out of band.

Looks like a good suggestion to me. Anything else that would be missing apart from clarifications that issuer metadata or similar conventions could be communicated out of band?

[pmhsfelix]

We still need to allow some format specific parameters on authorization requests using RAR, such as:

• credentialSubject for jwt_vc_json
• claims for vc+sd-jwt
  since these convey information not present in the metadata entry, typically a customization of what is allowed by the metadata entry.

PS. And for credential requests, when a credential_identifier is not available. I.e., allow for some format specific parameters, even if format is not allowed.

[Sakurann]

Talked to @tlodderstedt, who said that it is better to close this PR and keep things as-is, because...

1. an option to use one credential_configuration_id parameter might be easier to the developers than using combination of format and type parameters, but it is probably making it harder for the ecosystem(s)/use-cases because they will have to define credential_configuration_id for format and type combinations, which might be easy if there is only one issuer, but suddenly becomes harder when there is more than one ecosystem/use-case, which is pretty common.
2. ... and credential_configuration_id is a construct in VCI while format and type are credential format construct, so always mandating a mapping to exist between credential_configuration_id and format and type combinations mixes these things up.

[babisRoutis]

Talked to @tlodderstedt, who said that it is better to close this PR and keep things as-is, because...

1. an option to use one `credential_configuration_id` parameter might be easier to the developers than using combination of `format` and `type` parameters, but it is probably making it harder for the ecosystem(s)/use-cases because they will have to define `credential_configuration_id` for `format` and `type` combinations, which might be easy if there is only one issuer, but suddenly becomes harder when there is more than one ecosystem/use-case, which is pretty common.

2. ... and `credential_configuration_id` is a construct in VCI while format and type are credential format construct, so always mandating a mapping to exist between `credential_configuration_id` and `format` and `type` combinations mixes these things up.

I don't agree on closing the PR.

VCI is all about allowing wallet to place a credential request. It doesn't seem consistent that throughout the issuance process (offer, authorization_details, auth. req) an unambiguous identifier can be used, except the most important step.

If there isn't a consensus to remove format + type from credential request, at least , we should have the alternative option to use credential_configuration_id.

[tlodderstedt]

@babisRoutis

VCI is all about allowing wallet to place a credential request. It doesn't seem consistent that throughout the issuance process (offer, authorization_details, auth. req) an unambiguous identifier can be used, except the most important step.

What do you expect the wallet to know, when it starts the process? I would expect the wallet to know format and type of the credential the holder is looking for. That's what is being standardized not a credential configuration id. Just as an example, ISO 18013-05 defines the mDL doc type. It does not define how the credential configuration id of an OID4VCI issuer supporting this doc types is. As this is a most likely locally defined metadata identifier. And it is protocol specific.

So how to cope with this situation?

1. the wallet could determine the issuer specific credential configuration id(s) for a certain format/type and use the respective credential configuration id in the authorization request.
2. the wallet sends the format/type in the authorization request, the issuer provides the wallet with its local reference (either through a credential configuration and/or a credential identifier) in the token response to be used in subsequent steps.
3. The credential configuration id was defined somewhere (in addition to credential types and schemas), and is used by all issuers supporting the same credential type
4. A wallet only works with one issuer for a certain type and is pre-configured or hard coded to use its credential configuration id.

What would you prefer and why?

[babisRoutis]

What do you expect the wallet to know, when it starts the process? I would expect the wallet to know format and type of the credential the holder is looking for

Hi @tlodderstedt

I think option 1 is the way to go.

For an issuance process, that is initiated at issuer's site, wallet's participation begins with a credential offer (No format/type)

On the other hand, for a wallet-initiated issuance, wallet should know (or could search, to a local or trusted registry of issuers, for):

• credential issuer id
• format
• type

Of course, holder is interested to get a specific credential type, from a trusted issuer. Few would care or even understand about formats.

With these three values, wallet can "assemble" on its own a stateless credential offer as follows:

• Obtain issuer metadata, then
• Determine the credential configuration id that for the type and format the holder is interested in.
• Assemble a credential offer that uses authorization code grant

So, actually, I believe that wallet has to have always a credential offer (issuer provided or locally created) to interact with the issuer.

Format/type can be used as criteria to just query issuer's metadata. With this problem solved, I find no reason to use format/type in any of the subsequent steps (authorization, authorization_details & credential request), should this PR be accepted.

[jruizaranguren]

I applied the changes discussed in hybrid call to this PR. Please check @Sakurann @jogu @babisRoutis @tlodderstedt @c2bo @jruizaranguren @nemqe

I find it ready for implementation 😄

[paulbastian]

I approve as I submitted most of the changes

[Sakurann]

honestly, it feels weird AS returning credential_identifier in the aurhorization_details object in the token response, when AS uses scopes (and not authorization details) in the authorization request, but guess that is the least optionality.

Also added a section summarizing all of the options for clarity: https://github.com/openid/OpenID4VCI/pull/392/files#diff-1f424614b35a9899813079f1b1f6218631a2aedd993368ccb89bb81a9eda0289R189

[danielfett]

Mostly editorial feedback so far.

[danielfett]

Suggested change

	in the `authorization_details` parameter in theToken Response,
	in the `authorization_details` parameter in the Token Response,

[danielfett]

Suggested change

	If the Authorization Server supports returning top-level`credential_identifiers` parameter
	If the Authorization Server supports returning a top-level `credential_identifiers` parameter

[danielfett]

Some definition of what applies when the condition after "REQUIRED" is not met should be provided.

[danielfett]

What if the condition after "OPTIONAL" is not met?

[Sakurann]

discussed on the WG call, agreed to use credential_identifiers in the authorization_details in the token response even when AS used scopes in the authotization request.