Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
 with ESMTP id D2D7528C0E9 for <oauth@core3.amsl.com>;
 Thu, 10 Jun 2010 08:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level: 
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.063,
 BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEG4l8-JGZmA for
 <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:44:26 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net
 (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com
 (Postfix) with SMTP id B5B253A695F for <oauth@ietf.org>;
 Thu, 10 Jun 2010 08:44:26 -0700 (PDT)
Received: (qmail 8280 invoked from network); 10 Jun 2010 15:44:24 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by
 p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 15:44:24 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by
 P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi;
 Thu, 10 Jun 2010 08:44:23 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Paul Lindner <lindner@inuus.com>,
 "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Date: Thu, 10 Jun 2010 08:44:17 -0700
Thread-Topic: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
Thread-Index: AcsIsPkBzOQ+FzigT2SxkTBZei3iNgAAr1SA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com>
In-Reply-To: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative;
 boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 10 Jun 2010 15:44:27 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The request is very different on the resource server. On the authorization =
server, why would you use the same endpoint?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
aul Lindner
Sent: Thursday, June 10, 2010 8:24 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

Hi,

As I've been working through our oauth2 implementation I've noticed that it=
's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the reques=
t parameters alone.   Based on some investigative at the Shindig project it=
 appears that the only standard way to to determine 1.0a vs 2.0 is by check=
ing for the oauth_signature_method parameter.  More info here:

https://issues.apache.org/jira/browse/SHINDIG-1361

Has anyone else considered this use case?  How did you solve it?


--_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The reque=
st is very different on the resource server. On the authorization server, w=
hy would you use the same endpoint?<o:p></o:p></span></p><p class=3DMsoNorm=
al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color=
:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p><=
/o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f=
amily:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><di=
v style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0=
pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3=
.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;f=
ont-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:=
10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:o=
auth-bounces@ietf.org] <b>On Behalf Of </b>Paul Lindner<br><b>Sent:</b> Thu=
rsday, June 10, 2010 8:24 AM<br><b>To:</b> OAuth WG (oauth@ietf.org)<br><b>=
Subject:</b> [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests<o:p></o:p></s=
pan></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>Hi,<o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></=
div><div><p class=3DMsoNormal>As I've been working through our oauth2 imple=
mentation I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0=
 API calls based on the request parameters alone. &nbsp; Based on some inve=
stigative at the Shindig project it appears that the only standard way to t=
o determine 1.0a vs 2.0 is by checking for the&nbsp;<span class=3Dapple-sty=
le-span><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>oa=
uth_signature_method parameter. &nbsp;More info here:</span></span><o:p></o=
:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p c=
lass=3DMsoNormal><a href=3D"https://issues.apache.org/jira/browse/SHINDIG-1=
361">https://issues.apache.org/jira/browse/SHINDIG-1361</a><o:p></o:p></p><=
/div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DM=
soNormal>Has anyone else considered this use case? &nbsp;How did you solve =
it?<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></di=
v></div></div></body></html>=

--_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_--
