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

[Mark Dobrinic <[e-mail]>]

Just some way I could look at this discussion:

One way to separate an AS and an RS is specified by UMA, so for UMA it
is required to have a standardized Token Introspection feature.

If there are no other uses for separating AS/RS, then UMA would be the
place for standardizing Token Introspection.

On the other hand, if there might be other uses for a standardized Token
Introspection, then it would make the most sense that it would be made a
feature of the set of OAuth specifications.

Personally, I've been surprised to find that the main OAuth spec does
not specify a standard way to return a token's info.

Cheers!

Mark

On 29/07/14 03:23, Justin Richer wrote:
> I think this perspective has a lot to do with your idea of OAuth's
> deployment model. You're right in that many people bundle the RS and the
> AS very tightly, but that's not always case, nor is it desirable. We're
> increasingly seeing cases where a group (often an enterprise) has their
> own AS on premises and wants to stand up an RS from a vendor. Without a
> means to connect the RS to the AS in a standard way, you're stuck with
> using whatever AS the RS vendor wants to sell you along side their RS.
> But with the right mechanisms (like JWT and token introspection), you're
> able to connect the RS from one vendor to the AS from another vendor,
> and it works together. I'm not sure what's unclear, but this is the very
> definition of interoperability.
> 
> This is to say nothing of simply being able to locate the RS remotely
> from the AS within a particular security domain and still use
> artifact-style tokens (ie, tokens that don't encode everything within
> them).
> 
> I have already had to deal directly with several cases of RS'es and
> AS'es from different vendors doing effectively the token introspection
> thing in different ways, in protecting vanilla OAuth within a single
> security domain. They were doing it slightly differently for no
> compelling reason other than having to invent the "I have a token and
> need to look it up" mechanism independently. When both sides were able
> to speak the same token introspection protocol (based on the individual
> draft I'd submitted), then we could actually make things work. And none
> of this was running UMA, which also makes use of this.
> 
> I really don't see JWT as any different. To borrow your statement: In
> OAuth, a site may never implement JWT nor may it do it in the way that
> JWT describes. Why would that be a problem? (Hint: it isn't, they're
> free to do whatever token they want. Same with introspection, it's a
> tool that you can use if it makes sense for you to use it. So far a
> whole bunch of people have said it makes sense.)
> 
>  -- Justin
> 
> On 7/28/2014 8:59 PM, Phil Hunt 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>
>> [e-mail] <mailto:[e-mail]>
>>
>>
>>
>> On Jul 28, 2014, at 5:39 PM, Justin Richer <[e-mail]
>> <mailto:[e-mail]>> 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 <[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]
>>>> 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
>