Re: [Txauth] Changes to XYZ

[David Waite <[e-mail]>]

> On Oct 11, 2019, at 8:30 AM, Justin Richer <[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"
  }

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

-DW