Re: [Txauth] Polymorphism (Was: JSON Schema?)

[Dick Hardt <[e-mail]>]

Hi Steve

XAuth does make use of polymorphism, just not with JSON types. The
authorization object has a "type" property that indicates the semantics of
the rest of the authorization properties.

Justin's statement:

"the XAuth protocol was not designed with polymorphism as a tool to
consider"

seemed pretty clear to me that Justin stated that I did not consider
polymorphism in the design of the XAuth protocol, but to confirm, I asked
him to clarify, but have yet to get a response on the list.

Justin has stated:

"GNAP should make use of a polymorphic protocol structure"

and then later:

"I think polymorphism should be one of the tools in consideration from the
start."

Which statement is his position?

While my comments were personal in nature as I was commenting on Justin's
response, they were not intended as an attack on Justin. In expressing my
disappointment in not getting a response from Justin, my frustration came
through and I apologize to the list and Justin for what I see could be
construed as counter productive.


/Dick



On Wed, Jul 8, 2020 at 11:09 AM Stephen Moore <[e-mail]> wrote:

> Hi Dick,
> I've looked over your draft, and the emails here. You said you didn't use
> polymorphism, and the draft does not appear to use polymorphism. I'd think
> it is safe to say that the XAuth protocol was not built with polymorphism
> in mind. I don't think that Justin meant to imply you didn't consider it,
> but rather that from the discussions (up to that point) and the draft
> itself, it doesn't say polymorphism is a tool that can be applied in the
> tokens.
>
> As for the "GNAP should make use of a polymorphic protocol structure",
> that's just his position on what he thinks GNAP should do. I don't really
> see how that is a 'mistake'.
> -steve
>
> On Wed, Jul 8, 2020 at 12:55 PM Dick Hardt <[e-mail]> wrote:
>
>> Justin: it is disappointing that you deflect from responding to:
>>
>> It’s not surprising that this is the case, as the XAuth protocol was not
>>> designed with polymorphism as a tool to consider. This is exactly the
>>> reason that I say we should have polymorphism in the toolbox from the
>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>
>>
>>  What evidence do you have to make this statement? "XAuth protocol was
>> not designed with polymorphism as a tool to consider"
>>
>> Similarly, you deflected responding to your statement:
>>
>> "GNAP should make use of a polymorphic protocol structure"
>>
>> How are we going to have a productive conversation when you won't
>> acknowledge mistakes, either intentional, or unintentional?
>>
>> wrt. your proposal to represent an authorization request as an array of
>> scopes is overly simplistic. Both XYZ and XAuth represent the request as an
>> object to enable a request richer than just an array of scopes.
>>
>> /Dick
>>
>>
>>
>> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer <[e-mail]> wrote:
>>
>>> I’m glad that you’re looking at polymorphism as a possible solution to
>>> this, though I would contend that this particular style of polymorphism is
>>> not doing much more than pushing the mutual-exclusivity check down a layer
>>> instead of solving it.
>>>
>>> Using multiple types can in fact solve this problem, and several others,
>>> as long as you’re willing to let go of the syntax that OAuth 2 invented to
>>> solve a problem that we don’t have to solve here (passing an array-type
>>> value over the front channel). In XYZ’s syntax, the request for a single
>>> access token would look like this:
>>>
>>> {
>>>   “resources”: [ “read”, “write” ]
>>> }
>>>
>>> And the request for the multiple access tokens would look like this:
>>>
>>> {
>>>   “resources": {
>>>      “reader": [ “read” ],
>>>      “writer”: [ “write” ]
>>>   }
>>> }
>>>
>>> I find this to be much simpler to parse and generate, as you no longer
>>> need to check for a specially-reserved field name (“type”), and you no
>>> longer have to do a sub-parse on one of the values to get what you really
>>> want (the space-separated scope string into a set). It’s also a lot simpler
>>> for the developers that need to write this.
>>>
>>>  — Justin
>>>
>>> On Jul 7, 2020, at 7:30 PM, Dick Hardt <[e-mail]> wrote:
>>>
>>>
>>>
>>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer <[e-mail]> wrote:
>>>
>>>> I wanted to respond to this comment more fully:
>>>>
>>>> > wrt. my authorization / authorizations oddness, polymorphism would
>>>> not solve it as the contents of both authorization / authorizations in
>>>> XAuth are objects.
>>>>
>>>> It’s not surprising that this is the case, as the XAuth protocol was
>>>> not designed with polymorphism as a tool to consider. This is exactly the
>>>> reason that I say we should have polymorphism in the toolbox from the
>>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>>
>>>
>>>  What evidence do you have to make this statement? "XAuth protocol was
>>> not designed with polymorphism as a tool to consider"
>>>
>>> It sounds like you are saying I did not consider polymorphism in the
>>> XAuth protocol design.
>>>
>>> I will restate my comment above about polymorphism.
>>>
>>> Using different JSON types does not solve the problem, but as I suggest
>>> in my comments, polymorphism of different JSON objects is one solution. An
>>> authorization, or a dictionary of authorizations. It has the restriction
>>> that the string "type" cannot be used as a label in the dictionary. An
>>> example:
>>>
>>> {
>>>     "authorizations" {
>>>         "type": "oauth_scope",
>>>         "scope": "read write"
>>>     }
>>> }
>>>
>>> {
>>>     "authorizations" {
>>>         "reader": {
>>>             "type": "oauth_scope",
>>>             "scope": "read"
>>>         },
>>>         "writer": {
>>>             "type": "oauth_scope",
>>>             "scope": "write"
>>>         },
>>>     }
>>> }
>>>
>>>
>>> I am looking at making this change in XAuth and in the implementation.
>>>
>>>
>>>
>>> ᐧ
>>>
>>>
>>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> ᐧ