Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <4ea6f9af-d67f-97df-6bae-752cf34f920c@connect2id.com>
Date: Sat, 18 Jul 2020 11:12:57 -0400
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5B80874-7A8F-4B9B-AA97-0516661F4E9D@mit.edu>
References: <E9F67961-B83D-40EF-A9CC-F3E4B495379F@mit.edu>
 <4ea6f9af-d67f-97df-6bae-752cf34f920c@connect2id.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xFUVqAyjwe2bwNEx7r0i9_MOXyM>
Subject: Re: [OAUTH-WG] Namespacing "type" in RAR
Precedence: list

I think publishing supported =E2=80=9Ctype=E2=80=9D parameters isn=E2=80=99=
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=E2=80=99t allow to =
be described very well, pointing at a specific RS instead of just =
=E2=80=9Csome kind of access=E2=80=9D, so I=E2=80=99m not sure how =
they=E2=80=99re 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 =E2=80=9Ctype=E2=80=9D 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.

 =E2=80=94 Justin

> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov =
<vladimir@connect2id.com> wrote:
>=20
>=20
> On 17/07/2020 17:38, Justin Richer wrote:
>> And all that brings me to my proposal:=20
>>=20
>> 4) Require all values to be defined by the AS, and encourage =
specification developers to use URIs for collision resistance.
>>=20
>> So officially in RAR, the AS would decide what =E2=80=9Ctype=E2=80=9D =
means, and nobody else. But we can also guide people who are developing =
general-purpose interoperable APIs to use URIs for their RAR =E2=80=9Ctype=
=E2=80=9D definitions. This would keep those interoperable APIs from =
stepping on each other, and from stepping on any locally-defined special =
=E2=80=9Ctype=E2=80=9D 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.
>=20
> Define, but not publish in AS metadata?
>=20
>=20
>> My argument is that this seems to have worked very, very well for =
scopes, and the RAR =E2=80=9Ctype=E2=80=9D is cut from similar =
descriptive cloth.
>=20
> I would argue that it didn't work so well for scopes - the OAuth
> Resource Indicators spec is a testament to that.
>=20
> 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.
>=20
>=20
> Vladimir
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth