Re: [Txauth] Changes to XYZ

[Justin Richer <[e-mail]>]

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

On Oct 11, 2019, at 8:30 AM, Justin Richer <[e-mail]<mailto:[e-mail]>> 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 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.

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"
  }


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.

 - 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.

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.

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