Add parameter for required LoA to Authorization Server Metadata

[paulbastian]

Within the eIDAS ecosystem, Wallet attestations are being discussed. One of the proposed mechanisms how to prove the authenticity of a Wallet and potential hardware keys is Attestation-Based Client Authentication.

The usual pattern in OpenID4VCI is that the Issuer declares his supported features in the metadata and the Wallet compares this with its own capabilities, makes its choices and sends the appropriate requests, e.g.

• the Wallet will compare supported formats and send the according format/credential_configuration_identifier
• the Wallet will compare supported proof_types and send the according proof_type

Applying this concept to Wallet attestations and the regulatory requirements of the Issuer (e.g. I need level of assurance high in the eIDAS trust ecosystem) the Wallet will select a specific key store type (e.g. software keys, Strongbox, a cloud-hsm or my pluggable yubikey). If the Wallet has multiple options to cryptographically bind a credential (which seemss likely to me) then the best practice is:

1. the Wallet reads the Issuer's requirements
2. the Wallet compares this with its own capabilities
3. the Wallet selects a cryptographic device and produces a Wallet Attestation for this device
4. the Issuer validates that the Wallet Attestation, the referenced trust ecosystem and the included LoA matches his requirements (probably checking this against some sort of trust list)
5. the Issuer binds the credential to a key contained in the Wallet Attestation

Alternatively, the Wallet would need to send all potential Wallet Attestations to the Issuer and he would chose one of them. This seems very inefficient and may be not privacy-preserving.

I propose to add Issuer metadata that contains the regulatory requirements of the Issuer. The contents of this parameter may change depending on the trust ecosystem. Before proposing concrete examples, I want to start the discussion here.

Some questions remain:

• Does this belong to the Authorization Server or the Credential Issuer? (Imo this belongs to the Authorization Server)
• Allowing these concepts that evolve in eIDAS will likely make it complicated to completely decouple AS and Credential Issuer, the AS may need to communicate the approved keys to the Credential Issuer, e.g. inside the access token or in a backchannel as the authenticity of the Wallet and the key proofing is closely coupled.

Anyway I think it makes sense to continue the existing pattern and let the Issuer communicate his needs and offers.

Happy for feedback!

[peppelinux]

This makes sense.

Does this belong to the Authorization Server or the Credential Issuer? (Imo this belongs to the Authorization Server)

I think that the LoA is related and required to the authentication of the subject at the authorization endpoint (user) and to the token endpoint for the authentication and reliability assessment of the client (wallet instance). Credential endpoint is an RS, I don't see any LoA there. Did I miss something?

make it complicated to completely decouple AS and Credential Issuer, the AS may need to communicate the approved keys to the Credential Issuer

anyway the decouple of AS and RS is needed because these are different things. That's OAuth 2.0.

[peppelinux]

otherwise, if we want to merge VCI and AS/OP, well, the credential should be provided in the form of token in the token endpoint response

even a vp_token :-)

multiple tokens could be provided ... also in this way.

but it seems to me that things have now gone too far with the current openid4vci specs such that we wouldn't have to go back to the basic components again, if we agreed.

[Sakurann]

required level of assurance is different for each credential configuration, correct? if so, it sounds natural to add trust framework related parameters in the credential_configuration_supported map. this would probably simplify wallet's processing, since as you describe above, wallet already makes a lot of decisions based on the parameters in the credential_configuration_supported map such as proof_types, format, etc.

regarding AS and Credential issuer, the metadata of each has to be hosted at different .well-known path, but that does not mean VCI mandates "decoupling". it is totally valid to use the same server as AS and Issuer and host each metadata under example.com/.well-known/oauth-authorization-server and example.com/.well-known/openid-credential-issuer.

[paulbastian]

Yes, the LoA should probably be attributed to a specific credential, that means it should probably go to credential configuration

[tlodderstedt]

Is the requirement more related to the wallet or the key the credential shall be bound to? I’m asking since this is the separation between AS (wallet authentication and authorization) and Issuer (Credential Issuance). Am 18. Jan. 2024, 22:49 +0100 schrieb Paul Bastian @.***>:

Yes, the LoA should probably be attributed to a specific credential, that means it should probably go to credential configuration — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>