Re: [OAUTH-WG] Namespacing "type" in RAR

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 26 July 2020 11:27 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69D13A0DB4 for <oauth@ietfa.amsl.com>; Sun, 26 Jul 2020 04:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 TR9p43PqoXjD for <oauth@ietfa.amsl.com>; Sun, 26 Jul 2020 04:27:02 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 8A3813A0DB3 for <oauth@ietf.org>; Sun, 26 Jul 2020 04:27:01 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id y10so14283122eje.1 for <oauth@ietf.org>; Sun, 26 Jul 2020 04:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=+SzUlii+X1jrsA2JGC8zTtBOVnMHRsS7l6Py8o72uow=; b=Bhmot9tnlFcpx+ZGEnz1aj4GDeut4B/UK/XNnj5kPQX22a9fx/+N/xbhgrafh+alCH xF44agHFXs0Eyizq1kHcro4JBgft7AzLSm4Qfoyguq5Zp6C9hFaCh1yoxq3I7O2HA0YV G0qKr7YGMO3o3TMrfAen+d1dYbgxOs0wGThzUMRf9npGmy1uSsYXA0B2dILNuuYJH6Ye 3Tya/rY45zUzWjRjG8UWb40A1SK3nUTc0LeozOAUFlyRwlbRl6kWyCfxY3si/tLeKbv/ egBbzjjL+9DuLFPi/SSV1Z/XGZh2Qfmumfyft/UmnXvFNJMAkJ0U5cuPNOxsCLWBBLSX TgQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=+SzUlii+X1jrsA2JGC8zTtBOVnMHRsS7l6Py8o72uow=; b=f/PaaXO7+gCJl5cZv5TIV9j12HJsDnyjk6VGNXULQceDy9lgCqnOMmSOv08PhkIN5r SsnDPdRbxoWYbdWckSxLMPx/PsNBy1ma3QpNVKVWgh+2W1zKCRISQccuZHPEoo9Lw7QY 9RlcasBRe3e6nToyumuemxOFjI5Cfq8oP1eKM3FXlkNolHJ1mQLj5i2VCxoNaUTd97k/ yYOzqio+czADfz2TDCdXdB1AI0tVWsUzbuNH1wK/qlIUBQdIpPOvZdvhbKEmpEtpAEcv Uz+L8lANS3N6TGF9I5BDvsdNLwyeR8BrsmnQNGhLhOXpV/AW67RgUpX3adRfRx3N6Dpy jAzQ==
X-Gm-Message-State: AOAM5301NFuCL24oSS1uSHkVtkqOehgcCq4W7drsOYXT4azwTMkTrJW/ uKpAhEh/cMYZCHXkG8PA2HIeMw==
X-Google-Smtp-Source: ABdhPJwAJcBEmzZNZmTNVuTGqmQLHhGmQfiwutp+an0UtNKlv9NDxyjTfwdb9fu0i/IQuQdxowA1Gg==
X-Received: by 2002:a17:906:d04c:: with SMTP id bo12mr17398941ejb.31.1595762819675; Sun, 26 Jul 2020 04:26:59 -0700 (PDT)
Received: from ?IPv6:2003:eb:8f01:3850:788f:f2b2:c893:de76? (p200300eb8f013850788ff2b2c893de76.dip0.t-ipconnect.de. [2003:eb:8f01:3850:788f:f2b2:c893:de76]) by smtp.gmail.com with ESMTPSA id cn16sm5000345edb.86.2020.07.26.04.26.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jul 2020 04:26:58 -0700 (PDT)
Content-Type: multipart/signed; boundary=Apple-Mail-B7D810C2-2DA3-4E2C-BE1A-076E99E1B59A; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Sun, 26 Jul 2020 13:26:57 +0200
Message-Id: <E0541BBE-63AF-4699-9F06-DA5E13C8C0CC@lodderstedt.net>
References: <50FA3A37-00E5-4C9D-91B0-5829268C76C6@mit.edu>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
In-Reply-To: <50FA3A37-00E5-4C9D-91B0-5829268C76C6@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: iPad Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JPQDlIjB6J8taDa1Er1b6KCzs2w>
Subject: Re: [OAUTH-WG] Namespacing "type" in RAR
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2020 11:27:05 -0000

