Re: [OAUTH-WG] Mandatory-to-implement token type
William Mills <wmills@yahoo-inc.com> Fri, 02 December 2011 01:51 UTC
Return-Path: <wmills@yahoo-inc.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 1BDF921F955A for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 17:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.397
X-Spam-Level:
X-Spam-Status: No, score=-17.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 d2zFS344tive for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 17:51:09 -0800 (PST)
Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 634651F0C87 for <oauth@ietf.org>; Thu, 1 Dec 2011 17:50:34 -0800 (PST)
Received: from [98.139.91.62] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 02 Dec 2011 01:50:34 -0000
Received: from [98.139.91.35] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 02 Dec 2011 01:50:34 -0000
Received: from [127.0.0.1] by omp1035.mail.sp2.yahoo.com with NNFMP; 02 Dec 2011 01:50:34 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 293519.52110.bm@omp1035.mail.sp2.yahoo.com
Received: (qmail 23332 invoked by uid 60001); 2 Dec 2011 01:50:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322790633; bh=DlJlTKnKtOvn6WlrleckW1lclHUCzp5Gped7qXwiAyI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S/j4w+Th3B9ZLKp3F4YHIyKquihMenEdKjnb8B1F95Nh3TM5kvq8VYFi5w8MVRYOvM3h4rJ6rl/2PaPmxF6s4n3Xn3IQd9lvGcaYjbVtPSfCbbRALZZpGCcMTwu2lNUX6R2nGKKX2kVBwwBNPduh0W3OH+6QUtycA9KgGQ4SrOY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V6iaV8zSLwYGrqpy/yqWMZTYbFjssWYJuDrVA1p0cAfwXhKbCBckmzCMSYOkG7k2IYs6fp2p/p7oxmXwY8NIMzNut23TrbpkHIW9TzO48i55lgXnzpE2ooL5ApKbxLlquaAKc0pc6d1WSz+xyUtw+f89kt1ePRjnxMrCPiL0mPQ=;
X-YMail-OSG: JVEVmOMVM1nuoz8M7Yl3Dwowoyifr.0AeKliLB6LFkZK9f1 zBuj6ZXs.2GVTGtn3.0yRnSukd1r21V3quhrOuw7MgW5DzujUf0ho_rM8KAo 30IoCNrWG8rrhwbMYRk0i95QR1Bnbj4DLyCCAf7cM9o8g4f45b_gP7AuoWne FreRMjRLQr6GDtfNSJJpuzbTroe0NkV6eRb4gIKTwWuvC8z3nYozfxnmBSb4 wCy3aLv3io6Enl0mhqVc3eHYLb3kjEieZ4NdIli8XuZUswfmA4NNn58kR3ft gPxRtuMFKbMvpx6_7zPuKmuMDl5hdsARd1kkjKb0OxRpwvTSPlAmgybP4CBj GGTI4F6dOgihyVhniOtx897t8H0bJhYSCzaPrCziQGBCO1l4Px_Ap_biFJmn d1Gd6.tITFgJF.WzNuWcRsvRqSNz06KMKoPoGXdiz8TLv3K7f835AsoELcD5 AGf0PdhDDZtxGAa8ex9ZGZ_ckG61Zem92KhoVX0dD65tVKLJuAw1SCHGxoA- -
Received: from [209.131.62.113] by web31816.mail.mud.yahoo.com via HTTP; Thu, 01 Dec 2011 17:50:33 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
References: <CALaySJJ+2au5rxEQmSSpXO42KmgCu=NhiLPBCx-3AH0hud=5CQ@mail.gmail.com> <4ED7F0D8.6010703@cs.tcd.ie> <17870960-E739-40BC-B2C1-EB93507F34EA@oracle.com> <4ED8288E.90101@cs.tcd.ie>
Message-ID: <1322790633.20785.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Thu, 01 Dec 2011 17:50:33 -0800
From: William Mills <wmills@yahoo-inc.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <4ED8288E.90101@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-1269876988-1322790633=:20785"
Cc: Barry Leiba <barryleiba@computer.org>, oauth WG <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
Reply-To: William Mills <wmills@yahoo-inc.com>
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, 02 Dec 2011 01:51:11 -0000
If we MTI a "weaker" token type (arguably Bearer falls here) that means the spec will be inappropriate in higher security requirement situations, those folks walk away. If we MTI something like SAML it makes the folks that want a light weight Bearer token solution walk away. ________________________________ From: Stephen Farrell <stephen.farrell@cs.tcd.ie> To: Phil Hunt <phil.hunt@oracle.com> Cc: Barry Leiba <barryleiba@computer.org>; oauth WG <oauth@ietf.org> Sent: Thursday, December 1, 2011 5:23 PM Subject: Re: [OAUTH-WG] Mandatory-to-implement token type On 12/02/2011 12:23 AM, Phil Hunt wrote: > Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. I just don't get that. Why is it somehow difficult to pick one but at the same time easy to implement any? <snip / ________________________________ From: Stephen Farrell <stephen.farrell@cs.tcd.ie> To: Phil Hunt <phil.hunt@oracle.com> Cc: Barry Leiba <barryleiba@computer.org>; oauth WG <oauth@ietf.org> Sent: Thursday, December 1, 2011 5:23 PM Subject: Re: [OAUTH-WG] Mandatory-to-implement token type On 12/02/2011 12:23 AM, Phil Hunt wrote: > Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. I just don't get that. Why is it somehow difficult to pick one but at the same time easy to implement any? > E.g. MAC tokens work well for non-TLS protected resources. Bearer tokens in contrast are easier to use, but require TLS protected service to avoid theft-of-credential. So picking is a nuisance sure. But it helps interop. > Even at this level, site security policies will simply override whatever is stated in the specification and choose one type only. Yes, but those policies will be affected by what's available in the running code. I'd like if what's available was known when the coder says "we implement RFC <foo>" > Having multiple MTIs, suggests choice and that causes other problems. What happens when a client wants to use a bearer token over an unprotected connection? How does the client discover what can be used and when? Having no MTI causes identical problems. > The approach we have now where the Token specification defines interop requirements and a profile for use with OAuth2 seems to be a good way to go. We disagree about that I guess. To me it seems a peculiar way to go unless one assumes that coders write code that's specific to a specific service provider. S. > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2011-12-01, at 1:25 PM, Stephen Farrell wrote: > >> >> Barry, all, >> >> First, apologies for being so slow responding, various >> travels got in the way. I hope we can quickly resolve this now. >> >> Bit of process first: at the meeting we discussed this and at the >> end of that discussion, there were quite a few more folks for the >> "pick one" position. People who favour that outcome and really >> care about that need to speak up on the list, since the list >> consensus trumps the sense of the room in the chairs' evaluation >> of the WG consensus. >> >> Second, at the meeting I said that I'd like to see either MAC or >> bearer picked as MTI, and if not, that I want the draft to say >> why its ok to have no MTI token type. So the WG either need to >> pick one, or else explicitly and convincingly justify not >> picking one. That's the "firm" AD position to which Barry >> referred. (I didn't properly call out the "if not" part of >> that in my AD review, sorry.) >> >> My own argument for picking one is simple: if every relevant >> piece of code has to know how to handle one then it becomes >> easier to get interop. If everyone decides for themselves >> then interop is less likely since there are currently two >> choices and may be more in future. >> >> I do realise that the background here and current practice >> is that code tends to be written that is specific to a >> resource server (or however that's best phrased) but that's >> maybe where the IETF differs from the community that produced >> OAuth - here we want two independent implementers who've >> never talked to produce code that interops even so. >> >> I also realise that that's not the full story for getting >> interop with OAuth and that more is needed. However, this >> aspect is otherwise fully specified and so I don't buy the >> argument that this isn't worth doing just because we don't >> have the full registration story etc. figured out. If we don't >> sort this out now, then later specs will have to update >> this one in this respect. possibly making existing code >> "non-compliant" in some sense, so just going ahead and doing >> it right now is better. >> >> So, pick one (my strong personal preference) or establish and >> document why you're not picking one seem to me to be the choices >> available. >> >> Regards, >> Stephen. >> >> >> On 11/17/2011 08:28 AM, Barry Leiba wrote: >>> Stephen, as AD, brought up the question of mandatory-to-implement >>> token types, in the IETF 82 meeting. There was some extended >>> discussion on the point: >>> >>> - Stephen is firm in his belief that it's necessary for >>> interoperability. He notes that mandatory to *implement* is not the >>> same as mandatory to *use*. >>> - Several participants believe that without a mechanism for requesting >>> or negotiating a token type, there is no value in having any type be >>> mandatory to implement. >>> >>> Stephen is happy to continue the discussion on the list, and make his >>> point clear. In any case, there was clear consensus in the room that >>> we *should* specify a mandatory-to-implement type, and that that type >>> be bearer tokens. This would be specified in the base document, and >>> would make a normative reference from the base doc to the bearer token >>> doc. >>> >>> We need to confirm that consensus on the mailing list, so this starts >>> the discussion. Let's work on resolving this over the next week or >>> so, and moving forward: >>> >>> 1. Should we specify some token type as mandatory to implement? Why >>> or why not (*briefly*)? >>> >>> 2. If we do specify one, which token type should it be? >>> >>> Barry, as chair >>> _______________________________________________ >>> 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