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 phil.h...@oracle.com On Jul 29, 2014, at 3:24 PM, George Fletcher <gffle...@aol.com> 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 <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
