>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 <jric...@mitre.org
>> <mailto:jric...@mitre.org>> 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." <jric...@mitre.org
>
>>>> <mailto:jric...@mitre.org>> 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: *<internet-dra...@ietf.org
><mailto:internet-dra...@ietf.org>>
>>>>>> *Subject: **New Version Notification for
>>>>>> draft-richer-oauth-introspection-00.txt*
>>>>>> *Date: *November 27, 2012 1:44:01 PM EST
>>>>>> *To: *<jric...@mitre.org <mailto:jric...@mitre.org>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> Eve Maler http://www.xmlgrrl.com/blog
>>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>>>>
>>>>
>>>
>>
>>
>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
