remove any mandatory requirements for key attestations

[jogu]

There are situations where it makes sense for the issuer to directly consume a (for example) iOS / Android platform attestation rather than requiring a backend as per OAuth 2.0 Attestation-Based Client Authentication. We should allow this in HAIP.

[jogu]

Not sure but I suspect this actually might need to be in VCI as it sounds like a protocol change/addition rather than just profiling.

[Sakurann]

@martijnharing can you please elaborate on "situations where it makes sense for the issuer to directly consume a (for example) iOS / Android platform attestation" since i think Joseph opened this issue on behalf.

[TimoGlastra]

I thought the whole reason to avoid doing this, is so that issuers won't have to deal with the platform specific attestation formats.

I could see why not requiring a backend for the wallet may be nice, but i think it can hinder interoperability so it should be really clear when the different attestation formats should be used/supported.

And wouldn't it be fair to say wallets participating in HAIP are assumed to have a wallet backend? (i would be more open adding this to oid4vci over haip)

Until now HAIP has been generally interoperable, but by adding this you are basically required to create options (native or oauth wallet attestations) or require issuers to support both but that would also not make sense. So then you're back at a specific ecosystem defining which method to use and we lose the value of HAIP.

[martijnharing]

Some examples where you may want to consume attestations directly:

• If there is no wallet provider used in the flow.
• If the issuer needs to directly verify the attestation coming from the key-storage location.
• If the wallet provider does not want to see any keys for privacy reasons.
• If attestation formats cannot (easily) be changed because of security / certification requirements for attestation formats.

There isn’t at this point a format that all security hardware in the relevant ecosystems support. Until that is the case, HAIP can’t have a mandatory requirement to support a certain key attestation format. Even if a format is specified it would take considerable time to have it adopted widely.

[jogu]

@TimoGlastra That was the point, and there are trade offs here and I'm not sure where the line lies.

There are definitely privacy advantages to avoiding a call to the wallet backend.

I don't think there's currently anything else in HAIP that really assumes there is a wallet backend (but please correct me if I'm wrong!).

[paulbastian]

This is mixing up client authentication and key attestation. I'm not supportive of this for wallet attestation/client authentication, as only the backend can really verify the authenticity of the wallet with the current technology that we have.

For key attestation, this may be different and I'm supportive to look for key attestations that can be issued by the WSCD itself.

[martijnharing]

The previous comment also applies to applications that are authenticating. Also for client authentication we run into the same issues if we mandate a particular format. The endpoint of the client that the issuer is interacting with can be implemented in a variety of ways, for example as a secure element, TEE, application etc. These can have existing attestation formats and we need to support those for the scenarios where there is no wallet provider, or when there are security or privacy benefits for not having the wallet backend recreate the attestation. (see previous comment for examples)