Making everything optional achieves no benefits, you just end up with a complex set of options and no inter op.
We had the same issue with dyn reg. I prefer to first get agreement on use case. What are the questions a caller can ask and what form of responses are available. Should this be limited to authz info or is this a back door for user data and wbfinger data? I would prefer to have agreement on use cases before picking a solution right now. Phil > On Jul 29, 2014, at 11:13, Justin Richer <jric...@mitre.org> wrote: > > 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.mad...@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.h...@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 >>> phil.h...@oracle.com >>> >>> >>> >>>> On Jul 28, 2014, at 5:39 PM, Justin Richer <jric...@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.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 >> >> _______________________________________________ >> 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
