Have you considered "status" instead of "valid"? It could have values like "active", "expired", and "revoked".
Is it worthwhile including the status of the client also? For example, a client application could be disabled, temporarily or permanently, and thus disabling its access tokens as well. On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prab...@wso2.com> wrote: > 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> >>>>>>>> To: <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 >>>>> >>>>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
