Re: [GNAP] Support of FIDO

[David Waite <[e-mail]>]

> On Aug 19, 2020, at 02:37, Denis <[e-mail]> wrote:
>> U2F devices do not typically store private keys per site, but instead rely on a “credential handle” presented by the RP which contains an encrypted form of the key or keying material used to reserve the key. Some CTAP2 implementations do store private keys even in U2F compatibility mode, but these still require presentation of a credential handle. 
>> 
>> So authentication either can use a CTAP2 authentication with a previously created credential that is resident/discoverable, or you perform some initial user authentication to determine which credential handles are appropriate to challenge a U2F authenticator with
> Such implementations details are not important for the present discussion. The key question is whether FIDO authentication would be one authentication possibility 
> advertised by the RS and, if so, how the client should be informed of it by the RS.
> 

Use cases and feasibility are complicated. Here are the use cases as I understand them:

1. AS integration for user authentication:
Short term, it is far easier to just have the browser do Web Authentication of the user at the AS.

Medium-term, user authentication to the AS is feasible for first-party clients to the AS. Platforms have and are expected to continue locking down access to CTAP2 over standardized transports and providing Webauthn-like API access to those as well as to any integrated platform authentication capabilities - and use entitlements and web-domain-based discovery to determine which applications have access. These applications are trusted not to use the credentials elsewhere, so for example a browser needs special entitlements to be able to do WebAuthn across all domains. I would expect this to be an interaction mode - with challenge message and response very similar to the WebAuthn API GetAssertion call, perhaps with Base64-encoded strings substituted for ArrayBuffers.

2. AS integration for client authentication:
It might make sense to create credentials for use to verify an authentic client. This would be similar to a software statement when doing OAuth DCR.

DCAppAttestService is a feature coming in iOS 14 which will create an attestation that the application instance is legitimate. The interface for using these attestations is based heavily on Web Authentication, although the client information block is free-form. Since the attestations (hopefully) are distinct from platform attestations for browser-based web authentication, there should not be a platform restriction on acquiring these.

I wouldn’t expect this to be a feature in the core specification unless other platforms followed suit however - Google for instance has SafetyNet instead. 

3. RS integration for client authentication and user authentication:
I suspect this goes counter to GNAP just how it would go counter to OAuth - both policy and complexity are usually centralized by the AS. Of course, if an RS is also an AS for its own domain, it would have the use cases above.

-DW

> 
> Denis
> 
>> 
>> Sent from my iPhone
>> 
>>> On Aug 18, 2020, at 10:38 AM, Denis <[e-mail]> <mailto:[e-mail]> wrote:
>>> 
>>> 
>>> Hi Tony,
>>>> Not quite Dennis, the U2F device does not store the private key, it only creates the private key.
>>> Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:
>>> 
>>> https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf <https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf>
>>> Extract:
>>> 
>>>  (...) the ASPSP  (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator
>>> which is then cryptographically signed by a private key stored in the authenticator.
>>> 
>>> Denis
>>> 
>>>>  
>>>> From: TXAuth <[e-mail]> <mailto:[e-mail]> On Behalf Of Denis
>>>> Sent: Friday, August 14, 2020 3:04 AM
>>>> To: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>>>> Subject: Re: [GNAP] Support of FIDO
>>>>  
>>>> Hi Tony, 
>>>> Dennis, not all the way correct 
>>>> It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user 
>>>> and no trust relationships need to be defined since there is no AS
>>>> Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK 
>>>> None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS. 
>>>> Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible
>>>> There is nothing that prohibits the RS from sharing registration information between RS 
>>>> I am speaking of FIDO U2F where there are two main phases: registration and authentication.
>>>> 
>>>> The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step. 
>>>> Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device 
>>>> via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back 
>>>> to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.
>>>> 
>>>> There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.
>>>> 
>>>> Denis
>>>> 
>>>>  
>>>> From: TXAuth <[e-mail]> <mailto:[e-mail]> On Behalf Of Denis
>>>> Sent: Thursday, August 13, 2020 10:31 AM
>>>> To: [e-mail] <mailto:[e-mail]>
>>>> Subject: [GNAP] Support of FIDO
>>>>  
>>>> This topic has already been tackled on the list, but I open a new thread for it.
>>>> 
>>>> In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens, 
>>>> there have been used everywhere, even when they were not strictly needed. 
>>>> 
>>>> 
>>>> It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user 
>>>> and no trust relationships need to be defined since there is no AS. 
>>>> 
>>>> 
>>>> FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym 
>>>> specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.
>>>> 
>>>> 
>>>> RFC 7519 states:
>>>> The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject.  
>>>> The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.
>>>> In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer) 
>>>> while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server 
>>>> (i.e. not supporting OAuth) that is using the same globally unique identifier.
>>>> 
>>>> 
>>>> None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS. 
>>>> 
>>>> Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible. 
>>>> 
>>>> 
>>>> There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.
>>>> 
>>>> 
>>>> Denis
>>>>  
>>>> 
>>> 
>>> -- 
>>> TXAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth