I noticed that the latest Token Revocation draft [1] has introduced the parameter "token_type_hint". I would suggest the same here, as that would make what is meant by "valid" much clear..
[1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 Thanks & regards, -Prabath On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena <prab...@wso2.com>wrote: > Hi Justin, > > I doubt whether valid_token would make a difference..? > > My initial argument is what is the validation criteria..? Validation > criteria depends on the token_type.. > > If we are talking only about metadata - then I believe "revoked", > "expired" would be more meaningful.. > > Thanks & regards, > -Prabath > > > On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jric...@mitre.org> wrote: > >> OK, I can see the wisdom in changing this term. >> >> I picked "valid" because I wanted a simple "boolean" value that would >> require no additional parsing or string-matching on the client's behalf, >> and I'd like to stick with that. OAuth is built with the assumption that >> clients need to be able to recover from invalid tokens at any stage, so I >> think a simple yes/no is the right step here. >> >> That said, I think you're both right that "valid" seems to have caused a >> bit of confusion. I don't want to go with "revoked" because I'd rather have >> the "token is OK" be the positive boolean value. >> >> Would "valid_token" be more clear? Or do we need a different adjective >> all together? >> >> -- Justin >> >> >> On 02/11/2013 08:02 PM, Richard Harrington wrote: >> >> 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><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 <%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 >> >> >> > > > -- > 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
