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

Justin Richer <> Sat, 18 July 2020 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A29E3A03ED for <>; Sat, 18 Jul 2020 08:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jgly8Fd8R550 for <>; Sat, 18 Jul 2020 08:13:01 -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 99D8E3A0303 for <>; Sat, 18 Jul 2020 08:13:01 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 06IFCvdt011710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jul 2020 11:12:58 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Justin Richer <>
In-Reply-To: <>
Date: Sat, 18 Jul 2020 11:12:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Vladimir Dzhuvinov <>
X-Mailer: Apple Mail (2.3608.
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: Sat, 18 Jul 2020 15:13:03 -0000

I think publishing supported “type” parameters isn’t a bad idea, and it aligns with publishing supported scopes and claims in discovery.

I have always seen the resource indicators work as providing a more specific dimension to the requests that scopes didn’t allow to be described very well, pointing at a specific RS instead of just “some kind of access”, so I’m not sure how they’re a testament to name spacing issues with scopes. Can you help me understand here?

I do think that if nothing else we can give better guidance in RAR as to what the “type” field is. I do think it should still just be a string, but we can help people make better decisions about what to put in that string.

 — Justin

> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov <> wrote:
> On 17/07/2020 17:38, Justin Richer wrote:
>> 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.
> Define, but not publish in AS metadata?
>> My argument is that this seems to have worked very, very well for scopes, and the RAR “type” is cut from similar descriptive cloth.
> I would argue that it didn't work so well for scopes - the OAuth
> Resource Indicators spec is a testament to that.
> But one could also argue that scopes were not defined along the lines of
> your proposal for "type" in RAR. In fact, RFC 6749 has no mention of
> collision resistance or name spacing for scope values.
> Vladimir
> _______________________________________________
> OAuth mailing list