Re: [OAUTH-WG] Mandatory-to-implement token type
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 04 December 2011 14:44 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 0037A21F846C for <oauth@ietfa.amsl.com>; Sun, 4 Dec 2011 06:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAAE8z0nSOG0 for <oauth@ietfa.amsl.com>; Sun, 4 Dec 2011 06:44:15 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E344621F8466 for <oauth@ietf.org>; Sun, 4 Dec 2011 06:44:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 089C2171CB4; Sun, 4 Dec 2011 14:44:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1323009853; bh=huo3QHd+hyzNox czHrf/J+7Pjkpo+kveoT+27OW1XAg=; b=pADakI2VWLv8YBf/9ItHjgJr9gUTYN BPUV+cM9kD5Z7j0BxeTczgqBXvHIzJ3B8Jd/YrCpnhfIIt8dSRCRyQThLflvLxSJ YubJzAfi768XBxeOMHHNsBmeQSQ9wa3/x4lJDRVCZSLTL//UdRZhle9jeDqqhL/s ASmDJ9mJ5TtWudfl6F46P7FaekDnaccA9aj0f+y+uZYxsJZxvGle8LYLO9xyrZqf SISKQdxEQEDG5BS+UYXWlXyNPUddgMesSvTqHFDjjVG7QxqImgC/O5uto2f/AJJG g/V4eXiROk0127xU8h0b+rCmcU2d4VnOKl9BI17Qz8tZ2qlyTTY+Tdqw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2sz4Ims9BIAB; Sun, 4 Dec 2011 14:44:13 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.44.76.70]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E9A38171C61; Sun, 4 Dec 2011 14:44:12 +0000 (GMT)
Message-ID: <4EDB873C.4040005@cs.tcd.ie>
Date: Sun, 04 Dec 2011 14:44:12 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>
References: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com> <CAH-8B6sjim_tcBkTPFWc1SnjhtHDQTR7sVT+aOjnYv7cs8JssA@mail.gmail.com> <4ED82D62.3070800@cs.tcd.ie> <CALaySJLKYLpPWc14_GUJKc5j1E3QovKQOx9HsdR-n2YV7kstpQ@mail.gmail.com> <4ED89384.9060603@cs.tcd.ie> <CAC4RtVBQdV+dwhzK903nkeNhsKzrHNFPYMK+EZtxRXnHWGs68w@mail.gmail.com> <4EDB726E.2060900@gmail.com> <4EDB81A9.5090007@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739435F757A6B@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F757A6B@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
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: Sun, 04 Dec 2011 14:44:16 -0000
Whatever. If the entire WG want to get excited by the difference between MAY do mac and not mentioning it then fine. Personally, I'd be more interested in getting done rather than nailing that final nail into any coffin;-) S On 12/04/2011 02:21 PM, Mike Jones wrote: > The core spec should be completely silent on MAC, as it is not ready for prime time. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Sunday, December 04, 2011 6:20 AM > To: Paul Madsen > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Mandatory-to-implement token type > > > FWIW, if Barry's suggested text was amended to say "MUST do bearer, MAY do mac" I'd still be ok with that. > > Much as I'd like if the mac scheme were more popular, my comment on -22 was interop and not really security related. > > S > > On 12/04/2011 01:15 PM, Paul Madsen wrote: >> Commercial OAuth authorization servers are neither 'toolkits' nor >> 'purpose built code' - not used to build OAuth clients/servers but yet >> required to support more variety in deployments than a single purpose >> built server. >> >> But, that variety is driven by customer demand, and none of ours >> (yet?) have demanded MAC. If and when that demand comes, we will add support. >> >> To stipulate MAC as MTI would in no way reflect what the market wants. >> And 'interop' nobody wants is not meaningful interop. >> >> paul >> >> On 12/3/11 4:37 PM, Barry Leiba wrote: >>> Stephen says: >>>> On 12/02/2011 03:20 AM, Barry Leiba wrote: >>>>> Maybe what would work best is some text that suggests what I say >>>>> above: that toolkits intended for use in implementing OAuth >>>>> services in general... implement [X and/or Y], and that code >>>>> written for a specific environment implement what makes sense for that environment. >>>>> It seems to me that to require any particular implementation in the >>>>> latter case is arbitrary and counter-productive, and doesn't help >>>>> anything interoperate. Whereas general-purpose toolkits that >>>>> implement everything DO help interop. >>>> That'd work just fine for me. >>> OK, so here's what I suggest... I propose adding a new section 7.2, thus: >>> >>> ----------------------------------- >>> 7.2 Access Token Implementation Considerations >>> >>> Access token types have to be mutually understood among the >>> authorization server, the resource server, and the client -- the >>> access token issues the token, the resource server validates it, and >>> the client is required to understand the type, as noted in section >>> 7.1, above. Because of that, interoperability of program code >>> developed separately depends upon the token types that are supported >>> in the code. >>> >>> Toolkits that are intended for general use (for building other >>> clients and/or servers), therefore, SHOULD implement as many token >>> types as practical, to ensure that programs developed with those >>> toolkits are able to use the token types they need. In particular, >>> all general-use toolkits MUST implement bearer tokens [...ref...] and >>> MAC tokens [...ref...]. >>> >>> Purpose-built code, built without such toolkits, has somewhat more >>> flexibility, as its developers know the specific environment they're >>> developing for. There's clearly little point to including code to >>> support a particular token type when it's known in advance that the >>> type in question will never be used in the intended deployment. >>> Developers of purpose-built code are encouraged to consider future >>> extensions and to plan ahead for changes in circumstances, and might >>> still want to include support for multiple token types. That said, >>> the choice of token-type support for such purpose-built code is left >>> to the developers and their specific requirements. >>> ----------------------------------- >>> >>> I think that expresses a reasonable compromise that might actually be >>> followed and might actually do some good. Comments? Can we go with >>> this and close this issue? (And, sorry, I've been a Bad Chair, and >>> haven't put this in the tracker.) >>> >>> Barry >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
- [OAUTH-WG] Mandatory-to-implement token type Barry Leiba
- Re: [OAUTH-WG] Mandatory-to-implement token type Justin Richer
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael Thomas
- Re: [OAUTH-WG] Mandatory-to-implement token type Eran Hammer-Lahav
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type William Mills
- Re: [OAUTH-WG] Mandatory-to-implement token type Phil Hunt
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael Thomas
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael D Adams
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type William Mills
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael D Adams
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael Thomas
- Re: [OAUTH-WG] Mandatory-to-implement token type Michael D Adams
- Re: [OAUTH-WG] Mandatory-to-implement token type Barry Leiba
- Re: [OAUTH-WG] Mandatory-to-implement token type William Mills
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Bart Wiegmans
- Re: [OAUTH-WG] Mandatory-to-implement token type Blaine Cook
- [OAUTH-WG] Fwd: Re: Mandatory-to-implement token … Justin Richer
- Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement to… André DeMarre
- Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement to… Richer, Justin P.
- Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement to… André DeMarre
- Re: [OAUTH-WG] Fwd: Re: Mandatory-to-implement to… Dan Taflin
- Re: [OAUTH-WG] Mandatory-to-implement token type Barry Leiba
- Re: [OAUTH-WG] Mandatory-to-implement token type Mike Jones
- Re: [OAUTH-WG] Mandatory-to-implement token type John Bradley
- Re: [OAUTH-WG] Mandatory-to-implement token type Anthony Nadalin
- Re: [OAUTH-WG] Mandatory-to-implement token type Paul Madsen
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Mike Jones
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Eran Hammer-Lahav
- Re: [OAUTH-WG] Mandatory-to-implement token type Eran Hammer-Lahav
- Re: [OAUTH-WG] Mandatory-to-implement token type Blaine Cook
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell
- Re: [OAUTH-WG] Mandatory-to-implement token type Justin Richer
- Re: [OAUTH-WG] Mandatory-to-implement token type Marius Scurtescu
- Re: [OAUTH-WG] Mandatory-to-implement token type Leif Johansson
- Re: [OAUTH-WG] Mandatory-to-implement token type Leif Johansson
- Re: [OAUTH-WG] Mandatory-to-implement token type William Mills
- Re: [OAUTH-WG] Mandatory-to-implement token type Blaine Cook
- Re: [OAUTH-WG] Mandatory-to-implement token type Leif Johansson
- Re: [OAUTH-WG] Mandatory-to-implement token type Barry Leiba
- Re: [OAUTH-WG] Mandatory-to-implement token type Stephen Farrell