Subject: [Txauth] Registered Clients and Dynamic Clients

From: Denis <[email-masked]>
Date: Wed, 15 Jul 2020 19:04:39 +0200

Hello Dick,

I am puzzled with the two following definitions in 
draft-hardt-xauth-protocol-13 :

*Registered Client* - a Client that has registered with the GS and has a 
Client ID to identify itself, and
        can prove it possesses a key that is linked to the Client ID.The 
GS may have different policies for what
        different Registered Clients can request.A Registered Client MAY 
be interacting with a User.

[Denis]  I interpret the last sentence in the following way: A 
Registered Client may be either an Application or a User.
              Is it correct ?

*Dynamic Client* - a Client that has not been previously registered with 
the GS, and each instance will generate
        it’s own asymmetric key pair so it can prove it is the same 
instance of the Client on subsequent requests. The GS
        MAY return a Dynamic Client a Client Handle for the Client to 
identify itself in subsequent requests. A single-page
        application with no active server component is an example of a 
Dynamic Client. A Dynamic Client MUST be interacting
        with a User.

[Denis] The draft does not include any other explanation for the reason 
to support the so-called "Dynamic Clients".
While I can understand the value to use a temporary key pair for a given 
RS, I can't understand the value for a GS
             to support unknown clients. If a GS knows nothing about a 
so-called "Dynamic Client", then it will not be able to deliver
             any user attribute into an access token to such client.

Denis

---

From: Dick Hardt <[email-masked]>
Date: Wed, 15 Jul 2020 10:17:14 -0700

On Wed, Jul 15, 2020 at 10:04 AM Denis <[email-masked]> wrote:

>       *Registered Client* - a Client that has registered with the GS and
> has a Client ID to identify itself, and
>        can prove it possesses a key that is linked to the Client ID.  The
>        different Registered Clients can request.  A Registered Client MAY
> [Denis]  I interpret the last sentence in the following way: A Registered
> Client may be either an Application or a User.
>              Is it correct ?
>

No. A Registered Client MAY be interacting with a User, or it MAY not. IE,
a Registered Client may be a service.

>
>       *Dynamic Client* - a Client that has not been previously registered
> with the GS, and each instance will generate
>             While I can understand the value to use a temporary key pair
> for a given RS, I can't understand the value for a GS

More of an explanation of Dynamic Clients is a good call out, thanks!

A Dynamic Client MUST be interacting with a User, as "trust" of the Client
is done by the User. A Single Page Application (SPA) or a mobile app are
examples of clients that cannot have a shared secret, but can generate and
keep secure their own key pair..

As suggested in another thread, GNAP could support Clients that are between
these two extremes. Mike called out automatic registration per OpenID
Connect Federation as one example. Other options include a "software
statement" passed from the Client to the GS.

We may want to revisit the terms "Registered Client" and "Dynamic Client"
as we broaden the mechanisms for Clients to "register" with a GS, but these
are the common cases today, so I picked them.

/Dick

---

From: Denis <[email-masked]>
Date: Thu, 16 Jul 2020 14:37:12 +0200

Hi Dick,

> On Wed, Jul 15, 2020 at 10:04 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Dick,
>
>            can prove it possesses a key that is linked to the Client
>     ID.The GS may have different policies for what
>            different Registered Clients can request.A Registered
>     Client MAY be interacting with a User.
>
> No. A Registered Client MAY be interacting with a User, or it MAY not. 
> IE, a Registered Client may be a service.

It seems that what I call an Application is what you call a service. 
Usually a service may be supported by multiple servers,
so I get the impression that my terminology is better suited. If not, 
would you be able to explain ?

>           *Dynamic Client* - a Client that has not been previously
>     registered with the GS, and each instance will generate
>            MAY return a Dynamic Client a Client Handle for the Client
>     to identify itself in subsequent requests. A single-page
>            application with no active server component is an example
>     of a Dynamic Client. A Dynamic Client MUST be interacting
>            with a User.
>
>     [Denis] The draft does not include any other explanation for the
>     reason to support the so-called "Dynamic Clients".
>     While I can understand the value to use a temporary key pair for a
>     given RS, I can't understand the value for a GS
>                 to support unknown clients. If a GS knows nothing
>     about a so-called "Dynamic Client", then it will not be able to
>     deliver
> A Dynamic Client MUST be interacting with a User, as "trust" of the 
> Client is done by the User.
> A Single Page Application (SPA) or a mobile app are examples of 
> clients that cannot have a shared secret, but can generate and keep 
> secure their own key pair..
>
> As suggested in another thread, GNAP could support Clients that are 
> between these two extremes.
> Mike called out automatic registration per OpenID Connect Federation 
> as one example. Other options include a "software statement" passed 
> from the Client to the GS.
>
> We may want to revisit the terms "Registered Client" and "Dynamic 
> Client" as we broaden the mechanisms for Clients to "register" with a 
> GS, but these are the common cases today, so I picked them.

It seems that the intent is to support both a client registration 
protocol and a client operational protocol with the GS/AS.

Client registration may be done in many ways until the user is able to 
get a /both an identifier/ and private key
usable for an AS, and the AS is able to use /t//he same identifier/ and 
the corresponding public key to authenticate the user.

For example, draft-hardt-xauth-protocol-13 states: "The Client always 
uses a private asymmetric key to authenticate to the GS".

This should be the start of the story with an important observation: the 
client always uses /an identifier/, in particular to allow to gracefully 
change that private key.

One way to register and then to authenticate to a GS may simply be to 
use FIDO.FIDO is currently supported by many web browsers.

If/once we will be finished with the main topic, then why not address 
client registration but there is no strong adherence with our main topic.
Hence, client registration should not be on the list of our top priorities.

If we define one /or more/ client registration schemes, then this should 
better be in a separate and independent RFC.

Denis

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jul 2020 10:42:29 -0700

inline ...

On Thu, Jul 16, 2020 at 5:37 AM Denis <[email-masked]> wrote:

>>        different Registered Clients can request.  A Registered Client
>> MAY be interacting with a User.
>>

A Client could be an application the User is using, or it could be a
service with no specific User.

> is done by the User.
> A Single Page Application (SPA) or a mobile app are examples of clients
> that cannot have a shared secret, but can generate and keep secure
> their own key pair..
>
> Mike called out automatic registration per OpenID Connect Federation as
> one example. Other options include a "software statement" passed from the
> Client to the GS.
>
> It seems that the intent is to support both a client registration protocol
> and a client operational protocol with the GS/AS.
>
> Client registration may be done in many ways until the user is able to get
> a *both an identifier* and private key
> usable for an AS, and the AS is able to use *t**he same identifier* and
It appears you are mixing client identifiers and user identifiers, as well
as user authentication at a AS, and client authentication at an AS. User
authentication at the AS is out of scope of GNAP as I understand it (there
are lots of existing mechanisms that work fine). Client authentication to
the AS is in scope.

> For example, draft-hardt-xauth-protocol-13 states: "The Client always uses
> a private asymmetric key to authenticate to the GS".
>
> client always uses *an identifier*, in particular to allow to gracefully
> change that private key.
>
The challenge is that the client needs a unique identifier for the GS,
which is why in both XYZ, and XAuth, the GS generates the identifier for
dynamic clients, and the generally also generates the identifier for
registered clients.

> One way to register and then to authenticate to a GS may simply be to use
> FIDO. FIDO is currently supported by many web browsers.
>

Technically, the web browsers support WebAuthN. While FIDO is great
technology, I would see it as an authentication choice between the GS and
the User, and out of scope of GNAP. A challenge with FIDO is portability
across devices, as a binding is usually tied to a specific device.

> If we define one *or more* client registration schemes, then this should
Maybe, maybe not.

My preference is to have a larger document that covers inter-related topics
than a bunch of smaller documents that an implementer has to bounce around
between.

/Dick

---

From: Denis <[email-masked]>
Date: Fri, 17 Jul 2020 18:09:00 +0200

Hi Dick,

I picked three of your sentences below :

    It appears you are mixing client identifiers and user identifiers,
    as well as user authentication at a AS, and client authentication at
    an AS.
    User authentication at the AS is out of scope of GNAP as I
    understand it (there are lots of existing mechanisms that work fine).
    Client authentication to the AS is in scope.

An AS needs to authenticate users in order to relate them to their 
attributes: there is a user account at the AS for each registered user.
So user authentication is one important step in the protocol. It shall 
be handled using an asymmetric key pair.

A client is a piece of software and/or hardware trusted either by an 
application or by a user that interfaces on their behalf with ASs and RSs.

An AS usually does not handle clients accounts. It may be interesting in 
some cases to make sure, from an AS point of view, that a user is indeed
using a secure element with some specific properties. But at this time 
the wording "secure element" has not been pronounced. If we would like
to go in that direction we would need to describe APDUs (Application 
Protocol Data Units) but at this time I am not aware that the IETF has 
already
addressed such topic.

However, I got the impression that the real need is not "entity 
authentication" for the client.
Would you explain the rational for your need, instead of the solution ?

I picked another sentence:

    A challenge with FIDO is portability across devices, as a binding is
    usually tied to a specific device.

This is currently true with what the FIDO Alliance has currently 
published, but this can be solved.
Denis

