Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Sergey Beryozkin <[e-mail]>]

On 30/07/14 04:45, Eve Maler wrote:
> I would say that if an RS and AS are relatively tightly coupled and have
> established their trust "off stage", then the RS will know where to go
> and how to interpret the results.
+1. It is an obvious answer, there has to be a trust established between 
RS and AS.
let me ask Phil: How does RS know today, when it asks AS to return the 
info about a given token that the AS endpoint is authoritative ?
Thanks, Sergey
> If an RS and AS are entirely loosely
> coupled, then there are a number of options for trust establishment for
> which UMA provides one solution, leveraging an OAuth-protected token
> introspection endpoint and an endpoint discovery mechanism.
>
> (BTW, I first wrote about this usage of token introspection on this list
> in November 2012
> <http://www.ietf.org/mail-archive/web/oauth/current/msg10230.html>,
> where I distinguished "shallow" and "deep" options for RS/AS communication.)
>
> Eve
>
> On 29 Jul 2014, at 6:17 PM, Phil Hunt <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> Mike's proposal may be sufficient for Thomas' case given a small token
>> lifetime.
>>
>> The federated cases may have other issues....
>>
>> How does the RS know who issued the opaque token and what
>> introspection point is authoritative?
>>
>> I am not saying your spec is not the right answer. I am just not
>> prepared to limit functionality yet by adopting the draft until we
>> have sufficient requirements understood.
>>
>> Let the rest of us catch up please.
>>
>> Phil
>>
>> On Jul 29, 2014, at 18:07, Justin Richer <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>> So you want a service where the RS can call an HTTP endpoint to see
>>> if the token is alive or not? That sounds like an awesome idea! Very
>>> useful for a variety of use cases that people have already mentioned
>>> on that list. Maybe that service should respond in JSON with, say, {
>>> "active": true } if it's still valid. That's a great start, and that
>>> should obviously be MTI.
>>>
>>> But while we're there, we probably want to know what else the token
>>> is for, since this service will probably know that, so let's add in
>>> the "scope" and "client_id" and whatever other meta-information we
>>> have about the token. If this endpoint doesn't have that information?
>>> Well then, I guess it can't return it. So we need to make sure to be
>>> flexible about that while we define a common core set of semantics.
>>> Flexibility like that is very powerful and could be used in a variety
>>> of protocols and deployments across domains and vendors.
>>>
>>> You know, this idea is sounding better and better. In fact, I'll do
>>> you one better. I think this is such a fantastic idea that I wrote it
>>> all down in RFC format:
>>>
>>> http://tools.ietf.org/html/draft-richer-oauth-introspection-06
>>>
>>> Glad to have you on board, Phil.
>>>
>>>  -- Justin
>>>
>>> On 7/29/2014 9:02 PM, Phil Hunt wrote:
>>>> I think one alternative to an introspection service is a revocation
>>>> status service.
>>>>
>>>> But it is often not needed if token lifetimes are small (minutes /
>>>> session life) compared to the refresh token which might last much
>>>> longer.
>>>>
>>>> Again having info on the case helps explain the requirements of your
>>>> case and we can tell what the best pattern is.
>>>>
>>>> Phil
>>>>
>>>> On Jul 29, 2014, at 17:55, Thomas Broyer <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>> Try it where? When you're the RS trying to determine whether you
>>>>> should accept the token or reject it?
>>>>>
>>>>> Le 30 juil. 2014 02:49, "Mike Jones" <[e-mail]
>>>>> <mailto:[e-mail]>> a écrit :
>>>>>
>>>>>     Yes, but that’s the simplest thing to determine – try the token
>>>>>     and see whether it works or not.
>>>>>
>>>>>
>>>>>     *From:*Thomas Broyer [mailto:[e-mail]
>>>>>     <mailto:[e-mail]>]
>>>>>     *Sent:* Tuesday, July 29, 2014 5:43 PM
>>>>>     *To:* Mike Jones
>>>>>     *Cc:* <[e-mail] <mailto:[e-mail]>>; George
>>>>>     Fletcher; Phil Hunt
>>>>>     *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of
>>>>>     "OAuth Token Introspection" as an OAuth Working Group Item
>>>>>
>>>>>
>>>>>     Decoding a token with a specific format wouldn't tell you
>>>>>     whether the token is still live: it could have been revoked
>>>>>     before its expiration.
>>>>>
>>>>>     Le 30 juil. 2014 02:16, "Mike Jones"
>>>>>     <[e-mail]
>>>>>     <mailto:[e-mail]>> a écrit :
>>>>>
>>>>>     Did you consider standardizing the access token format within
>>>>>     that deployment so all the parties that needed to could
>>>>>     understand it, rather requiring an extra round trip to an
>>>>>     introspection endpoint so as to be able to understand things
>>>>>     about it?
>>>>>
>>>>>
>>>>>     I realize that might or might not be practical in some cases,
>>>>>     but I haven’t heard that alternative discussed, so I thought
>>>>>     I’d bring it up.
>>>>>
>>>>>
>>>>>     I also second Phil’s comment that it would be good to
>>>>>     understand the use cases that this is intended to solve before
>>>>>     embarking on a particular solution path.
>>>>>
>>>>>
>>>>>     -- Mike
>>>>>
>>>>>
>>>>>     *From:*OAuth [mailto:[e-mail]
>>>>>     <mailto:[e-mail]>] *On Behalf Of *George Fletcher
>>>>>     *Sent:* Tuesday, July 29, 2014 3:25 PM
>>>>>     *To:* Phil Hunt; Thomas Broyer
>>>>>     *Cc:* [e-mail] <mailto:[e-mail]>
>>>>>     *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of
>>>>>     "OAuth Token Introspection" as an OAuth Working Group Item
>>>>>
>>>>>
>>>>>     We also have a use case where the AS is provided by a partner
>>>>>     and the RS is provided by AOL. Being able to have a
>>>>>     standardized way of validating and getting data about the token
>>>>>     from the AS would make our implementation much simpler as we
>>>>>     can use the same mechanism for all Authorization Servers and
>>>>>     not have to implement one off solutions for each AS.
>>>>>
>>>>>     Thanks,
>>>>>     George
>>>>>
>>>>>     On 7/28/14, 8:11 PM, Phil Hunt wrote:
>>>>>
>>>>>         Could we have some discussion on the interop cases?
>>>>>
>>>>>
>>>>>         Is it driven by scenarios where AS and resource are
>>>>>         separate domains? Or may this be only of interest to
>>>>>         specific protocols like UMA?
>>>>>
>>>>>
>>>>>         From a technique principle, the draft is important and
>>>>>         sound. I am just not there yet on the reasons for an
>>>>>         interoperable standard.
>>>>>
>>>>>
>>>>>         Phil
>>>>>
>>>>>
>>>>>         On Jul 28, 2014, at 17:00, Thomas Broyer
>>>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>
>>>>>             Yes. This spec is of special interest to the platform
>>>>>             we're building for http://www.oasis-eu.org/
>>>>>
>>>>>
>>>>>             On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig
>>>>>             <[e-mail]
>>>>>             <mailto:[e-mail]>> wrote:
>>>>>
>>>>>             Hi all,
>>>>>
>>>>>             during the IETF #90 OAuth WG meeting, there was strong
>>>>>             consensus in
>>>>>             adopting the "OAuth Token Introspection"
>>>>>             (draft-richer-oauth-introspection-06.txt) specification
>>>>>             as an OAuth WG
>>>>>             work item.
>>>>>
>>>>>             We would now like to verify the outcome of this call
>>>>>             for adoption on the
>>>>>             OAuth WG mailing list. Here is the link to the document:
>>>>>             http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
>>>>>
>>>>>             If you did not hum at the IETF 90 OAuth WG meeting, and
>>>>>             have an opinion
>>>>>             as to the suitability of adopting this document as a WG
>>>>>             work item,
>>>>>             please send mail to the OAuth WG list indicating your
>>>>>             opinion (Yes/No).
>>>>>
>>>>>             The confirmation call for adoption will last until
>>>>>             August 10, 2014.  If
>>>>>             you have issues/edits/comments on the document, please
>>>>>             send these
>>>>>             comments along to the list in your response to this
>>>>>             Call for Adoption.
>>>>>
>>>>>             Ciao
>>>>>             Hannes & Derek
>>>>>
>>>>>
>>>>>             _______________________________________________
>>>>>             OAuth mailing list
>>>>>             [e-mail] <mailto:[e-mail]>
>>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             --
>>>>>             Thomas Broyer
>>>>>             /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>>>>
>>>>>             _______________________________________________
>>>>>             OAuth mailing list
>>>>>             [e-mail] <mailto:[e-mail]>
>>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>
>>>>>         OAuth mailing list
>>>>>
>>>>>         [e-mail]  <mailto:[e-mail]>
>>>>>
>>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>