[Openid-specs-ab] Issue #1542: Support for FIDO Authentication (openid/connect)

[David Chadwick]

New issue 1542: Support for FIDO Authentication
https://bitbucket.org/openid/connect/issues/1542/support-for-fido-authentication

David Chadwick:

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 token 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 token 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
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.