Re: [Txauth] Key handle vs client id & handle

[Justin Richer <[e-mail]>]

The problem I have with this approach is that it artificially encodes two, and only two, tiers of client within the protocol needlessly. In my experience with systems that support dynamic registration, it’s not a black and white world like that. There are clients who can present :some: form of proof that they’re legit, but they haven’t been statically registered with the AS. (See MODRNA and OBUK, for instance.) There are clients whose identities are tied explicitly to the current user (like a Solid pod). There are clients who are “statically” registered but through a developer-facing portal, vs clients that are registered through an admin-only interface. 

As you say below, if the AS needs to differentiate between classes, it can decide to do so based on the key or identifier and the policies associated with it. I disagree with encoding these two tiers, or any tiers, into the protocol itself. This is ultimately a matter of the AS and its policy. In OAuth 2 there is no differentiation between a “static” or “dynamic” client ID, and yet an AS today can still differentiate between them — because it knows the context in which the client ID was generated. It’s the same with the “key handle” concept in XYZ: the AS knows where the handle came from and can apply different policies regardless. 

Now, it’s a bigger question what the “handle” refers to. XYZ started with it being tied to “all client software information” and then broke it into pieces, with the “key” portion being the cornerstone piece. While I still think this makes sense, I think that’s something that GNAP needs to figure out with more input from the community than just my own experience.

 — Justin

> On Jul 10, 2020, at 4:16 PM, Dick Hardt <[e-mail]> wrote:
> 
> + 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.
> 
>