Hi Justin, Any thoughts on the following...
Thanks & regards, -Prabath On Fri, Feb 8, 2013 at 11:21 AM, Prabath Siriwardena <prab...@wso2.com>wrote: > Hi Justin, > > I have couple of questions related to "valid" parameter... > > This endpoint can be invoked by the Resource Server in runtime... > > In that case what is exactly meant by the "resource_id" in request ? > > 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.. > > 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 <%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 > -- 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
