Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt

[Justin Richer <[e-mail]>]

Hi Eve,

Yes, you've got the right idea. In a lot of cases that we're dealing 
with, the relationship between the RS and AS is set up ahead of time. So 
the RS knows which AS to ask, and the AS knows how to deal with the 
different RS's it cares about. UMA gives you a nice dynamic way to 
introduce the two, but I think that the introduction should be a 
separate step from the query, since both parts are reusable independently.

Correct me if I'm wrong, but UMA also has the whole API for returning 
permissions associated with a token, beyond just the simple 
current-status message, right? Even so, I think it makes sense to decide 
on what the core set of info that would come back from such a token 
introspection would be, and what it means. Different types of tokens 
(Bearer, MAC, HOK) are going to have different types of metadata 
associated with them, probably, but there are a few core pieces 
(expiration, scopes) that would be common and useful.

  -- Justin

On 11/29/2012 05:59 PM, Eve Maler wrote:
> Hi Justin-- Glad to see this moving forward. This draft seems pretty 
> straightforward, and I imagine the UMA core spec 
> <http://docs.kantarainitiative.org/uma/draft-uma-core.html> could 
> probably incorporate a reference out to this rather than continuing to 
> use our custom-specified method for what we'd called "token status". I 
> wanted to highlight a couple of things we've defined beyond what you 
> have here, in case they're of interest to the wider community.
>
> This spec defines what I'd call "shallow AS/RS communication", in that 
> it assumes a trust relationship and context that's set up between them 
> completely out of band. UMA needed "deep AS/RS communication", which 
> allows for them to live in separate domains, potentially run by 
> disparate parties. (This is akin to the separation in OpenID Connect 
> of IdPs and third-party claim providers, and I've heard of a number of 
> use cases now for the same separation in plain OAuth.) Thus, we 
> defined a means by which the AS and RS could be introduced -- it's 
> actually just an embedded OAuth flow -- so that your mention of a 
> "separate OAuth2 Access Token" option in Section 2.1 is dictated in 
> UMA to be an OAuth token, with a particular scope covering the use of 
> the token introspection endpoint.
>
> The API exposed by the AS (in UMA, an "authorization manager" or AM) 
> that includes usage of the token introspection endpoint is called a 
> "protection API", and it includes registration of information about 
> protected resources so that the AS can manage the issuance of tokens 
> that it will later be asked to introspect.
>
> Finally, UMA has a simple extension point, called "UMA token profile", 
> defined in its (JSON-encoded) AM config data that allows the content 
> associated with the token to be standardized. Actually it dictates 
> more than the content; there are protocol aspects to it too, perhaps 
> akin to OAuth's token profiles.
>
> If there's interest in sedimenting some of these pieces into the OAuth 
> layer, we'd certainly be interested to carve out modules (where 
> possible) and submit them for consideration. Note that all of these 
> features are present in our 
> http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.
>
> Thanks,
>
> Eve
>
> On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> I took some time this morning to put together a draft of Token 
>> Introspection. This is largely based on how we implemented it here a 
>> few years ago, and I'm hoping that this and the Ping draft can help 
>> move the conversation about introspection forward.
>>
>>  -- Justin
>>
>> Begin forwarded message:
>>
>>> *From: *<[e-mail] <mailto:[e-mail]>>
>>> *Subject: **New Version Notification for 
>>> draft-richer-oauth-introspection-00.txt*
>>> *Date: *November 27, 2012 1:44:01 PM EST
>>> *To: *<[e-mail] <mailto:[e-mail]>>
>>>
>>>
>>> A new version of I-D, draft-richer-oauth-introspection-00.txt
>>> has been successfully submitted by Justin Richer and posted to the
>>> IETF repository.
>>>
>>> Filename:draft-richer-oauth-introspection
>>> Revision:00
>>> Title:OAuth Token Introspection
>>> Creation date:2012-11-27
>>> WG ID:Individual Submission
>>> Number of pages: 6
>>> URL: 
>>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt
>>> Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>> Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-00
>>>
>>>
>>> Abstract:
>>>   This specification defines a method for a client or protected
>>>   resource to query an OAuth authorization server to determine meta-
>>>   information about an OAuth token.
>>>
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> [phone] http://www.twitter.com/xmlgrrl
>
>