Clarification on use of 'format' claim in authorization_details

[vafeini]

Draft 13 specifies that authorization_details, among other claims, it must contain either

a credential_configuration_id referencing a specific credential configuration in issuer's credential_configurations_supported

or

a format claim along with profile specific extra attributes (ex. doctype for ISO mDL, vct for SD-JWT VC etc.)

I was wondering if both flavors are needed.

In my understanding when format + profile_specific_extra_attribute is used it can only point to a credential configuration supported from issuer and thius advertized in its metadata. It cannot be used to request arbitrary credentials outside credential_configurations_supported. If this is the case only using the credential_configuration_id flavor of authorization_details is enough to identify specific credential supported by issuer.

Most probably I am missing something :D , can you provide your view on that?

[TakahikoKawasaki]

@vafeini Your comment assumes that a verifiable credential requested by authorization_details.format + other vc-specific parameters MUST be a subset of a supported credential configuration. However, the intention of the DCP WG is unclear. They may want to introduce a means to request an ad-hoc verifiable credential that may not be listed in credential_configurations_supported.

If the DCP WG thinks that a verifiable credential requested by authorization_details.format MUST be a subset of a supported credential configuration, the format parameter should not have been resurrected.

When I saw the format parameter being resurrected, I interpreted it as the DCP WG wanting to introduce a means to request an ad-hoc verifiable credential. If it was not the DCP WG's intention, having resurrected the format parameter is simply a technical mistake.

[vafeini]

@TakahikoKawasaki Indeed this might be the reason, though in this case how would a wallet know about the issuer'a capability to issue such a credential?
So far issuer's metadata is the only way for an issuer to advertise its issuing capabilities and the specifics of each credential's issuance (claims, proof types supported for credential).

[TakahikoKawasaki]

@vafeini If the OID4VCI specification allows wallets to request an ad hoc verifiable credential that is not listed in credential_configurations_supported, there is no way for the wallets to know whether the credential issuer can issue the ad hoc verifiable credential or not.

Those who believe "all the verifiable credentials the credential issuer can issue should be listed in credential_configurations_supported" will likely object to introducing the format parameter. On the other hand, those tolerating this implementation-dependent behavior (some credential issuers may issue ad hoc verifiable credentials while others may not) will not object to the format parameter.

Personally, I don't recommend introducing the format parameter, but I do not intend to strongly argue against it.

[babisRoutis]

I don't think that the intention of VCI is to allow a wallet to place requests for credential that are not advertised via issuer's meta-data.

It's not only the format vs credential_configuration_id in the authorization details.
What about other meta-data that the wallet must be aware of, like, for instance, whether proofs are required, proof algorithms, encrypted response option etc.

Frankly, I believe that with draft 13:

• authorization_details should just keep the credential_configuration_id and drop the format alternative.
• The credential request should also drop the format. A request could identify the VC either in terms of credential_configuration_id or a credential_id.

With these changes, all the important entities of the protocol will be expressed in terms of credential_configuration_id:

• Credential offer contains one more credential_configuration_id
• Issuer Metadata provides credential_configurations_supported that uses again credential_configuration_id
• Authorization details, if used, reference credential_configuration_id
• Credential request the same.

This offers a clear path for wallet's when processing a credential offer and issuer's when handling the relevant issuance process.

[TakahikoKawasaki]

@babisRoutis It seems that you have noticed the issue reported by Issue #175 ("Wallet can't always identity whether key proof is required") and the feature of enforcing a key proof cannot be implemented. 😅

Yes, the format parameter in a credential request exhibits a similar ambiguity issue to the format parameter in authorization_details.

[babisRoutis]

@TakahikoKawasaki 👍

With regards to #175 I think there is a problem for the issuer, as well.

In particular when should they provide the pair of c_nonce & c_nonce_expires_in in the credential response. Given that an an access token may grant issuance of for more than one credential types, some requiring proofs others not, its not clear (at least for me) when the issuance service should return the c_nonce attributes.

Personally, I made the simplification to always return those attributes and let the meta-data convey the requirement of using proofs or not.
Of course, returning back to the present issue, this means that I support only VCs advertised via issuer's meta-data.

[jogu]

In my understanding when format + profile_specific_extra_attribute is used it can only point to a credential configuration supported from issuer and thius advertized in its metadata. It cannot be used to request arbitrary credentials outside credential_configurations_supported.

The format option was only recently re-added - see #217 and the related PR #219 for the background. The intention is that RAR can be used to request non-advertised credentials, as was possible in older drafts.

[paulbastian]

As I stated here I strongly support the idea of removing format again and this discussion is very valuable, pointing in the same direction.

[babisRoutis]

@paulbastian let me assure you, I didn't copy your comment 😄.
Jokes aside, it 's obvious that we agree.

@jogu Thanks for the insight.
If I understand correctly, format re-added to support:

• Out-band knowledge &
• Provide backward compatibility to earlier version of the spec.

For the out-band knowledge, I think wallet can grab issuer's meta-data and then, rather easily, locate the credential_configuration_id using format, doctype or any other criteria.
In this way, out-band knowledge can be minimized to the knowledge of issuer's id.

Given that draft 13 introduces, anyway, several breaking changes (totally justified IMO), it sounds somehow strange to keep a redundant feature just because this was the case in some older draft.

It seems to me like unnecessary complexity for both authorization_details & credential request.

[jogu]

For the out-band knowledge, I think wallet can grab issuer's meta-data and then, rather easily, locate the credential_configuration_id using format, doctype or any other criteria.
In this way, out-band knowledge can be minimized to the knowledge of issuer's id.

The point was that the issuer's metadata won't contain a relevant credential_configuration_id as in some cases the issuer's want to be able to not publicly disclose (in their public metadata) the types of credentials they issue.

[babisRoutis]

The point was that the issuer's metadata won't contain a relevant credential_configuration_id as in some cases the issuer's want to be able to not publicly disclose (in their public metadata) the types of credentials they issue.

Could never have imagined that!

Even in this case, why assume that wallet is aware of a format plus one of doctype/vct/types and not just a credential_configuration_id (which - for whatever reason - issuer doesn't disclose)?

[Sakurann]

labelling pending-close and closing in a week, unless objections, because we discussed this extensively especially in the context of this PR #392, and I beleive the outcome was consensus to keep both format and crededential_configuration_ids in authorization_details. I could imagine, It would be up to HAIP to mandate one over the other, if ever.

[paulbastian]

It seems to me that there is a clear majority in this issue that thinks otherwise?

[Sakurann]

i think the comments in this issue pre-date the decision that led to PR #392 we have discussed it extensively. and this issuer should have been closed when we merged #392.