Whats the capability negotiation model assumed between the relying party (RP) / origin and the wallet / provider?

[tplooker]

When it comes to requesting presentation of a digital credential from a wallet, one of the pre-requisites to enable a successful transaction is that the two parties in the protocol, the RP and wallet are in fact capable of transacting. A couple of examples of such capabilities I mean in this context are:

• Credential formats
• Cryptographic algorithms whether they be signatures, authentication modes (like with 18013-5 having MAC and DSA) or content encryption ciphers

Protocols like OpenID4VP have an approach which may be suitable for usage with this API or a more efficient model might be possible through the existence of a browser API and the browser facilitating some part in this negotiation. I think this issue is important to discuss nearer term as it affects what the browser needs to be aware of from a protocol perspective vs what it doesn't.

[OR13]

I agree, but I will refine this a bit further to highlight some details:

credential formats

• serialization of the envelop (jose, cose, jwt, cwt, sd-jwt, sd-cwt, etc)
• serialization of the claims (jose, cose, jwt, cwt, sd-jwt, sd-cwt, etc)
• format requirements (nonce, attestation, certificate chains)
• dynamic state (CRLs, OCSP, status list )
• format algorithms (ECDSA, EdDSA, ML-DSA, SLH-DSA, RSA, etc)

presentation formats

• serialization of the envelop (jose, cose, jwt, cwt, sd-jwt, sd-cwt, etc)
• serialization of the claims (jose, cose, jwt, cwt, sd-jwt, sd-cwt, etc)
• format requirements (nonce, attestation, certificate chains)
• dynamic state (CRLs, OCSP, status list )
• format algorithms (ECDSA, EdDSA, ML-DSA, SLH-DSA, RSA, etc)

As you can see, the total number of combinations leads to a high probability of little to no interoperability without restriction.

I would like to make a strong statement, "presentation formats" are "protocols in disguise".

There should be no support for negotiating "presentation formats".

So what is essential for preparing a credential for delivery to a verifier?

• Trust in the verifier (identity & reputation information)
• Confidential delivery to the verifier (message and transport level encryption, possibly with transport layer unlinkability like Tor or OHAI)
• Replay resistance (nonce freshness / interactivity)
• Trust in the wallet (identity & reputation information)

Attestation, Evidence and Endorsements (as described in https://datatracker.ietf.org/wg/rats/about/) help with the Trust sandwich.

HPKE helps with the confidentiality at the message and transport layer.

OHAI or Tor, are probably not needed when the browser is the primary trusted middleman, but perhaps we do not trust the browser to make connections (in which case your comment on the last call needs to be revisited)...

The network related properties of OIDC are also possibly leaking information which we would prefer to not leak.

Replay resistance, requires interactivity, and leads to the timeout UX - webauthn-2/#dom-publickeycredentialrequestoptions-timeout) we see in other parts of the browser crypto APIs.

So I see the fundamental interaction as follows:

Requesting a single credential from a wallet

{
"verifier_identity": (only standard token or certificate formats please)
"verifier_reputation": (with integrity protection please)
"verifier_encryption_key": ... (only standard key formats please, restricted to a single algorithm please)
"acceptable_credential_formats: [ mdoc, sd-jwt, etc...],
"globally_unique_claim_names": { ... },
"nonce": webauthn-2/#sctn-cryptographic-challenges,
}

Presenting a single credential to a verifier

{
"verifier_endpoint": (only WHATWG URLs?)
"wallet_ciphertext": (opaque bytes)
}

In the case that a wallet needs to prove properties related to its "identity and reputation", those proofs need to go inside the ciphertext.... which is also where the wallet can put more than one credential, and the browser has no way to stop that.

[npdoty]

Enumeration of wallets or wallet capabilities is a serious privacy risk -- it would certainly be abused for fingerprinting, but even more so, it would be abused to learn perhaps what affiliations the user has with different jurisdictions.

(I think this is well-understood and discussed on today's call, but just thought it should be noted here in the issue.)

[timcappalli]

Discussed on the 2024-02-26 call

Raw notes: https://github.com/WICG/digital-identities/wiki/2024-02-26-Meeting-Notes#issue-76-whats-the-capability-negotiation-model-assumed-between-the-relying-party-rp--origin-and-the-wallet--provider

AI generated summary:

Manu raises the question of how the verifier can trust digital signatures, suggesting possibilities such as metadata discovery between the wallet and provider or wallet credentials. Lee argues that this is a different issue than verifying the wallet itself and that it's up to the issuer to ensure that only capable wallets can honor requests.

Nick brings up privacy concerns with capability negotiation and suggests that silent APIs or wallet broadcasting capabilities are both bad ideas. John proposes mechanisms for verifiers to send enough information to the matcher without learning anything about the wallet before the user consents. Lee suggests asking for credentials directly and only learning about capabilities if the user consents. Hicham agrees that understanding what information the reader wants from wallets is important, and Manu expresses opposition to a centralized credential registry. John emphasizes that security is one property of the credential, and additional constraints from the verifier can lead to interoperability issues.