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

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 01 Dec 2012 16:11:36 +0100

>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 <[email-masked] 
>> <mailto:[email-masked]>> 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." <[email-masked]
>
>>>> <mailto:[email-masked]>> 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: *<[email-masked]
><mailto:[email-masked]>>
>>>>>> *Subject: **New Version Notification for 
>>>>>> draft-richer-oauth-introspection-00.txt*
>>>>>> *Date: *November 27, 2012 1:44:01 PM EST
>>>>>> *To: *<[email-masked] <mailto:[email-masked]>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth

---

From: "Anganes, Amanda L" <[email-masked]>
Date: Mon, 3 Dec 2012 14:26:33 +0000

A couple of nits: in section 2.3 you have all of the responses labeled as "requests"
"Following is a non-normative example request (with line wraps for

   display purposes only):"

I think those should be labeled as example responses.

--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
[email-masked]

From: <Richer>, Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 27, 2012 1:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt

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: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-richer-oauth-introspection-00.txt
Date: November 27, 2012 1:44:01 PM EST
To: <[email-masked]<mailto:[email-masked]>>

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Dec 2012 09:59:38 -0500

Thanks, likely a copy-paste error.

  -- Justin

On 12/03/2012 09:26 AM, Anganes, Amanda L wrote:
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> 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: *<[email-masked] <mailto:[email-masked]>>

---

From: Eve Maler <[email-masked]>
Date: Fri, 30 Nov 2012 17:43:01 -0800

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 <[email-masked]> 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
> 

\

---

From: Eve Maler <[email-masked]>
Date: Thu, 29 Nov 2012 14:59:41 -0800

Hi Justin-- Glad to see this moving forward. This draft seems pretty straightforward, and I imagine the UMA core spec 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." <[email-masked]> wrote:

>> From: <[email-masked]>
>> To: <[email-masked]>

---

From: Eve Maler <[email-masked]>
Date: Fri, 30 Nov 2012 11:06:27 -0800

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 <[email-masked]> 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
>