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

Agreed on this point -- which is why the only MTI bit in the individual 
draft is "active", which is whether or not the token was any good to 
begin with. There are a set of claims with defined semantics but all are 
optional, and the list is extensible. I think in practice we'll see 
people settle on a set of common ones.

  -- Justin

On 07/29/2014 02:11 PM, Bill Mills wrote:
> This is exactly the same problem space as webfinger, you want to know 
> something about a user and there's a useful set of information you 
> might reasonably query, but in the end the server may have it's own 
> schema of data it returns.  There won't be a single schema that fits 
> all use cases, Any given RS/AS ecosystem may decide they have custom 
> stuff and omit other stuff.  I think the more rigid the MTI schema 
> gets the harder the battle in this case.
>
>
> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen <paul.madsen@gmail.com> 
> wrote:
>
>
> Standardized Introspection will be valuable in NAPPS, where the AS and 
> RS may be in different policy domains.
>
> Even for single policy domains, there are enterprise scenarios where 
> the RS is from a different vendor than the AS, such as when an API 
> gateway validates tokens issued by an 'IdP' . We've necessarily 
> defined our own introspection endpoint and our gateway partners have 
> implemented it, (at the instruction of the customer in question). But 
> of course it's proprietary to us.
>
> Paul
>
> On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.hunt@oracle.com 
> <mailto:phil.hunt@oracle.com>> wrote:
>
>> That doesn't explain the need for inter-operability. What you've 
>> described is what will be common practice.
>>
>> It's a great open source technique, but that's not a standard.
>>
>> JWT is much different. JWT is a foundational specification that 
>> describes the construction and parsing of JSON based tokens. There is 
>> inter-op with token formats that build on top and there is inter-op 
>> between every communicating party.
>>
>> In OAuth, a site may never implement token introspection nor may it 
>> do it the way you describe.  Why would that be a problem?  Why should 
>> the group spend time on something where there may be no inter-op need.
>>
>> Now that said, if you are in the UMA community.  Inter-op is quite 
>> foundational.  It is very very important. But then maybe the spec 
>> should be defined within UMA?
>>
>> Phil
>>
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>
>>
>>
>> On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU 
>> <mailto:jricher@MIT.EDU>> wrote:
>>
>>> It's analogous to JWT in many ways: when you've got the AS and the 
>>> RS separated somehow (different box, different domain, even 
>>> different software vendor) and you need to communicate a set of 
>>> information about the approval delegation from the AS (who has the 
>>> context to know about it) through to the RS (who needs to know about 
>>> it to make the authorization call). JWT gives us an interoperable 
>>> way to do this by passing values inside the token itself, 
>>> introspection gives a way to pass the values by reference via the 
>>> token as an artifact. The two are complementary, and there are even 
>>> cases where you'd want to deploy them together.
>>>
>>>  -- Justin
>>>
>>> On 7/28/2014 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.broyer@gmail.com 
>>>> <mailto:t.broyer@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.tschofenig@gmx.net <mailto:hannes.tschofenig@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 <mailto:OAuth@ietf.org>
>>>>>     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
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org  <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth