Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

Justin Richer <jricher@mitre.org> Thu, 14 February 2013 14:25 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECE21F882C for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level:
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs2W6alkdcr8 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:25:40 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86D21F882E for <oauth@ietf.org>; Thu, 14 Feb 2013 06:25:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 55ED51F2C9F; Thu, 14 Feb 2013 09:25:38 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 39CC41F2C88; Thu, 14 Feb 2013 09:25:38 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:25:36 -0500
Message-ID: <511CF3B3.7010502@mitre.org>
Date: Thu, 14 Feb 2013 09:24:51 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena <prabath@wso2.com>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org> <CAJV9qO_8-4FowrXK=ae-+xMjiJFP04ryVMLQ8SGUH8kp3PHrLg@mail.gmail.com> <5113C3AA.1040701@mitre.org> <CAJV9qO8BVV57eAb5kUNes15AYOpUKqw5XWQswh-FJA=b1pPgSA@mail.gmail.com> <5113DDB2.7060805@mitre.org> <CAJV9qO_gM1oera9ae9sqh9n17e-ZLKuC2pmsZwhq-RmFcMyqHA@mail.gmail.com> <51196777.6000502@mitre.org> <CAJV9qO-5bWZbNUfCmaqYBQoy-qwNaSZFOsO9GL3CrbSejwVTzw@mail.gmail.com> <F6595A40-6B4E-4718-ABB5-694CA975C4DB@maymount.com> <511A5062.5010108@mitre.org> <CAJV9qO_Mr87NX=KZRqCsWasQ1FuvDNBw14eS-TcPf_KRJztQFg@mail.gmail.com> <CAJV9qO-71-sM6kXOB6Fb_bvVkDBQ5JBbs8E5X=f-K=iEmGezRA@mail.gmail.com> <511CEEAA.3030801@mitre.org> <CAJV9qO-JSXgSTkw2_pdH0D-o-xDWGDqxx=PAWYtnTj4hOQXW4Q@mail.gmail.com>
In-Reply-To: <CAJV9qO-JSXgSTkw2_pdH0D-o-xDWGDqxx=PAWYtnTj4hOQXW4Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030105000502060207030806"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 14:25:46 -0000

OK, so you mean "token type" as defined by the "token_type" field coming 
back from the Token Endpoint, and *not* as defined by the 
"token_type_hint" in the revocation draft. Right?

The RO probably won't know or care about the token type. The client and 
AS have to know because they need to know how to use and provision it, 
respectively. The RS needs to know the type to be able to validate the 
call at some level.

I'm not opposed to token types being returned, I just want people to be 
very clear about what they mean by "token type" when they say it.

  -- Justin

On 02/14/2013 09:22 AM, Prabath Siriwardena wrote:
> Both the client and the resource owner should be aware of the token type.
>
> My argument is, if the authorization server to decide whether the 
> token is valid or not ( irrespective of who asked the question) - AS 
> needs to know the token type - because to validate a token AS should 
> know the token type.
>
> The token type could be, bearer or MAC or any other token type.
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer <jricher@mitre.org 
> <mailto:jricher@mitre.org>> wrote:
>
>     What exactly are you suggesting be added to introspection? The
>     "token_type_hint" is from the client to the server, but what
>     you've asked for in terms of "token type" is from the server to
>     the client. And there was never an answer to what exactly is meant
>     by "token type" in this case, particularly because you seem to
>     want to call out things like SAML and Bearer as separate types.
>
>      -- Justin
>
>
>
>     On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>     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
>>     <prabath@wso2.com <mailto:prabath@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
>>         <jricher@mitre.org <mailto:jricher@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
>>>             <prabath@wso2.com <mailto:prabath@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
>>>>             <jricher@mitre.org <mailto:jricher@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
>>>>>                 <jricher@mitre.org <mailto:jricher@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
>>>>>>                     <jricher@mitre.org
>>>>>>                     <mailto:jricher@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 <jricher@mitre.org
>>>>>>>                         <mailto:jricher@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-drafts@ietf.org>
>>>>>>>                             <mailto:internet-drafts@ietf.org>
>>>>>>>                             To: 	<jricher@mitre.org>
>>>>>>>                             <mailto:jricher@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 <mailto:OAuth@ietf.org>
>>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         -- 
>>>>>>>                         Thanks & Regards,
>>>>>>>                         Prabath
>>>>>>>
>>>>>>>                         Mobile : +94 71 809 6732
>>>>>>>                         <tel:%2B94%2071%20809%206732>
>>>>>>>
>>>>>>>                         http://blog.facilelogin.com
>>>>>>>                         http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -- 
>>>>>>                     Thanks & Regards,
>>>>>>                     Prabath
>>>>>>
>>>>>>                     Mobile : +94 71 809 6732
>>>>>>                     <tel:%2B94%2071%20809%206732>
>>>>>>
>>>>>>                     http://blog.facilelogin.com
>>>>>>                     http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Thanks & Regards,
>>>>>                 Prabath
>>>>>
>>>>>                 Mobile : +94 71 809 6732
>>>>>                 <tel:%2B94%2071%20809%206732>
>>>>>
>>>>>                 http://blog.facilelogin.com
>>>>>                 http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Thanks & Regards,
>>>>             Prabath
>>>>
>>>>             Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>>>
>>>>             http://blog.facilelogin.com
>>>>             http://RampartFAQ.com
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>         -- 
>>         Thanks & Regards,
>>         Prabath
>>
>>         Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>
>>         http://blog.facilelogin.com
>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 <tel:%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