Re: [Txauth] Registered Clients and Dynamic Clients

[Dick Hardt <[e-mail]>]

On Wed, Jul 15, 2020 at 10:04 AM Denis <[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.


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

/Dick



> Denis
>
>