> inline ...
>
> On Thu, Jul 16, 2020 at 5:37 AM Denis <[email-masked] 
>>               *Registered Client* - a Client that has registered with
>>         the GS and has a Client ID to identify itself, and
>>                can prove it possesses a key that is linked to the
>>         Client ID.The GS may have different policies for what
>>         [Denis]  I interpret the last sentence in the following way:
>>         A Registered Client may be either an Application or a User.
>>                      Is it correct ?
>>
>>
>>     No. A Registered Client MAY be interacting with a User, or it MAY
>>     not. IE, a Registered Client may be a service.
>
>     It seems that what I call an Application is what you call a
>     service. Usually a service may be supported by multiple servers,
>     so I get the impression that my terminology is better suited. If
>     not, would you be able to explain ?
>
>
>>                it’s own asymmetric key pair so it can prove it is the
>>         same instance of the Client on subsequent requests. The GS
>>                MAY return a Dynamic Client a Client Handle for the
>>         Client to identify itself in subsequent requests. A single-page
>>                application with no active server component is an
>>         example of a Dynamic Client. A Dynamic Client MUST be
>>         interacting
>>                with a User.
>>
>>         [Denis] The draft does not include any other explanation for
>>         the reason to support the so-called "Dynamic Clients".
>>         about a so-called "Dynamic Client", then it will not be able
>>         to deliver
>>     A Dynamic Client MUST be interacting with a User, as "trust" of
>>     the Client is done by the User.
>>     clients that cannot have a shared secret, but can generate and
>>     As suggested in another thread, GNAP could support Clients that
>>     are between these two extremes.
>>     Mike called out automatic registration per OpenID Connect
>>     Federation as one example. Other options include a "software
>>     Client" as we broaden the mechanisms for Clients to "register"
>>     with a GS, but these are the common cases today, so I picked them.
>
>     Client registration may be done in many ways until the user is
>     able to get a /both an identifier/ and private key
>     usable for an AS, and the AS is able to use /t//he same
>     identifier/ and the corresponding public key to authenticate the user.
>
> It appears you are mixing client identifiers and user identifiers, as 
> well as user authentication at a AS, and client authentication at an 
> AS. User authentication at the AS is out of scope of GNAP as I 
> understand it (there are lots of existing mechanisms that work fine). 
> Client authentication to the AS is in scope.
>
>     For example, draft-hardt-xauth-protocol-13 states: "The Client
>     always uses a private asymmetric key to authenticate to the GS".
>
>     This should be the start of the story with an important
>     observation: the client always uses /an identifier/, in particular
>     to allow to gracefully change that private key.
>
> which is why in both XYZ, and XAuth, the GS generates the identifier 
> for dynamic clients, and the generally also generates the identifier 
> for registered clients.
>
>     One way to register and then to authenticate to a GS may simply be
>     to use FIDO.FIDO is currently supported by many web browsers.
>
>
> technology, I would see it as an authentication choice between the GS 
> and the User, and out of scope of GNAP. A challenge with FIDO is 
> portability across devices, as a binding is usually tied to a specific 
> device.
>
>
>     If/once we will be finished with the main topic, then why not
>     address client registration but there is no strong adherence with
>     our main topic.
>     If we define one /or more/ client registration schemes, then this
>     should better be in a separate and independent RFC.
>
> Maybe, maybe not.
>
> My preference is to have a larger document that covers inter-related 
> topics than a bunch of smaller documents that an implementer has to 
> bounce around between.
>
> /Dick

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Jul 2020 11:06:58 -0700

Comments inline ...

On Fri, Jul 17, 2020 at 9:09 AM Denis <[email-masked]> wrote:

> as user authentication at a AS, and client authentication at an AS.
> User authentication at the AS is out of scope of GNAP as I understand it
> (there are lots of existing mechanisms that work fine).
> So user authentication is one important step in the protocol. It shall be
> handled using an asymmetric key pair.
>

I think user authentication is an important step, but I strongly view it is
out of scope of the protocol. There continues to be innovatio in user
authentication, and there I fail to see the value in GNAP standardizing
what an AS MUST do.

> application or by a user that interfaces on their behalf with ASs and RSs.

Given that a client is making API calls, I don't see how a client can be
hardware.

> using a secure element with some specific properties. But at this time the
> wording "secure element" has not been pronounced. If we would like

A reminder that there are many other use cases for GNAP than your use case,
and that supporting existing OAuth and OpenID Connect use cases is in
scope. Often, what an AS will grant a client is dependent on which client
it is, hence the requirement for "entity authentication".

> published, but this can be solved.

Maybe, but it is out of scope of GNAP, and I don't think we should design a
protocol based on what we would like another standards body to do.

/Dick
ᐧ