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

[Tom Jones <[e-mail]>]

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]> 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]>
> 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]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>