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

> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
> 
> 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 think that would be a nice thing for an AS/API to offer, but I don’t think it should be expected or required here. That might be a good note in the guidance, say that if you use a URI for your “type” field then it would be nice if it resolved to something either human or machine readable. What I don’t want is for us to require every AS to have to resolve these URIs in order to process and understand them. That’s why I’m taking the position of it being a string, and the URI can provide disambiguation in the way you’re talking about below.

>> 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/ <https://some-rs.example.com/>
> 
> RS scopes: read, update, delete
> 
> ->
> 
> https://some-rs.example.com/read <https://some-rs.example.com/read>
> https://some-rs.example.com/update <https://some-rs.example.com/update>
> https://some-rs.example.com/delete <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 <https://rs.example.com/accounts> and https://rs.example.com/accounts/v1 <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.
> 
That only really works if you are asking for multiple tokens for different resources. With RAR we can at least group things together, and so things like the read/update/delete can now be under the “actions” field with “https://some-rs.example.com/ <https://some-rs.example.com/>“ be the “type” field. Or even better, “https://some-rs-example.com/ <https://some-rs-example.com/>“ is the “locations” value and the “type” is something like “https://rs.example.com/accounts <https://rs.example.com/accounts>”. Since things get combined inside an object with distinct fields, and not as substrings and prefixes, we don’t have the ambiguity with “https://rs.example.com/accounts/v1 <https://rs.example.com/accounts/v1>” anymore. As a note we would also treat “https://rs.example.com/accounts/ <https://rs.example.com/accounts/>“ (with a trailing slash) as a distinct “type” value under this logic.
> I also remember one case with an application having a scope name which is also used for the OIDC userinfo endpoint.
> 
> 
> 
This is exactly the kind of thing that I think we can do better to avoid here. So I would expect a protocol like OIDC to use something like “https://openid.net/specs/connect/ <https://openid.net/specs/connect/>userinfo“ as its “type” field, since it’s coming from a standards body and is meant to be used by many different systems. But if I’ve also got some custom internal timecard API I would just use “timecard” as the “type” there, since it’s internal to just that one AS. And if both of these have an “email” value for, say, “datatype”, then they don’t overlap with each other.
>> 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.
> 
> 
> 

Thanks for the feedback!

 — Justin

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