Thanks for the review, answers inline:
why is there a need for both scope and audience? I would assume the
scope of the authorization request is typically turned into an
audience of an access token.
You can have an audience of a single server that has multiple scopes, or
a single scope that's across multiple servers. Scope is an explicit
construct in OAuth2, and while it is sometimes used for audience
restriction purposes, they really are independent. Note that both of
these are optional in the response -- if the AS has no notion of
audience restriction in its stored token metadata, then it just doesn't
return the "audience" field.
Generally, wouldn't it be simpler (spec-wise) to just return a JWT
instead of inventing another set of JSON elements?
What would be the utility in returning a JWT? The RS/client making the
call isn't going to take these results and present them elsewhere, so I
don't want to give the impression that it's a token. (This,
incidentally, is one of the main problems I have with the Ping
introspection approach, which uses the Token Endpoint and invents a
"token type" as its return value.) Also, the resource server would have
to parse the JWT instead of raw JSON, the latter of which is easier and
far more common. Besides, I'd have to invent new claims for things like
"valid" and "scopes" and what not, so I'd be extending JWT anyway.
So while I think it's far preferable to use an actual JSON object, I'd
be fine with re-using JWT claim names in the response if people prefer
that. I tried to just use the expanded text since size constraints are
not an issue outside of a JWT, so "issued_at" instead of "iat".
Finally, note that this is *not* the same as the old OIDC CheckId
endpoint which merely parsed and unwrapped the data inside the token
itself. This mechanism works just as well with an unstructured token as
input since the AS can store all of the token's metadata, like
expiration, separately and use the token's value as a lookup key.
-- Justin
Am 09.01.2013 um 20:10 schrieb Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>>:
Updated the introspection draft with feedback from the UMA WG, who
have incorporated it into their latest revision of UMA.
I would like this document to become a working group item.
-- Justin
-------- Original Message --------
Subject: New Version Notification for
draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-dra...@ietf.org>
To: <jric...@mitre.org>
A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename: draft-richer-oauth-introspection
Revision: 01
Title: OAuth Token Introspection
Creation date: 2013-01-08
WG ID: Individual Submission
Number of pages: 6
URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01
Abstract:
This specification defines a method for a client or protected
resource to query an OAuth authorization server to determine meta-
information about an OAuth token.
The IETF Secretariat
_______________________________________________
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
