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

Justin Richer <jricher@mit.edu> Tue, 07 July 2020 10:40 UTC

Return-Path: <jricher@mit.edu>
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 E36533A0A97 for <txauth@ietfa.amsl.com>; Tue, 7 Jul 2020 03:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E5rMRdocuRQA for <txauth@ietfa.amsl.com>; Tue, 7 Jul 2020 03:40:50 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C32B3A0A94 for <txauth@ietf.org>; Tue, 7 Jul 2020 03:40:50 -0700 (PDT)
Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 067Aelrt022165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 06:40:48 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAD9ie-vyB8+5jS=K_qUHfvxsF2wPV5APRo+7WUDfJxNzJONJpg@mail.gmail.com>
Date: Tue, 7 Jul 2020 06:40:47 -0400
Cc: txauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>
References: <CAD9ie-vnA98pobbboS00SAHneEG52_8eMxh_sE3r3jg6gyooGg@mail.gmail.com> <E9EC90C9-7A9A-4909-8627-A161B33E941F@mit.edu> <CAD9ie-vyB8+5jS=K_qUHfvxsF2wPV5APRo+7WUDfJxNzJONJpg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/c5jgCEv4y85qgCPZaW4YNEpW3Kk>
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: Tue, 07 Jul 2020 10:40:52 -0000

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.

The equivalent “resources” structure in XYZ uses an array to convey the scope strings and the rich request objects at the same level. This allows the protocol to have one construct, the “resources” array, that contains items that describe what rights the client is requesting in the resulting access token. An array of items is the natural representation of such a construct in a JSON-based protocol.

The reason for this design is a simple adaptation of OAuth 2. The native data structure underlying the OAuth 2 “scope” parameter is a set, but OAuth 2 had to invent a standard serialization for it (the space-separated single string) in order to convey it across the front channel as a query parameter. I remember we’d considered making it an array in the token endpoint response, but ultimately decided to keep it consistent with the lowest-common-denominator representation, which makes sense. However, we aren’t bound to that limitation of OAuth 2 anymore and so there is no reason to keep the space-separated-string notion around. At the very least, scopes should be a native JSON array of strings. RAR uses a JSON array of objects natively, but encodes it as a URL-encoded string in order to fit into OAuth 2’s front channel and token endpoint push. Should we also keep the encoding part of RAR if we keep the space-separated-string encoding of scope from OAuth 2? It certainly seems silly to argue for that, and  would argue that we need neither string-based encoding and we can use native structures for both.

Since GNAP is also allowing fine-grained requests as well as the more course-grained scope style access, we can also put them together. This would allow us to have a single array of elements, each element being either a single string or an object with multiple dimensions. 

Now: while this is an example of the benefits of polymorphism at the protocol level, how does this help the authorization/authorizations conundrum above? In XYZ, a single access token request is an array of “resource” elements, but a multiple access token request is an object/map, whose values are the same “resource” arrays as a single request. This makes the requests much more consistent to create and parse than having two closely-named and mutually-exclusive properties. 

This isn’t a magic panacea though, and it requires a bit of work to apply the tools well. When I added multiple access tokens to XYZ, I didn’t want to change the format of the single access token, which was already an object. The natural response type of the multiple access tokens was also an object, and so we ended up with — you guessed it — a pair of closely-named and mutually-exclusive properties. I don’t like it, and I think there’s likely a better way around this, but I haven’t gone back to try and design that problem out yet. But it’s something that I think we can likely address in GNAP, especially if we’re willing to step back and change how we look at things.

 — Justin