I disagree with this position and think it's vital to standardize a
return structure and a common set of return values -- and that this work
would be rather pointless without it. Mike, I think you might be
thinking in terms of introspection simply unpacking what's already
contained inside the token, and the AS doing the effort of unpacking
that for the RS. This is, after all, what used to be the case for the
now-defunct OpenID Connect "CheckID Endpoint". But what's really
happening here is this general pattern:
- The client passes the token to the RS. The client doesn't know or
care what's in the token or what it's used for, it just knows that it
can use the token at the RS.
- The RS gets the token and passes it along to the introspection
endpoint on the AS. The means by which the RS figures out where its AS
is is out of scope for this bit of work.
- The AS is looking at the token as passed in, (whether it's
structured like a JWT, a random UUID, an integer into a DB, whatever
deployment-specific bit you want) and figures out if the token is any
good and what it's for. The AS can do this in whatever
deployment-specific way it wants to: look up the token in a DB, unpack
the JWT and check the signature, decrypt the token's payload, whatever.
- The AS returns (in a standardized JSON object) a set of claims about
the token. While it's possible that these claims can be included in the
token directly (as a JWT, for instance) and the RS could have read them
if it knew how to parse said token, it's important that they don't have
to be communicated that way and the token itself does not have to be
structured at all. The AS can literally issue a token of "foo.bar.123"
and the RS can do an introspection call to turn "foo.bar.123" into
{valid: true, sub: user-person, aud: resource-server, ... }
- The RS looks at the returned JSON value and uses that to make its
authorization decision.
It's imperative to note that the token in OAuth is opaque to the
*client* -- it is not opaque to other parties, namely the AS. And in
most deployments, it's not opaque to the RS either, since the RS has to
be able to turn the OAuth token into something that can help it make
authorization decisions. Having an introspection endpoint with a
standardized return value would actually allow the token content itself
to be opaque to the RS as well as the Client.
All that said, I think there is enough variability and flexibility in
OAuth deployments that the introspection data response should (and so
far, has) follow the JWT model: define a core set of claims with clear
semantics, make them all optional apart from the common "active" field,
and allow for copious extension. It's a very simple, very useful pattern
that's been implemented by many different developers.
-- Justin
On 07/29/2014 01:15 PM, Mike Jones wrote:
As I see it, there are two different kinds of standardization for
introspection that could occur. One is defining a standard endpoint
for doing introspection on an access token and possibly refresh
token. The other is defining standard contents to be returned from
the introspection.
I'm skeptical of the standard contents, given that access tokens and
refresh tokens are intentionally opaque. Implementations could range
from being an integer index into a database table, to being a UUID to
being an encrypted JWT with context-specific claims. I don't see
anything in common in those implementations for introspection to return.
While I can see marginal utility to having a common endpoint and
request syntax, I would be against trying to standardize the contents
of what an introspection request might return. It's as
deployment-specific as the access token representation itself.
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Paul Madsen
*Sent:* Tuesday, July 29, 2014 2:48 AM
*To:* Phil Hunt
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth
Token Introspection" as an OAuth Working Group Item
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
