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
<mailto: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 <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Jul 28, 2014, at 5:39 PM, Justin Richer <jric...@mit.edu
<mailto: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
<mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
