Subject: [GNAP] Support of FIDO

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 19:30:59 +0200

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 11:21:14 -0700

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to
stop site A from asking for the user's username and password at site B so
that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think should be
out of scope. There are a plethora of authentication mechanisms, and
standardizing how the user authenticates is not required for interop.
Sharing the "quality" of the authentication is an area of standardization
that has been done in OpenID Connect, and I think should be included in
GNAP.

Having said that, the Client could optionally use FIDO to authenticate the
User and somehow transmit that to the AS.

ᐧ

On Thu, Aug 13, 2020 at 10:31 AM Denis <[email-masked]> wrote:

> 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,
> FIDO should be one allowed possibility for the user authentication. In the
> case of FIDO, the user is authenticated under a pseudonym
> 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.
> 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)
> properties of FIDO which cannot be met using the claims currently defined
> in OAuth.
>
> Denis
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: <[email-masked]>
Date: Thu, 13 Aug 2020 11:25:32 -0700

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 

From: TXAuth <[email-masked]> On Behalf Of Denis
Sent: Thursday, August 13, 2020 10:31 AM
To: [email-masked]
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

---

From: <[email-masked]>
Date: Thu, 13 Aug 2020 11:27:24 -0700

*	Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

Agree, this can be done now, we are also looking at some delegation mechanisms in WebAuthn to accomplish this 

From: TXAuth <[email-masked]> On Behalf Of Dick Hardt
Sent: Thursday, August 13, 2020 11:21 AM
To: Denis <[email-masked]>
Cc: [email-masked]
Subject: Re: [GNAP] Support of FIDO

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to stop site A from asking for the user's username and password at site B so that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think should be out of scope. There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop. Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP.

Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

  <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=fcbd933e-899b-44eb-a8d8-b2330c4868e7> ᐧ

On Thu, Aug 13, 2020 at 10:31 AM Denis <[email-masked] <mailto:[email-masked]> > wrote:

RFC 7519 states:

Denis

-- 
TXAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/txauth

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 12:04:10 +0200

Hi Tony,
>   * It is also possible to get rid of IDs and passwords using FIDO.
>     FIDO discloses no private information at all about the user
> 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.
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 <[email-masked]> *On Behalf Of *Denis
> *Sent:* Thursday, August 13, 2020 10:31 AM
> *To:* [email-masked]
> *Subject:* [GNAP] Support of FIDO
>
> 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:
>
>     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.
>
> 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
> 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.
>

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 12:05:43 +0200

Hi Dick,

> OAuth 2.0 goal was not to get rid of usernames and passwords. It was 
> to stop site A from asking for the user's username and password at 
> site B so that site A could access resources at site B.
>
> How the AS authenticates the User is out of scope, and I think should 
> be out of scope.

Maybe, may be not. Some means of authentication between a User and an AS 
could be recommended and documented.

However, how the RS authenticates the User should be within the scope.

> There are a plethora of authentication mechanisms, and standardizing 
> how the user authenticates is not required for interop.
> Sharing the "quality" of the authentication is an area of 
> standardization that has been done in OpenID Connect, and I think 
> should be included in GNAP.
>
> Having said that, the Client could optionally use FIDO to authenticate 
> the User and somehow transmit that to the AS.

No. The RS Client could optionally use FIDO to authenticate the User. 
Since FIDO does not mandate any AS, there is no interaction with any AS 
at that stage.

Denis

> ᐧ
>
> On Thu, Aug 13, 2020 at 10:31 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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,
>     It is also possible to get rid of IDs and passwords using FIDO.
>     FIDO should be one allowed possibility for the user
>     authentication. In the case of FIDO, the user is authenticated
>     under a pseudonym
>         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.
>
>     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
>     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

---

From: Mike Varley <[email-masked]>
Date: Fri, 14 Aug 2020 13:04:52 +0000

I think allowing a trusted Client to authN the end user and have the AS trust that authentication is an important feature, especially for mobile client or in the example of FIDO/WebAuthN.
I have captured the use case here:
https://github.com/ietf-wg-gnap/general/wiki/Client-can-AuthN-End-User

MV

From: TXAuth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Friday, August 14, 2020 at 6:05 AM
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [GNAP] Support of FIDO

Hi Dick,

How the AS authenticates the User is out of scope, and I think should be out of scope.

Maybe, may be not. Some means of authentication between a User and an AS could be recommended and documented.

However, how the RS authenticates the User should be within the scope.
There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop.
Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP.

No. The RS Client could optionally use FIDO to authenticate the User. Since FIDO does not mandate any AS, there is no interaction with any AS at that stage.

