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 <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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
