Subject: [Txauth] Changes to XYZ

From: Justin Richer <[email-masked]>
Date: Fri, 11 Oct 2019 14:30:34 +0000

Following last week’s great conversations at IIW, I’ve made a handful of changes to XYZ:

 - Clients can now signal more than one kind of interaction is possible. Syntactically this means we’re sending keys with booleans instead of a “type” key with a string value. Practically this means that the AS now can choose from among a set of options that the client can do and determine what makes the most sense, probably allowing multiple options that it supports.
 - Among the new interaction options are “didcomm" and “didcomm_query”, which give us a way to bridge to another kind of front channel that doesn’t use the web browser. In this case, DID-based agents. I can envision lots of other options, from webauthn challenge/response to direct app communications.
 - Key presentation and key format are now separate from each other. This doesn’t really have much impact on the syntax as it turns out, just the assumptions of what the underlying model is. A “key handle” will still represent a pair of key and presentation method.
 - I renamed the “client” section to “display” because that’s more what it was — user-facing elements. It’s my hope that this will be less of a place to hang everything off of, like the client ended up being in OAuth2.
 - I shuffled around a few things to show how the continuation request can happen, and hopefully show how it’s different from a base transaction request. The question still remains of how to specify a continuation request with additional features (more resources, more client info, etc), and that’s going to require careful wording in the client definition.
 - The “data” element of the resource request is now “datatype”, from feedback on RAR.
 - I added a “capabilities” array to both the client’s request and server’s response, which will list a set of extensions that are supported. It’s a way to do general purpose discovery through this same interface, and it fits the transaction model well (“this is what I can do, tell me what you can do”).

I’ve updated the website https://oauth.xyz/ with these changes, but I haven’t had a chance to update the spec draft text or the implementations yet.

I’d love to start getting feedback on these ideas as we’re moving towards the BoF in Singapore!

— Justin

---

From: David Waite <[email-masked]>
Date: Fri, 11 Oct 2019 12:09:00 -0600

> On Oct 11, 2019, at 8:30 AM, Justin Richer <[email-masked]> wrote:

<snip>

>  - Clients can now signal more than one kind of interaction is possible. Syntactically this means we’re sending keys with booleans instead of a “type” key with a string value. Practically this mean…

Would it make sense for the interaction configuration to be the value of that key? e.g.

  "redirect": {
    "callback": "https://client.example.net/return/123455",
    "nonce": "LKLTI25DK82FX4T4QFZC"
  }

>  - I renamed the “client” section to “display” because that’s more what it was — user-facing elements. It’s my hope that this will be less of a place to hang everything off of, like the client ende…

It sounds like the use of the term “client” is being deemphasized in the protocol. Would a tweak to the role name potentially be in scope, or would we want to avoid the arguments that come from adding that whole extra wing onto the current bike shed?

I ask because while I have obviously gotten very comfortable with the use of the term client, the generic nature of the term does cause collisions and confusion when OAuth is adopted into a pre-existing space.

It may also be that the use of ‘client’ gets qualified and/or deemphasized once you are talking about the role only in the context of interaction with transaction endpoints.

-DW

---

From: Justin Richer <[email-masked]>
Date: Fri, 11 Oct 2019 19:26:10 +0000

On Oct 11, 2019, at 2:09 PM, David Waite <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 11, 2019, at 8:30 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

  "redirect": {

That’s an interesting idea, and that’s kinda why “callback” is an object but “redirect” is a boolean now. I’d looked into doing exactly what you suggest above, but I think it makes more sense to keep them separate because the way the client can get the user :out: to some interaction piece and the way the client gets information :back: from the AS could be different.

Take for example the device-with-QR-code case. Here you have a client that’s capable of getting the user to an arbitrary URL (by having the user scan a QR code), but not back from it on the same channel. So that’s a “redirect” interaction but without the “callback” portion. Or with the DIDComm work, the client could get the user out to an agent with a DIDComm message, but then the agent might send its responses directly to the AS through some shared fabric, while the client polls.

So it’s not so much that the “client” is de-emphasized in the protocol, so much as that section isn’t really talking just about the “client” as a whole piece of software, and I think it’s important that we don’t pretend that it is. Otherwise we run the risk of lots of other stuff, like capabilities and keys and callbacks and scopes, all getting dumped into that section. In other words, it’s an attempt to separate concerns.

I believe that in OAuth2 we’ve got an unfortunate situation where the “client” data object became the thing that we hung :everything: off of. And so we need the “client_id” everywhere because that’s the only chance we have to switch a whole bunch of functionality. It’s awkward and I think e can do better with this. Keeping this section to just “user-facing display information about the client software instance” is one step toward there.

I don’t really want to bike shed the name of the role right now, even with its baggage. What’s more important to me is that we get pieces of the protocol to represent what we intend them to in a clear way.

 — Justin