Re: [Txauth] The client is identified by its key.

[Justin Richer <[e-mail]>]

My explanation below isn’t based on speculation, but on many years of experience in dealing with these kinds of things in real systems. I’m with you in the importance of implementation, which is why there are already several independent implementations of XYZ out there. Specifications are just ideas until someone puts it into practice!

I’m eager to hear what kinds of solutions you have in mind for supporting key rollover in this protocol, and how we can best enable it. 

  — Justin

> On Jun 9, 2020, at 1:51 PM, Tom Jones <[e-mail]> wrote:
> 
> That is feel good description.  I am skeptical until a full description of the protocol exists. Even then i don't believe it works until i see it work for myself. If the roll-over is to be in the IETF spec then it requires two implementations. If it is not in the spec, then I would oppose adoption of the spec. Until i see some evidence that it works, I would not like to see it adopted. Otherwise we will get deployments that work fine for a year and then all start to fai. I've been there, that is not fun.
> 
> Peace ..tom
> 
> 
> On Tue, Jun 9, 2020 at 10:38 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> Key rollover is really important. When I say that the client is identified by the key, I do not mean that a client is DEFINED by its key. And with that, it is important to know that it’s the AS that decides what any particular key represents at any time. So long as the AS knows which key to map to which set of policies that govern the actions of a client, everything is fine. That mapping can change and the AS can keep the new key tied to the same internal entity. The AS could even have multiple keys tied to that entity, and accept any of those keys during a request. 
> 
> It’s exactly the same as changing a deployed OAuth 2 client’s client_secret today. You change the secret on the AS and change it in the client and it just keeps working like you’d expect. 
> 
> Oh, but you might be thinking — there we have the client ID to tie it all together! Don’t we need that! Well, we actually don’t. The AS can keep whatever internal identifier it wants to during a client rollover. The protocol, and importantly the client itself, need never be aware of that identifier. It might still be there but you are no longer forced to expose it. 
> 
> Removing an external and explicit client identifier enables this kind of deployment behavior, it doesn’t hamper it.
> 
>  — Justin
> 
>> On Jun 9, 2020, at 12:38 PM, Tom Jones <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> This needs to be its own thread. I see the same trend in OpenID for self-issued subject identification. I cannot imagine how key roll-over could possibly work without major disruption to ongoing activity.  Someone must show that key rollover in a fully functioning system is possible before it is even considered.
>> 
>> from justin
>> 
>> The client is identified by its key. There is no external client identifier. I think you’re confused because you’re still thinking in terms of OAuth 2’s client ID based model and I am trying to move us past that. It took me time to realize that we really can let it go, so hopefully this is helpful in explaining why.
>> 
>> When a credential is cryptographically random enough to be unique, it can be used as its own identifier, particularly when you don’t need to identify the entity outside of the context that it can present and prove its credential. To stretch a metaphor, passwords don’t always need usernames. This is, after all, the driving design pattern behind OAuth access tokens. An access token doesn’t have a “username” portion to it, even though it would have been trivial to require the client to send its client ID alongside the access token. Why does that work? Because our model of what the RS does with the access token is built around it answering the questions: is this token valid and does it allow what’s being requested? If the RS needs to know which client was issued the token, it can discover that information without being told separately from the token -- perhaps it’s in the token itself or it’s in an introspection response. And in a lot of cases, the RS doesn’t care about the client software, it just wants to know if the token’s any good. Even in constrained tokens such as MTLS, PoP, and DPoP, we aren’t really authenticating the client at the RS so much as making sure the right key is presented alongside the right token. 
>> 
>> XYZ takes that same approach with the client talking to the AS and uses the credential (key) to identify the client as well as authenticate and protect the request. We can’t just say “OAuth 2 had client IDs and people are used to it so it must be good and we have to keep using it”. We need to ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue that it doesn’t make sense anymore and we need to step back and look at a better model. OAuth 2 needs a client ID because it gets passed in the front channel and the client’s credentials can’t be used there. The access token doesn’t need an equivalent because it’s passed in the back channel and can be used directly. Now that the client no longer needs to be identified, but not authenticated, through untrusted third parties (such as the browser), we don’t need to have a separate identifier as part of the protocol. With an intent-based protocol, that starts in the back channel, you don’t need a client identifier anymore. Once the AS finds that key, the AS can then figure out what policies, rights, and restrictions are attached to that key. In many implementations, there’s going to be some kind of “registered client” object in a database somewhere that drives those policies. That’s the classical OAuth model, and it works in many cases. But in other cases, the key is going to just be a value used to protect the request chain (and possibly the token itself), and the policy is going to be built up by other things like a device posture or signature on the calling software or verified user information. It’s not just about client authentication, even though it can be used for it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, in different ways. 
>> 
>> On top of that, PAR is showing us that a lot of the constraints that we have in OAuth 2 don’t really apply anymore. For instance, Redirect URI restrictions can be relaxed because now you CAN identify and authenticate the software sending it, which isn’t true with a front-channel-first approach. All of the things that are required in OAuth 2 start to become redundant, and it leads to things like requiring that “client_id” still always be passed in the front channel even though the information could be looked up from an internal request_uri reference using PAR and JAR together.
>> 
>> That’s why a key handle isn’t exactly the same as a client ID and I did not call it a client ID in the XYZ protocol. It’s a shortcut to refer to the key material for certain optimized cases, but ultimately it’s pointing to a key. This has an interesting and beneficial side effect — if you HAVE a client ID as part of your internal data model, it can FUNCTION as a key handle because it’s a unique value the AS can use to look up key information. It’s not “authenticating the client”, it’s pointing to a key which in turn identifies and authenticates the software making the call. The fact that it’s a “client ID” is an artifact of the implementation, which in this case has an OAuth 2 legacy to work with. 
>> 
>> If we’re going to move past the constraints of OAuth 2 we need to stop thinking so strictly in its terms and models. There are better ways to approach this now and client IDs are not required by this protocol model.
>> Peace ..tom
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>