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

Dick Hardt <> Mon, 20 July 2020 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 306BE3A0DEE for <>; Mon, 20 Jul 2020 11:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Status: No, score=-0.097 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IAcnBYss0GiG for <>; Mon, 20 Jul 2020 11:59:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30BD83A0DD3 for <>; Mon, 20 Jul 2020 11:59:54 -0700 (PDT)
Received: by with SMTP id x9so21395962ljc.5 for <>; Mon, 20 Jul 2020 11:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RNeue9OsqJIwkXrShxalvEMYRAVMu6mVFvVidGl2h0Y=; b=tOYkidGXHqm6FxS2J2wanxfQOO7rRZdU0/eKOtAGAq4UWySzAtKCoUt88IpObAgTOQ 4Zt2CGifdaqAdDmzywNa2Bf8MtOlcj95/Fd6seiRH1PUSPzgFUf5fgOdmZ8/X/cI6nfD rymLUtZ2KK0EMgVcuXPo4Bs55/VF4Jq9Ke17wNZvnytT5UeWGTQXI9rGOqGmfcNdePpS CQqVZzZHXk2OZE0fu0eTTu4wkHC2o9+MUo9+2bgDHPWI8lqdqr4AnjQViBIna2uXKUrV 6h9CELSUUuQljqxDSPyjx/KKMxkBVOpgzt1xBoKts4aGjJcGKguDshdLO6JrTUetx2J0 c5rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RNeue9OsqJIwkXrShxalvEMYRAVMu6mVFvVidGl2h0Y=; b=jDeiTJNsArw6tFASnxuhxOWRst0NtOrBv+27XVKm/8etu6SM5riogq5EkUwQdeEUFs wbPtoSEjN1Xo/5sWYdsxzSh0BzmWAccZQbIMP+VCYWt7lRVScA0NafspVSrou6gV37/4 /OqkHnuyAwhdMSA0EqZckQZ6Dk/DEwPTD/TQspGvBSEUkhC0D4NTrECzu1uE50S0IkSv Q1FrSnpv6ejZ/DWBUW0PXX87y5Is7IcKFbYwF66hQU2OoVVyJz5VP7xFb81UOEGnD6hS P9mPH+2PjUiHLWPePEqlbh4LMzY9jfMTzLJSApZ6ym7BPFPTG71JPtNgYvIGkuGeSSn9 Fepw==
X-Gm-Message-State: AOAM533i6gvDxqVA9STbdHgtsPrmCuUpM6f5UQtC4UYhZiczRQttxFnW aOHBMmJmNr6JhXHTLsETrMZ4gFVWex3K8ccTp2j0bmD6
X-Google-Smtp-Source: ABdhPJyYR6gH2LyPtUgidiqqDqb97rO2lhJNI6xy33GO/pgSA+Mv1mbSfqjvmzhv1gj0l/MpXxfsUBvOW0FXl7rpwF4=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr11387032ljg.69.1595271592098; Mon, 20 Jul 2020 11:59:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Mon, 20 Jul 2020 11:59:16 -0700
Message-ID: <>
To: Justin Richer <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000091453b05aae41cff"
Archived-At: <>
Subject: Re: [OAUTH-WG] Namespacing "type" in RAR
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2020 18:59:57 -0000

Canonicalization of URIs and unicode is fairly well specified. I was not
suggesting we invent anything there.

A byte comparison, as you suggested earlier, will be problematic, as I have
pointed out.

I'm confused why you are still talking about the AS retrieving a URI.


On Mon, Jul 20, 2020 at 4:42 AM Justin Richer <> 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 <> 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
> has not
> been updated with the "type" field.
> On Sat, Jul 18, 2020 at 8:10 AM Justin Richer <> 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:
>> 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 <> 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 <> 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