Preparing generically for context to be provided by the RS/host, as well as 
metadata provided back by the AS/AM, seems like a good idea, and hopefully 
doesn't have to be over-complex. Extension points can be quite simple if 
designed right. But I agree that the basic use case of "give me back the info 
about this token" should be nice and clean.

        Eve

On 30 Nov 2012, at 11:48 AM, Justin Richer <jric...@mitre.org> wrote:

> I think this approach makes sense and it gels with the basic concept that I'd 
> had about the response from the introspection endpoint being extensible and, 
> at some level, service specific. An interesting question then is do we want 
> to have some kind of signaling from the client as to what they want or need 
> back? In other words, make it into a full query API as opposed to a single 
> callback. UMA starts to do this, with fields for the resource_set_id and 
> host_id as part of the request. The pattern that I had written would have 
> implicitly tied the "resource set id" to whatever client credentials were 
> being used to make the request, but we already have potential use cases here 
> (not implemented yet) of the RS wanting to provide more context to the 
> authorization server. One of these would be passing along the user's OIDC 
> id_token in addition to their access_token to help make auth decisions. 
> 
> All of that's very quickly going down the road to complexity that might crowd 
> out the simple case, though, so my gut instinct is to avoid it in the core 
> spec. Still, it's something to consider, especially if UMA wants to be 
> wrapped using generic introspection, and the right level of complexity in the 
> core could make the future much simpler. 
> 
> But even so, I think the simple case of "I have a token and want to know 
> about it" needs to be supported without extra scaffolding. 
> 
>  -- Justin
> 

\
Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to