Should it be possible to have offers that are usable by a wallet without resorting to information in the metadata's `credentials_supported`

[pmhsfelix]

I'm creating this issue based on a question that we had on the 2023-09-29 DCP meeting (https://lists.openid.net/pipermail/openid-specs-ab/2023-September/010092.html).

Should it be possible to have offers that do not require any information from the metadata's credentials_supported, i.e., offers that contain all the information required for the wallet to do an authorization request + token request + credential request without needing to map the offer into one of the metadata's credential_supported entry?

The use case would be to create one-of/dynamic offers that don't map into any of the statically defined metadata entries.

This question is similar/identical to the one in #77, however the discussion there seems to have gone to a slightly different subject, which is how to map and offer into a credential_supported entry.

Notes:

• The issuer metadata would still be needed to discover the credential endpoint and the authorization server ID. However no data from the credentials_supported array would be needed by a wallet to obtain a credential from an offer.
• In order for an offer to be usable without anything from the metadata's supported_credential, the offer would need to include fields such as cryptographic_binding_methods_supported, cryptographic_suites_supported, display, as well as format specific fields such as credentialSubject and order. For instance, this would allow for dynamic credentialSubject objects tailored to each specific offer.

If the answer is to this issue question is yes, then we probably have other things to discuss however that probably should be the subject of a different issue.

[Sakurann]

The use case would be to create one-of/dynamic offers that don't map into any of the statically defined metadata entries.

Why is this necessary? what are your concerns? is it the ability to dynamically generate metadata entries? Or is it the wallet making an error when trying to obtain a correct crednetials_supported object after fetching an entire issuer metadata.

I think both could be mitigated by for example putting identifier in the offer instead of scope and enabling an option of the wallet passing identifier as a query ?c_identifier=xxx when fetching the issuer metadata so that the issuer can return only relevant parts.

It might be ok to have inline metadata as an option, but it does not make sense to me to pass metadata entry as a value that is also being hosted. Do you agree with the proposal I made in two bullet points in #77 (comment) ? (I do think we should continue this discussion in #77...)

[Sakurann]

agreed at pre-IIW DCP WG:

• no inline metadata
• identifier in the offer is an identifier - it is the used to reference either an entry in the issuer metadata, or a separate private file if pre-agreed btw the wallet and the issuer (because there is no obligation in OAuth/OIDC to publish all the credentials supported in the metadata, can be in a private namespace)
• Credential type identifier vs credential instance identifier are different things
• no credential instance identifier in the credential offer; because wallet does not need information on instance identifiers for user consent at that stage of the protocol
• current PR 65 is sufficient for credential instance identifiers - returning it from the token endpoint.

https://docs.google.com/document/d/1q_vcI7PGJLtM3j0jvpLfmiBsj69jCilTzDQCjKRT2xY/edit

[nikosft]

What @pmhsfelix says makes absolute sense. IMHO credentials_supported metadata should be avoided for two reasons:

• It is public information and creates privacy and security risks for issuers
• Metadata file may become very big, complex, and hard to process

I think that the best option is either to put all required information in the credential offer, or if it does not fit (e.g., when credential offer is displayed as a QR code), to use credential_offer_uri.

So instead of putting a string in credential[] that matches with c_identifier value in the credentials_supported metadata entry as @Sakurann says here it is better to use that string as a query parameter in the URL included in credential_offer_uri and let the issuer do its magic.

[peppelinux]

I don't think so, the metadata provided with the well-known endpoint represent one of the best way to allow a credential issuance discovery based on public data (one of the few traces of the decentralization paradigm, which became a lever for adoption and forgotten immediately afterwards).

Metadata are json, easy to be processed. Then instead of inflating a single metadata, probably it would be better to scale multiple credential types to multiple nodes (AS/RS) and then having specialized metadata for specialized entities with credentials.

In the same way, the credential offer endpoint would disclose the credential available, giving the same disclosure of information but with more computational costs. @nikosft do you protect that endpoint with some kind of client authentication (such as with oauth attestation based client auth)? Probably not, then the information disclosure is equivalent than the metadata.

Or did I miss something? Sorry if any.

[Sakurann]

It is public information and creates privacy and security risks for issuers

Does it? I would assume that it should be an easily discoverable knowledge which credentials the issuer is capable of issuing because it verifier trusting the issuer of the credential it receives is at the core of the three party model’s trust.
Credential offer is not signed and cannot be trusted which is another reason why putting part of the metadata by value there should be avoided.

Metadata file may become very big, complex, and hard to process

Agreed. That’s why I really think shifting the burden of returning part of the metadata to the issuer should be enabled.