Hi,

the wording regarding type works for me.

Similar to Brian, I don’t understand how the data type registry is supposed to work.

In my opinion, type and locations are completely different from the other elements since they are required by the protocol itself. Their semantics must not be changed by applications.

The other element types are reusable components, but I don’t understand how an application or standard would refer to them, include them into there type definition, and how overloading might happen. For example, are these elements always included in the top level container or can they be used deeper in the structure?

There are alternative solutions for reuse. I personally would use JSON schemas to define such reusable elements and the authorization data types utilizing them. 

I therefore don’t see the need for a RAR specific mechanism (a registry).

best regards,
Torsten.

> Am 26.07.2020 um 02:48 schrieb Justin Richer <jricher@mit.edu>du>:
> 
> Brian,
> 
> I can appreciate the confusion on the elements registry. It’s really about having a place to put re-usable components that people might use within their own “type” definitions, if they want to. The construct in use there is similar to what we used in Vectors of Trust (RFC8485), https://tools.ietf.org/html/rfc8485
> 
> A VoT “trust framework” document can technically define whatever categories and values that it wants to. However, there is a registry for common categories, designed to be core dimensions applicable across a number of different trust frameworks. 
> 
> So the way that it works is that a “type” can redefine its own syntax and semantics for something like “actions” or “locations”, if it wants to, but the registry is giving people a place to look and say, “oh hey, someone already uses ‘actions’ in a general way, maybe that works for me and I can use that definition, or maybe I should find a different word”. So while “type” avoids the programmatic namespace collision of two different definitions of “action”, the registry helps to avoid developer confusion about having two different uses for the same word. 
> 
> It’s not foolproof, but it’s better than making every API designer start from a completely blank slate.
> 
>  — Justin
> 
>> On Jul 24, 2020, at 5:55 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> 
>> I think I'm on board with the type being a just string and the guidance provided about collision-resistance (rather than having a registry for types or requiring type to be a URI or something along those lines). I don't believe there's actually an issue with string comparison in that context and so see no need for the draft to say anything special about it. 
>> 
>> In looking at the pull request, however, I'm surprised by there being a registry for the data elements. And honestly confused about how that would even work in practice. The contents of the authorization details object are determined by the `type` parameter but there's also a registry of the elements that can make up that content that are general across type. I don't see how to reconcile that. 
>> 
>> On Mon, Jul 20, 2020 at 10:00 AM Justin Richer <jricher@mit.edu> wrote:
>>> I created a pull request with some proposed language here:
>>> 
>>> https://github.com/oauthstuff/draft-oauth-rar/pull/52
>>> 
>>>  — Justin
>>> 
>>>> On Jul 20, 2020, at 7:42 AM, Justin Richer <jricher@mit.edu> wrote:
>>>> 
>>>> Since this is a recommendation for namespace, we could also just say collision-resistant like JWT, and any of those examples are fine. But that said, I think there’s something particularly compelling about URIs since they have somewhat-human-readable portions. But again, I’m saying it should be a recommendation to API developers and not a requirement in the spec. In the spec, I argue that “type” should be a string, full stop.
>>>> 
>>>> If documentation is so confusing that developers are typing in the wrong strings, then that’s bad documentation. And likely a bad choice for the “type” string on the part of the AS. You’d have the same problem with any other value the developer’s supposed to copy over.  :)
>>>> 
>>>> I agree that we should call out explicitly how they should be compared, and I propose we use one of the handful of existing string-comparison RFC’s here instead of defining our own rules.
>>>> 
>>>> While the type could be a dereferenceable URI, requiring action on the AS is really getting into distributed authorization policies. We tried doing that with UMA1’s scope structures and it didn’t work very well in practice (in my memory and experience). Someone could profile “type" on top of this if they wanted to do so, with support at the AS for that, but I don’t see a compelling reason for that to be a requirement as that’s a lot of complexity and a lot more error states (the fetch fails, or it doesn’t have a policy, or the policy’s in a format the AS doesn’t understand, or the AS doesn’t like the policy, etc). 
>>>> 
>>>> And AS is always free to implement its types in such a fashion, and that could make plenty of sense in a smaller ecosystem. And this is yet another reason that we define “type” as being a string to be interpreted and understood by the AS — so that an AS that wants to work this way can do so.
>>>> 
>>>>  — Justin
>>>> 
>>>> PS: thanks for pointing out the error in the example in XYZ, I’ll fix that prior to publication.
>>>> 
>>>>> On Jul 18, 2020, at 8:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>> 
>>>>> Justin: thanks for kindly pointing out which mail list this is.
>>>>> 
>>>>> To clarify, public JWT claims are not just URIs, but any collision-resistant namespace: 
>>>>> "Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and      X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]."
>>>>> 
>>>>> I think letting the "type" be any JSON string and doing a byte-wise comparison will be problematic. A client developer will be reading documentation to learn what the types are, and typing it in. Given the wide set of whitespace characters, and unicode equivalence, different byte streams will all look the same, and a byte-wise comparison will fail.
>>>>> 
>>>>> Similarly for URIs. If it is a valid URI, then a byte-wise comparison is not sufficient. Canonicalization is required. 
>>>>> 
>>>>> These are not showstopper issues, but the specification should call out how type strings are compared, and provide caveats to an AS developer.
>>>>> 
>>>>> I have no idea why you would think the AS would retrieve a URL.
>>>>> 
>>>>> Since the type represents a much more complex object then a JWT claim, a client developer's tooling could pull down the JSON Schema (or some such) for a type used in their source code, and provide autocompletion and validation which would improve productivity and reduce errors. An AS that is using a defined type could use the schema for input validation. Neither of these would be at run time. JSON Schema allows comments and examples.
>>>>> 
>>>>> What is the harm in non-normative language around a retrievable URI?
>>>>> 
>>>>> BTW: the example in https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2 has not been updated with the "type" field.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Jul 18, 2020 at 8:10 AM Justin Richer <jricher@mit.edu> wrote:
>>>>>> Hi Dick,
>>>>>> 
>>>>>> This is a discussion about the RAR specification on the OAuth list, and therefore doesn’t have anything to do with alignment with XAuth. In fact, I believe the alignment is the other way around, as doesn’t Xauth normatively reference RAR at this point? Even though, last I saw, it uses a different top-level structure for conveying things, I believe it does say to use the internal object structures. I am also a co-author on RAR and we had already defined a “type” field in RAR quite some time ago. You did notice that XYZ’s latest draft added this field to keep the two in alignment with each other, which has always been the goal since the initial proposal of the RAR work, but that’s a time lag and not a display of new intent. 
>>>>>> 
>>>>>> In any event, even though I think the decision has bearing in both places, this isn’t about GNAP. Working on RAR’s requirements has brought up this interesting issue of what should be in the type field for RAR in OAuth 2.
>>>>>> 
>>>>>> I think that it should be defined as a string, and therefore compared as a byte value in all cases, regardless of what the content of the string is. I don’t think the AS should be expected to fetch a URI for anything. I don’t think the AS should normalize any of the inputs. I think that any JSON-friendly character set should be allowed (including spaces and unicodes), and since RAR already requires the JSON objects to be form-encoded, this shouldn’t cause additional trouble when adding them in to OAuth 2’s request structures.
>>>>>> 
>>>>>> The idea of using a URI would be to get people out of each other’s namespaces. It’s similar to the concept of “public” vs “private” claims in JWT:
>>>>>> 
>>>>>> https://tools.ietf.org/html/rfc7519#section-4.2
>>>>>> 
>>>>>> What I’m proposing is that if you think it’s going to be a general-purpose type name, then we recommend you use a URI as your string. And beyond that, that’s it. It’s up to the AS to figure out what to do with it, and RAR stays out of it.
>>>>>> 
>>>>>>  — Justin
>>>>>> 
>>>>>>> On Jul 17, 2020, at 1:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>>> 
>>>>>>> Hey Justin, glad to see that you have aligned with the latest XAuth draft on a type property being required.
>>>>>>> 
>>>>>>> I like the idea that the value of the type property is fully defined by the AS, which could delegate it to a common URI for reuse. This gets GNAP out of specifying access requests, and enables other parties to define access without any required coordination with IETF or IANA.
>>>>>>> 
>>>>>>> A complication in mixing plain strings and URIs is the canonicalization. A plain string can be a fixed byte representation, but a URI requires canonicalization for comparison. Mixing the two requires URI detection at the AS before canonicalization, and an AS MUST do canonicalization of URIs.
>>>>>>> 
>>>>>>> The URI is retrievable, it can provide machine and/or human readable documentation in JSON schema or some such, or any other content type. Once again, the details are out of scope of GNAP, but we can provide examples to guide implementers.
>>>>>>> 
>>>>>>> Are you still thinking that bare strings are allowed in GNAP, and are defined by the AS?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Jul 17, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
>>>>>>>> The “type” field in the RAR spec serves an important purpose: it defines what goes in the rest of the object, including what other fields are available and what values are allowed for those fields. It provides an API-level definition for requesting access based on multiple dimensions, and that’s really powerful and flexible. Each type can use any of the general-purpose fields like “actions” and/or add its own fields as necessary, and the “type” parameter keeps everything well-defined.
>>>>>>>> 
>>>>>>>> The question, then, is what defines what’s allowed to go into the “type” field itself? And what defines how that value maps to the requirements for the rest of the object? The draft doesn’t say anything about it at the moment, but we should choose the direction we want to go. On the surface, there are three main options:
>>>>>>>> 
>>>>>>>> 1) Require all values to be registered. 
>>>>>>>> 2) Require all values to be collision-resistant (eg, URIs).
>>>>>>>> 3) Require all values to be defined by the AS (and/or the RS’s that it protects).
>>>>>>>> 
>>>>>>>> Are there any other options?
>>>>>>>> 
>>>>>>>> Here are my thoughts on each approach:
>>>>>>>> 
>>>>>>>> 1) While it usually makes sense to register things for interoperability, this is a case where I think that a registry would actually hurt interoperability and adoption. Like a “scope” value, the RAR “type” is ultimately up to the AS and RS to interpret in their own context. We :want: people to define rich objects for their APIs and enable fine-grained access for their systems, and if they have to register something every time they come up with a new API to protect, it’s going to be an unmaintainable mess. I genuinely don’t think this would scale, and that most developers would just ignore the registry and do what they want anyway. And since many of these systems are inside domains, it’s completely unenforceable in practice.
>>>>>>>> 
>>>>>>>> 2) This seems reasonable, but it’s a bit of a nuisance to require everything to be a URI here. It’s long and ugly, and a lot of APIs are going to be internal to a given group, deployment, or ecosystem anyway. This makes sense when you’ve got something reusable across many deployments, like OIDC, but it’s overhead when what you’re doing is tied to your environment.
>>>>>>>> 
>>>>>>>> 3) This allows the AS and RS to define the request parameters for their APIs just like they do today with scopes. Since it’s always the combination of “this type :AT: this AS/RS”, name spacing is less of an issue across systems. We haven’t seen huge problems in scope value overlap in the wild, though it does occur from time to time it’s more than manageable. A client isn’t going to just “speak RAR”, it’s going to be speaking RAR so that it can access something in particular.
>>>>>>>> 
>>>>>>>> And all that brings me to my proposal: 
>>>>>>>> 
>>>>>>>> 4) Require all values to be defined by the AS, and encourage specification developers to use URIs for collision resistance.
>>>>>>>> 
>>>>>>>> So officially in RAR, the AS would decide what “type” means, and nobody else. But we can also guide people who are developing general-purpose interoperable APIs to use URIs for their RAR “type” definitions. This would keep those interoperable APIs from stepping on each other, and from stepping on any locally-defined special “type” structure. But at the end of the day, the URI carries no more weight than just any other string, and the AS decides what it means and how it applies.
>>>>>>>> 
>>>>>>>> My argument is that this seems to have worked very, very well for scopes, and the RAR “type” is cut from similar descriptive cloth.
>>>>>>>> 
>>>>>>>> What does the rest of the group think? How should we manage the RAR “type” values and what they mean?
>>>>>>>> 
>>>>>>>>  — Justin
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth