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

Dick Hardt <dick.hardt@gmail.com> Wed, 08 July 2020 18:59 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42063A00AE for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV68-MUVg9GD for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:59:15 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBAC3A0063 for <txauth@ietf.org>; Wed, 8 Jul 2020 11:59:14 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id q4so19762374lji.2 for <txauth@ietf.org>; Wed, 08 Jul 2020 11:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DDVJKmbYoeZO+XYbKcpbEsn1NIAyLpbApgk9hs9iVQc=; b=hWyzVUK0B4OQzjkGMTiEvhm9lva8fflouQbIlLUauzNWMbV1pbOq4bFiIsupfzs1h9 JAClHYHgbGxrIRz3ZjZcse8MJmUwdexyW/wRITd6e+VAjrShQc63Dcq/mnfF4v+qYOHj zcRMiHG+o506gALeOvDu8/EjSNpsYQ3UerkAJdR/SSv8C7pyB0FZD2CabTrD5kZZRNcl pOfxMTkh5R3af8ljmqEq0TfOcFXe1X3v6R91roJ83vLq5gq7gdwEA+rbh7p4vZkVYG3O 27R6NRLqF1ChJdui6artAEN6kepT8vCNeFS7pt4fQd8S/WhZ+X8uYZYKKKx3YuRUZjkh Fabw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DDVJKmbYoeZO+XYbKcpbEsn1NIAyLpbApgk9hs9iVQc=; b=NdOcx70VKmdjUKVyjoNmrwfMdXocU9dgDnKLE1Wc+TyYjeG1GR0UQJ4FNznmJDm4Yg KwWY4LHLhdwxHkKtSC4jC0QiRT7Ynr2LIFHsVGKfGSTr1Ifi0uF5Nb586O8V+1vE1cXb i/1XAcr7jKlXHB7plNqKDkZpecoHry9R0i2R1iw9cpMDpjasDaahVHv40ZT4iklyxGJB 2FiXaV0vS68rNr7gbTorvKOs33zyxtX6KOJisX8qxnztIYtI6GXZx/KoQdQRYt6GbWiH B8IXNi1VmLduYYjpjcFwd+Ynp9T4U6nUuv10uit805meREDIYi1Q/b4DoCs+A8DgDT+x Y3AQ==
X-Gm-Message-State: AOAM531viRudWi2V2URfWqk52aGeoJLx4fFvfUrRX8BmCKzQbJDwrXAu 2gyG7bJg6N44i1HwTu5zyBu4WbGHfiSsfFYbC34=
X-Google-Smtp-Source: ABdhPJzGk9jPX2nuLUKobvb12BJ5NMtN3yxeGJdfwTEADSkBpyF8ZXnFYTmMQCP4Fcj0okvkJdC7qnVJKUqVbx3vmyw=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr23002467ljh.110.1594234752566; Wed, 08 Jul 2020 11:59:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-vnA98pobbboS00SAHneEG52_8eMxh_sE3r3jg6gyooGg@mail.gmail.com> <E9EC90C9-7A9A-4909-8627-A161B33E941F@mit.edu> <CAD9ie-vyB8+5jS=K_qUHfvxsF2wPV5APRo+7WUDfJxNzJONJpg@mail.gmail.com> <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu> <CAD9ie-u9z7Mc-wNjztoOTy4N_Z9jFDc2Sb6quLspasMGAMKdSw@mail.gmail.com> <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> <CAD9ie-tpuisauOFGiUj65-RcYPtcvW_gZP1CAadqq5cE6P36HQ@mail.gmail.com> <CAK5Vu_CxQ45SabbAYFUqpZ4-XUSsQp8uqFijNZL+Ppg3K--+cg@mail.gmail.com>
In-Reply-To: <CAK5Vu_CxQ45SabbAYFUqpZ4-XUSsQp8uqFijNZL+Ppg3K--+cg@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 8 Jul 2020 11:58:36 -0700
Message-ID: <CAD9ie-tCZd2-V3mtchiKYkKj7n1szs6PNmj2YoVV4osp5YJTwQ@mail.gmail.com>
To: Stephen Moore <srmoore@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001d8f5f05a9f2b40f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/IzI7Kjfd6boqKk6YvIkf2ml8dU0>
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 18:59:18 -0000

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 <srmoore@gmail.com> 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 <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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 <dick.hardt@gmail.com> wrote:
>>>
>>>
>>>
>>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer <jricher@mit.edu> 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
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> ᐧ