Re: [Txauth] Client Registration (Was: Key handle vs client id & handle

I suggested earlier to use the entity statement of the Openid federation
spec, but heard no feedback. Why not?

thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:00 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> (changing subject to reflect topic)
>
> In my opinion, client registration is in scope.
>
> In both XYZ and XAuth, the client can provide some information about
> itself, and get back an ID it can use in subsequent calls. No one has said
> that should NOT be in scope so far.
>
> Myself, I do support adding other mechanisms for a Client to share
> information about itself with an AS such as software statements, or a URI
> that binds a URI to information retrieved from that URI, and to the Client.
>
> I agree that we don't want to define software statements per se, but we
> should refer to some standards so that interop between clients and ASs.
>
> /Dick
>
> On Tue, Jul 14, 2020 at 10:54 AM Mike Varley <mike.varley@securekey.com>
> wrote:
>
>> Is client registration in scope for the protocol?
>>
>>
>>
>> A generic way of handling clients (via ID or Handle or Key or whatever)
>> is to have processing rule on the AS such as “if the AS recognizes the
>> client ID (and authentication of that client ID) then it may process the
>> request on behalf of that client. If the AS does not recognize the client
>> ID, it must treat this as a new client registration and evaluate any
>> authorization evidence the client provides before enabling the client and
>> mapping policies to that client” (this means dynamic or automatic clients
>> need to provide additional assertions / software statements whatever to
>> register their ID.
>>
>>
>>
>> Something like this allows for very flexible systems:
>>
>> System A can be unknown to the AS but can dynamically registered each
>> time with an appropriate software statement
>>
>> System B can have a fairly stable client ID at the AS, but rotate that ID
>> every month through automatic registration (with an assertion it got from
>> the AS during a pre-registration for example)
>>
>> System C can pre-register with the AS for a client ID because it doesn’t
>> deal with software statements etc…
>>
>> …
>>
>> And even ‘StatelessAS’ can operate by never storing client IDs because it
>> will always just rely on the software statements.
>>
>>
>>
>> I think a client registration protocol that allows these scenarios would
>> be very useful in GNAP, but hopefully avoiding having to define what
>> ‘evidence’ the AS needs to accept for each scenario.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> MV
>>
>>
>>
>> *From: *Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones
>> <Michael.Jones=40microsoft.com@dmarc.ietf.org>
>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>> *To: *Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <
>> txauth@ietf.org>, Justin Richer <jricher@mit.edu>
>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>
>>
>>
>> I agree that there are significant differences between statically and
>> dynamically registered clients and that’s appropriate to be able to
>> syntactically differentiate between them at runtime.  For one thing, the
>> resource requirements at the authorization server can be very different.
>>
>>
>>
>> We should also be thinking about how to include what the OpenID Connect
>> Federation spec
>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>> “Automatic Registration”.  This lets the client encode a registration
>> request reference in the client ID, so no static or dynamic registration
>> even occurs.  See
>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1
>> .
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Dick Hardt <dick.hardt@gmail.com>
>> *Sent:* Friday, July 10, 2020 1:17 PM
>> *To:* txauth@ietf..org <txauth@ietf.org>; Justin Richer <jricher@mit.edu>;
>> Mike Jones <Michael.Jones@microsoft.com>
>> *Subject:* Key handle vs client id & handle
>>
>>
>>
>> + Mike as he had interest in this topic
>>
>>
>>
>> My understanding is that an existing OAuth 2 client would use their
>> current client id as their key handle, and a dynamic client (one that was
>> not pre-registered) would be given a key handle by the AS.
>>
>>
>>
>> There are potentially some significant differences between a registered
>> client, and a dynamic client to an AS.
>>
>>
>>
>> The AS is likely to know the identity of a registered client, and have
>> different policies between the two types of clients. For example, a
>> registered client may have access to a 'write" scope, while a dynamic
>> client does not.
>>
>>
>>
>> The AS may have 100s or 1000s of registered clients, but a dynamic client
>> may have 10Ms or 100Ms of instances, which may dictate separate storage
>> services. Additionally, internal to the AS, which systems can write to the
>> registered client store is going to be different than the dynamic
>> client store.
>>
>>
>>
>> In XYZ, subsequent calls to the AS, both registered clients and dynamic
>> clients pass a key handle, so there is no easy way to differentiate between
>> the two.
>>
>>
>>
>> While the AS could embed semantics in the key handle identifier to
>> indicate which identifiers are pre-registered vs dynamic, there are many
>> cases where the AS does need to know the difference, so making the
>> difference a feature of GNAP seems like a better path.
>>
>>
>>
>>
>>
>> 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.
>>
> ᐧ
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>