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.

[Sakurann]

Is credential configuration identifier specific to each issuer or specific to a use-case and is determined by multiple issuers?
If it is the former, the wallet has to look up every time it is talking to a new issuer, which makes wallet-initiated flows harder. If it is the latter what if a credential of the same format/type combination is used in multiple use-cases and use-case 1 wants to use credential_configuration_id A and use-case 2 wants to use credential_configuration_id B for that same credential format&type?
I honestly think we don't know yet, and I do see the risk of mandating credential_configuration_id making wallet-initiated flows using scopes harder for the ecosystems.

[tlodderstedt]

In the most general case, every issuer has its own credential configuration ids. Implementation experience will tell whether there are situations with shared credential configuration definitions.

[babisRoutis]

Dear @Sakurann

Is credential configuration identifier specific to each issuer or specific to a use-case and is determined by multiple issuers?

I think it is clearly the former. Every issuer is free to define its own values for scope & credential configuration id for a given credential.

If it is the former, the wallet has to look up every time it is talking to a new issuer, which makes wallet-initiated flows harder.
If it is the latter what if a credential of the same format/type combination is used in multiple use-cases and use-case 1 wants to use credential_configuration_id A and use-case 2 wants to use credential_configuration_id B for that same credential format&type?

We can agree, I guess, that the wallet has to lookup credential issuer's metadata, in any case:

• For a wallet initiated flow and/or while handling a credential offer
• For a "known" or a new Issuer
• Using format/type (as we currently do) or credential configuration id (if PR makes it to the spec)

So, if wallet cannot avoid grabbing the metadata, then it can easily determine the configuration for the format/type the holder is looking for, by querying the metadata.

I honestly think we don't know yet, and I do see the risk of mandating credential_configuration_id making wallet-initiated flows using scopes harder for the ecosystems.

Format/Type have a business value for (or recognized by) the holder and the verifier.
In VP this explains why they both appear to queries. Verifier expresses his query in terms of format/type/attributes.

With regards to VCI, we already have format/type to our metadata.
I feel that we don't have to "leak" those business values to every step/call. Their place is in the metadata 😄

Moving towards 1.0, perhaps, it would be more reasonable to use credential configuration id instead of format/type, and if there is a need/demand add the format/type afterwards.

[jogu]

It looks like we have 3 options on the table and I'm unclear if we have consensus around any of them. I'll add them as separate comments, can people please thumbs up options they like, ignore options they can live with, and thumbs down options they hate?

[jogu]

Option 1. We close this PR and keep the spec as is, for scopes you would need to use format+type in the credential request

[jogu]

Option 2. We merge this PR as is, and for scopes there is a choice of two possible credential requests - format+type or credential_configuration_id (potentially removing one of these options in the future as we see how they get used)

[jogu]

Option 3. We remove the format+type option in this PR before merging it

[awoie]

Can we change the title of the PR if we discuss removing certain functionality?

[Sakurann]

discussed in a WG:

• when scopes were used in the authorization response,
• if AS is capable of returning credential_identifiers parameter in the token response, wallet MUST use that in the credential request.
• if AS is NOT capable of returning credential_identifiers parameter in the token response, wallet MUST use credential_configuration_id in the credential request.

[jruizaranguren]

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.

In the current draft, additional attributes are allowed both in Token Response as well as in authorization details.

[jruizaranguren]

Option 3. We remove the format+type option in this PR before merging it

If I understand correctly, this would also remove the format-specific attributes such as vct in the credential request, right?

For example, in the sd-jwt-vc profile, the vct attribute is required when the format option is used. This vct value must also be specified in the credential_configuration_supported metadata and must match the credential_configuration_id.

This creates considerable complexity just to use credential_configuration_id.

Hence, we may have two kind of flows:

1. those using out-of-band correlation to the specific credentials to be issued, up to the AS (scopes, access_token, etc.).
2. those using authorization_details and credential_configuration_id. credential_configuration_id values might be retrieved from credential offers , issuer meta-data or out-of-band means.

Aside from potentially breaking some implementations (ours included), in what scenarios does only maintaining credential_configuration_id and credential_identifiers become problematic?

@jogu, this continues the chat at last WG.

[paulbastian]

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

[paulbastian]

Please verify that this is your interpretation of the Hybrid DCP Call

[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 😄