search

openid / OpenID4VCI

68 stars 20 forks source link

add an option to use credential_configuration_id in credential request #392

Closed Sakurann closed 3 days ago

Sakurann commented 2 months ago

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 commented 2 months ago

This is missing an entry for the document history

Sakurann commented 2 months ago

My understanding from the discussion around https://github.com/openid/OpenID4VCI/issues/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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

I think that

paulbastian commented 1 month ago

I think that

I couldn't agree more

awoie commented 1 month ago

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 commented 1 month ago

I think that

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 commented 1 month ago

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.

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 1 month ago

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

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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):

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:

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

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 :smile:

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

awoie commented 3 weeks ago

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

Sakurann commented 3 weeks ago

discussed in a WG:

jruizaranguren commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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

jruizaranguren commented 2 weeks ago

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 :smile:

Sakurann commented 1 week ago

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

Sakurann commented 6 days ago

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.