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

[Torsten Lodderstedt <[e-mail]>]

>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.

+1


>
>  -- Justin
>
>
>
>On 11/30/2012 02:06 PM, Eve Maler wrote:
>> You're right that UMA bundles several things in the protection API 
>> (covered by the protection scope, whose keyword is actually the 
>> resolvable URI 
>> "http://docs.kantarainitiative.org/uma/scopes/prot.json"). One of 
>> those things is the use of the token status endpoint; the rest is the
>
>> whole mechanism for outsourcing protection.  Maybe it makes sense for
>
>> us to define "protection" as a superset scope that includes a smaller
>
>> scope of "introspection", which would map to using the introspection 
>> endpoint being defined in your spec.  What do you think?
>>
>> The permissions that get returned as the result of UMA-style 
>> introspection are actually part of the definition of the "bearer" UMA
>
>> token profile. Other token contents could be profiled specifically
>for 
>> use with UMA, or we could perhaps also reuse OAuth token profiles.
>The 
>> wrapper being defined in your spec for totally generic token metadata
>
>> seems like a good idea; the innards could be any number of things 
>> (with their own unique metadata), such as policy yes/no decisions,
>the 
>> claims gathered, etc. This topic is discussed in the latter part of 
>> this slide deck: 
>>
>http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf
>>
>> Thanks!
>>
>> Eve
>>
>> On 30 Nov 2012, at 7:56 AM, Justin Richer <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>
>>
>> Eve Maler http://www.xmlgrrl.com/blog
>> [phone] http://www.twitter.com/xmlgrrl
>>
>>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OAuth mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/oauth