It validates the token, which would be either the token itself in the
case of Bearer or the token "id" part of something more complex like
MAC. It doesn't directly validate the usage of the token, that's still
up to the PR to do that.
I nearly added a "token type" field in this draft, but held back because
there are several kinds of "token type" that people talk about in OAuth.
First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
within Bearer you have "JWT" or "SAML" or "unstructured blob". Then
you've also got "access" vs. "refresh" and other flavors of token, like
the id_token in OpenID Connect.
Thing is, the server running the introspection endpoint will probably
know *all* of these. But should it tell the client? If so, which of the
three, and what names should the fields be?
-- Justin
On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
Okay.. I was thinking this could be used as a way to validate the
token as well. BTW even in this case shouldn't communicate the type of
token to AS? For example in the case of SAML profile - it could be
SAML token..
Thanks & regards,
-Prabath
On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
"valid" might not be the best term, but it's meant to be a field
where the server says "yes this token is still good" or "no this
token isn't good anymore". We could instead do this with HTTP
codes or something but I went with a pure JSON response.
-- Justin
On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
Hi Justin,
I believe this is addressing one of the key missing part in OAuth
2.0...
One question - I guess this was discussed already...
In the spec - in the introspection response it has the attribute
"valid" - this is basically the validity of the token provided in
the request.
Validation criteria depends on the token and well as token type (
Bearer, MAC..).
In the spec it seems like it's coupled with Bearer token type...
But I guess, by adding "token_type" to the request we can remove
this dependency.
WDYT..?
Thanks & regards,
-Prabath
On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Updated introspection draft based on recent comments. Changes
include:
- "scope" return parameter now follows RFC6749 format
instead of JSON array
- "subject" -> "sub", and "audience" -> "aud", to be
parallel with JWT claims
- clarified what happens if the authentication is bad
-- Justin
-------- Original Message --------
Subject: New Version Notification for
draft-richer-oauth-introspection-02.txt
Date: Wed, 6 Feb 2013 11:24:20 -0800
From: <internet-dra...@ietf.org>
<mailto:internet-dra...@ietf.org>
To: <jric...@mitre.org> <mailto:jric...@mitre.org>
A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename: draft-richer-oauth-introspection
Revision: 02
Title: OAuth Token Introspection
Creation date: 2013-02-06
WG ID: Individual Submission
Number of pages: 6
URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
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
--
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
http://blog.facilelogin.com
http://RampartFAQ.com
--
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
