New Key Attestation proof type for local authentication policies without requiring a wallet backend

Problem statement

The core problem is preventing key injection attacks without a wallet backend for key attestations, while supporting keys protected by local authentication policies (e.g. biometrics) without degrading UX.

Relying on a wallet backend is problematic for at least two reasons:

• it would introduce additional roundtrips, which are undesirable, and
• it may not be feasible to distribute the wallet backend keys needed to verify key attestations based on the existing attestation proof type.

At the same time, there is a need to convey credential-bound keys to the Credential Endpoint without requiring proof-of-possession (PoP). In practice, these keys may be protected by a strict local authentication policy, such as biometrics on iOS or Android, and therefore cannot be used directly to sign the PoP without sacrificing UX. As a result, the existing jwt proof type is not suitable either.

This leaves a gap: the Credential Endpoint needs to receive the credential-bound keys securely, but in many cases, the available proof types do not provide a practical way to do so.

Proposal

A viable solution appears to be a new key attestation proof type that allows the credential-bound keys to be conveyed in a signed JWT, while using the DPoP key to provide the necessary cryptographic binding.

The DPoP key is already trusted within the OAuth layer. If it is used to sign the key attestation JWT, this creates a strong cryptographic linkage between the OAuth session and the keys included in the attestation. In turn, this mitigates key injection attacks without requiring additional infrastructure such as a wallet backend.

For this reason, I propose introducing a new key attestation proof type in which the attestation JWT is signed with the DPoP key rather than a wallet backend key.

Benefits

This would allow wallets to use securely stored keys managed under strict local authentication policies at the Credential Endpoint without degrading the user experience, while still maintaining the necessary security guarantees.

Format

The new Key Attestation type would be equivalent to the existing Key Attestation format defined in D.1 Key Attestation, but would use a different typ header value, for example:

key-attestation-dpop

The processing logic would remain the same as defined in D.1, with the additional requirement that the Key Attestation is verified using the DPoP key.

@leecam @GarethCOliver @tplooker @c2bo

Read D.1 Key Attestation and the existing attestation and jwt proof-type processing; identify the Credential Endpoint and OAuth/DPoP validation entry points mentioned by the issue. Done means an agreed key-attestation-dpop format and processing path that binds the attestation to the DPoP key without a wallet backend.