I guess confusion is with 'valid' parameter is in the response..
I thought this will be helpful to standardize the communication
between Resource Server and the Authorization Server..
I would suggest we completely remove "valid" from the response - or
define it much clearly..
May be can add "revoked" with a boolean attribute..
Thanks & regards,
-Prabath
On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
Hi Justin,
I have couple of questions related to "valid" parameter...
This endpoint can be invoked by the Resource Server in runtime...
That's correct.
In that case what is exactly meant by the "resource_id" in request ?
The resource_id field is a service-specific string that basically
lets the resource server provide some context to the request to
the auth server. There have been some other suggestions like
client IP address, but I wanted to put this one in because it
seemed to be a common theme. The client is trying to do
*something* with the token, after all, and the rights,
permissions, and metadata associated with the token could change
based on that. Since the Introspection endpoint is all about
getting that metadata back to the PR, this seemed like a good idea.
IMO a token to be valid depends on set of criteria based on it's
type..
For a Bearer token..
1. Token should not be expired
2. Token should not be revoked.
3. The scope the token issued should match with the scope
required for the resource.
For a MAC token...
1. Token not expired (mac id)
2. Token should not be revoked
3. The scope the token issued should match with the scope
required for the resource.
4. HMAC check should be valid
There are similar conditions for SAML bearer too..
This isn't really true. The SAML bearer token is fully
self-contained and doesn't change based on other parameters in
the message, unlike MAC. Same with JWT. When it hands a SAML or
JWT token to the AS, the PR has given *everything* the server
needs to check that token's validity and use.
MAC signatures change with every message, and they're done across
several components of the HTTP message. Therefor, the HMAC check
for MAC style tokens will still need to be done by the protected
resource. Introspection would help in the case that the signature
validated just fine, but the token might have expired. Or you
need to know what scopes apply. Introspection isn't to fully
validate the call to the protected resource -- if that were the
case, the PR would have to send some kind of encapsulated version
of the original request. Otherwise, the AS won't have all of the
information it needs to check the MAC.
I think what you're describing is ultimately *not* what the
introspection endpoint is intended to do. If that's unclear from
the document, can you please suggest text that would help clear
the use case up? I wouldn't want it to be ambiguous.
-- Justin
Thanks & regards,
-Prabath
On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
<jric...@mitre.org <mailto:jric...@mitre.org>> wrote:
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 <tel:%2B94%2071%20809%206732>
http://blog.facilelogin.com
http://RampartFAQ.com
--
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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
