Support for FIDO Authentication

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1542

Original Reporter: dwc8

Here is a proposal for how to include the use of FIDO authentication between the wallet and the issuer using existing open source FIDO2 code. It proposes an extension to OAuth by defining two new authorization grant types of FIDO Registration and FIDO Authentication.

1. The wallet (acting as RP/client) makes a request to the issuer’s authorization endpoint (authz server) using a new response type of FIDO Registration.
2. The authz server responds with a new token: the FIDO2 registration challenge, prepared using a standard FIDO2 server library (open source implementations of this exist), along with the FIDO UserID.
3. The wallet responds to the challenge by using a call to the FIDO2 client library already provided by Google on Android (and by a third party on iOS). This library creates a new FIDO key pair with the private key stored in the phone’s hardware and creates the response to the challenge. The user has to agree to this key being created and stored in the phone’s hardware by using the phone’s standard authn mechanism ie. faceid, fingerprint, PIN etc. The FIDO key pair is stored along with the FIDO UserID and Authz Server URL (to enforce SOP).
4. The wallet returns the FIDO2 response to the authz server’s token endpoint, and asks for an Access Token
5. The authz server validates the FIDO2 response token using the FIDO server, and stores the FIDO UserID of the wallet and its FIDO public key (to be used in subsequent authentication exchanges).
6. The authz server returns an Access Token to the wallet.
7. Flow continues as before, by the wallet using the Access Token to get the credential.

Subsequent connections between the wallet and issuer can be authenticated and secured using the FIDO private key stored in the wallet’s hardware.

1. The wallet makes a request to the authz server authorization endpoint using a new response type of FIDO Authentication, passing its FIDO UserID.
2. The authz server responds with a new token; the FIDO Authentication Request, created by the FIDO server especially for the wallet’s public key.
3. The wallet creates a response to this request by using a call to the FIDO2 client library. This library uses the existing FIDO key pair that is stored for this Authz Server (thereby enforcing SOP) and creates the response to the request. The user has to agree to the private key being used in the phone’s hardware by using the phone’s standard authn mechanism ie. faceid, fingerprint, PIN etc.
4. The wallet returns the Authentication Response to the Authz Server’s token endpoint
5. Upon validation of the Authentication Response the Authz Server returns an Access Token to the wallet.
6. Flow continues as before

The advantages of the above are:

i) Uses existing FIDO implementations (server and client)

ii) Stores wallet authentication keys in the wallet’s hardware removing any chance of the keys being stolen

iii) Enforces SOP between the wallet and issuer

iv) Can require the user to be present and authenticated by the phone in order to use the private key (dependent upon FIDO parameters)

v) Removes any need for the user to have a un/pw with the issuer

vi) Removes the need for the secure storage of Access Tokens and Refresh Tokens by the wallet as FIDO private keys provide the long term secure storage in the phone’s hardware.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I believe this proposal is in scope for FIDO, but out of scope for OpenID Foundation.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

It is not a FIDO issue, but an OIDF issue because we are specifying one way of using FIDO that will allow OIDC4VCI to leverage FIDO during the VC issuing process. We are not modifying FIDO nor suggesting any changes to FIDO.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

what are the changes you are suggesting to VCI?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

also is this issue duplicate of #1460

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Issue #1460 was background discussion that led to the current issue being published. Consequently 1460 can now be closed

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

what are the changes you are suggesting to VCI?

To have a way of including FIDO2 tokens in (one or more of) the OIDC4VCI flow(s) for the advantages described above. I also believe that it is a way of avoiding having a split wallet as described in PR#257

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwaite40

The wallet (acting as RP/client) makes a request to the issuer’s authorization endpoint (authz server) using a new response type of FIDO Registration.

Are you thinking of this as a new grant type, to be in parallel to code and implicit flow? A response type does not sound appropriate, as it is used to form an existing response to a particular ‘channel’ for returning data - e.g. a form post to a redirect endpoint, or encoded into query parameters to the same. Response modes aren’t normally used to indicate additional data being sent.

