Supporting hardware attestations in the credential request when cryptographic binding is being used

[Tobias Looker]

Some credential types that are issued by providers that are making use of cryptographic holder binding MAY want to understand the nature under which the keys are secured by the holder which could involve the usage of an HSM or secure element to meet these assurances. To facilitate this some HSM’s or secure elements support schemes whereby an attestation can be generated (either directly or indirectly) and shared to verify a particular key is hardware backed. We should consider how we can support supplying this information in a credential request so the issuer can verify it when needed.

[Tom Jones]

This is certainly interesting and something i have tried to interest the group in doing in the past. The major point to be made is that the hardware attestation is not the most important thing to consider. First you need to know if the wallet app is planning to use the hardware that is available. I remind the group about this proto-spec that was designed to do that. https://kantarainitiative.org/download/kantara-mobile-assurance-statement-html/

[Torsten Lodderstedt]

That’s an important topic we need to pursue.

Note: the DIF Wallet Security Working Group is working on this topic as well. Here is some information: https://hackmd.io/0vFZNmD7R-2NTJbiQ2e3sA?view

I think the issuer also needs to share metadata with the wallet to announce its requirements.

[David W Chadwick]

WebAuthn (FIDO2) already standardises the challenge response tokens that can be carried in any protocol. So I suggest that we simply adopt the FIDO tokens and find an appropriate place in an OIDC protocol to place them

[Torsten Lodderstedt]

In my perception, WebAuthn has two pieces: 1) user authentication (be way of establishing trust in a key and proof possession of the corresponding private key) and 2) authenticator attestation (what company, what product, model, batch, …). We are looking for (2) only here. Is it possible to utilize that part of the protocol separately?

[David W Chadwick]

Authenticator attestation is an optional feature of FIDO2. So the wallet can provide no attestations, self-asserted attestations, manufacturer provided attestations, CA provided attestations and DAA attestations to accompany proof of possession of the private key. I dont know if attestations on their own can be provided.

BTW as part of the eSSID DOOR project we are adding DAA attestations to our Android app

[Tobias Looker]

I think the issuer also needs to share metadata with the wallet to announce its requirements.

+1 I think this should be elaborated on as a part of the holder binding options the issuer advertises support for

WebAuthn (FIDO2) already standardises the challenge response tokens that can be carried in any protocol. So I suggest that we simply adopt the FIDO tokens and find an appropriate place in an OIDC protocol to place them

Could you provide some links to this? I would be wary of constraining the attestation format to one kind there are numerous efforts going on around attestation formats.

We are looking for (2) only here. Is it possible to utilize that part of the protocol separately?

Just to be clear im not advocating for just sharing an attestation, instead sharing an attestation alongside the key material and PoP it is attesting to. There is no point sharing an attestation with an issuer if it does not relate to key material you are requesting a credential be bound to.

BTW as part of the eSSID DOOR project we are adding DAA attestations to our Android app

Can you share details on this? What format is this attestation?

‌

[Jeremie Miller]

Is this different than the intended use of the proof value in PR #136?

[Tobias Looker]

To me the proof value is primarily about proving you possess the associated private or secret cryptographic material associated to the key material you are supplying, not proof of the nature of how the key is stored or accessed (e.g via an HSM)

[Jeremie Miller]

While the cryptographic contents will be different between the two, an attestation vs. PoP, the result of applying a policy decision to the proof value is not.

An HSM attesting that it is managing a key is still a proof that can be verified showing active possession of that key.

Evaluating wether an HSM is required is indeed a different usage and I don’t consider that in scope for this context either.

[Tom Jones]

right - requirements belong in policy - i am working on that in Linux Foundation and in Kantara - here is one use case that discusses policy. (There are others near this one).

https://kantarainitiative.org/confluence/display/PEMCP/Credential+Policy+Coordination

‌

[Kristina Yasuda]

2022-Mar-17 SIOP call Agreed for the need of this kind of attestations, need a more concrete PR to discuss further.

[Torsten Lodderstedt]

I created PR #157 with security considerations and proposed extensions for the credential request.

[Kristina Yasuda]

Can this be considered resolved with PR#157 that we merged? @Tobias Looker

[Tobias Looker]

yes thanks

[Tobias Looker]

Resolved as per #157