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

Justin Richer <jricher@mitre.org> Mon, 11 February 2013 21:50 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 5DEA921F87FD for <oauth@ietfa.amsl.com>; Mon, 11 Feb 2013 13:50:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level:
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 7i6mekmV1qJi for <oauth@ietfa.amsl.com>; Mon, 11 Feb 2013 13:50:27 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2E21F869B for <oauth@ietf.org>; Mon, 11 Feb 2013 13:50:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1647B53105B4; Mon, 11 Feb 2013 16:50:26 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E28731F13DC; Mon, 11 Feb 2013 16:50:25 -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; Mon, 11 Feb 2013 16:50:25 -0500
Message-ID: <51196777.6000502@mitre.org>
Date: Mon, 11 Feb 2013 16:49:43 -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>
In-Reply-To: <CAJV9qO_gM1oera9ae9sqh9n17e-ZLKuC2pmsZwhq-RmFcMyqHA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040108080707050504020200"
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: Mon, 11 Feb 2013 21:50:29 -0000

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
>
> http://blog.facilelogin.com
> http://RampartFAQ.com