Re: [OAUTH-WG] AD review of -22
Michael Thomas <mike@mtcc.com> Thu, 03 November 2011 16:52 UTC
Return-Path: <mike@mtcc.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 0015811E8149 for <oauth@ietfa.amsl.com>; Thu, 3 Nov 2011 09:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 3NDDMwjjxNuu for <oauth@ietfa.amsl.com>; Thu, 3 Nov 2011 09:52:25 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0872D11E8099 for <oauth@ietf.org>; Thu, 3 Nov 2011 09:52:25 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id pA3GqFqK031459 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 09:52:15 -0700
Message-ID: <4EB2C6BF.2060801@mtcc.com>
Date: Thu, 03 Nov 2011 09:52:15 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <4E971C36.7050000@cs.tcd.ie> <4EB19DD1.6050904@lodderstedt.net> , <5E3E5DFE-C122-4D89-9578-61A6C16EBD76@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E72345263321025@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1320274139.8042.YahooMailNeo@web31809.mail.mud.yahoo.com> <1320324374.15549.29.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345263403444@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345263403444@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5707; t=1320339137; x=1321203137; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[OAUTH-WG]=20AD=20review=20of=20-22 |Sender:=20 |To:=20Eran=20Hammer-Lahav=20<eran@hueniverse.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=axmiQe10D1LzAeKzF08+GTT90joEhsD/GAQsSPbisi4=; b=EbOuvTXF6GtmeZA8OJz7w/2Gzk33xZGUVmkRmMnrtqqtn+I/I5L9NmCI1p p4nKbuQwVIff8UZtqHWokQ9Kh8fHIaYSdDP4gfrSqjtt/uPRXXntNBYGghyv knBzpiNIBWEvFUYMnYfqow8Zb2zI8vREWjfKnVgL8mxTwlz76CLXk=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of -22
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, 03 Nov 2011 16:52:26 -0000
On 11/03/2011 09:25 AM, Eran Hammer-Lahav wrote: > It can help by telling servers that as long as they support one of the MTI types, they will be able to interop. Of course, they don't have to. > > My feeling is that until there is an actual discovery experience out there that works, this kind of interop is not really an issue ATM. > From what I can tell as a developer, it seems that every oauth server deployment comes with their very own oauth client library/sdk. So there's a twitter one, a g+ one, a fb one, etc. Ultimately there may be an oauth equivalent to openssl, but it's not there afaik, and probably won't be for a while since the library/sdk needs to support php, perl, python, ruby, blah, blah, blah instead of just a C library with higher level language specific veneers on top of it as needed. So the reality is that any unified client is going to have to support what servers demand, not the other way around. Which means it's going to have to be a kitchen sink client library to handle the various choices that servers make. So I'd say no to any form of an sdp-like* offer/answer protocol; it's just easier to keep adding to the client kitchen sink. Mike [*] sdp offer/answer was necessary because of _hardware_ limitations... usually because of codec complexity where an endpoint physically might not be able to interoperate. that's good motivation. I doubt there's anything comparable with oauth. > EHL > > >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mitre.org] >> Sent: Thursday, November 03, 2011 5:46 AM >> To: William Mills >> Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of -22 >> >> This is exactly what I was thinking of. If a given token type is MTI for clients, >> but servers can do whatever they want (this, as I read it, is what was >> suggested), how does the MTI bit help interop at all? >> >> -- Justin >> >> On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote: >> >>> I actually think the protected resource specifies the token type(s) in >>> either it's service docs or discovery information, and it does know >>> knowing it's authentication server will issue compatible tokens. The >>> client may encounter endpoints requiring token types it doesn't >>> support, and it needs to fail gracefully. The client may select any >>> supported OAuth 2 scheme it understands which the PR supports. >>> >>> >>> >>> I am not in favor of specifying MUST for any particular flavor of >>> token. >>> >>> >>> What is the value of mandating a token type? >>> >>> >>> >>> -bill >>> >>> >>> >>> >>> >>> >> __________________________________________________________ >> ____________ >> >>> From: Eran Hammer-Lahav<eran@hueniverse.com> >>> To: John Bradley<ve7jtb@ve7jtb.com>; Torsten Lodderstedt >>> <torsten@lodderstedt.net> >>> Cc: "oauth@ietf.org"<oauth@ietf.org> >>> Sent: Wednesday, November 2, 2011 1:11 PM >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> Do you want to see no change or adjust it to client must implement >>> both, server decides which to use. >>> >>> EHL >>> >>> >>> >>> >> __________________________________________________________ >> ____________ >> >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>> John Bradley [ve7jtb@ve7jtb.com] >>> Sent: Wednesday, November 02, 2011 1:06 PM >>> To: Torsten Lodderstedt >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of -22 >>> >>> >>> >>> +1 >>> On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: >>> >>> >>>> Hi Stephen, >>>> >>>> I'm concerned about your proposal (7) to make support for MAC a MUST >>>> for clients and BEARER a MAY only. In my opinion, this does not >>>> reflect the group's consensus. Beside this, the security threat >>>> analysis justifies usage of BEARER for nearly all use cases as long >>>> as HTTPS (incl. server authentication) can be utilized. >>>> regards, >>>> Torsten. >>>> >>>> Am 13.10.2011 19:13, schrieb Stephen Farrell: >>>> >>>>> Hi all, >>>>> >>>>> Sorry for having been quite slow with this, but I had a bunch of >>>>> travel recently. >>>>> >>>>> Anyway, my AD comments on -22 are attached. I think that the first >>>>> list has the ones that need some change before we push this out >>>>> for IETF LC, there might or might not be something to change as a >>>>> result of the 2nd list of questions and the rest are really nits >>>>> can be handled either now or later. >>>>> >>>>> Thanks for all your work on this so far - its nearly there IMO and >>>>> we should be able to get the IETF LC started once these few things >>>>> are dealt with. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 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] AD review of -22 Stephen Farrell
- Re: [OAUTH-WG] AD review of -22 Eran Hammer-Lahav
- Re: [OAUTH-WG] AD review of -22 Torsten Lodderstedt
- Re: [OAUTH-WG] AD review of -22 John Bradley
- Re: [OAUTH-WG] AD review of -22 Eran Hammer-Lahav
- Re: [OAUTH-WG] AD review of -22 Phil Hunt
- Re: [OAUTH-WG] AD review of -22 Justin Richer
- Re: [OAUTH-WG] AD review of -22 Stephen Farrell
- Re: [OAUTH-WG] AD review of -22 Mike Jones
- Re: [OAUTH-WG] AD review of -22 Stephen Farrell
- Re: [OAUTH-WG] AD review of -22 John Bradley
- Re: [OAUTH-WG] AD review of -22 Phillip Hunt
- Re: [OAUTH-WG] AD review of -22 Stephen Farrell
- Re: [OAUTH-WG] AD review of -22 Torsten Lodderstedt
- Re: [OAUTH-WG] AD review of -22 Eran Hammer-Lahav
- Re: [OAUTH-WG] AD review of -22 John Bradley
- Re: [OAUTH-WG] AD review of -22 André DeMarre
- Re: [OAUTH-WG] AD review of -22 William Mills
- Re: [OAUTH-WG] AD review of -22 Justin Richer
- Re: [OAUTH-WG] AD review of -22 Eran Hammer-Lahav
- Re: [OAUTH-WG] AD review of -22 Phil Hunt
- Re: [OAUTH-WG] AD review of -22 Michael Thomas
- Re: [OAUTH-WG] AD review of -22 William Mills