@peppelinux what is the credential offer endpoint that you mention? Approaches to retrieve part of the metadata described here and #42 do not require a new endpoint by the issuer, it would be the same endpoint with a query attached: “issuer.com/.well-known/openid-credential-issuer/
?credentials_supported_identifier=123”

[nikosft]

Does it? I would assume that it should be an easily discoverable knowledge which credentials the issuer is capable of issuing because it verifier trusting the issuer of the credential it receives is at the core of the three party model’s trust.

I assume metadata endpoint is not protected and I can imagine attackers searching in .well known directory as part of a reconnaissance. Current draft allows too much information to be included in metadata file.

Credential offer is not signed and cannot be trusted which is another reason why putting part of the metadata by value there should be avoided.

Credential offer found in credential_offer_uri is singed. IMHO this should be the preferred way of offering credentials.

Agreed. That’s why I really think shifting the burden of returning part of the metadata to the issuer should be enabled.

That would require defining yet another API.

[Sakurann]

I assume metadata endpoint is not protected and I can imagine attackers searching in .well known directory as part of a reconnaissance. Current draft allows too much information to be included in metadata file.

what information in current metadata is "too much" and concerns you?

Credential offer found in credential_offer_uri is singed. IMHO this should be the preferred way of offering credentials.

Currently it is not signed. And I would be reluctant to enable this option because of key discovery and trust establishment in this key adds complexity that I think can be avoided.

That would require defining yet another API.

How is wallet sending issuer.com/.well-known/openid-credential-issuer/?credentials_supported_identifier=123 a new API?

[nikosft]

what information in current metadata is "too much" and concerns you?

Even the supported VC types. Imagine that you will be able to Google for "URLs that issue UniversityDegreeCredential" or any other type of high value credentials

Currently it is not signed. And I would be reluctant to enable this option because of key discovery and trust establishment in this key adds complexity that I think can be avoided.

I mean it is received over HTTPs directly from the origin server. It is as protected as metadata.

How is wallet sending issuer.com/.well-known/openid-credential-issuer/?credentials_supported_identifier=123 a new API?

It makes things complicated for the issuer. Currently, metadata is usually a statically hosted .json file. Suddenly the issuer should be able to parse it based on the provided credentials_supported_identifier . Then, definitely the appetite for new query parameters will increase (e.g., #42 provides examples for credentials_supported and Accept-Language).

[Sakurann]

Even the supported VC types. Imagine that you will be able to Google for "URLs that issue UniversityDegreeCredential" or any other type of high value credentials

You can make your issuer metadata private and available only within your closed ecosystem - VCI does not prevent that. thought IMO the whole point of metadata is being public and discoverable. you can already google URLs that issue ID Tokens. but we don't necessarily need to agree on that :)

It makes things complicated for the issuer.

It does. but why would it be better to put this complexity into the wallet's hands? that sounds more error prone to me.

Is there any change to the specification that you are requesting? given that VCI does not prevent metadata to be private if you want to? The Credential Issuer's configuration can be retrieved using the Credential Issuer Identifier.

[nikosft]

you can already google URLs that issue ID Tokens

The security risks are not equivalent. A DrivingLicenceCeredential may allow you to drive and an EmploymentCredential may allow you to receive a green card. ID Tokens include an audience whereas VCs can be used anywhere. ID tokens are tranmitted directly from the IdP to the RP, whereas VCs are stored in the user's wallet. IMHO the moment a type of credential receives some legal validity, attackers will start searching for vulnerable endpoints and VCI currently facilitates them.

It does. but why would it be better to put this complexity into the wallet's hands? that sounds more error prone to me.

It is complex if you rely on metadata for receiving a VC. If you include all necessary information in the credential_offer (as the first message of this issue suggests) the wallet should be able to retrieve a VC without relying on metadata. Therefore, metadata become simpler, more secure, and there is no complexity to the wallet.

Is there any change to the specification that you are requesting?

All in all, I don't care for metadata being private, I do care however for the "wallet to be able to retrieve a VC without resorting to information in the metadata's credentials_supported" (as the title of this issue and the first message suggest). If it was on me to change something in the specifications would be the following:

• require credential_offer to be self-contained, as this issue and Inline credential offer lacks required metadata #77 suggest, i.e., put all information of credentials_supported metadata (related to the specific credential) into the credential_offer
• If you want to offer credential using a QR code the preferred method should be: store the (self-contained) credential_offer at an endpoint of the issuer (protected using HTTPS), and encode credential_offer_uri in the QR code.
• Warn in the Security Considerations section about the potential risks of credentials_supported metadata