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 <vladi...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
