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

Vladimir Dzhuvinov <vladimir@connect2id.com> Sun, 19 July 2020 17:04 UTC

Return-Path: <vladimir@connect2id.com>
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 986743A0B6E for <oauth@ietfa.amsl.com>; Sun, 19 Jul 2020 10:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 MFSzHjYwIFrC for <oauth@ietfa.amsl.com>; Sun, 19 Jul 2020 10:04:52 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 0C16D3A0B6D for <oauth@ietf.org>; Sun, 19 Jul 2020 10:04:51 -0700 (PDT)
Received: from [192.168.10.64] ([81.174.4.8]) by :SMTPAUTH: with ESMTPSA id xCk5jEhgvDaCExCk6jgxL3; Sun, 19 Jul 2020 10:04:51 -0700
X-CMAE-Analysis: v=2.3 cv=SvjuF8G0 c=1 sm=1 tr=0 a=vVDcMwBpR/yuU2vi46uXpQ==:117 a=vVDcMwBpR/yuU2vi46uXpQ==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=A1X0JdhQAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=i8wZipv3lY2PXhKeaqEA:9 a=QEXdDO2ut3YA:10 a=HDiSmjr4jzRZaKFRhUYA:9 a=G3bo8Pr6VXIhWx_w:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=Df3jFdWbhGDLdZNm0fyq:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.org
References: <E9F67961-B83D-40EF-A9CC-F3E4B495379F@mit.edu> <4ea6f9af-d67f-97df-6bae-752cf34f920c@connect2id.com> <B5B80874-7A8F-4B9B-AA97-0516661F4E9D@mit.edu>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <c84ca5ce-5fa0-dc8e-afaa-88f48dc6eaa8@connect2id.com>
Date: Sun, 19 Jul 2020 19:04:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <B5B80874-7A8F-4B9B-AA97-0516661F4E9D@mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060504070901020404060908"
X-CMAE-Envelope: MS4wfGusYBKTNZHsEbZIfuz3vAT9wno+ZtxtDtDairmZqPC2qWWXzSKAtp3e2jmOj6iVzmpHPbIw43MyqdEtQLQtIUtFTvUFS0FL7do2QjYY6swG94MTn8nm Rn3s03bvXvU4QbWhDiNQYpHPPhAK9K8GQc2Jp3kC65rnsgK1fExub1TDaU+VLoqUDM8KYbnu1Uu4Ag==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GRJcBzG5q_pwckz2Z2-7fq4mFAo>
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, 19 Jul 2020 17:04:54 -0000

On 18/07/2020 17:12, Justin Richer wrote:
> I think publishing supported “type” parameters isn’t a bad idea, and it aligns with publishing supported scopes and claims in discovery.

If you are a developer, would you like to be able to find out if the
authorization_details for a given "type" has a JSON schema and what it
looks like?


> 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?

Putting the scopes for each RS in a unique name space, for example by
giving them a URI prefix which identifies the RS, can make the resource
indication redundant.

RS: https://some-rs.example.com/

RS scopes: read, update, delete

->

https://some-rs.example.com/read

https://some-rs.example.com/update

https://some-rs.example.com/delete

This will not work if the chosen name spacing pattern can produce
ambiguities, e.g. if https://rs.example.com/accounts and
https://rs.example.com/accounts/v1 are two different RSes.


I have witnessed situations when an AS is given some application to deal
with, with hard-wired scope values that have no name spacing, and to
prevent potential collisions with other applications, Resource
Indicators had to come to the rescue.

I also remember one case with an application having a scope name which
is also used for the OIDC userinfo endpoint.


> I do think that if nothing else we can give better guidance in RAR as to what the “type” field is. 

+1


> 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.

I'm still on the fence with that but I do see your argument.


Vladimir


>
>  — Justin
>
>> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov