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

Eve Maler <eve@xmlgrrl.com> Fri, 08 February 2013 05:54 UTC

Return-Path: <eve@xmlgrrl.com>
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 26AC321F8943 for <oauth@ietfa.amsl.com>; Thu, 7 Feb 2013 21:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.692
X-Spam-Level:
X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
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 5pVzgRTbR4YA for <oauth@ietfa.amsl.com>; Thu, 7 Feb 2013 21:54:54 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id B56CE21F8921 for <oauth@ietf.org>; Thu, 7 Feb 2013 21:54:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id EFFE4B1DA53; Thu, 7 Feb 2013 21:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-HV67u4KnIh; Thu, 7 Feb 2013 21:54:48 -0800 (PST)
Received: from [192.168.0.28] (s01060026f3e16488.vc.shawcable.net [24.84.235.32]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 22380B1DA3A; Thu, 7 Feb 2013 21:54:48 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDEA92BF-EA0E-409C-A2AD-98C7DB184394"
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <5113DDB2.7060805@mitre.org>
Date: Thu, 07 Feb 2013 21:54:46 -0800
Message-Id: <7E230B91-90A5-45B1-B306-5ED07B60AF8E@xmlgrrl.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>
To: Justin Richer <jricher@mitre.org>
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] 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: Fri, 08 Feb 2013 05:54:55 -0000

This discussion seems to take one step into the territory that I think of as "deep" AS/RS communications. Solving token introspection all by itself means that a whole bunch of stuff must have been settled out of band/statically/in proprietary fashion. It's for this reason that UMA spec'd out "deep" communications, calling out to the token introspection spec for one "shallow" piece. The additional pieces include:

- Machine-readable AS config data that specifies the token profiles it supports (in this case, an UMA "requesting party token" profile that participates in its unique "get a token/use a token" flows)
- An MTI token profile
- An extensible mechanism for defining token profiles
- An extensible mechanism for requiring, allowing, and/or disallowing use of the token introspection endpoint for token profiles other than the MTI one

UMA calls the data associated with the token "authorization data". The spec always says "associated with", and not "contained within", since then it covers both structured and "artifact" token use cases. I've been thinking for some time that it would be useful to characterize token types/profiles along two axes: the format of the data and whether the data is locally accessible to the RS (e.g. through verifying a signature or decrypting a blob or whatever) vs. must be retrieved from the AS at run time by dereferencing an artifact. Justin, your note below hints at both of these.

I'm a bit wary of spec'ing some of the "deep" pieces in the token introspection spec unless we take a global view of what may really be required.

	Eve


On 7 Feb 2013, at 9:00 AM, Justin Richer <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> 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> 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>
>>> To:	<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
>>> 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


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl