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

[George Fletcher <[e-mail]>]

Actually, I view this in a much simpler way. In today's environment 
there is a tight coupling between AS and RS. Each deployment has to 
develop it's own mechanism for dealing with understanding tokens (even 
if the AS and RS are in the same domain).

The introspection spec solve probably 80+ percent of those tight 
coupling use cases.

As an RS, I do not want to have to write special code for every AS to 
understand their unique token or mechanism for validating tokens and I'm 
sure that every AS does not want to implement our specific token. In 
both of these cases there is a tight coupling required.

As for the privacy issues, the introspection endpoint is an OAuth2 
protected API and can enforce the presentation of an authorization token 
(RFC 6750) before responding with the token data. This allows for the 
return of pseudonymous identifiers and other privacy protecting mechanisms.

Thanks,
George

// Line feeds added for formatting purposes only :)
{
    "bit_of_a_rant" : "Since the introspection spec is not mandatory to
                       implement, I don't see why there is such concern 
over
                       it. If an AS doesn't want to implement the endpoint,
                       they don't need to. However, for those who do 
(and there
                       is a good number in this community) it solves a
                       real problem."
}

On 7/29/14, 7:44 PM, Phil Hunt wrote:
> Thanks everyone for the comments.
>
> It sounds like we have multiple dimensions to introspection features 
> and requirements:
>
> * there are UMA cases,
> * corporate third-party AS-RS relationships (e.g. the RS chooses a 
> third-party AS),
> * multi-vendor cases,
> * tooling/library cases,
>
> There’s also federation cases. Federated authorization seems like a 
> different problem than federated authentication from a trust perspective.
>
> Another dimension to this is methodology:
> 1.  Lookup by token / token id / reference
> 2.  Query by token / token id / reference
> 3.  Passing standardized information in a standardized token format or 
> token URI.
>
> There may be some complex privacy issues involved as well. For 
> example, in many cases, the desire is to allow authz information 
> *only* the actual content owner / delegator may be intentionally 
> pseudonymous.
>
> _I would support first developing a use case document to figure out if 
> there is an appropriate pattern that can satisfy (and simplify) a 
> majority of cases._
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
> On Jul 29, 2014, at 3:24 PM, George Fletcher <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> 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]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>