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.comphil.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
