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> 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> 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> 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>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><internet-dra...@ietf.org> >>>> To: >>>> <jric...@mitre.org> <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 >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >>> >>> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 <%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 > > > -- 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
