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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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: >>>>> <[email protected]><[email protected]> To: >>>>> <[email protected]> <[email protected]> >>>>> >>>>> 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 >>>>> [email protected] >>>>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
