Support for FIDO (Web Authn)

[David W Chadwick]

Wallets may establish FIDO connections with issuers so that they can strongly authenticate to the issuers with their hardware stored keys each time they connect to the issuers to manage their credentials (e.g. to revoke, suspend, delete or refresh them). The issuing process should allow for a FIDO connection to be established between the issuer and wallet during the wallet registration process.

[Tobias Looker]

I can think of two ways in which FIDO keys may be involved in a credential issuance flow

1. As the keys used to bind the resulting issued credential to
2. As a means to authenticate the end user during the OpenID transaction

For point 1, I think this can be easily accommodated by supporting a model where the hardware attestation (e.g a FIDO style attestation) can be included in the credential request made to the credential endpoint.

For point 2, which authentication methods a provider uses to authenticate the end user is out of scope for this specification as is the case for OpenID and OAuth, there is however nothing stopping a provider from using this method.

Im unsure what you mean exactly by a FIDO connection? What value would this provide above what I’ve highlighted and how does it fit in with the OpenID OAuth model?

[Jeremie Miller]

1. This isn’t a document usage pattern for FIDO, it would have to be invented and definitely falls outside of the typical flows. WebAuthn isn’t directly usable here either as it is entirely browser driven/based.
2. Agree this is out of scope, 4VCI is defining the use of OIDC. Using FIDO for issuance would look similar from a high level, but this isn’t the right place for it. Again, WebAuthn would only help if the issuance was entirely browser based.

‌

[Tobias Looker]

This isn’t a document usage pattern for FIDO, it would have to be invented and definitely falls outside of the typical flows. WebAuthn isn’t directly usable here either as it is entirely browser driven/based.

Agreed, I’ve opened https://bitbucket.org/openid/connect/issues/1461/supporting-hardware-attestations-in-the to have a more general conversation around this topic.

‌

[David W Chadwick]

@jeremie. FIDO does not have to be browser based. The FIDO standard defines the tokens which any protocol can carry to authenticate the client (wallet app) to the RP (Issuer). So we could include these in OIDC (cf we have already included VP tokens)

[David W Chadwick]

@Tobias. FIDO can be used as you suggest, but in fact the same FIDO key can be used for both in the model where the wallet is in the middle between the human user and the issuer.

[Tobias Looker]

@Tobias. FIDO can be used as you suggest, but in fact the same FIDO key can be used for both in the model where the wallet is in the middle between the human user and the issuer.

I think the main point here is that this model is fundamentally different to OIDC OAuth and hence would be difficult to map it or use in meaningfully in the in the OIDC4VCI protocol.

‌

[David Waite]

‌

The FIDO standard defines the tokens which any protocol can carry to authenticate the client (wallet app) to the RP (Issuer). 

Speaking to the first option;

I’m not sure what the FIDO standard eludes to, but I am only aware of efforts to define authentication in specific contexts (such as authentication to a secure web origin, or to OpenSSH servers)

Also, the client has no identity in WebAuthn; the authenticator does not know it is talking to Chrome, nor is there any integrity-protected evidence of that in the message to the RP.

The wallet app is not normally the client itself; instead there is underlying platform support allowing it to interact with authenticators. There are some platforms which do not restrict arbitrary applications from interacting with authenticators; others consider such direct access to CTAP authenticators to be a significant security concern, and lock such access down via entitlements.

[David Waite]

The platforms which restrict native application access behind entitlements typically do so by requiring two steps:

• at application publication time, you need to request entitlements for the specific origins you want to request credentials for
• at installation or runtime, the platform will check those origins for a well-known resource that says the application is allowed to request credentials for a domain.

These entitlement systems makes usage by wallets difficult to an issuer RP, as wallets are typically meant to be distinct from the issuer. Wallets would need to be provisioned by the issuer into their system, which creates logistical, political and scalability limitations to deployment.

There is also the risk that the platform may specify additional limits to prevent abuse, since WebAuthn is not supposed to be usable for cross-context tracking - such as allowing all apps claiming to be a wallet to correlate the user or letting such apps phish the user into getting authenticated access to the issuer.

A third-party browser may be able to get an entitlement to request credentials for all domains from a platform provider, but I do not know what their processes are for evaluating/approving such a request.

Your best bet would be to do non-discoverable registrations with just the wallet app as RP, and to share those public key credentials with the issuer - but at that point you are basically treating FIDO registrations as a carrying case for hardware attestations from the authenticator. Such attestations do not serve the same purpose as attestations of the wallet app and underlying platform.

[David W Chadwick]

@DW. This is not correct. You can publish wallets in iStore and PlayStore without specifying any origins. Our wallets are already publicly available. It is true that IdPs have to authorise our PlayStore wallet to connect to it via FIDO. This is a sensible security precaution and means that the IdP is not connecting to an unknown Playstore wallet which may have security vulnerabilities. Google fully documents how this is done, so it is something they allow for. Apple have much more stringent app validation procedures than Google, and so validate apps before you can publish them.

[David W Chadwick]

@DW. Concerning CTAP, currently we have judged this to be a security vulnerability and therefore do not allow it. The reason is that many USB based HSMs allow the device to be shared between users and there is no authentication of who the user is - they simply need to touch a button on the device. Therefore I could share my VCs with you by sharing my USB device with you (whilst still keeping my smartphone to myself). Until authentication of the user is fully supported, we suggest that only platform authenticators should be supported and the FIDO protocol allows the IdP to mandate this. Then I would have to give my smartphone to you for you to use my VCs. Even this is not foolproof, but there is a way to stop this as well using live biometric testing via the phone’s inbuilt camera. This is now available from a third party provider (as demonstrated to the ISO mDL group a month or so ago).

[David W Chadwick]

I think the main point is that FIDO is a standardised way of mandating hardware stored wallet keys. So if IdPs and RPs require this extra layer of security, then FIDO is a good solution for this. If however, IdPs and RPs are happy with software based keys and key sharing/backup (which some wallets do), then they have no requirement for the extra security provisions of FIDO.

[Kristina Yasuda]

What we discussed in the last SIOP call:

“David C. described how in their implementation user sets up a WebAuthn connection with the issuer using the wallet. Ie user uses WebAuthn to establish a key pair in on device A (the wallet), so that the Issuer can recognize device A later in the issuance flow and in subsequent interactions e.g. to revoke, refresh or delete the credential“.

I thought we finally had a pretty clear idea how to use WebAuthn in cross-device scenario..

‌

[Kristina Yasuda]

2022-Mar-17 SIOP call It was clarified that WebAuthn Credentials are tied to the origin and not the native application.

[David W Chadwick]

Tim also clarified in the call that what David C is suggesting is not the use of the web authentication protocol, but rather the use of FIDO2 challenge and response tokens passed in another protocol, in order to strongly authenticate the wallet app to the Issuer.

Thus it would be possible to pass these tokens in the OIDC4VCI protocol if the group chose to do so.

[David W Chadwick]

A proposal for how to pass FIDO2 tokens in OIDC4VCI is presented in issue 1542, so the current issue can now be closed

[Kristina Yasuda]

understood. thank you!