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 <jric...@mit.edu> 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 <t.bro...@gmail.com> 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" <michael.jo...@microsoft.com> 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:t.bro...@gmail.com]
>>>> Sent: Tuesday, July 29, 2014 5:43 PM
>>>> To: Mike Jones
>>>> Cc: <oauth@ietf.org>; 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" <michael.jo...@microsoft.com> 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:oauth-boun...@ietf.org] On Behalf Of George Fletcher
>>>> Sent: Tuesday, July 29, 2014 3:25 PM
>>>> To: Phil Hunt; Thomas Broyer
>>>> Cc: oauth@ietf.org
>>>> 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 <t.bro...@gmail.com> 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
>>>> <hannes.tschofe...@gmx.net> 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
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thomas Broyer
>>>> /tɔ.ma.bʁwa.je/
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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
