benefits of attestation based client auth draft seem to be overstated

[jogu]

https://github.com/openid/OpenID4VCI/blob/main/openid-4-verifiable-credential-issuance-1_0.md?plain=1#L1335 currently says:

Note: For the attacker to be able to present to the Verifier a Credential bound to a replayed Key Proof, the attacker also needs to obtain the victim's private key. To limit this, servers are RECOMMENDED to check how the Wallet protects the private keys, using mechanisms such as Key Based Client Authentication defined in [@I-D.looker-oauth-attestation-based-client-auth].

I don't think this draft provides any mechanism for the authorization server to check how the Wallet protects the private keys, so we should reword this or remove the reference to the draft.

[paulbastian]

The actual usage of attestation based client authentication how to do this is currently described in HAIP

[selfissued]

I also thought that "servers are RECOMMENDED to check how the Wallet protects the private keys" was somewhat odd, when reviewing the spec, since it's not clear that this recommendation is actionable. The security considerations text here also doesn't say what the Wallet might want to do if it can't obtain this information or if it doesn't like the answer.

[Sakurann]

I see Mike's point and we could change RECOMMENDED to simply say servers should consider checking or something to make it less binding. but the rest of the paragraph makes sense to me: if the issuer wants to make sure prevent replay of the credentials, it would want to know how the wallet stores the public keys and, sure, attestation draft is not the only way (and may not be the best one) to do so, but I think it is the one we wanted to rally implementations around because platform provided attestations had their limits too.

[jogu]

The important point here is that https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/ does not as far as I can see provide any general mechanism for an authorization server to check how a wallet is protecting private keys.

Within an ecosystem that has a clear trust framework, certification of wallets where a third party inspects the wallet source code, etc, then yes it could be used for the authorization to achieve some level of confidence in how the wallet stores private keys, but the draft by itself doesn't. The only thing the draft does is provide a generic mechanism for an authorization server to have some confidence that a particular request came from an installation of a wallet app that the developer of the wallet thinks is genuine. The authorization server is 100% reliant on that statement from the third party, it cannot use the draft to actually check how the key is stored.