Hi Eve,
Yes, you've got the right idea. In a lot of cases that we're dealing
with, the relationship between the RS and AS is set up ahead of time. So
the RS knows which AS to ask, and the AS knows how to deal with the
different RS's it cares about. UMA gives you a nice dynamic way to
introduce the two, but I think that the introduction should be a
separate step from the query, since both parts are reusable independently.
Correct me if I'm wrong, but UMA also has the whole API for returning
permissions associated with a token, beyond just the simple
current-status message, right? Even so, I think it makes sense to decide
on what the core set of info that would come back from such a token
introspection would be, and what it means. Different types of tokens
(Bearer, MAC, HOK) are going to have different types of metadata
associated with them, probably, but there are a few core pieces
(expiration, scopes) that would be common and useful.
-- Justin
On 11/29/2012 05:59 PM, Eve Maler wrote:
Hi Justin-- Glad to see this moving forward. This draft seems pretty
straightforward, and I imagine the UMA core spec
<http://docs.kantarainitiative.org/uma/draft-uma-core.html> could
probably incorporate a reference out to this rather than continuing to
use our custom-specified method for what we'd called "token status". I
wanted to highlight a couple of things we've defined beyond what you
have here, in case they're of interest to the wider community.
This spec defines what I'd call "shallow AS/RS communication", in that
it assumes a trust relationship and context that's set up between them
completely out of band. UMA needed "deep AS/RS communication", which
allows for them to live in separate domains, potentially run by
disparate parties. (This is akin to the separation in OpenID Connect
of IdPs and third-party claim providers, and I've heard of a number of
use cases now for the same separation in plain OAuth.) Thus, we
defined a means by which the AS and RS could be introduced -- it's
actually just an embedded OAuth flow -- so that your mention of a
"separate OAuth2 Access Token" option in Section 2.1 is dictated in
UMA to be an OAuth token, with a particular scope covering the use of
the token introspection endpoint.
The API exposed by the AS (in UMA, an "authorization manager" or AM)
that includes usage of the token introspection endpoint is called a
"protection API", and it includes registration of information about
protected resources so that the AS can manage the issuance of tokens
that it will later be asked to introspect.
Finally, UMA has a simple extension point, called "UMA token profile",
defined in its (JSON-encoded) AM config data that allows the content
associated with the token to be standardized. Actually it dictates
more than the content; there are protocol aspects to it too, perhaps
akin to OAuth's token profiles.
If there's interest in sedimenting some of these pieces into the OAuth
layer, we'd certainly be interested to carve out modules (where
possible) and submit them for consideration. Note that all of these
features are present in our
http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.
Thanks,
Eve
On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
I took some time this morning to put together a draft of Token
Introspection. This is largely based on how we implemented it here a
few years ago, and I'm hoping that this and the Ping draft can help
move the conversation about introspection forward.
-- Justin
Begin forwarded message:
*From: *<internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>>
*Subject: **New Version Notification for
draft-richer-oauth-introspection-00.txt*
*Date: *November 27, 2012 1:44:01 PM EST
*To: *<jric...@mitre.org <mailto:jric...@mitre.org>>
A new version of I-D, draft-richer-oauth-introspection-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename:draft-richer-oauth-introspection
Revision:00
Title:OAuth Token Introspection
Creation date:2012-11-27
WG ID:Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt
Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-00
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
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
