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

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 13 July 2020 09:02 UTC

Return-Path: <yaronf.ietf@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 AD71F3A0C6A for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 02:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Level:
X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=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 qZlOTQ1XDjFz for <txauth@ietfa.amsl.com>; Mon, 13 Jul 2020 02:02:54 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 BD4A23A0C61 for <txauth@ietf.org>; Mon, 13 Jul 2020 02:02:53 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id z13so15126642wrw.5 for <txauth@ietf.org>; Mon, 13 Jul 2020 02:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=gtIGTHoMxgxbkgvPmMMJnAubKCA+EoJLjmC+bTSN3Vo=; b=KF481GKKoflUD58n+Kw44JkFn8AlSxUih24nsAfYTNAgCbFFWUgcE0X6gJT7nbv/Gl EiUSgd1F8OTK9LSSspJDqY5pyYa7djviKuLw0cTgYKZ9kgFKArhuLDyTj/mBIw7PrwZF 7tSBHHXU9rHlsZY0uF1CPOw47+W7ItGuIsEkb+aazlArdMPg3xC0dMWI4g+YnuZJOhvK hiXaq3lMOqFg7n3ycfm7bA59Y+L3b2MxL1QqFMZs/LRB96cuafd16N4KlbxmCNCAVcQ2 hH4wolEKtcZuYheKJ5DsfGCXJcb2Ip1dwYT96Gqc3/wA0S59uxtemE+EG0fKefV0ebij 1KTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=gtIGTHoMxgxbkgvPmMMJnAubKCA+EoJLjmC+bTSN3Vo=; b=TOnbBTw34uH7EQTNbwaOzbHQnidJIN+ciDfEBDEZgFAU5qKmwhWPU9OyDhXFXG3gjs HJw3En1IcHIm0NlFBgcE+H4A27bYqVqU55uIT9//ahtijz3ynRrUmWbCqQuKYH6zTQh5 CtsVxBFSPS6DOIYRENqr0qk0lYKMr8oKDi7kK8a5YmXBoKN2MM3nCPcAue4m4iheGv0G LbylhZHAfJf4lTNCcB8F9WEe1Kv5BDC1hw+chxgga8zolZ/dGFWWs0q6JVvhsevYXXjT S9mMSpXl3jRmvg5IQaYoyIO/F/EGuNUbrrq5aR1Bzrv1L4W67n21CU2KNvIoOnORhG+Q TVkQ==
X-Gm-Message-State: AOAM532LgM1QQB2L5ZzK365mUAMT4Nj1dx0D5QRewe8GXqbF8a3KdMDh LWHl+UGnrJxdTDWB7kQAACQ=
X-Google-Smtp-Source: ABdhPJymS674DlWhl0HBzXQqqGM8Bvd/vMWRsXC+0nbsMVnuG2vd23w7SAuklK55vKki7YpXMLovGw==
X-Received: by 2002:adf:ee4d:: with SMTP id w13mr49385287wro.245.1594630971997; Mon, 13 Jul 2020 02:02:51 -0700 (PDT)
Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id w13sm23074861wrr.67.2020.07.13.02.02.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 02:02:51 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.38.20061401
Date: Mon, 13 Jul 2020 12:02:50 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>, <txauth@ietf.org>
Message-ID: <CCAF4A53-9836-4CB1-AB47-154C517ACFC5@gmail.com>
Thread-Topic: [Txauth] Turning polymorphism up to 11 (P11)
References: <CAD9ie-tLwzoqv08dVC+iZme9wRTF6HZh2MVuorLRCr986A=LFw@mail.gmail.com> <CAD9ie-tuenNGRzggE4=1friK-7mXKPvwDM9BzPo4prYS77voew@mail.gmail.com>
In-Reply-To: <CAD9ie-tuenNGRzggE4=1friK-7mXKPvwDM9BzPo4prYS77voew@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3677486570_793933616"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/M4aW2fC46Y1oTluI-FAClj8GZTo>
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 09:02:56 -0000

<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

 

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> 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",

            ],

            "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",

            ],

            "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",

                ],

                "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",

            ],

            "actions": [

                "read"

            ],

            "datatypes": [

                "contacts",

                "photos"

            ]

        }    

    }

}

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth