TXAuth (XYZ,RAR, JAR,JARM…)
TXAuth (XYZ, RAR, PAR, JARM JARM…)
Wednesday 8A
Convener(s): Justin Richer
Notes-taker(s): Júlio Santos & Justin Richer
Tags for the session - technology discussed/ideas considered:
- OAuth2, OAuth XYZ, PAR, RAR, JAR, PKCE, DYNReg, JSON, DPoP, UMA2, CIBA
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
1. Notes from Júlio Santos:
OAuth XYZ = PAR+RAR+JAR+PKCE+DYNReg+JSON+DPoP+UMA2+CIBA
There is a new mailing list about this, txauth@ietf.org, 2 days old, please join
there seems to be a general agreement that the world is moving towards this, so standards should evolve with it
justin didn't so much invent any of these ideas, just attempted to bring them together in a way they can work in a holistically consistent way; he thinks when you're doing a standard, if you keep deleting things and the standard becomes more flexible with it, you're going in a good direction
Why DYNReg? We have a lot of use cases where it's either the user's consent that's the driving trust anchor for the process, or the combination of this plus an attestation the software can make. Now that we have developer facing portals, self-service registration etc, this stops working.
A lot of the same checks you have to do around redirect_uris etc, you should be doing these same checks in a static environment such as a self-service portal. So why are we pretending that we have this middle-man thing?
XYZ starts by pushing a bunch of info to the server (identity, capability and intention). It also helps in cases where you can do a dynamic lookup of attributes about the client, by the client providing a verifiable reference. E.g. the solid project, where everything is based off webid. Similar to SAML RP discovery but smarter. It allows the auth server to say "yes, i know who you are and you can indeed do those things".
The most important output from DYNReg in OAuth2 is that you get a client id, to pass in the front channel. If we didn't have that, we could just use keys directly (ID you through your keys, or secret, no need for client ID).
The way that XYZ works is the client shows up and it pushes a bunch of info about itself, authenticates itself, can be in JSON in XYZ, and gets back if necessary a URL to have the user go and interact with. It's a ref to the tx that only the auth server knows about. Not passing scopes, client ID, no more info, no need to protect this info because it's not in the front channel.
This is the fundamental idea of XYZ — stop using the front channel.
PAR allows for better security and simpler client code. There are a lot of use cases where in XYZ the auth server can get enough info about the request to determine that it doesn't need the user to actually interact.
RAR. Scopes in OAuth2 are not expressive enough for certain classes of clients. Where Justin thinks we're trying to sell, and this is active debate, is that we should have a JSON object but also have there be a schema such as URL locations, types of actions etc. You can send this things as either an object that obeys the schema, or as a single string in the same data structure. It represents a pre-filled out resource object aka a scope.
Someone asks "How would the scopes be defined? At runtime, registered with the AS, or...?" Registered with the AS at build time, Justin says. The AS would have a list of scopes.
Someone suggests this could be more flexible, and is potentially too restrictive for OAuth2 to define.
Someone suggests it would be more powerful if the client could also specify the scopes. It would allow scopes to be more powerful (e.g. aliases). Someone else observes the mechanisms for this would live outside XYZ. Justin agrees.
Someone asks if XYZ allows you to specify both JSON and strings, if there are rules to help reconcile this. Justin says they need to be defined, and ultimately would be up to the AS.
OpenID has a lot of functionality that's independent from resource servers. There's work to be done in XYZ to figure out how to support this.
JAR. The big idea is that you don't have to send everything as query parameters on the front channel (vulnerable to a lot of attacks). XYZ gets around that by not using the front channel as much (see PAR).
XYZ gives you a lot more flexibility about how to interact with the user.
The client talks to the AS (XReg), gets back an interact_uri (and a tx handle X_H, meaning "we're not done, next time you talk to me, give me this"; this is how you distinguish a first from other requests). The client just asks the user agent to go to it, no parameters added. The client has no way to modify what's in this url.
Keeping clients dumb is realy important, as it's one of the biggest things we got right in OAuth2.
User gets redirected to the URL, then to the callback_uri. In XYZ, this has an "interaction handle",which allows the client to continue the tx (XCont) by saying "yes i can prove i got sth back from the front channel".
Someone asks if the expectation with the XCont is that the transaction actually continues or could be complete.
People don't handle error cases in the front channel properly. XYZ helps because it's easier to tell state because of interact_url, X_H etc.
We don't need a whole bunch of error messages coming back, because if the user denies the request, the client will know when it tries to proceed.
Once I get an AT, I can also get another tx handle X_H with the AT. In OAuth2, I'd need a refresh token. In XYZ, this is done through continuing the tx through its handle.
Someone asks if we can do downscoping etc through this process too. Justin doesn't know what, but he feels like this would be done through creating a new tx based off the results to a previous tx. "and btw I've already done this bit". There's still work to be done in specifying how these things would work.
PKCE isn't needed anymore since you're not relying so much on the front channel. XYZ grants you the same type of crypto protection without needing PKSE.
DYNReg. There aren't really "public clients" anymore, because when you start a tx you start it with a key.
In OAuth2, everything hangs off the client. In XYZ, you don't need that. The client is just an aspect of the tx itself, and the tx is the primary model. The client is just about "who started this":
Someone says that from an implementation perspective, the client is super important. They'd need to know that this request is coming from this particular entity, with a high level of assurance. Justin says "sure, that's why you use the client secret". They object and say this makes it harder to disable bad actors. Justin says this is possible with XYZ because your AS always know the client's keys, and you don't need to expose a client ID for that.
Someone else says the client identity's may not matter from a protocol/sec protocol, but it does matter a lot from an operational/Deployment standpoint. They don't think key IDs are sufficient, because if they are an operator they want to be able to aggregate txs from one client across all devices, and not just one. Also important for end users to manage their active sessions. Someone else agrees and adds to this to say this is super important from a user consent perspective. Justin says this supports his point about moving away from client id, in which you can't diff between 2 instances of a client vs 2 different clients.
Someone says this all sounds like we shouldn't be rebuilding OAuth from the ground up just because OAuth2 isn't perfect. Also that DYNReg would be an issue from a regulatory perspective because it allows for anonymous registrations. Someone else agrees. Justin doesn't respond.
JSON allows us not to use form encoding anymore.
DPoP gives the client agility to be able to say "this is the kind of key i want to prove, and here's how i can prove it". What kinds of keys are allowed to do what kind of things? This proof happens and is included in every request.
UMA2 is about no longer making assumptions that the person using the client is the resource owner, and this can be done asynchronously in XYZ because of tx handles and continuation requests.
Someone asks how you communicate the next url for resource discovery, in subsequent requests? Justin says resource discovery is hard and hasn't been properly specced yet, but it'll be easier with the use of RAR.
*********** *********** ************** *************** ************ **********
2. Notes from Justin Richer:
Please add the following URLs for all the related specifications and workgroups to the session notes.
XYZ: https://oauth.xyz/ https://tools.ietf.org/html/draft-richer-transactional-authz-02
PAR: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
RAR: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
JAR: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19
PKCE: https://tools.ietf.org/html/rfc7636
DynReg: https://tools.ietf.org/html/rfc7591 https://tools.ietf.org/html/rfc7592
DPoP: https://tools.ietf.org/html/draft-fett-oauth-dpop-02
UMA2: https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html
CIBA: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html