Denis
[Image removed by sender.]ᐧ

On Thu, Aug 13, 2020 at 10:31 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
This topic has already been tackled on the list, but I open a new thread for it.

[email-masked]<mailto:[email-masked]>

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 15:14:40 +0200

Mike,

Please open a new thread if you want to discuss this topic as it is 
unrelated to FIDO.

Denis

> I think allowing a trusted Client to authN the end user and have the 
> AS trust that authentication is an important feature, especially for 
> mobile client or in the example of FIDO/WebAuthN.
>
> *From: *TXAuth <[email-masked]> on behalf of Denis 
> <[email-masked]>
> *Date: *Friday, August 14, 2020 at 6:05 AM
> *To: *Dick Hardt <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [GNAP] Support of FIDO
>
> Hi Dick,
>
>     OAuth 2.0 goal was not to get rid of usernames and passwords. It
>     was to stop site A from asking for the user's username and
>     password at site B so that site A could access resources at site B.
>
>     There are a plethora of authentication mechanisms, and
>     Having said that, the Client could optionally use FIDO to
>     authenticate the User and somehow transmit that to the AS.
>
> Since FIDO does not mandate any AS, there is no interaction with any 
> AS at that stage.
>
> Denis
>
>     Image removed by sender.ᐧ
>
>         It is also possible to get rid of IDs and passwords using
>         FIDO. FIDO discloses no private information at all about the user
>         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
>         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.
>
>         unlinkeability properties of FIDO which cannot be met using
>         the claims currently defined in OAuth.
>
>         Denis
>
>         -- 
>         TXAuth mailing list
> This email and any attachments are for the sole use of the intended 
> recipients and may be privileged, confidential or otherwise exempt 
> from disclosure under law. Any distribution, printing or other use by 
> anyone other than the intended recipient is prohibited. If you are not 
> an intended recipient, please contact the sender immediately, and 
> permanently delete this email and its attachments.
>

---

From: Steinar Noem <[email-masked]>
Date: Fri, 14 Aug 2020 15:23:38 +0200

Hi Denis, I have always perceived U2F (which I think has been replaced by
FIDO2/CTAP/WebAuthn) as just a pure second factor and not an authentication
in itself.
I may be wrong, but from my understanding U2F makes sense in combination
with user authentication, but not as a stand-alone solution.

<mvh>Steinar</mvh>

fre. 14. aug. 2020 kl. 12:04 skrev Denis <[email-masked]>:

>    - It is also possible to get rid of IDs and passwords using FIDO. FIDO
> 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
>    other server) becomes impossible
>
>
>
> 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.
>
> *From:* TXAuth <[email-masked]> <[email-masked]> *On
> Behalf Of *Denis

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: <[email-masked]>
Date: Fri, 14 Aug 2020 07:14:58 -0700

Correct U2F is not passwordless like FIDO2 or UAF

From: TXAuth <[email-masked]> On Behalf Of Steinar Noem
Sent: Friday, August 14, 2020 6:24 AM
To: Denis <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [GNAP] Support of FIDO

Hi Denis, I have always perceived U2F (which I think has been replaced by FIDO2/CTAP/WebAuthn) as just a pure second factor and not an authentication in itself.

I may be wrong, but from my understanding U2F makes sense in combination with user authentication, but not as a stand-alone solution.

<mvh>Steinar</mvh>

fre. 14. aug. 2020 kl. 12:04 skrev Denis <[email-masked] <mailto:[email-masked]> >:

Hi Tony, 

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  <mailto:[email-masked]> <[email-masked]> On Behalf Of Denis
Sent: Thursday, August 13, 2020 10:31 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [GNAP] Support of FIDO

RFC 7519 states:

Denis

 

-- 

Vennlig hilsen

Steinar Noem

Partner Udelt AS

Systemutvikler

|  <mailto:[email-masked]> [email-masked] |  <mailto:[email-masked]> [email-masked]  | +47 955 21 620 |  <http://www.udelt.no/> www.udelt.no |

---

From: <[email-masked]>
Date: Fri, 14 Aug 2020 07:16:58 -0700

Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

From: TXAuth <[email-masked]> On Behalf Of Denis
Sent: Friday, August 14, 2020 3:04 AM
To: [email-masked]; [email-masked]
Subject: Re: [GNAP] Support of FIDO

Hi Tony, 

Denis

RFC 7519 states:

Denis

---

From: Denis <[email-masked]>
Date: Tue, 18 Aug 2020 18:37:21 +0200

Hi Tony,
> 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

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

