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

Stephen Moore <srmoore@gmail.com> Wed, 08 July 2020 18:09 UTC

Return-Path: <srmoore@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 11DA73A05A0 for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:09:23 -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 Kw3mHKhVVB-5 for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:09:21 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 295343A059F for <txauth@ietf.org>; Wed, 8 Jul 2020 11:09:21 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id g6so2740821ybo.11 for <txauth@ietf.org>; Wed, 08 Jul 2020 11:09:21 -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=1F1LLnq+Hudu6s6ecnW/D85yhDBx+FzpG1dS0uJcXpI=; b=bMqjDGC++1eKhgj7bsGOJFJY1cn+AjOoH7B06rs/H9gb9JKYeyidk7L4IlYkJx/yUg V4S6IkvRTqPxvFT9urE+h5F1v4UQaQWvz0JWP/L74e1gqp9A+z+u7kH4PbvzMxPE4EtS dyvxaFTjxCRzuliv8NcCpiT18/XmjxwfXYL824waXyN373+sl2OmylpghOfABJNdDmtL mhJg3B4Qa8NsATPUK5VamNn0x1bg5YZqXqm+7xTaaOQ5CHcdY3p/weiRPg1bvpRropJY bIOKicyEB6e6WDiyhaRQorcCThnWlj5vATyBNA/GyPtAps6UiwseBWju0PwWms3h1W84 qB7g==
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=1F1LLnq+Hudu6s6ecnW/D85yhDBx+FzpG1dS0uJcXpI=; b=ihpjMMpwlhLaTuPCeAlhOVbQCP7i9YCOqgDsKgUUC7r/xIh9976Pd1vqWi4dvOON8V FKimo76yHRMKfktF7KXXQcnLAM1XslxOttzi5EywrXX7B+tnw+2yDWzCuPlVpV99yyhE 7RPhOTXVPlgdxhdcyWPTW+QxizByb1TE69K+5hcrep+dM5T9boWPDeAynvUVtQ9HB2e9 HhfLuLGGROla8O5isuQribCUysXDVirJr6B6b7Szq04+GmjyGZXUMYmo8N8w9LLWGOIN VDV6AvuAmjdlzweGCOOgYNCDNA9EPKikp+TJ0vrKFgWvgYEebmXcW8eas2FBlx2t34Tv fAfw==
X-Gm-Message-State: AOAM531SAxlj3oXZOZ/zkyS0nbUbxXWB53RMDB6mmg5P4n0i4KaOi70u GfYLZFbLUdrJznOVi5/cOTbSMue2EJkT45g33Fj7f87c
X-Google-Smtp-Source: ABdhPJyQwXOb8Qt8+uBYdue8Qtx6FXfzQ2Q8tEp2cnxHXva1Yc9ndFGXrsgO86UK/GUsRc7FQN2lTILcDTgD5hZ4pe8=
X-Received: by 2002:a25:46:: with SMTP id 67mr10680249yba.517.1594231760323; Wed, 08 Jul 2020 11:09:20 -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>
In-Reply-To: <CAD9ie-tpuisauOFGiUj65-RcYPtcvW_gZP1CAadqq5cE6P36HQ@mail.gmail.com>
From: Stephen Moore <srmoore@gmail.com>
Date: Wed, 8 Jul 2020 14:09:08 -0400
Message-ID: <CAK5Vu_CxQ45SabbAYFUqpZ4-XUSsQp8uqFijNZL+Ppg3K--+cg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c3874305a9f201e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/3Yvwz5xseJ4iWh9n4P9wkpP7sBQ>
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:09:23 -0000

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
>