Re: [Txauth] Registered Clients and Dynamic Clients

Denis <> Thu, 16 July 2020 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E4303A09E4 for <>; Thu, 16 Jul 2020 05:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4ZJxdmr05_v2 for <>; Thu, 16 Jul 2020 05:37:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02B503A0A7E for <>; Thu, 16 Jul 2020 05:37:16 -0700 (PDT)
Received: from [] ([]) by mwinf5d81 with ME id 3odE230054FMSmm03odE9o; Thu, 16 Jul 2020 14:37:15 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 16 Jul 2020 14:37:15 +0200
To: Dick Hardt <>
Cc: "" <>
References: <> <>
From: Denis <>
Message-ID: <>
Date: Thu, 16 Jul 2020 14:37:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------A0BEB5181878082A37BDACEF"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 12:37:20 -0000

Hi Dick,

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


> /Dick
>     Denis