The authz server responds with a new token: the FIDO2 registration challenge, prepared using a standard FIDO2 server library (open source implementations of this exist), along with the FIDO UserID.

What would the RPID be for this? Both native and web-hosted wallets can only fulfill requests for their own domain (with web having a benefit of being able to use iframes or child windows, but that isn’t what I think you are describing here)

What sort of limitations do you see on this challenge? Requesting discoverable credentials or certain extensions can have a possibly negative effect on the relying party (e.g. the wallet domain)

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

@DW “Are you thinking of this as a new grant type, to be in parallel to code and implicit flow?"

Yes, because code is not appropriate as the authorization server is not an intermediary between the client and resource owner. In OIDC4VCI the resource owner is the credential issuer and not the user.

My reading of RFC6749 is that the client informs the authorization server of the desired grant type using the response_type parameter. Since a new grant type is being requested then a new response_type is needed isnt it? In this case the response is different because it contains the FIDO Registration Challenge token.

"What would the RPID be for this?"

This is the ID of the Authz Server, so that SOP can be enforced by the wallet. The wallet is the client.

The client/wallet is a confidential client (in OAuth2 terminology) because it can store its private keys in the phone’s hardware, to be released on the say-so of the phone’s user.

Does this answer all your questions?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwaite40

This is the ID of the Authz Server, so that SOP can be enforced by the wallet. The wallet is the client.

This will preclude support by many platforms, which expect an entitlement for an app (wallet) to be able to create or request credentials against a particular rpid. The entitlement to request for all domains may require a special arrangement or only be given in certain circumstances - for instance to a web browser.

The platforms expect by default that native apps will act as relying parties, not as clients.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

OIDC4VCI expects the authenticated client to request a credential to be issued to a freshly minted public key that can be presented to any RP. So after FIDO authentication between the client and OIDC4VCI issuer, an OIDC4VCI issuer will behave in exactly the same way.

The Android platform fully supports native apps to work as clients. The iOS platform also supports this (using third party FIDO software).

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: anders_rundgren

I’m all for reusing FIDO. However, OAuth is not the only possible target. For payments (my particular area of interest…), building on an enhanced EMV scheme seems like a better idea because it lends itself to wallets which OAuth (AFAICT…) does not. The SPC scheme recently launched by Google and the W3C does not make much sense to me:
https://github.com/mozilla/standards-positions/issues/570#issuecomment-972578433

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: anders_rundgren

I don’t fully understand how this proposal is supposed to be used on Web.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

It is designed to create a strong long term FIDO authentication key pair between the wallet and the issuer’s Oauth server. The OIDC4VCI model is that the wallet creates a fresh key pair for the issuer to bind to each new VC that it issues. The FIDO key pair can replace the OAuth refresh token which is a bearer token so not as strong. So after authentication using FIDO, the wallet will get a short lived access token to send to the issuer along with a new key pair for the VC. In this way all the user has to do in order to get a fresh VC is swipe their finger on their smartphone, or use face-id etc. and a new VC will be provided to the wallet.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: gffletch

One concern I have is that we are defining authentication and registration semantics around the token endpoint which historically have been out-of-scope for OAuth. I’d prefer these authentication mechanisms be implemented on a separate endpoint. I do get the similarity to either ROPC or client_credentials flow though in neither of those cases is there a “dynamic” “registration” event.

[MonkeyRDluffy]

I have a concern about ISO18013-5. As far as i know, FIDO format signature is incompatible with authentication process within ISO18013-5. The cause is the application does not have a full control over the signature input ( 5 Generating a signature of https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-signature-format-v2.0-ps-20150904.html) Also, OpenID4VCI should be able to support ISO18013. How can a VCI server knowns the cryptographic capabilities of the future public key.

[Sakurann]

closing in a week. Might reopen if there will be a strong demand for this feature from multiple implementers.

[Sakurann]

Also, OpenID4VCI should be able to support ISO18013. How can a VCI server knowns the cryptographic capabilities of the future public key.

@MonkeyRDluffy VCI supports mdocs, please take a look at cwt proof section. https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-7.2.1.3