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

Justin Richer <> Mon, 06 July 2020 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B7C03A0AF9 for <>; Mon, 6 Jul 2020 14:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yowPTaQOSFnQ for <>; Mon, 6 Jul 2020 14:15:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3C7D3A0AF8 for <>; Mon, 6 Jul 2020 14:15:07 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 066LF48b012567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 17:15:05 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB20E481-6885-4725-A14B-DFA72E23A1B2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 6 Jul 2020 17:15:04 -0400
In-Reply-To: <>
To: Dick Hardt <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 21:15:10 -0000

I once felt that way, too, and the first few iterations of XYZ did not use polymorphism. But I found, through hands-on experience, that it solves many more problems than it creates. I think that JWT didn’t quite do it because there was one limited place in the spec that used the feature — it was the exception, not a core part of the data model. And, JWT implementations that don’t expect an array in “aud” aren’t compliant, after all.

This is obviously an implementation detail for the WG to debate, and I think polymorphism should be one of the tools in consideration from the start. 

 — Justin

> On Jul 6, 2020, at 4:41 PM, Dick Hardt <> wrote:
> Responding to Justin's polymorphism comments ... 
> On Mon, Jul 6, 2020 at 12:54 PM Justin Richer < <>> wrote:
> Polymorphism in the protocol is an important part of the XYZ proposal’s design, and as a feature it directly addresses a number of the items you found when doing your XAuth implementation, like parsing OAuth scopes and dealing with the authorization/authorizations mutually-exclusive oddness that you mentioned. I strongly believe that GNAP should make use of a polymorphic protocol structure for these and other reasons. Polymorphism is a built-in feature of the JSON data model, and it’s also fully possible to support under CBOR and other data serialization languages. Even JWT most famously uses polymorphism for the “aud” field, which can be a string or an array of strings depending on context, all with clear semantics.
>  I strongly disagree with "GNAP should make use of a polymorphic protocol structure"
> We should use it only if we really need it, and it makes implementations simpler. I personally don't think it accomplished that in JWT with the audience. I would bet there is a fair amount of code that does not check if the 'aud' property is an array, it just assumes it is a string.
> wrt. my authorization / authorizations oddness, polymorphism would not solve it as the contents of both authorization / authorizations in XAuth are objects. 
> /Dick