Is this object also used for proof type "attestation"? If so, this statement should be conditional.

I think you are correct. @c2bo did you add this text?

This is from from your initial commit, but it seems I forgot to change it when introducing the second proof type. We should move this into the jwt proof type text imho.

Editors Call:

• Mike says key_type is kind of used in JWK land, try to rename

Given that the description of metadata here: https://github.com/openid/OpenID4VCI/pull/389/files#diff-1f424614b35a9899813079f1b1f6218631a2aedd993368ccb89bb81a9eda0289R1308 says

If the Credential Issuer does not expect a key attestation, this object is absent.

Is this sentence here valid

A Credential Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism.

It reads to me that a Credential Issuer can decide to require attestations but not put it in the metadata, but maybe that is the goal.

Do you mean SHOULD -> MAY ?

Justto clarify key attestations are completly optional, but if an Issuer wants them, the typical way in OAuth is to include the needs in the metadata, therefore we added such entries to the Credential Issuer metadata

Do you mean SHOULD -> MAY ?

I am not qualified to have this conversations. :) I will try to explain In layman's terms the way I read this

The issuer medatada section says:

If the Credential Issuer does not expect a key attestation, this object is absent.

So my expectation here would be that if I read the metadata, don't find this object, i don't send an attestation as it is not required/expected -- but I think my expectation would be wrong because there is this sentence:

A Credential Issuer SHOULD communicate this requirement to evaluate key attestations through its metadata or using some sort of out-of-band mechanism.

This one reads, for me at least, like "Issuer may choose to require the attestation but the exact way this requirement is communicated is not enforced" i.e. if I go to metadata and see that there is no key_attestations_required it could just mean that this expectation/requirement is defined elsewhere (other metadata, or using the mentioned out-of-band mechanisms like policy or interop profile).

I would potentially just remove the sentence I mentioned above from the issuer metadata section and add a link to the attestation section where one can read that this object can be used to advertise attestation requirement but that the usage of this filed is not mandated for such a purpose and that one needs to consult the issuer's/ecosystem's documentation on whether the wallet must include it or not. Or maybe even not add a link.

Stupid comment, but this kid is a bit confusing for me here in this form, is this referring to a particular key from the attestation or is it just a random value for the sake of the example?

This jwt would be signed by the Wallet Backend or the key storage directly - it cannot be referring to a key from the attestation. But it might make sense to change it to x5c for the example to avoid confusion?

Would just point out this thing if it makes sense.

https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-8.2-2.3.1 says:

Object providing a single proof of possession of the cryptographic key material to which the issued Credential instance will be bound to...

Not sure if this will be in conflict because now credentials are not then bound to the key doing the proof or possession

Good catch! We probably need to adapt those lines describing proofs and proof a bit. We still get a proof that the wallet is in possession of the key(s), it just doesn't have to be a proof of possession.

Is there a requirement that the key doing the signing of the proof must be an attested key from the set of attested_keys, and is that what the "kid" is used below in the example?

I am having trouble finding where this is defined.

kind of a copy comment of: https://github.com/openid/OpenID4VCI/pull/389/files#r1811469557

Are the methods defined in user_authentication evaluated as OR or AND? If they are OR, then how would you encode MFA?

It was meant as logical OR, does this text fit better or do you have better words?

to clarify: the key given from key_storage_type forms the possession factor. So whatever is in user_authentication already creates MFA. If you want 3FA, then we would need to create a user_authentication value like pin_and_biometry

I'm not sure if this would meet NIST 2FA requirements for all listed cases since both factors have to be independent, i.e., especially not sure if the key is stored by the app and the device biometrics to unlock the same app are used would meet the 2FA requirement.

However, I'm fine with the suggested text to resolve this issue.

Wouldn't it make sense to allow to convey the key attestations also in the in the Pushed Authorization and/or Token Request, i.e., using OAuth2 attestation-based client authentication? This way, the AS could also make a decision if they want to issue an access/refresh token to the wallet? Or is this mechanism out of scope of OID4VCI while still being possible because an AS can use the OAuth2 client authentication extension mechanism to support this use case anyways?

If it is out of scope, perhaps adding a note would still make sense?

I would say in an ideal world, key attestations would be its own draft and could be applied to OpenID4VCI credential request and attestation-based client authentication. If you would want it for access/refresh tokens, it would only require to add attestation claim to the DPoP proof, which I also proposed (see checklist in PR description).

Should OID4VCI also say something about how these key attestations might relate to encryption? We had the discussion in the past that the encryption is not adding a lot on top of TLS because the wallet keys are not trusted necessarily. If the key attestations would also contain keys the wallet provides for encryption, wouldn't this solve this specific problem we had with encryption?

I like the idea in general, but I think the keys from the wallet attestation (attestation-based client authenticaiton) may be a better fit, as the wallet attestation generates trust in who the wallet is, key attestation only says this is some valid key from hardware

Wallet attestations are currently defined in HAIP. Probably a separate issue, but would it make sense to create an issue to add a note to the spec to explain how wallet attestation and encryption can relate to each other?

Following the discussion, would this be acceptable for everyone?

This jwt would be signed by the Wallet Backend or the key storage directly - it cannot be referring to a key from the attestation. But it might make sense to change it to x5c for the example to avoid confusion?