Re: [OAUTH-WG] Revised Section 3

Anthony Nadalin <tonynad@microsoft.com> Fri, 22 April 2011 23:12 UTC

Return-Path: <tonynad@microsoft.com>
X-Original-To: oauth@ietfc.amsl.com
Delivered-To: oauth@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E4ADE0669 for <oauth@ietfc.amsl.com>; Fri, 22 Apr 2011 16:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.016
X-Spam-Level:
X-Spam-Status: No, score=-7.016 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq0CLKYdFl8U for <oauth@ietfc.amsl.com>; Fri, 22 Apr 2011 16:12:15 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 34CAEE065F for <oauth@ietf.org>; Fri, 22 Apr 2011 16:12:15 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 22 Apr 2011 16:12:13 -0700
Received: from VA3EHSOBE009.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 22 Apr 2011 16:12:14 -0700
Received: from mail63-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 22 Apr 2011 23:12:13 +0000
Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 1947AA381B3 for <oauth@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Fri, 22 Apr 2011 23:12:13 +0000 (UTC)
X-SpamScore: -29
X-BigFish: PS-29(zz9371OzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1303513928891538_15963; Fri, 22 Apr 2011 23:12:08 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.253]) by mail63-va3.bigfish.com (Postfix) with ESMTP id C81FE228050; Fri, 22 Apr 2011 23:12:08 +0000 (UTC)
Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 22 Apr 2011 23:12:01 +0000
Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.221]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.042; Fri, 22 Apr 2011 23:11:59 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: "William J. Mills" <wmills@yahoo-inc.com>, Eran Hammer-Lahav <eran@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [OAUTH-WG] Revised Section 3
Thread-Index: Acv64NrBpCvr7/oJRM63yzYYeWvbGwAAF3XwAA2tm9AAvpIFMAAA6NTAAB2/gYAAA7I5gAADPdkAAAF71YAAAvT6gAABnOkAAAAhFQAAAJ1bAAABBRIAAAIBpIAAATynAAAAMeuAACk2iiAADuGQAAAm7+iAAAIawIAALNYVsAALpPcAAAAY5aAAAEP/cAAANtkAAAD8qIAAAA/YwA==
Date: Fri, 22 Apr 2011 23:11:59 +0000
Message-ID: <B26C1EF377CB694EAB6BDDC8E624B6E71A480DDB@CH1PRD0302MB115.namprd03.prod.outlook.com>
References: <B26C1EF377CB694EAB6BDDC8E624B6E71A480C92@CH1PRD0302MB115.namprd03.prod.outlook.com> <C9D748FE.11633%eran@hueniverse.com> <B26C1EF377CB694EAB6BDDC8E624B6E71A480CF1@CH1PRD0302MB115.namprd03.prod.outlook.com> <90C41DD21FB7C64BB94121FBBC2E723447535BBF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B26C1EF377CB694EAB6BDDC8E624B6E71A480D35@CH1PRD0302MB115.namprd03.prod.outlook.com> <242018.69896.qm@web31811.mail.mud.yahoo.com>
In-Reply-To: <242018.69896.qm@web31811.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.28.29.165]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E71A480DDBCH1PRD0302MB115_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%YAHOO-INC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-OriginatorOrg: microsoft.com
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Revised Section 3
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, 22 Apr 2011 23:12:17 -0000

There is no extension in WRAP to allow this, it’s allowed as part of WRAP.

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Friday, April 22, 2011 4:10 PM
To: Anthony Nadalin; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3

That WRAP allowed extension and that someone extended with a second assertion does not imply that a second assertion is provided for in WRAP.  It means that WRAP allowed extension.  AQre we trying to bring that extension into the main spec as a needed use case?

________________________________
From: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
To: Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>>; Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>
Cc: OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Friday, April 22, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Revised Section 3


Not sure I have to show you anything. The WRAP specification does not preclude the usage of 2 assertions as this was one of the must support use cases for WRAP. As I indicated this was not the best spelled out feature in the WRAP specification. Yaron’s append was an attempt to clarify the use case with additional text. If you want to come on site you can see the code and the dates on the code that predates Yaron’s text.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Friday, April 22, 2011 3:40 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

Let me make sure we’re clear here:

Your argument is that this is not a new use case because WRAP allows ‘additional parameters’ and doesn’t explicitly forbids it?

If I missed something, please quote the exact normative language in WRAP showing how to use two assertions, or any text differentiating between using an assertion for client authentication vs. using an assertion for resource owner authorization. Show me anything that pre-dates Yaron’s text documenting the two assertions use case.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]<mailto:[mailto:tonynad@microsoft.com]>
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3

I disagree here, this is not new or even completely new use case as this was in WRAP as we are using this feature now. I would agree that it’s not very well documented but that was attempted by Yaron in his append was to clarify the support.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3



From: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
Date: Fri, 22 Apr 2011 14:51:33 -0700

AJN-> So the client credentials originate from WRAP also, it’s not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The  section 5.2 (and subsections) in the WAP specification is where you see the assertion documented but what is not explicitly stated (other than additional parameters clause)there but not disallowed is the ability to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRAP for authentication

It is completely new.

The two assertions functionality is certainly NOT in WRAP. It is not even hinted at.

Seems to me you just made my case for dropping this issue. If this is your rational for adding two assertions support in v2, then we can be done right now. v2 already gives you the exact same 'additional parameters' support and does not disallow two assertions. You have made statements in the past that WRAP did everything you needed and that v2 has to cover the same scope.

Well, it already does.

We can certainly continue to debate whether v2 needs to address this new use case, and if so how to accomplish it, but that is based solely on new requirements and is an expansion of the agreed protocol scope (WRAP + OAuth 1.0).

EHL



_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth