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

Tom Jones <thomasclinganjones@gmail.com> Wed, 08 July 2020 17:10 UTC

Return-Path: <thomasclinganjones@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 9304B3A0FD9 for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 10:10:57 -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 zAn8hx4ZI6dY for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 10:10:55 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 073483A1044 for <txauth@ietf.org>; Wed, 8 Jul 2020 10:10:41 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id h13so16904932otr.0 for <txauth@ietf.org>; Wed, 08 Jul 2020 10:10:41 -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=JvFzQvF2wNAlsK6eUTWunmxbUErSl2FxJHP6vxIKer8=; b=DnEy58abrvTsb69BLpNaxBI58PwWjfAcsQluabL9J1U5A7cCITAaVwZ4n2UvxF6zSD S79rUnBT/voBQaSxHhe4/niljDStOoShXRniVbIfUgAOEb2NEg5I/z94SWAD4yfDxUfa /QEQmO30UvTx4zx+xCX8YOdtV0EcYB551wBtJv+mIfo03JCCxuscM3MrwdShH7ms9HSL J2NKn1/ph8GX20yJvSsUwtc7/baRAdzl7RnyqDNU0J+EZ916++caDLIMclNpH6ueqrzw cLS4s2kWRiXaRBA6w6VEf8bhby8CWDq3kEjp6Kdf43DnvIW4lSX9xOWhx3gzCUDYh0HK hvaA==
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=JvFzQvF2wNAlsK6eUTWunmxbUErSl2FxJHP6vxIKer8=; b=T6J3I4XYgZ2jMEi/QhMHZ0PaJvgp/Hq/pWGQc1w/EySP/ir4EeEMZ9+62ItSPl+HEM sf1rJLv+ZUNe/6cSMj9Iun4CXbGrD9IxiygYp/lRSCR/8nmSB7gdljLs1jG6w+I7An1M iLvnXmnhdy1Mi2vXmLBfFb3GwKMsdLiGJIYyuyN3meM/5+Or3tvWUIMqK2IRBnAOkf5U uLRRZAj8C9nc/f7lahYZ1uA5Q/F/4fcFqnUqu1elbRDP+jiw9tVU6+zMmB53d2XXr1rk xEpgdujedRKisAvh2eVpXFGuuyWWV+fhNeAWtKDc26J+RJQ6ojha63HbINneGM+3Bj+Q 9s8w==
X-Gm-Message-State: AOAM530xnGVe1MNxpUZYGbyM/S3t/Akvrg7VLiaCTaLTex5uhuf7640T x6nvOh2iAVOCgOkGWi+0tnuIBaMrnWwx3cC0SXs=
X-Google-Smtp-Source: ABdhPJxxj7rN5AEaRDQHYrHGq2o8sVpEPgpFY9qcUJ6soMBdZrRs31qNjAgSwvGaTP+E2/HWZq0PWkp0N/WmTnw7csQ=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr33657650otm.358.1594228241025; Wed, 08 Jul 2020 10:10:41 -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: Tom Jones <thomasclinganjones@gmail.com>
Date: Wed, 8 Jul 2020 10:10:29 -0700
Message-ID: <CAK2Cwb6j0owdCS9Z57R1C-7Ug9iAyvXwS44hqQFHAtakzxGVzA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ff5bdc05a9f12fc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/_yh0It3rtuHptG-Y63BLqN1YxC4>
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 17:11:04 -0000

a somewhat milder response might be.
It seems that justin's proposal is not, in fact, a grant negotiation, but a
generalized token format.
So - what could that mean here?
I have a problem with the whack-a-mole approach of OAuth, with RAR JAR ad
infinitum.
That is a never-ending stream of hacks.
if Justin's proposal is to be considered seriously, it must be at some
higher level that GNAP..
I suggest  that the current approach of xauth txauth authxyz is not really
headed to a convergence.
Perhaps we need to start with an abstract set of goals and data flows.  One
that includes the user/RO.
I do have one for healthcare - but i am short of time right now to
generalize it.
One item I would like to see resolved early is to remove the dependency on
transport layer security. One that includes the handling of key roll-over.
In Kantara we focused first on the legal responsibilities of the token
maker. That problem seems to have consumed FAPI, altho they have multiple
names for it.
In the real world we have legal entities (natural and unnatural) and legal
names (brands) as well as pseudonyms. OAuth just had endpoints with SSL
keys and certs.  How about we start there?
Peace ..tom


On Wed, Jul 8, 2020 at 9:55 AM 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
>