Re: [Txauth] Turning polymorphism up to 11 (P11)

Justin Richer <jricher@mit.edu> Mon, 13 July 2020 13:27 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 751F53A11CE for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 06:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mE8k9yfGeVyg for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 06:27:53 -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 6254C3A117C for <txauth@ietf.org>; Mon, 13 Jul 2020 06:27:53 -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 06DDRopm028354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 09:27:51 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <33EB90F0-D7FB-4C15-B5C4-0B265A818007@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_82D2C698-5D4C-4AAC-908B-92B6976C7696"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 09:27:50 -0400
In-Reply-To: <CCAF4A53-9836-4CB1-AB47-154C517ACFC5@gmail.com>
Cc: Dick Hardt <dick.hardt@gmail.com>, txauth@ietf.org
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <CAD9ie-tLwzoqv08dVC+iZme9wRTF6HZh2MVuorLRCr986A=LFw@mail.gmail.com> <CAD9ie-tuenNGRzggE4=1friK-7mXKPvwDM9BzPo4prYS77voew@mail.gmail.com> <CCAF4A53-9836-4CB1-AB47-154C517ACFC5@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/fTlxYdF_uZS4WpN8Pzo130Sb-hM>
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
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: Mon, 13 Jul 2020 13:27:55 -0000

Yaron,

Just as a data point: As it turns out, the type of polymorphism that I am proposing is in fact expressible in JSON Schema. I was unaware of this construct previously, since I don’t use JSON Schema with any regularity:

https://json-schema.org/understanding-json-schema/reference/combining.html#anyof <https://json-schema.org/understanding-json-schema/reference/combining.html#anyof>

I am unaware of the exact expression capabilities in any of the other half-dozen JSON-based schema definition languages, though. :) 

As for misunderstanding values, avoiding such things is actually the motivation behind the design I am proposing. A given data type in a particular place should have one and only one interpretation at all times.

And finally, as for the comment about the client needing to understand the response, perhaps the AS shouldn’t be the one doing the transformations when it returns data back to the client, and that should be restricted for exactly this reason. Additionally, I know of few OAuth clients that actively check the returned “scope” value in the wild. I know they are out there, but the common practice, in my experience, is to ask for stuff and use whatever comes back. I think the conversation on “directed tokens” might help us change this in a clear way, and it could include rules on how the AS is allowed to return information.

Thanks,
 — Justin

> On Jul 13, 2020, at 5:02 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
> 
> <no hats>
>  
> The issue of polymorphism is somewhat religious, similarly to strong vs. weak typing in programming languages, and I am of the non-polymorphic (unimorphic?) persuasion. Specifically when it comes to security protocols, where a recipient misunderstanding a value can easily result in a vulnerability.
>  
> With respect to a schema language, IMO the fact that it is difficult to express some polymorphic constructs in JSON Schema is a reason to avoid these constructs, rather than go looking for a different schema language.
>  
> Thanks,
>                 Yaron
>  
> From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
> Date: Monday, July 13, 2020 at 03:56
> To: <txauth@ietf.org>
> Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
>  
> For those not familiar with "turning up to 11" https://en.wikipedia.org/wiki/Up_to_eleven <https://en.wikipedia.org/wiki/Up_to_eleven>
>  
> A counter argument to all of this polymorphism is that the AS is sending back the granted authorization. While pushing type detection to the AS to provide a simpler interface for the Client, it seems counterproductive if the Client has to do the same. A consistent response from the AS will be simpler for the Client, but would then also be different then what the Client originally requested from the GS.
>  
> On Fri, Jul 10, 2020 at 6:01 PM Dick Hardt <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote:
>> Taking Justin's model of strings being shortened versions of OAuth scopes, adding in the "type" property from RAR, and defining a default type, we *could* add a bunch of polymorphism. (I have not implemented the code below, but it looks doable assuming I have not overloaded a type in the same context)
>>  
>> /Dick
>>  
>>  
>> Let's start with a request for 2 authorizations using OAuth scopes, one for writing and the other for reading:
>>  
>> (1)
>> {
>>     "authorizations": {
>>         "writer": [
>>             { 
>>                 "type": "oauth_scope",
>>                 "scope": ["create","update","delete"]
>>             }
>>         ],
>>         "reader": [
>>             { 
>>                 "type": "oauth_scope",
>>                 "scope": ["read","list"]
>>             }
>>         ]
>>     }
>> }
>>  
>> We can ask for just one token with all the same capabilities:
>> (2)
>> {
>>     "authorizations": [
>>         { 
>>             "type": "oauth_scope",
>>             "scope": ["create","update","delete"]
>>         },
>>         { 
>>             "type": "oauth_scope",
>>             "scope": ["read","list"]
>>         }
>>     ]
>> }
>>  
>> Of course (2) can be simplified as:
>> (3)
>> {
>>     "authorizations": [
>>         { 
>>             "type": "oauth_scope",
>>             "scope": ["create","update","delete","read","list"]
>>         }
>>     ]
>> }
>>  
>> Now let's say that in "oauth_scope", the array of scopes can also be a space separated string. So the following is equivalent:
>> (4)
>> {
>>     "authorizations": [
>>         { 
>>             "type": "oauth_scope",
>>             "scope": "create update delete read list"
>>         }
>>     ]
>> }
>>  
>> Now let's say that the "oauth_scope" type is the default, so we can express it as:
>> (5)
>> {
>>     "authorizations": ["create","update","delete","read","list"]
>> }
>>  
>> Or use a space separated string instead of an array:
>> (6)
>> {
>>     "authorizations": "create update delete read list"
>> }
>>  
>> In summary, (2) - (6) will give the exact same result.
>>  
>> Let's add another authorization type to the request, "customer_information":
>> (7)
>> {
>>     "authorizations": [
>>         "create update delete read list",
>>         {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers <https://example.com/customers>",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }
>>     ]
>> }
>>  
>> And the space separated strings can be turned into individual strings and we have the equivalent request:
>> (8)
>> {
>>     "authorizations": [
>>         "create",
>>         "update",
>>         "delete",
>>         "read",
>>         "list",
>>         {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers <https://example.com/customers>",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }
>>     ]
>> }
>>  
>> Let's go back to our first example, and ask for 3 separate tokens:
>> (9)
>> {
>>     "authorizations": {
>>         "writer": "create update delete",
>>         "reader": "read list",
>>         "customer": [
>>             {
>>                 "type": "customer_information",
>>                 "locations": [
>>                     "https://example.com/customers <https://example.com/customers>",
>>                 ],
>>                 "actions": [
>>                     "read"
>>                 ],
>>                 "datatypes": [
>>                     "contacts",
>>                     "photos"
>>                 ]
>>             }    
>>         ]
>>     }
>> }
>>  
>> In a multi token request, if there is only one item in the array, we can shorten (9) to the following:
>> (10)
>> {
>>     "authorizations": {
>>         "writer": "create update delete",
>>         "reader": "read list",
>>         "customer": {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers <https://example.com/customers>",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }    
>>     }
>> }
> 
> -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth 
> -- 
> Txauth mailing list
> Txauth@ietf.org <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>