Re: [Txauth] Registered Clients and Dynamic Clients

[Denis <[e-mail]>]

Hi Dick,

> On Wed, Jul 15, 2020 at 10:04 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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 ?
>
>
> 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
>            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.
>
>
> 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.

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

>
> /Dick
>
>     Denis
>