> *Sent:* Friday, August 14, 2020 3:04 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [GNAP] Support of FIDO
>
> Hi Tony,
>
>       * It is also possible to get rid of IDs and passwords using
>     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
>         and any other server) becomes impossible
>
>     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
>     *From:* TXAuth <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *Denis
>     *To:* [email-masked] <mailto:[email-masked]>
>         subject of the JWT.  The claims in a JWT are normally

---

From: David <[email-masked]>
Date: Tue, 18 Aug 2020 10:46:47 -0600

Denis,

That text is not in the referenced document?

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

Sent from my iPhone

> On Aug 18, 2020, at 10:38 AM, Denis <[email-masked]> wrote:
> 
> 
> Hi Tony,
> Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:
> 
>  (...) 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: <[email-masked]>
Date: Tue, 18 Aug 2020 10:35:36 -0700

U2F is not CTAP2 or FIDO2, U2F device usually do not store the cryptographic material on the device as the device has limited capabilities 

From: Denis <[email-masked]> 
Sent: Tuesday, August 18, 2020 9:37 AM
To: [email-masked]; [email-masked]
Subject: Re: [GNAP] Support of FIDO

Hi Tony,

Extract:

Denis

From: TXAuth  <mailto:[email-masked]> <[email-masked]> On Behalf Of Denis
Sent: Friday, August 14, 2020 3:04 AM
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [GNAP] Support of FIDO

Hi Tony, 

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

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

Denis

RFC 7519 states:

Denis

---

From: Denis <[email-masked]>
Date: Wed, 19 Aug 2020 10:37:04 +0200

David,

> That text is not in the referenced document?

You are right. This sentence is present in that document:

    https://media.fidoalliance.org/wp-content/uploads/2020/06/PSD2-Support-Why-Change-to-FIDO-White-Paper.pdf

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

Denis

>>     which is then cryptographically signed by a *private key stored
>>     in the authenticator.*
>>
>> Denis
>>
>>>     can be all sorts of information passed in ClientData field of
>>>     the FIDO response, not desirable but perfectly OK
>>>
>>>         Hence, the linkage of users between two RSs (or between one
>>>         RS and any other server) becomes impossible
>>>
>>>     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
>>>     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.
>>>
>>>     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:
>>>
>>>     users between two RSs (i.e. using a locally unique identifier in
>>>     the context of the issuer)

---

From: Denis <[email-masked]>
Date: Wed, 19 Aug 2020 10:39:07 +0200

Hi Tony,

Functionally, private keys are stored and used by the authenticator. For 
capacity limitations, they can be stored elsewhere if both correctly 
integrity and confidentiality protected.
That additional storage is an extension of the limited storage of the 
authenticator.

I was attempting to promote the use of FIDO within this WG. Are you 
against or in favour of such a possibility ?

Denis

> U2F is not CTAP2 or FIDO2, U2F device usually do not store the 
> cryptographic material on the device as the device has limited 
> capabilities
>
> *From:* Denis <[email-masked]>
> *Sent:* Tuesday, August 18, 2020 9:37 AM
>     *To:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>          1. It is also possible to get rid of IDs and passwords using
>         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
>
>          2. 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
>
>         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

---

From: Steinar Noem <[email-masked]>
Date: Wed, 19 Aug 2020 10:49:56 +0200

I personally like FIDO2 a lot, and think that it would serve well as an
example of how to solve authentication.
But I also think that it is just one of many examples of how authentication
can be handled, and that it should not be presented as a "preferred"
solution or any other form of tight coupling between FIDO and GNAP.
There are well founded reasons for choosing other mechanisms (e.g. national
eIDs etc).

-S

ons. 19. aug. 2020 kl. 10:39 skrev Denis <[email-masked]>:

> cryptographic material on the device as the device has limited capabilities
>
>
>
> *From:* Denis <[email-masked]> <[email-masked]>
>  (...) 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
>
>
>
>    1. It is also possible to get rid of IDs and passwords using FIDO.
>    1. None of these two semantics fit with the FIDO use case where the

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

---

From: David Waite <[email-masked]>
Date: Wed, 19 Aug 2020 09:10:32 -0600

> On Aug 19, 2020, at 02:37, Denis <[email-masked]> wrote:
> 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 <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> 
>>> Hi Tony,
>>> 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:
>>> 
>>>> From: TXAuth <[email-masked]> <mailto:[email-masked]> On Behalf Of Denis
>>>> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>>> From: TXAuth <[email-masked]> <mailto:[email-masked]> On Behalf Of Denis
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> TXAuth mailing list
> [email-masked]