From beaton@google.com Wed Jun 1 00:00:20 2011 Return-Path: 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 CABF0E06B6 for ; Wed, 1 Jun 2011 00:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Ga5EaGVEil for ; Wed, 1 Jun 2011 00:00:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9AAE0697 for ; Wed, 1 Jun 2011 00:00:20 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p5170JIG012513 for ; Wed, 1 Jun 2011 00:00:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306911619; bh=ntOw0KOqOChpnw/r+uZso2a2N4s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=kB7kfuTobjW2VXfC8NMCOBsDj/MaZpE28CuP0mvnV8d9t2fwtflecVbbq8oagj3m+ KNEAJ85MD3f/c0vUYCGtw== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by wpaz29.hot.corp.google.com with ESMTP id p5170CUA024411 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 00:00:13 -0700 Received: by pxi13 with SMTP id 13so2221811pxi.39 for ; Wed, 01 Jun 2011 00:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0piEW6Dgl0M9T1SU5lgOoSJ47DTYF68Su7QSdOtwVlo=; b=g+YhWZA7R91PQZvfRXKJ6tEk8KgOlWDsLMUjawFUvXOxxz1JOKVtSOz9+KbQPNuhzG quPr+i/HW+85KmKyjZ9w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ojGYnfbitoN+jcwfAeYwlHS8ZdtC1u9FBqyQv/2UuOQ50N2BOaXYmWkrGkKjEjPOEl NnWs4JP40FzCmWQBHmFA== MIME-Version: 1.0 Received: by 10.142.248.41 with SMTP id v41mr1176891wfh.323.1306911608092; Wed, 01 Jun 2011 00:00:08 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 00:00:08 -0700 (PDT) In-Reply-To: <2D3B9285-476D-4EA8-ADB5-F3A0FD71815C@gmail.com> References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <2D3B9285-476D-4EA8-ADB5-F3A0FD71815C@gmail.com> Date: Wed, 1 Jun 2011 00:00:08 -0700 Message-ID: From: Brian Eaton To: Kris Selden Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:00:20 -0000 On Tue, May 31, 2011 at 11:47 PM, Kris Selden wrote= : > If a provider chooses to do that though, in the attack you described, the= y could still revoke the refresh token to stop the abuse when it is discove= red, and that is still easier in my opinion than rotating a client secret b= ut yes, allowing that does make the client secret pointless for refreshing = tokens. The attack I am describing is against a web server, so what you are saying is not true. We should talk about installed apps (no real client secret) differently than we talk about web servers. They are different problems. From recordond@gmail.com Wed Jun 1 00:06:07 2011 Return-Path: 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 EAD58E076E for ; Wed, 1 Jun 2011 00:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQHzo73r0RJQ for ; Wed, 1 Jun 2011 00:06:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7755E0697 for ; Wed, 1 Jun 2011 00:06:06 -0700 (PDT) Received: by vws12 with SMTP id 12so5379513vws.31 for ; Wed, 01 Jun 2011 00:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=poaQKxNVUm9HyK0jVxgbPmyjE3HDdyDIydYkmFPctXw=; b=srEr35FoJLN664NUtsy1EIrTPHXlXaA03YvPUf3mLLriE8My4itBuwWWAAHP8KoRCb B1GNrCZTAC0L2xDUs/KthVsv+x2psmEcSMDwHkbYv/nb/vOFluLjEMbAtd3ojKf6ZUbp JOqPqC53UApL+3cLJoPsKJRUW+9/fqEo3vIz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R3srJCTfzT1zHK5TSDJw6gnSOfsPvGq9/OjalqlI92jW1sjDa4prmblB4fXlm7ky3a rq/xAjN1DZUu6Thl/B3mPp73ETk1uzmuhR3CV09UqzBY+LiqY8FaBrNfTf0FC6WLQ1Vu xMBH/NBqorZR9CPlfp8hqtrg9tmeoKvRAarWE= MIME-Version: 1.0 Received: by 10.52.94.239 with SMTP id df15mr1688918vdb.254.1306911965522; Wed, 01 Jun 2011 00:06:05 -0700 (PDT) Received: by 10.52.158.169 with HTTP; Wed, 1 Jun 2011 00:06:05 -0700 (PDT) In-Reply-To: <4DE541B5.6080605@aol.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> Date: Wed, 1 Jun 2011 00:06:05 -0700 Message-ID: From: David Recordon To: George Fletcher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:06:08 -0000 Yeah, can understand how we got here. Just found it quite confusing when reading these two specifications together with an implementor's hat on. On Tue, May 31, 2011 at 12:29 PM, George Fletcher wrote: > Brief pointer to the "history" of this change. This change was adopted in > draft 4 of the bearer spec as there were concerns with the previous > parameter name of 'oauth_token'. The suggestion was made to use > 'bearer_token' so that it matches the scheme used in the Authorization > header. The thinking being that reading the bearer token spec would seem > weird if the Authorization header used one name and the GET/POST methods > used a different name. > > The 'bearer_token' name got a few +1 and no dissents. > > Full thread starts here [1]. Mike accepting the 'bearer_token' > recommendation is here [2]. > > Thanks, > George > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html > > On 5/28/11 12:30 PM, David Recordon wrote: > > Did a full read through of draft 16 and the bear token spec with Paul > yesterday afternoon in order to do a manual diff from draft 10. The > point Doug raised was actually confusing. Throughout the core spec > it's referred to as access_token but then becomes bearer_token upon > use. > > Just thinking through this from a developer documentation perspective, > it's going to become confusing. Developer documentation focuses on > getting an access token and then using that access token to interact > with an API. Thus the code you're writing as a client developer will > use variables, cache keys, and database columns named `access_token`. > But then when you're going to use it, you'll need to put this access > token into a field named bearer_token. > > Feels quite a bit simpler to just name it access_token. Realize the > core spec never did this since we didn't want to trample on protected > resources which might already have a different type of access_token > parameter. oauth_token was a good compromise since developers would > already know that they were using OAuth and thus a new term wasn't > being introduced. That's no longer true with bearer_token since 99% of > developers will have never heard of a bearer token. > > Googling for "bearer token" turns up Eran's blog post titled "OAuth > Bearer Tokens are a Terrible Idea" and there isn't a single result on > the first page which explains what they are. Binging for "bearer > token" is equally scary. > > --David > > > On Mon, May 23, 2011 at 11:38 AM, Mike Jones > wrote: > > The working group explicitly decided that a different name should be used= , > to make it clear that other token types other than bearer tokens could al= so > be used with OAuth 2. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Doug Tangren > Sent: Wednesday, May 11, 2011 10:09 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] consistency of token param name in bearer token type > > > > This may have come up before so I'm sorry if I'm repeating. Why does bear= er > token spec introduce a new name for oauth2 access tokens [1], > "bearer_token", and before that [2], "oauth_token"? > > > > I=A0apologize=A0if this may sound shallow but, why introduce a new parame= ter > name verses sticking with what the general oauth2 spec already defines, > "access_token". It seems arbitrary for an auth server to hand a client an > apple then have the client hand it off to the resource server and call it= an > orange. > > > > Was this just for the sake of differentiating the parameter name enough s= o > that the bearer tokens may be used in other protocols without being confu= sed > with oauth2 access_tokens? > > > > [1]:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2= .2 > > [2]:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2= .2 > > > > -Doug Tangren > http://lessis.me > > _______________________________________________ > 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 > > > -- > Chief Architect AIM: gffletch > Identity Services Engineering Work: george.fletcher@teamaol.com > AOL Inc. Home: gffletch@aol.com > Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com > Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch > From cmortimore@salesforce.com Wed Jun 1 00:08:06 2011 Return-Path: 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 8B76DE0744 for ; Wed, 1 Jun 2011 00:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHLpj0h9bcai for ; Wed, 1 Jun 2011 00:08:04 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with SMTP id 3B23CE0697 for ; Wed, 1 Jun 2011 00:08:04 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKTeXlU4QgzHT0XtWltSEFGz9lQOAwLQj/@postini.com; Wed, 01 Jun 2011 00:08:04 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Wed, 1 Jun 2011 00:08:03 -0700 From: Chuck Mortimore To: Brian Eaton Date: Wed, 1 Jun 2011 00:08:00 -0700 Thread-Topic: [OAUTH-WG] Text for Native Applications Thread-Index: AcwgKSAlye8czDPhSQOQkpqI/o2hWAAAYPpp Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA0B33601AAA7cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:08:06 -0000 --_000_CA0B33601AAA7cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 5/31/11 11:56 PM, "Brian Eaton" wrote: On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore wrote: > It's not entirely necessary; I'm just having a tough time figuring out an= y > practical difference between the implicit grant flow, and the webserver f= low > with no credentials. In general I agree with your points, but I think w= e > have a similar, perhaps worse, scenario with relaxing the need for > credentials on the web server flow. No doubt. =3D) I think it's unfortunate that the spec was changed to make the client credentials optional for the web server flow. As you say, it's a security problem for web apps. We are treating the client secret as mandatory in our deployments, and basically everyone who deploys the web server flow should do the same. It's a shame the spec is so vague on this point. This is one reason we've favored implicit for native apps. The root cause of the spec ambiguity was disagreement over how to handle secrets for installed applications. I can think of three paths forward. - split out "installed app flow" from "web server flow". Use a new grant type. (DON'T switch installed apps to use the "implicit" grant type. That doesn't work either, because it doesn't return a long-lived credential. DON'T have the implicit grant type return a refresh token directly, either, since that causes serious security problems for real web apps that can keep client secrets.) Our approach to this issue has been to avoid returning refresh tokens to we= b URLs when using the implicit grant. We only support returning to one co= ntrolled URL on our server, or to a custom scheme url. It's bit tough to = explain doc for developers though. - make the client secret mandatory, but tell people who are offended by client secrets in installed apps to use the string "notasecret" for all installed apps. Toyed with this idea. -cmort - ignore the problem and leave the spec vague and insecure. > In terms of your example, wouldn't basic XSRF protection in the state par= am protect? Nope. Assume the following scenario: - bad guy has stolen refresh token - client web server has detected attack and changed their client secret - bad guy wants to find a way to keep using the refresh token If refresh tokens are returned without client authentication, the bad guy can do it as follows: - visit client. log in as account badguy1234. - client redirects to authorization server, including state=3D1234 - bad guy ignores redirect to authorization server, visits client callback server with refresh_token=3Dstolen&state=3D1234 - client picks up stolen refresh token and associates it with badguy1234. - whenever badguy1234 visits the client web site, he can see data from the stolen refresh token. Cheers, Brian --_000_CA0B33601AAA7cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Text for Native Applications On 5/31/11 11:5= 6 PM, "Brian Eaton" <beaton@goog= le.com> wrote:

On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
<cmortimore@salesforce.com>= wrote:
> It’s not entirely necessary; I’m just having a tough time = figuring out any
> practical difference between the implicit grant flow, and the webserve= r flow
> with no credentials. =A0=A0In general I agree with your points, but I = think we
> have a similar, perhaps worse, scenario with relaxing the need for
> credentials on the web server flow.

No doubt. =3D)  I think it's unfortunate that the spec was changed to<= BR> make the client credentials optional for the web server flow.  As you<= BR> say, it's a security problem for web apps.  We are treating the client=
secret as mandatory in our deployments, and basically everyone who
deploys the web server flow should do the same.  It's a shame the spec=
is so vague on this point.

This is one reason we’ve favored implicit for native apps= .


The root cause of the spec ambiguity was disagreement over how to
handle secrets for installed applications.  I can think of three paths=
forward.

- split out "installed app flow" from "web server flow"= .  Use a new
grant type.  (DON'T switch installed apps to use the "implicit&qu= ot; grant
type.  That doesn't work either, because it doesn't return a
long-lived credential.  DON'T have the implicit grant type return a refresh token directly, either, since that causes serious security
problems for real web apps that can keep client secrets.)


Our approach to this issue has been to avoid returning refresh = tokens to web URLs when using the implicit grant.   We only suppo= rt returning to one controlled URL on our server, or to a custom scheme url= .   It’s bit tough to explain doc for developers though.


- make the client secret mandatory, but tell people who are offended
by client secrets in installed apps to use the string "notasecret"= ; for
all installed apps.

Toyed with this idea.

-cmort


- ignore the problem and leave the spec vague and insecure.

> In terms of your example, wouldn’t basic XSRF protection in the = state param protect?

Nope.  Assume the following scenario:
- bad guy has stolen refresh token
- client web server has detected attack and changed their client secret
- bad guy wants to find a way to keep using the refresh token

If refresh tokens are returned without client authentication, the bad
guy can do it as follows:
- visit client.  log in as account badguy1234.
- client redirects to authorization server, including state=3D1234
- bad guy ignores redirect to authorization server, visits client
callback server with refresh_token=3Dstolen&state=3D1234
- client picks up stolen refresh token and associates it with badguy1234. - whenever badguy1234 visits the client web site, he can see data from
the stolen refresh token.

Cheers,
Brian

--_000_CA0B33601AAA7cmortimoresalesforcecom_-- From torsten@lodderstedt.net Wed Jun 1 00:15:26 2011 Return-Path: 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 54082E078C for ; Wed, 1 Jun 2011 00:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70p1jro5adlh for ; Wed, 1 Jun 2011 00:15:25 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by ietfa.amsl.com (Postfix) with ESMTP id 91002E0774 for ; Wed, 1 Jun 2011 00:15:25 -0700 (PDT) Received: from [80.187.223.2] (helo=[10.135.145.12]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRfeG-0004AF-2W; Wed, 01 Jun 2011 09:15:24 +0200 Message-ID: <4DE5E70C.6020309@lodderstedt.net> Date: Wed, 01 Jun 2011 09:15:24 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <2D3B9285-476D-4EA8-ADB5-F3A0FD71815C@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:15:26 -0000 I'm getting confused. This thread is about native apps. So why discuss security considerations for web apps here? regards, Torsten. Am 01.06.2011 09:00, schrieb Brian Eaton: > On Tue, May 31, 2011 at 11:47 PM, Kris Selden wrote: >> If a provider chooses to do that though, in the attack you described, they could still revoke the refresh token to stop the abuse when it is discovered, and that is still easier in my opinion than rotating a client secret but yes, allowing that does make the client secret pointless for refreshing tokens. > The attack I am describing is against a web server, so what you are > saying is not true. > > We should talk about installed apps (no real client secret) > differently than we talk about web servers. They are different > problems. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Wed Jun 1 00:15:46 2011 Return-Path: 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 778B8E079E for ; Wed, 1 Jun 2011 00:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.687 X-Spam-Level: X-Spam-Status: No, score=-6.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6WW1cVp-Ztw for ; Wed, 1 Jun 2011 00:15:44 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id E98F5E0799 for ; Wed, 1 Jun 2011 00:15:43 -0700 (PDT) Received: from mail-wy0-f171.google.com ([74.125.82.171]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXnHoJ96M5m8cpjVlkb7+i7pTh60Ibe@postini.com; Wed, 01 Jun 2011 00:15:44 PDT Received: by mail-wy0-f171.google.com with SMTP id 32so4411992wyb.30 for ; Wed, 01 Jun 2011 00:15:42 -0700 (PDT) Received: by 10.216.205.26 with SMTP id i26mr6872538weo.58.1306912542792; Wed, 01 Jun 2011 00:15:42 -0700 (PDT) Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id r20sm447830wec.7.2011.06.01.00.15.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 00:15:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 1 Jun 2011 09:15:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:15:46 -0000 Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A & B. Client ID is = the same across the two devices. - Frankie uses device A to authorize his iPhone to allow MegaWorld for = iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. = Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for = iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. = Time on device B is 1275375611. The provider, mega_app, does not issue multiple tokens for the same = grant request (scope, client_id). This simplifies provider = implementation but also helps enforce the correct user UI with respect = to credential control at http://megaworld.com/my/apps - that is, the = provider can't accurately know if frankie_uk has authorized one software = instance twice on the same device, or multiple software instances once = each (across multiple devices). Thus, the my/apps UI shows one = authorization for "Megaworld for iOS" and thus one option to = de-authorize this client_id (and thus all installed instances of the = single software program with ID mega_app). Regardless if age or timestamp is used, if the implementation for = validating the time value is sequential (perhaps with some window of = error) then one device will have all its OAuth requests rejected as soon = as the other presents a request. If timestamps are used the one with the = older clock (device B) is rejected. If age is used, the one with the = highest value of time (in this case, the more correct client) will be = rejected as age will be calculated to be smaller than device B with an = incorrect clock. If you also consider the case where device A and B have the same value = for current time (UTC time, let's say) then age fails for device B after = device A submits a request since device B thinks the credential is = younger than device A. Timestamp does not fail in this case (because = clocks are already sync'd). Only when the timestamp is a unified standard like UTC can both device A = and B both use token 89ARC. If client B has it's request rejected it can = quickly check UTC from any reasonable source (including = api.megaworld.com) to correct its clock. Even better, it can politely = check the correct system time on a regular basis and cache the offset = between UTC and device time. Though experience may show that many = software developers don't currently do this clock correction, it is = trivial to adopt as a best practice. (Many software developer also don't = routinely review their software for security or stability = vulnerabilities of any sort.) Certainly is nothing for the small = percentage of well-written high-value clients such as Firefox, TweetDeck = or any serious effort with even moderate distribution or engineering = resources. skylar On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > This is not true. >=20 > The age value has to be monotonically increasing, but not necessarily = unique. Really, any counter will do. The reason why timestamp isn't any = better than age or sequence is because ultimately, it is the server's = memory restriction which determines the nonces storage size, not = anything else (like a time limit). From beaton@google.com Wed Jun 1 00:16:35 2011 Return-Path: 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 D06F7E07B1 for ; Wed, 1 Jun 2011 00:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KeChEo5RAc4 for ; Wed, 1 Jun 2011 00:16:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 286FBE078C for ; Wed, 1 Jun 2011 00:16:31 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p517GUBk023189 for ; Wed, 1 Jun 2011 00:16:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306912590; bh=uil0LHPOaVj0OecYEhhf9WEZvZg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=tY7ic0fZyKyxwk7yQMN7g0U+EbdGrkxCcTWM0PEjcx13ZSMruqAFiDNsZhsIIfZ+6 mvSoeoqQlEuQA6T7sxgrA== Received: from pvh11 (pvh11.prod.google.com [10.241.210.203]) by wpaz29.hot.corp.google.com with ESMTP id p517GM9X006559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 00:16:29 -0700 Received: by pvh11 with SMTP id 11so2930474pvh.36 for ; Wed, 01 Jun 2011 00:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=REtvsQE+BWSu7ZkxwbV5/C2+2n2U90XI6uJjTGv5kso=; b=TwJ3KmS+vgs4VWRaLJRxZknc7LOyToZDG/GBzunwB1+4i1ldFjgk3Ka06qhPf0UmO3 OEKPxE4AjJ9mTPH8UtGg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=yXzW4c/bGZCXqz5BlrSBu7wJ00v0B8ZZFi+sI6RMMth4Dsc6XvCzYeOcRzvHydCg1b h20OrQnyduiedjKnr+Ew== MIME-Version: 1.0 Received: by 10.68.65.161 with SMTP id y1mr223785pbs.334.1306912589336; Wed, 01 Jun 2011 00:16:29 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 00:16:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 00:16:29 -0700 Message-ID: From: Brian Eaton To: Chuck Mortimore Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:16:35 -0000 On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore wrote: > This is one reason we=92ve favored implicit for native apps. OK, so are you using the implicit grant for both web apps and native apps...? I'm trying to figure out if you need two flows are three. - web server flow used with real secret client credentials gives out long-lived tokens - native app flow doesn't have real secret client credentials gives out long-lived tokens - implicit flow for javascript apps gives out short-lived tokens based on callback URLs (We need all three of those flows, BTW, plus at some point we'll get around to implementing a javascript flow that returns authorization codes, and a web server flow that provides short-lived credentials... but those are lower priority.) From beaton@google.com Wed Jun 1 00:20:49 2011 Return-Path: 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 9D9FBE0774 for ; Wed, 1 Jun 2011 00:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoddAzB3ggci for ; Wed, 1 Jun 2011 00:20:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DD835E06B6 for ; Wed, 1 Jun 2011 00:20:48 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p517KdEM002909 for ; Wed, 1 Jun 2011 00:20:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306912843; bh=r1eLNfFMtQgVNJL6dYViJBIqNOQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=N0y0F45EHHZLZZreSv1fGgNBhucI01gLXi1BYJygpkYonca77HnqYSY6kdNRPaMiD +QhYvFHDZjymBrWtIziGA== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by hpaq14.eem.corp.google.com with ESMTP id p517KVHF012023 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 00:20:37 -0700 Received: by pvg12 with SMTP id 12so2933194pvg.5 for ; Wed, 01 Jun 2011 00:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5GR9E7N/KQhTHb0X0o7Q7DSdynqs/u3ArWemGv5tQfc=; b=nQTtl4GLN5jIWRpmcuuhwydVWv1NDnykAbw3UXl/4NQ9zaP50CO1rk4xuWdGhOgiV+ 9J/+zXfw5bX/qP9VqSIA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ol2YmH/eYx9BIfQNyr7LvX/HeQ9/YE3VCdDufAba9h/r4Nas9jt92iLYK0ffr67PEZ 6T0Ib7JufrTXbYtuBg0w== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr1194837wff.266.1306912831083; Wed, 01 Jun 2011 00:20:31 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 00:20:30 -0700 (PDT) In-Reply-To: <4DE5E70C.6020309@lodderstedt.net> References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <2D3B9285-476D-4EA8-ADB5-F3A0FD71815C@gmail.com> <4DE5E70C.6020309@lodderstedt.net> Date: Wed, 1 Jun 2011 00:20:30 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:20:49 -0000 On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt wrote: > I'm getting confused. This thread is about native apps. So why discuss > security considerations for web apps here? They overlap because they both use refresh tokens. =/ When people propose changes that impact refresh tokens, it impacts both flows and we need to be careful it doesn't create new problems. For example: Chuck proposed returning a refresh token on the implicit grant type, for use by native apps. That would screw up the security considerations for javascript web apps that rely on the implicit grant type. From ietf@adambarth.com Wed Jun 1 00:25:30 2011 Return-Path: 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 C392EE0741 for ; Wed, 1 Jun 2011 00:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8N89JoumObk for ; Wed, 1 Jun 2011 00:25:29 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 442A0E0675 for ; Wed, 1 Jun 2011 00:25:29 -0700 (PDT) Received: by gyf3 with SMTP id 3so2864775gyf.31 for ; Wed, 01 Jun 2011 00:25:28 -0700 (PDT) Received: by 10.91.73.21 with SMTP id a21mr5898588agl.4.1306913128648; Wed, 01 Jun 2011 00:25:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id u32sm543090ann.30.2011.06.01.00.25.27 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 00:25:27 -0700 (PDT) Received: by ywp31 with SMTP id 31so2895842ywp.31 for ; Wed, 01 Jun 2011 00:25:27 -0700 (PDT) Received: by 10.91.207.26 with SMTP id j26mr5678345agq.206.1306913127077; Wed, 01 Jun 2011 00:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Wed, 1 Jun 2011 00:24:57 -0700 (PDT) In-Reply-To: References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Adam Barth Date: Wed, 1 Jun 2011 00:24:57 -0700 Message-ID: To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:25:30 -0000 Sounds like Eran's proposal will work fine for this scenario. MegaWorld for iOS can just do what you suggest in the final paragraph, which meets the new requirements for age. I'm glad we're able to address you use case. Thanks, Adam On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward wrote: > Provider: =A0api.megaworld.com > > Software Program: A universal binary iOS app called MegaWorld for iOS > Client ID: =A0mega_app > > User: =A0Frankie in London > Username: =A0frankie_uk > > Device A: =A0Frankie's iPhone > Device B: =A0Frankie's iPad > > Now imagine MegaWorld for iOS installed on device A & B. =A0Client ID is = the same across the two devices. > > - Frankie uses device A to authorize his iPhone to allow MegaWorld for iO= S to access his account (frankie_uk) > - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Tim= e on device A is 1306911444. > - Frankie uses device B to authorize his iPhone to allow MegaWorld for iO= S to access his account (frankie_uk) > - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Tim= e on device B is 1275375611. > > The provider, mega_app, does not issue multiple tokens for the same grant= request (scope, client_id). This simplifies provider implementation but al= so helps enforce the correct user UI with respect to credential control at = http://megaworld.com/my/apps - that is, the provider can't accurately know = if frankie_uk has authorized one software instance twice on the same device= , or multiple software instances once each (across multiple devices). Thus,= the my/apps UI shows one authorization for "Megaworld for iOS" and thus on= e option to de-authorize this client_id (and thus all installed instances o= f the single software program with ID mega_app). > > Regardless if age or timestamp is used, if the implementation for validat= ing the time value is sequential (perhaps with some window of error) then o= ne device will have all its OAuth requests rejected as soon as the other pr= esents a request. If timestamps are used the one with the older clock (devi= ce B) is rejected. If age is used, the one with the highest value of time (= in this case, the more correct client) will be rejected as age will be calc= ulated to be smaller than device B with an incorrect clock. > > If you also consider the case where device A and B have the same value fo= r current time (UTC time, let's say) then age fails for device B after devi= ce A submits a request since device B thinks the credential is younger than= device A. Timestamp does not fail in this case (because clocks are already= sync'd). > > Only when the timestamp is a unified standard like UTC can both device A = and B both use token 89ARC. If client B has it's request rejected it can qu= ickly check UTC from any reasonable source (including api.megaworld.com) to= correct its clock. Even better, it can politely check the correct system t= ime on a regular basis and cache the offset between UTC and device time. Th= ough experience may show that many software developers don't currently do t= his clock correction, it is trivial to adopt as a best practice. (Many soft= ware developer also don't routinely review their software for security or s= tability vulnerabilities of any sort.) Certainly is nothing for the small p= ercentage of well-written high-value clients such as Firefox, TweetDeck or = any serious effort with even moderate distribution or engineering resources= . > > skylar > > > On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > >> This is not true. >> >> The age value has to be monotonically increasing, but not necessarily un= ique. Really, any counter will do. The reason why timestamp isn't any bette= r than age or sequence is because ultimately, it is the server's memory res= triction which determines the nonces storage size, not anything else (like = a time limit). > > From eran@hueniverse.com Wed Jun 1 00:33:43 2011 Return-Path: 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 BB368E0741 for ; Wed, 1 Jun 2011 00:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MozwkIGTsS1c for ; Wed, 1 Jun 2011 00:33:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CE3E2E06A8 for ; Wed, 1 Jun 2011 00:33:42 -0700 (PDT) Received: (qmail 14753 invoked from network); 1 Jun 2011 07:33:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 07:33:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 1 Jun 2011 00:33:41 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Wed, 1 Jun 2011 00:33:13 -0700 Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token Thread-Index: AcwgK7oDy3BsgFTbQyqf9s+znX7liwAAiXqQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA442@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:33:43 -0000 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Wednesday, June 01, 2011 12:16 AM > To: Eran Hammer-Lahav > Cc: Adam Barth; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >=20 > Provider: api.megaworld.com >=20 > Software Program: A universal binary iOS app called MegaWorld for iOS Cli= ent > ID: mega_app >=20 > User: Frankie in London > Username: frankie_uk >=20 > Device A: Frankie's iPhone > Device B: Frankie's iPad >=20 > Now imagine MegaWorld for iOS installed on device A & B. Client ID is th= e > same across the two devices. This is broken. You are using MAC for client authentication, but your clien= t is a native application which should not have a secret... > - Frankie uses device A to authorize his iPhone to allow MegaWorld for iO= S to > access his account (frankie_uk) > - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Tim= e > on device A is 1306911444. > - Frankie uses device B to authorize his iPhone to allow MegaWorld for iO= S to > access his account (frankie_uk) > - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Tim= e > on device B is 1275375611. When you say issued, you mean MAC credentials (access token) or client cred= entials? EHL > The provider, mega_app, does not issue multiple tokens for the same grant > request (scope, client_id). This simplifies provider implementation but a= lso > helps enforce the correct user UI with respect to credential control at > http://megaworld.com/my/apps - that is, the provider can't accurately kno= w > if frankie_uk has authorized one software instance twice on the same > device, or multiple software instances once each (across multiple devices= ). > Thus, the my/apps UI shows one authorization for "Megaworld for iOS" and > thus one option to de-authorize this client_id (and thus all installed in= stances > of the single software program with ID mega_app). >=20 > Regardless if age or timestamp is used, if the implementation for validat= ing > the time value is sequential (perhaps with some window of error) then one > device will have all its OAuth requests rejected as soon as the other pre= sents > a request. If timestamps are used the one with the older clock (device B)= is > rejected. If age is used, the one with the highest value of time (in this= case, > the more correct client) will be rejected as age will be calculated to be= smaller > than device B with an incorrect clock. >=20 > If you also consider the case where device A and B have the same value fo= r > current time (UTC time, let's say) then age fails for device B after devi= ce A > submits a request since device B thinks the credential is younger than de= vice > A. Timestamp does not fail in this case (because clocks are already sync'= d). >=20 > Only when the timestamp is a unified standard like UTC can both device A > and B both use token 89ARC. If client B has it's request rejected it can = quickly > check UTC from any reasonable source (including api.megaworld.com) to > correct its clock. Even better, it can politely check the correct system = time on > a regular basis and cache the offset between UTC and device time. Though > experience may show that many software developers don't currently do this > clock correction, it is trivial to adopt as a best practice. (Many softwa= re > developer also don't routinely review their software for security or stab= ility > vulnerabilities of any sort.) Certainly is nothing for the small percenta= ge of > well-written high-value clients such as Firefox, TweetDeck or any serious > effort with even moderate distribution or engineering resources. >=20 > skylar >=20 >=20 > On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: >=20 > > This is not true. > > > > The age value has to be monotonically increasing, but not necessarily > unique. Really, any counter will do. The reason why timestamp isn't any > better than age or sequence is because ultimately, it is the server's mem= ory > restriction which determines the nonces storage size, not anything else (= like > a time limit). From skylar@kiva.org Wed Jun 1 00:35:28 2011 Return-Path: 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 CD192E06A8 for ; Wed, 1 Jun 2011 00:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.677 X-Spam-Level: X-Spam-Status: No, score=-6.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFZMByMCFF1K for ; Wed, 1 Jun 2011 00:35:28 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 9EC45E0675 for ; Wed, 1 Jun 2011 00:35:27 -0700 (PDT) Received: from mail-ww0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXrvwOdd+TxqyIoz/awUsrfRSN0LYWq@postini.com; Wed, 01 Jun 2011 00:35:27 PDT Received: by mail-ww0-f49.google.com with SMTP id 39so4765602wwb.30 for ; Wed, 01 Jun 2011 00:35:26 -0700 (PDT) Received: by 10.217.4.66 with SMTP id t44mr609200wes.104.1306913726857; Wed, 01 Jun 2011 00:35:26 -0700 (PDT) Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id c51sm449074wek.47.2011.06.01.00.35.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 00:35:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 1 Jun 2011 09:35:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Adam Barth X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:35:28 -0000 Actually, monotonically increasing fails for this use case because even = if clocks are sync'd, device A and B can submit requests sequentially in = UTC time but could arrive in reverse order. So monotonically increasing, with some tolerance or window of error = would seem to be sufficient for allowing the server to expire nonces yet = accounting for the complications of multiple devices presenting the same = token. If providers were left to determine the window of error (which is = really just a way of the provider controlling allocations for nonce = storage) then it could accommodate for minor variances in device system = time as before as well. skylar On Jun 1, 2011, at 9:24 AM, Adam Barth wrote: > Sounds like Eran's proposal will work fine for this scenario. > MegaWorld for iOS can just do what you suggest in the final paragraph, > which meets the new requirements for age. I'm glad we're able to > address you use case. >=20 > Thanks, > Adam >=20 >=20 > On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward = wrote: >> Provider: api.megaworld.com >>=20 >> Software Program: A universal binary iOS app called MegaWorld for iOS >> Client ID: mega_app >>=20 >> User: Frankie in London >> Username: frankie_uk >>=20 >> Device A: Frankie's iPhone >> Device B: Frankie's iPad >>=20 >> Now imagine MegaWorld for iOS installed on device A & B. Client ID = is the same across the two devices. >>=20 >> - Frankie uses device A to authorize his iPhone to allow MegaWorld = for iOS to access his account (frankie_uk) >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. = Time on device A is 1306911444. >> - Frankie uses device B to authorize his iPhone to allow MegaWorld = for iOS to access his account (frankie_uk) >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. = Time on device B is 1275375611. >>=20 >> The provider, mega_app, does not issue multiple tokens for the same = grant request (scope, client_id). This simplifies provider = implementation but also helps enforce the correct user UI with respect = to credential control at http://megaworld.com/my/apps - that is, the = provider can't accurately know if frankie_uk has authorized one software = instance twice on the same device, or multiple software instances once = each (across multiple devices). Thus, the my/apps UI shows one = authorization for "Megaworld for iOS" and thus one option to = de-authorize this client_id (and thus all installed instances of the = single software program with ID mega_app). >>=20 >> Regardless if age or timestamp is used, if the implementation for = validating the time value is sequential (perhaps with some window of = error) then one device will have all its OAuth requests rejected as soon = as the other presents a request. If timestamps are used the one with the = older clock (device B) is rejected. If age is used, the one with the = highest value of time (in this case, the more correct client) will be = rejected as age will be calculated to be smaller than device B with an = incorrect clock. >>=20 >> If you also consider the case where device A and B have the same = value for current time (UTC time, let's say) then age fails for device B = after device A submits a request since device B thinks the credential is = younger than device A. Timestamp does not fail in this case (because = clocks are already sync'd). >>=20 >> Only when the timestamp is a unified standard like UTC can both = device A and B both use token 89ARC. If client B has it's request = rejected it can quickly check UTC from any reasonable source (including = api.megaworld.com) to correct its clock. Even better, it can politely = check the correct system time on a regular basis and cache the offset = between UTC and device time. Though experience may show that many = software developers don't currently do this clock correction, it is = trivial to adopt as a best practice. (Many software developer also don't = routinely review their software for security or stability = vulnerabilities of any sort.) Certainly is nothing for the small = percentage of well-written high-value clients such as Firefox, TweetDeck = or any serious effort with even moderate distribution or engineering = resources. >>=20 >> skylar >>=20 >>=20 >> On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: >>=20 >>> This is not true. >>>=20 >>> The age value has to be monotonically increasing, but not = necessarily unique. Really, any counter will do. The reason why = timestamp isn't any better than age or sequence is because ultimately, = it is the server's memory restriction which determines the nonces = storage size, not anything else (like a time limit). >>=20 >>=20 From cmortimore@salesforce.com Wed Jun 1 00:41:18 2011 Return-Path: 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 20EDDE07BC for ; Wed, 1 Jun 2011 00:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1HS75YncXa8 for ; Wed, 1 Jun 2011 00:41:16 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by ietfa.amsl.com (Postfix) with SMTP id 7E6F1E0741 for ; Wed, 1 Jun 2011 00:41:16 -0700 (PDT) Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKTeXtGz3Hm+Pm9dZrHGk6ZA4R8l+dbrfT@postini.com; Wed, 01 Jun 2011 00:41:16 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Wed, 1 Jun 2011 00:41:15 -0700 From: Chuck Mortimore To: Brian Eaton Date: Wed, 1 Jun 2011 00:41:14 -0700 Thread-Topic: [OAUTH-WG] Text for Native Applications Thread-Index: AcwgK9dTKRdq7V5+Sme7B6lkUU7iEAAA3E+i Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA0B3B2A1AAD3cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:41:18 -0000 --_000_CA0B3B2A1AAD3cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have have need for all three types For web apps, we use web server flow with credentials, and can escalate som= e capabilities for the client since we can be more assured we're talking to= the actual client. For native apps, we support: 1. the implicit grant ( but we wont give out a refresh token to web/js ba= sed applications ) 2. the web server flow with a user+client_id specific secret which we can= issue through an admin controlled provisioning process. In this case we c= an also escalate capabilities as we're reasonably sure we're talking to an = instance of the client. For JS Apps we support the implicit grant with no refresh token -cmort On 6/1/11 12:16 AM, "Brian Eaton" wrote: On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore wrote: > This is one reason we've favored implicit for native apps. OK, so are you using the implicit grant for both web apps and native apps...? I'm trying to figure out if you need two flows are three. - web server flow used with real secret client credentials gives out long-lived tokens - native app flow doesn't have real secret client credentials gives out long-lived tokens - implicit flow for javascript apps gives out short-lived tokens based on callback URLs (We need all three of those flows, BTW, plus at some point we'll get around to implementing a javascript flow that returns authorization codes, and a web server flow that provides short-lived credentials... but those are lower priority.) --_000_CA0B3B2A1AAD3cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Text for Native Applications We have have ne= ed for all three types

For web apps, we use web server flow with credentials, and can escalate som= e capabilities for the client since we can be more assured we’re talk= ing to the actual client.

For native apps, we support:

  1. the implicit grant ( but we wont give out a refresh token to web/js = based applications )
  2. the web server flow with a user+client_id specific secret which we can i= ssue through an admin controlled provisioning process.  In this case w= e can also escalate capabilities as we’re reasonably sure we’re= talking to an instance of the client.

For JS Apps we support the implicit grant with no refresh token

-cmort


On 6/1/11 12:16 AM, "Brian Eaton" <beaton@google.com> wrote:

On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore
<cmortimore@salesforce.com>= wrote:
> This is one reason we’ve favored implicit for native apps.

OK, so are you using the implicit grant for both web apps and native
apps...?  I'm trying to figure out if you need two flows are three.
- web server flow
   used with real secret client credentials
   gives out long-lived tokens

- native app flow
   doesn't have real secret client credentials
   gives out long-lived tokens

- implicit flow for javascript apps
   gives out short-lived tokens based on callback URLs

(We need all three of those flows, BTW, plus at some point we'll get
around to implementing a javascript flow that returns authorization
codes, and a web server flow that provides short-lived credentials...
but those are lower priority.)

--_000_CA0B3B2A1AAD3cmortimoresalesforcecom_-- From cmortimore@salesforce.com Wed Jun 1 00:42:55 2011 Return-Path: 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 D69A2E0675 for ; Wed, 1 Jun 2011 00:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMNJjmCv0oOJ for ; Wed, 1 Jun 2011 00:42:54 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by ietfa.amsl.com (Postfix) with SMTP id 46C99E0787 for ; Wed, 1 Jun 2011 00:42:54 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKTeXtfag2fIO6eaf95VZ68hiEoKDGTZjL@postini.com; Wed, 01 Jun 2011 00:42:54 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Wed, 1 Jun 2011 00:42:53 -0700 From: Chuck Mortimore To: Brian Eaton , Torsten Lodderstedt Date: Wed, 1 Jun 2011 00:42:52 -0700 Thread-Topic: [OAUTH-WG] Text for Native Applications Thread-Index: AcwgLHc/GgjVaip6R1GOCH9Km1rIRQAAwu+r Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA0B3B8C1AAD5cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: Kris Selden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:42:56 -0000 --_000_CA0B3B8C1AAD5cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/1/11 12:20 AM, "Brian Eaton" wrote: On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt wrote: > I'm getting confused. This thread is about native apps. So why discuss > security considerations for web apps here? They overlap because they both use refresh tokens. =3D/ When people propose changes that impact refresh tokens, it impacts both flows and we need to be careful it doesn't create new problems. For example: Chuck proposed returning a refresh token on the implicit grant type, for use by native apps. That would screw up the security considerations for javascript web apps that rely on the implicit grant type. Not entirely what I'm suggesting, but looking back I wasn't clear. My Bad= . See my description of what we currently support that I just sent. -cmort _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA0B3B8C1AAD5cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Text for Native Applications


On 6/1/11 12:20 AM, "Brian Eaton" <beaton@google.com> wrote:

On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt
<torsten@lodderstedt.net> wro= te:
> I'm getting confused. This thread is about native apps. So why discuss=
> security considerations for web apps here?

They overlap because they both use refresh tokens. =3D/  When people propose changes that impact refresh tokens, it impacts both flows and
we need to be careful it doesn't create new problems.

For example: Chuck proposed returning a refresh token on the implicit
grant type, for use by native apps.  That would screw up the security<= BR> considerations for javascript web apps that rely on the implicit grant
type.

Not entirely what I’m suggesting, but looking back I wasn= ’t clear.   My Bad.  See my description of what we cur= rently support that I just sent.   

-cmort

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_CA0B3B8C1AAD5cmortimoresalesforcecom_-- From torsten@lodderstedt.net Wed Jun 1 00:47:15 2011 Return-Path: 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 465E9E06B6 for ; Wed, 1 Jun 2011 00:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw+ApnzpOQ5f for ; Wed, 1 Jun 2011 00:47:14 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6AEE0675 for ; Wed, 1 Jun 2011 00:47:14 -0700 (PDT) Received: from [80.187.223.2] (helo=[10.135.145.12]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRg92-0000uV-52; Wed, 01 Jun 2011 09:47:12 +0200 Message-ID: <4DE5EE7F.4040907@lodderstedt.net> Date: Wed, 01 Jun 2011 09:47:11 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:47:15 -0000 Am 01.06.2011 08:56, schrieb Brian Eaton: > On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore > wrote: >> It’s not entirely necessary; I’m just having a tough time figuring out any >> practical difference between the implicit grant flow, and the webserver flow >> with no credentials. In general I agree with your points, but I think we >> have a similar, perhaps worse, scenario with relaxing the need for >> credentials on the web server flow. > No doubt. =) I think it's unfortunate that the spec was changed to > make the client credentials optional for the web server flow. As you > say, it's a security problem for web apps. We are treating the client > secret as mandatory in our deployments, and basically everyone who > deploys the web server flow should do the same. It's a shame the spec > is so vague on this point. > > The root cause of the spec ambiguity was disagreement over how to > handle secrets for installed applications. I can think of three paths > forward. > > - split out "installed app flow" from "web server flow". Use a new > grant type. (DON'T switch installed apps to use the "implicit" grant > type. That doesn't work either, because it doesn't return a > long-lived credential. DON'T have the implicit grant type return a > refresh token directly, either, since that causes serious security > problems for real web apps that can keep client secrets.) So far every grant type represented a different protocol flow (not client type). Why do you want to define different grant types for basically the same flow but different client identification/authentication policies? What if a service provider is able to securely deploy instance-specific secrets to its native apps (e.g. in intranet scenarios - see Chuck's posting). Shall it use the "web server flow" then? The current text keeps client authentication and the grant type orthogonal. I would suggest to stick to this approach. > - make the client secret mandatory, but tell people who are offended > by client secrets in installed apps to use the string "notasecret" for > all installed apps. How is that any different from just not using a secret from a security perspective? > - ignore the problem and leave the spec vague and insecure. > Could you please describe what you consider "insecure"? I think we have the challenge to defining a secure protocol while supporting the needs of different client types. Past versions of the spec entirely focused on client secrets as mechanism to validate a client's identity. This created the false impression that native apps either 1) must use the implicit grant type (which does not support refresh tokens), or 2) use the authz code grant type in conjunction with a (weakly/none protected) secret in order to comply with the text of the specification. 3) It is also interesting to note that people have started to think OAuth does not support native apps! (1) results in a sub-optimal user experience since the app has to go through the (interactive) authz cycle with every startup or the authz server issues long-living a access tokens (?) or (even worse) the authz server automatically issue access tokens for sub-sequent requests by the same client (how to determine "same"?). (2) creates a _false_ impression of security because the authz server authenticated the clients. But the authorization server _must not_ rely on such a secret for validating the client's identity. The security consideration section clearly states this now. regards, Torsten. >> In terms of your example, wouldn’t basic XSRF protection in the state param protect? > Nope. Assume the following scenario: > - bad guy has stolen refresh token > - client web server has detected attack and changed their client secret > - bad guy wants to find a way to keep using the refresh token > > If refresh tokens are returned without client authentication, the bad > guy can do it as follows: > - visit client. log in as account badguy1234. > - client redirects to authorization server, including state=1234 > - bad guy ignores redirect to authorization server, visits client > callback server with refresh_token=stolen&state=1234 > - client picks up stolen refresh token and associates it with badguy1234. > - whenever badguy1234 visits the client web site, he can see data from > the stolen refresh token. > > Cheers, > Brian From beaton@google.com Wed Jun 1 00:50:59 2011 Return-Path: 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 D3002E06B6 for ; Wed, 1 Jun 2011 00:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xbdxtbgV8FS for ; Wed, 1 Jun 2011 00:50:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFB7AE0675 for ; Wed, 1 Jun 2011 00:50:53 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p517omBv007963 for ; Wed, 1 Jun 2011 00:50:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306914653; bh=vYOCU+KclzXCAJu4BvUIKjHHtSM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PFzbxgn2SkAUks+LkuUsHOSxFZgJufPkiaUwiS1EgGKWXj5MbR4PSi+/MS93NnWB8 xECG7qpFemAnRr5cwaCew== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by kpbe17.cbf.corp.google.com with ESMTP id p517o5aE026911 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 00:50:47 -0700 Received: by pxi20 with SMTP id 20so3245087pxi.13 for ; Wed, 01 Jun 2011 00:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u2VoET33NVunTPIEDnWp697MMM5UMrAuOTVKIh6ND/Q=; b=MsuZ2VmG+ciEh3fFcoNwtXfH3Do85iTqUj+SfavuuLDnj52xtSLp4NPDcDodX9mEDw TIBNnqqSy/mIEyUGQBMw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P4Xaxg1eBQoPu+bY9SLO0zYi4bOHJl4vjSE4gB+BjXtTmcP1uBMSN2GTsm5LUgEonW 41gqWomfqN87oU+TGVXQ== MIME-Version: 1.0 Received: by 10.142.221.1 with SMTP id t1mr1168354wfg.437.1306914646835; Wed, 01 Jun 2011 00:50:46 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 00:50:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 00:50:46 -0700 Message-ID: From: Brian Eaton To: Chuck Mortimore Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:50:59 -0000 OK, so you've got some native apps using the web server flow, and some using a modified version of the implicit grant that includes a refresh token. I hate to say it, but I think this whole thing would be a lot simpler if we had a grant type called "native app". Instead everyone is adding unspecified parameters or making parameters optional so that they can support native apps properly. On Wed, Jun 1, 2011 at 12:41 AM, Chuck Mortimore wrote: > We have have need for all three types > > For web apps, we use web server flow with credentials, and can escalate s= ome > capabilities for the client since we can be more assured we=92re talking = to > the actual client. > > For native apps, we support: > > the implicit grant ( but we wont give out a refresh token to web/js based > applications ) > the web server flow with a user+client_id specific secret which we can is= sue > through an admin controlled provisioning process. =A0In this case we can = also > escalate capabilities as we=92re reasonably sure we=92re talking to an in= stance > of the client. > > For JS Apps we support the implicit grant with no refresh token > > -cmort > > > On 6/1/11 12:16 AM, "Brian Eaton" wrote: > > On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore > wrote: >> This is one reason we=92ve favored implicit for native apps. > > OK, so are you using the implicit grant for both web apps and native > apps...? =A0I'm trying to figure out if you need two flows are three. > > - web server flow > =A0=A0=A0used with real secret client credentials > =A0=A0=A0gives out long-lived tokens > > - native app flow > =A0=A0=A0doesn't have real secret client credentials > =A0=A0=A0gives out long-lived tokens > > - implicit flow for javascript apps > =A0=A0=A0gives out short-lived tokens based on callback URLs > > (We need all three of those flows, BTW, plus at some point we'll get > around to implementing a javascript flow that returns authorization > codes, and a web server flow that provides short-lived credentials... > but those are lower priority.) > > From torsten@lodderstedt.net Wed Jun 1 00:53:38 2011 Return-Path: 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 9DD07E06B6 for ; Wed, 1 Jun 2011 00:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSfQsMfjF9da for ; Wed, 1 Jun 2011 00:53:38 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 09917E0675 for ; Wed, 1 Jun 2011 00:53:38 -0700 (PDT) Received: from [80.187.223.2] (helo=[10.135.145.12]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRgFE-00027Y-UV; Wed, 01 Jun 2011 09:53:37 +0200 Message-ID: <4DE5F001.9030002@lodderstedt.net> Date: Wed, 01 Jun 2011 09:53:37 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eran Hammer-Lahav , OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Section 10.1 (Client authentication) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:53:38 -0000 Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. From skylar@kiva.org Wed Jun 1 01:05:48 2011 Return-Path: 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 4AF28E06E1 for ; Wed, 1 Jun 2011 01:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.669 X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTy8jTgUzwVj for ; Wed, 1 Jun 2011 01:05:47 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 558BFE06DD for ; Wed, 1 Jun 2011 01:05:46 -0700 (PDT) Received: from mail-bw0-f47.google.com ([209.85.214.47]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXy2UrsKjUAJ1lQkHFXbH2vNRLQnw+0@postini.com; Wed, 01 Jun 2011 01:05:46 PDT Received: by mail-bw0-f47.google.com with SMTP id 5so7016240bwz.34 for ; Wed, 01 Jun 2011 01:05:45 -0700 (PDT) Received: by 10.204.75.22 with SMTP id w22mr6699584bkj.65.1306915545367; Wed, 01 Jun 2011 01:05:45 -0700 (PDT) Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id ag6sm644201bkc.6.2011.06.01.01.05.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 01:05:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA442@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 1 Jun 2011 10:05:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA442@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:05:48 -0000 > -----Original Message----- >> From: Skylar Woodward [mailto:skylar@kiva.org] >> Sent: Wednesday, June 01, 2011 12:16 AM >> To: Eran Hammer-Lahav >> Cc: Adam Barth; OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC = token >>=20 >> Provider: api.megaworld.com >>=20 >> Software Program: A universal binary iOS app called MegaWorld for iOS = Client >> ID: mega_app >>=20 >> User: Frankie in London >> Username: frankie_uk >>=20 >> Device A: Frankie's iPhone >> Device B: Frankie's iPad >>=20 >> Now imagine MegaWorld for iOS installed on device A & B. Client ID = is the >> same across the two devices. >=20 > This is broken. You are using MAC for client authentication, but your = client is a native application which should not have a secret... No, I had two use cases to discuss. One of access tokens being re-issued = and the other of client credentials. Token re-issue seemed easier to = explain because it is the more common case of device conflict.=20 The issues with client credentials are minimized with the algorithm for = nonce expiration that Adam suggested (sequential) which was not clear as = a suggestion by the spec. I could outline a problem with age for client = credentials which use the "flagged as old" algorithm, but this seems = less important now if we assume "sequential with a window of tolerance" = as the algorithm for invalidation. However, there are possible cases where two software instances use the = same client credential (and where it's still possible to secure the = secret). Most of those cases are ones where the software distribution is = protected inside a controlled network. A few examples (not common = across OAuth, though some of these will be popular for providers like = Kiva where its customers deploy proprietary software inside controlled = intranets where secrets can be protected from the public even in = "native" apps): - Great State University makes an app for managing student grading. This = app is distributed to all faculty iPhones using the Apple Enterprise = Deployment system. GSU expects faculty not to share the installed = software with non-faculty or to use jail-broken phones -- doing so is a = violation of school code of ethics. GSU makes the case that the client = credentials in the grading app are securable with reasonable deployment = and legal protections in place. All installs of the app onto faculty = iPhones use the same client credential. They use the client credential = as an additional hurdle to protect against forged clients trying to = authorize. - Green Microlender makes an app for submitting loan data to Kiva that = also interfaces with their local MIS system. This is a Visual Basic = program installed on Windows PCs throughout field offices in southern = Uganda which each on the organization's protected VLAN (or multiple = protected LANs). This program is deployed by IT staff only onto these = devices. They choose to use client credentials in this program as they = feel comfortable in asserting that the client secrets are protected = adequately by Green Microlender. - MegaWorld Tracker deploys websites in France and the US. They set up = different instances of their website program in servers in France and = the US. Each deployment is configured with the same MegaWorld OAuth = client ID since it is the same program, but different locale settings to = make the software render text in French or English, respectively. Since = MegaWorld Tracker isn't a huge corp, they've haven't put in place = measures to sync user's access tokens between the French servers and the = US servers. This means a user that hits both the FR server and the US = server will have to authenticate twice to megaworld.com (and thus access = tokens issued to each server install). Since they also didn't bother to = register two client IDs (mw_tracker instead of mw_tracker_us and = mw_tracker_fr) they essentially have two installs using the same client = credentials. It's a reasonable gray area. I do admit these won't be en masse in the grand collective of all = deployed OAuth v2 apps, but they are reasonable use cases, and for some = organizations, very important use cases. >> - Frankie uses device A to authorize his iPhone to allow MegaWorld = for iOS to >> access his account (frankie_uk) >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. = Time >> on device A is 1306911444. >> - Frankie uses device B to authorize his iPhone to allow MegaWorld = for iOS to >> access his account (frankie_uk) >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. = Time >> on device B is 1275375611. >=20 > When you say issued, you mean MAC credentials (access token) or client = credentials? these are access tokens >=20 > EHL >=20 >> The provider, mega_app, does not issue multiple tokens for the same = grant >> request (scope, client_id). This simplifies provider implementation = but also >> helps enforce the correct user UI with respect to credential control = at >> http://megaworld.com/my/apps - that is, the provider can't accurately = know >> if frankie_uk has authorized one software instance twice on the same >> device, or multiple software instances once each (across multiple = devices). >> Thus, the my/apps UI shows one authorization for "Megaworld for iOS" = and >> thus one option to de-authorize this client_id (and thus all = installed instances >> of the single software program with ID mega_app). >>=20 >> Regardless if age or timestamp is used, if the implementation for = validating >> the time value is sequential (perhaps with some window of error) then = one >> device will have all its OAuth requests rejected as soon as the other = presents >> a request. If timestamps are used the one with the older clock = (device B) is >> rejected. If age is used, the one with the highest value of time (in = this case, >> the more correct client) will be rejected as age will be calculated = to be smaller >> than device B with an incorrect clock. >>=20 >> If you also consider the case where device A and B have the same = value for >> current time (UTC time, let's say) then age fails for device B after = device A >> submits a request since device B thinks the credential is younger = than device >> A. Timestamp does not fail in this case (because clocks are already = sync'd). >>=20 >> Only when the timestamp is a unified standard like UTC can both = device A >> and B both use token 89ARC. If client B has it's request rejected it = can quickly >> check UTC from any reasonable source (including api.megaworld.com) to >> correct its clock. Even better, it can politely check the correct = system time on >> a regular basis and cache the offset between UTC and device time. = Though >> experience may show that many software developers don't currently do = this >> clock correction, it is trivial to adopt as a best practice. (Many = software >> developer also don't routinely review their software for security or = stability >> vulnerabilities of any sort.) Certainly is nothing for the small = percentage of >> well-written high-value clients such as Firefox, TweetDeck or any = serious >> effort with even moderate distribution or engineering resources. >>=20 >> skylar >>=20 >>=20 >> On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: >>=20 >>> This is not true. >>>=20 >>> The age value has to be monotonically increasing, but not = necessarily >> unique. Really, any counter will do. The reason why timestamp isn't = any >> better than age or sequence is because ultimately, it is the server's = memory >> restriction which determines the nonces storage size, not anything = else (like >> a time limit). >=20 From torsten@lodderstedt.net Wed Jun 1 01:11:34 2011 Return-Path: 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 1A12DE078E for ; Wed, 1 Jun 2011 01:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LotfqwZ8WCSl for ; Wed, 1 Jun 2011 01:11:33 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF05E0768 for ; Wed, 1 Jun 2011 01:11:32 -0700 (PDT) Received: from [80.187.223.2] (helo=[10.135.145.12]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRgWY-0004k3-Uw; Wed, 01 Jun 2011 10:11:31 +0200 Message-ID: <4DE5F433.6090503@lodderstedt.net> Date: Wed, 01 Jun 2011 10:11:31 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Mcgloin References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:11:34 -0000 Hi Mark, Am 31.05.2011 22:58, schrieb Mark Mcgloin: > Eran > > Here are some additional sections to add to the next draft under security > considerations > > CSRF > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from a user that the website trusts or has > authenticated. CSRF attacks on OAuth approvals can allow an attacker to > obtain authorization to OAuth Protected Resources without the consent of > the User. > The state parameter should be used to mitigate against CSRF attacks, > particularly for login CSRF attacks. It is strongly RECOMMENDED that the > client sends the state parameter with authorization requests to the > authorization server. The authorization server will send it in the response > when redirecting the user to back to the client which SHOULD then validate > the state parameter matches on the response. As far as I understand, the goal of the countermeasure is to bind the authz flow to a certain user agent (instance). So client must verify that the state parameter (or any other URL parameter?) matches some data found in the user agent itself before further processing the authz code. Breno explained it as follows: ----- - Client or user-agent generates a secret. - The secret is stored in a location accessible only by the client or the user agent (i.e., protected by same-origin policy). E.g.: DOM variable (protected by javascript or other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. - The secret is attached to the state before a request is issued by the client - When the response is received, before accepting the token or code, the client consults the user agent state and rejects the response altogether if the state does not match the user agent's stored value. ---- I would suggest to incorporate this into the decription: It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. _The state parameter MUST refer to a secret value retained at the user agent._ The authorization server will send the _state parameter_ in the response when redirecting the user to back to the client which _MUST_ then validate the state parameter_'s value against the secret value in the user agent_. regards, Torsten. > Clickjacking > Clickjacking is the process of tricking users into revealing confidential > information or taking control of their computer while clicking on seemingly > innocuous web pages. In more detail, a malicious site loads the target site > in a transparent iframe overlaid on top of a set of dummy buttons which are > carefully constructed to be placed directly under important buttons on the > target site. When a user clicks a visible button, they are actually > clicking a button (such as an "Authorize" button) on the hidden page. > To prevent clickjacking (and phishing attacks), native applications SHOULD > use external browsers instead of embedding browsers in an iFrame when > requesting end-user authorization. For newer browsers, avoidance of iFrames > can be enforced server side by using the X-FRAME-OPTION header. This header > can have two values, deny and sameorigin, which will block any framing or > framing by sites with a different origin, respectively. For older browsers, > javascript framebusting techniques can be used but may not be effective in > all browsers. > > > Regards > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jun 1 01:19:00 2011 Return-Path: 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 6945BE0774 for ; Wed, 1 Jun 2011 01:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 038vI92lJhls for ; Wed, 1 Jun 2011 01:18:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 93846E0675 for ; Wed, 1 Jun 2011 01:18:59 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p518IuiE029822 for ; Wed, 1 Jun 2011 01:18:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306916337; bh=E3ekvzW/ZneifEfMAcprQTymAOQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=s3++mLyvG5Ed85ZowkF0XzGfTROK80Kw8frd3zcYQ7U3oQ91iSMKCzixQiDde3M4/ 0hT3ygO046Ovohonka9yg== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by kpbe15.cbf.corp.google.com with ESMTP id p518Ittx003986 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 01:18:55 -0700 Received: by pxi7 with SMTP id 7so3618134pxi.16 for ; Wed, 01 Jun 2011 01:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vk6XCQ6XmmORifHVeLFcjgyxhIbg+Z4RT6iMDMB69A4=; b=dZjjvYuEOmSjLQs+kma6z7IRihxJR9QMun5MG7oX9b4CBSxMF1uze3MfX5kFyuS/Ka j7zgNOEFFTMFTw5BNAwg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OBeWv/57v29Eqn5phECU++CTZ2t0F/pRwvoWSmxFO+Ip7mkaphSINeLaa6BYP1/3i/ dOxhkF8va0LBysGJ02cw== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr1202775wff.266.1306916334849; Wed, 01 Jun 2011 01:18:54 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 01:18:54 -0700 (PDT) In-Reply-To: <4DE5EE7F.4040907@lodderstedt.net> References: <4DE5EE7F.4040907@lodderstedt.net> Date: Wed, 1 Jun 2011 01:18:54 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:19:00 -0000 On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt wrote: >> - ignore the problem and leave the spec vague and insecure. > > Could you please describe what you consider "insecure"? As an example, optional client authentication in the authorization code flow makes the web server flow much less secure. But it's permitted by the spec. The confusion you mention about how to support native apps is also going to create security problems. You mentioned the risks of auto-approving token requests from native apps. > I think we have the > challenge to defining a secure protocol while supporting the needs of > different client types. +1 to that. > Past versions of the spec entirely focused on client secrets as mechanism to > validate a client's identity. This created the false impression that native > apps either... I think your efforts to clear this up in the security considerations are so admirable that they should move into the main body of the spec instead. =) In particular, I think the spec should say that: - native apps always use the authorization code grant - if authorization servers are comfortable issuing client secrets to native apps, they may do so - if authorization servers are not comfortable issuing client secrets to installed apps, they may use a blank or well-known client secret. That would let us simplify the authorization code protocol and the refresh token protocol, since parameters would move from sometimes-they-are-required-sometimes-not to being required. It would also let us have a clear direction to point people who want to support native apps. And it would meet the requirement of having a clear path forward for people who don't want to trust native apps to keep secrets really secret. From d.tangren@gmail.com Wed Jun 1 01:22:02 2011 Return-Path: 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 F030DE0768 for ; Wed, 1 Jun 2011 01:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZluyUrEkyK0 for ; Wed, 1 Jun 2011 01:22:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72213E0675 for ; Wed, 1 Jun 2011 01:22:02 -0700 (PDT) Received: by iwn39 with SMTP id 39so6887310iwn.31 for ; Wed, 01 Jun 2011 01:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JQ1oMnLTHX0RgM9r40gJkKFD28PzCEuIrGOO1TbUcT4=; b=WfawpR+U8ZYjFXrCe26euEytisFbEewXlA1U662/EUsO5Kx/kt9u1+DI3/s+dDaX4s GReoR6oY9X5gJDX5kxz+K17/IBJYvhcdXFq5Jtt7kdkNsj0uV835kEPWQb75Q20buvLx rKpbFucZRqxkYq7MsqadlDznvaw6RReidnekc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KTRFcJKblY/ZVjgux1Adh5jRZpmDY1YQVTJqXgtPN3N7/AQ8dsV1kG7n38cbNaOUjz fEsrsHpYLgvDgomCHnSiLeR+Ex1NqH/Bth9SoWRjpqM12+uhUSopr8NoC/c2ORIuMe+m RN+PSgYqpCKhs2kSm+faP7XNBP4/BXpx9SW7s= MIME-Version: 1.0 Received: by 10.42.145.130 with SMTP id f2mr14682071icv.325.1306916521874; Wed, 01 Jun 2011 01:22:01 -0700 (PDT) Received: by 10.42.158.74 with HTTP; Wed, 1 Jun 2011 01:22:01 -0700 (PDT) Received: by 10.42.158.74 with HTTP; Wed, 1 Jun 2011 01:22:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 04:22:01 -0400 Message-ID: From: Doug Tangren To: Brian Eaton Content-Type: multipart/alternative; boundary=90e6ba6134ac0994b104a4a23744 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:22:03 -0000 --90e6ba6134ac0994b104a4a23744 Content-Type: text/plain; charset=UTF-8 > I hate to say it, but I think this whole thing would be a lot simpler > if we had a grant type called "native app". +1. stop muddying the waters --90e6ba6134ac0994b104a4a23744 Content-Type: text/html; charset=UTF-8


> I hate to say it, but I think this whole thing would be a lot simpler
> if we had a grant type called "native app".

+1. stop muddying the waters

--90e6ba6134ac0994b104a4a23744-- From skylar@kiva.org Wed Jun 1 01:41:34 2011 Return-Path: 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 21309E07CC for ; Wed, 1 Jun 2011 01:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.663 X-Spam-Level: X-Spam-Status: No, score=-6.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN4qWuUcp6XP for ; Wed, 1 Jun 2011 01:41:33 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id F30CFE07D0 for ; Wed, 1 Jun 2011 01:41:32 -0700 (PDT) Received: from mail-fx0-f53.google.com ([209.85.161.53]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKTeX7PE1IDO4SJccFIG5mtJQ2dCEHDMt3@postini.com; Wed, 01 Jun 2011 01:41:33 PDT Received: by fxm8 with SMTP id 8so3988839fxm.26 for ; Wed, 01 Jun 2011 01:41:31 -0700 (PDT) Received: by 10.223.23.143 with SMTP id r15mr1022834fab.29.1306917690964; Wed, 01 Jun 2011 01:41:30 -0700 (PDT) Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id x15sm292483fah.22.2011.06.01.01.41.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 01:41:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 1 Jun 2011 10:41:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE5EE7F.4040907@lodderstedt.net> To: Brian Eaton X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:41:34 -0000 On Jun 1, 2011, at 10:18 AM, Brian Eaton wrote: > And it would meet the requirement of having a clear path forward for > people who don't want to trust native apps to keep secrets really > secret. I just want to re-iterate my point from a few months ago that it = necessarily helpful to draw the line for secret protection between = native and non-native apps. For our users we're going to use the terms = VERIFIABLE and FORGEABLE with respect to client identity. We'll help = users determine if the can keep secrets or not. Developers who = understand they can't keep secrets will understand their app identity to = be forgeable (and thus they will not be issued secrets). Most native = apps will be forgeable thus we'll point them in this direction, but = there will be exceptions (especially with partners with protected app = distribution). My point is, we should focus on having developers understand if and why = their app can't keep secrets, not merely thinking "oh, this is app is = native so I have to do it this way." Verifyable and Forgeable were the best terms we've come up with so far = in attempt to put a label on "apps that can keep secrets" and "apps that = can't keep secrets," respectively. There are some aspects of OAuth flow that are unique to native apps = (mostly on account of the app not executing in a user agent), but = ability to keep secrets is not a property shared or exclusive to all = native apps. (Some web apps might not be able to keep secrets based on = open development or deployment model). From stephen.farrell@cs.tcd.ie Wed Jun 1 05:43:52 2011 Return-Path: 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 1D4FEE0B86; Wed, 1 Jun 2011 05:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz26MaXCl7YQ; Wed, 1 Jun 2011 05:43:49 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 24705E0825; Wed, 1 Jun 2011 05:16:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5A5E4153CD3; Wed, 1 Jun 2011 13:16:23 +0100 (IST) 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=1306930582; bh=B0uyx00XBLNKek /AwackzC4lMLYhoqEs4LxaRC2jnNM=; b=tMavOGikYAMNQZ3FGsFmgf9xFXM1Km EZc3+c2ZtVwIDlvpHiX8SUK1C6nwaSw60ySI0fPsWrtQqarRmS2IT/2/BC1rXMpY FgX6obZChRXJ/hJCt0njxxiVe1Ubn6c6pAJ/c+pzFVfmo6hh9J9+PHItrHHEShv6 o/GrfkIxmGNSsUnLHw/v7U9XXTpM4tzu5rc8aG9m1hQUU+oe50fTY/mg0kP9AcQm ZLBzjZWbP9sSbr3mfEP9KnserDJgnD7+PzMmSVgZ1Wq6ROQts+V4saJWLDMB1W93 8TNOZKEuTagsadkbaEJExC8wT2Y+s8H2o60XLMuBwFjnOTaGfPBf4bDQ== 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 bfMUO+l4uhr5; Wed, 1 Jun 2011 13:16:22 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.55.19]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 31630153CD2; Wed, 1 Jun 2011 13:16:19 +0100 (IST) Message-ID: <4DE62D93.7040009@cs.tcd.ie> Date: Wed, 01 Jun 2011 13:16:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Nottingham References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 12:43:52 -0000 Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing reasons). However I do agree that keeping in mind that folks may move towards something like DOESTA in future is a good plan. To be clear, as an individual, I do think that "something like DOSETA" is a really good idea and maybe DOSETA will turn out to be that something, I don't know. S. On 01/06/11 00:57, Mark Nottingham wrote: > Hi, > > Reading draft -05. > > The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). > > It would be more robust to calculate an effective request URI, as in [2]. > > Also, if you include a hash of the request body, you really need to include a hash of the body media type. > > Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. > > Regards, > > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 > > > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > >> (Please discuss this draft on the Apps-Discuss mailing list) >> >> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >> >> The draft includes: >> >> * An HTTP authentication scheme using a MAC algorithm to authenticate requests (via a pre-arranged MAC key). >> * An extension to the Set-Cookie header, providing a method for associating a MAC key with a session cookie. >> * An OAuth 2.0 binding, providing a method of returning MAC credentials as an access token. >> >> Some background: OAuth 1.0 introduced an HTTP authentication scheme using HMAC for authenticating an HTTP request with partial cryptographic protection of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 scheme was designed for delegation-based use cases, but is widely “abused” for simple client-server authentication (the poorly named ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 and has been reintroduced as a standalone, generally applicable HTTP authentication scheme called MAC. >> >> Comments and feedback is greatly appreciated. >> >> EHL >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From eran@hueniverse.com Wed Jun 1 07:17:45 2011 Return-Path: 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 1343DE0827 for ; Wed, 1 Jun 2011 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWReUDyr0U3W for ; Wed, 1 Jun 2011 07:17:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 2A0E0E07FE for ; Wed, 1 Jun 2011 07:17:21 -0700 (PDT) Received: (qmail 962 invoked from network); 1 Jun 2011 14:17:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 14:17:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 1 Jun 2011 07:17:16 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Wed, 1 Jun 2011 07:16:48 -0700 Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token Thread-Index: AcwgMrfnmUB6gR0TTpekZX7hZqipMwAM1zVQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA4B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA442@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:17:45 -0000 Then all these clients sharing the same credentials will require clock sync= (not a problem for cell phones usually, but can be for other devices). But= if you are implementing OAuth 2.0, the request including client authentica= tion is made over TLS (as required) and so replay isn't much of a concern. = If for some reason you are not using TLS alongside client authentication fo= r obtaining an access token, this particular use case becomes out of scope. EHL > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Wednesday, June 01, 2011 1:06 AM > To: Eran Hammer-Lahav > Cc: Adam Barth; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >=20 > > -----Original Message----- > >> From: Skylar Woodward [mailto:skylar@kiva.org] > >> Sent: Wednesday, June 01, 2011 12:16 AM > >> To: Eran Hammer-Lahav > >> Cc: Adam Barth; OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> Provider: api.megaworld.com > >> > >> Software Program: A universal binary iOS app called MegaWorld for iOS > >> Client > >> ID: mega_app > >> > >> User: Frankie in London > >> Username: frankie_uk > >> > >> Device A: Frankie's iPhone > >> Device B: Frankie's iPad > >> > >> Now imagine MegaWorld for iOS installed on device A & B. Client ID > >> is the same across the two devices. > > > > This is broken. You are using MAC for client authentication, but your c= lient > is a native application which should not have a secret... >=20 > No, I had two use cases to discuss. One of access tokens being re-issued = and > the other of client credentials. Token re-issue seemed easier to explain > because it is the more common case of device conflict. >=20 > The issues with client credentials are minimized with the algorithm for n= once > expiration that Adam suggested (sequential) which was not clear as a > suggestion by the spec. I could outline a problem with age for client > credentials which use the "flagged as old" algorithm, but this seems less > important now if we assume "sequential with a window of tolerance" as the > algorithm for invalidation. >=20 > However, there are possible cases where two software instances use the > same client credential (and where it's still possible to secure the secre= t). > Most of those cases are ones where the software distribution is protected > inside a controlled network. A few examples (not common across OAuth, > though some of these will be popular for providers like Kiva where its > customers deploy proprietary software inside controlled intranets where > secrets can be protected from the public even in "native" apps): >=20 > - Great State University makes an app for managing student grading. This = app > is distributed to all faculty iPhones using the Apple Enterprise Deployme= nt > system. GSU expects faculty not to share the installed software with non- > faculty or to use jail-broken phones -- doing so is a violation of school= code of > ethics. GSU makes the case that the client credentials in the grading app= are > securable with reasonable deployment and legal protections in place. All > installs of the app onto faculty iPhones use the same client credential. = They > use the client credential as an additional hurdle to protect against forg= ed > clients trying to authorize. >=20 > - Green Microlender makes an app for submitting loan data to Kiva that al= so > interfaces with their local MIS system. This is a Visual Basic program in= stalled > on Windows PCs throughout field offices in southern Uganda which each on > the organization's protected VLAN (or multiple protected LANs). This > program is deployed by IT staff only onto these devices. They choose to u= se > client credentials in this program as they feel comfortable in asserting = that > the client secrets are protected adequately by Green Microlender. >=20 > - MegaWorld Tracker deploys websites in France and the US. They set up > different instances of their website program in servers in France and the= US. > Each deployment is configured with the same MegaWorld OAuth client ID > since it is the same program, but different locale settings to make the > software render text in French or English, respectively. Since MegaWorld > Tracker isn't a huge corp, they've haven't put in place measures to sync = user's > access tokens between the French servers and the US servers. This means a > user that hits both the FR server and the US server will have to authenti= cate > twice to megaworld.com (and thus access tokens issued to each server > install). Since they also didn't bother to register two client IDs (mw_tr= acker > instead of mw_tracker_us and mw_tracker_fr) they essentially have two > installs using the same client credentials. It's a reasonable gray area. >=20 > I do admit these won't be en masse in the grand collective of all deploye= d > OAuth v2 apps, but they are reasonable use cases, and for some > organizations, very important use cases. >=20 >=20 > >> - Frankie uses device A to authorize his iPhone to allow MegaWorld > >> for iOS to access his account (frankie_uk) > >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. > >> Time on device A is 1306911444. > >> - Frankie uses device B to authorize his iPhone to allow MegaWorld > >> for iOS to access his account (frankie_uk) > >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. > >> Time on device B is 1275375611. > > > > When you say issued, you mean MAC credentials (access token) or client > credentials? >=20 > these are access tokens >=20 > > > > EHL > > > >> The provider, mega_app, does not issue multiple tokens for the same > >> grant request (scope, client_id). This simplifies provider > >> implementation but also helps enforce the correct user UI with > >> respect to credential control at http://megaworld.com/my/apps - that > >> is, the provider can't accurately know if frankie_uk has authorized > >> one software instance twice on the same device, or multiple software > instances once each (across multiple devices). > >> Thus, the my/apps UI shows one authorization for "Megaworld for iOS" > >> and thus one option to de-authorize this client_id (and thus all > >> installed instances of the single software program with ID mega_app). > >> > >> Regardless if age or timestamp is used, if the implementation for > >> validating the time value is sequential (perhaps with some window of > >> error) then one device will have all its OAuth requests rejected as > >> soon as the other presents a request. If timestamps are used the one > >> with the older clock (device B) is rejected. If age is used, the one > >> with the highest value of time (in this case, the more correct > >> client) will be rejected as age will be calculated to be smaller than = device B > with an incorrect clock. > >> > >> If you also consider the case where device A and B have the same > >> value for current time (UTC time, let's say) then age fails for > >> device B after device A submits a request since device B thinks the > >> credential is younger than device A. Timestamp does not fail in this c= ase > (because clocks are already sync'd). > >> > >> Only when the timestamp is a unified standard like UTC can both > >> device A and B both use token 89ARC. If client B has it's request > >> rejected it can quickly check UTC from any reasonable source > >> (including api.megaworld.com) to correct its clock. Even better, it > >> can politely check the correct system time on a regular basis and > >> cache the offset between UTC and device time. Though experience may > >> show that many software developers don't currently do this clock > >> correction, it is trivial to adopt as a best practice. (Many software > >> developer also don't routinely review their software for security or > >> stability vulnerabilities of any sort.) Certainly is nothing for the > >> small percentage of well-written high-value clients such as Firefox, > TweetDeck or any serious effort with even moderate distribution or > engineering resources. > >> > >> skylar > >> > >> > >> On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > >> > >>> This is not true. > >>> > >>> The age value has to be monotonically increasing, but not > >>> necessarily > >> unique. Really, any counter will do. The reason why timestamp isn't > >> any better than age or sequence is because ultimately, it is the > >> server's memory restriction which determines the nonces storage size, > >> not anything else (like a time limit). > > From eran@hueniverse.com Wed Jun 1 08:02:45 2011 Return-Path: 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 61357E0729 for ; Wed, 1 Jun 2011 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0HKrL0f0F7D for ; Wed, 1 Jun 2011 08:02:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 968DAE07F7 for ; Wed, 1 Jun 2011 08:02:23 -0700 (PDT) Received: (qmail 25729 invoked from network); 1 Jun 2011 15:02:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 15:02:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 1 Jun 2011 08:00:40 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 1 Jun 2011 08:00:12 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: Acwf7oEQJBF82ilkT/6VDPS/ahDBDQAfEq6g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:02:45 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, May 31, 2011 4:57 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; > 'Adam Barth (adam@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >=20 > Hi, >=20 > Reading draft -05. >=20 > The "normalized request string" contains the request-URI and values > extracted from the Host header. Be aware that intermediaries can and do > change these; e.g., they may change an absolute URI to a relative URI in = the > request-line, without affecting the semantics of the request. See [1] for > details (it covers other problematic conditions too). >=20 > It would be more robust to calculate an effective request URI, as in [2]. I'll take a look. > Also, if you include a hash of the request body, you really need to inclu= de a > hash of the body media type. This was suggested before, but are there really attack vectors for this? The problem is that content-type is a pretty flexible header, which means n= ormalization of the header will be required (case, parameter order, white s= pace, etc.). I would argue that if you are using MAC with body hash and an attacker chan= ging the media type can cause harm, you should use additional methods to se= cure the content-type (such as making the body self-describing). > Generally, I think that people can and will want to include other headers= ; just > because *some* developers can't get this right doesn't mean we should > preclude *all* developers from doing it. It'd be really nice to see this = either > leverage DOSETA [3][4], or at least offer a clean transition path to it. If someone comes up with a practical and secure way to normalize HTTP reque= st headers, they can either define a new authentication scheme or use the '= ext' parameter to pass the additional values. I would vote for a new scheme= . MAC is trivial to implement and interoperate. That simplicity comes at a = significant lack of features, and limiting extensibility is a design goal. EHL > Regards, >=20 > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section- > 4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-= 4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 >=20 >=20 > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: >=20 > > (Please discuss this draft on the Apps-Discuss > mailing list) > > > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > The draft includes: > > > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > > * An extension to the Set-Cookie header, providing a method for > associating a MAC key with a session cookie. > > * An OAuth 2.0 binding, providing a method of returning MAC credentials > as an access token. > > > > Some background: OAuth 1.0 introduced an HTTP authentication scheme > using HMAC for authenticating an HTTP request with partial cryptographic > protection of the HTTP request (namely, the request URI, host, and port). > The OAuth 1.0 scheme was designed for delegation-based use cases, but is > widely "abused" for simple client-server authentication (the poorly named > 'two-legged' use case). This functionality has been separated from OAuth = 2.0 > and has been reintroduced as a standalone, generally applicable HTTP > authentication scheme called MAC. > > > > Comments and feedback is greatly appreciated. > > > > EHL > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From wmills@yahoo-inc.com Wed Jun 1 09:02:00 2011 Return-Path: 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 2531DE07A9 for ; Wed, 1 Jun 2011 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.965 X-Spam-Level: X-Spam-Status: No, score=-15.965 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sPu91dXlAtr for ; Wed, 1 Jun 2011 09:01:58 -0700 (PDT) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by ietfa.amsl.com (Postfix) with SMTP id B209AE0714 for ; Wed, 1 Jun 2011 09:01:58 -0700 (PDT) Received: from [98.139.91.69] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 16:01:58 -0000 Received: from [98.139.91.31] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 16:01:58 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 01 Jun 2011 16:01:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 613390.77383.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 29744 invoked by uid 60001); 1 Jun 2011 16:01:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306944118; bh=jvBwqSsZS9edEZjzWd4/2zml1Id/6AzPt5tGng31Ro0=; 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=Ect+pPpLeT8KyIwFftfECD//mohyaIj9y2EruJfEXSuBmUH1kiljWFZXIqQGbKDxq+hQspsU7MsNB++KVmyggUkU8xEIddHEG7NZ9Q9f3zuGn+W6YW7qXALJZpquf0TAFPoPtkBF8Y6iJ3NwIhfV1gy4nFSLjiAHQfOEcW0HGNs= 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=B1wSSenR6HMOagFeKVLIKd8kdsqsbTb6m0owZ3LLxNgkEuCL6vtCmikxZqJDjLWhkQnd/dCdOUEf5C+SP96AjB6KFs63mWsK/QRYvMYeiSK8rVrWTP/V0Td4TFThcyHNvD78QX+6Bpf42fgjvU8fXN+rwL/1UnKKurv2Qie7BF0=; X-YMail-OSG: ohmK0u0VM1ltvTfidRfhPPFHQJ.WrenhH8iGvDdFkVpRVcP zOlLsghVxVmhZQBACxD33LakinQlOeJnUH.CyTRh5eXC99BEaVQQIf_s757z ri5UOpeQy4g_vUCG5eYRVfS4VHCya.tG.9YTEgMCp1H_FBAecKc06Sr42zG1 NO16RILwOmkYISNtBngNpilFIbu9fH7nuRw3A_Tarqt0OZERpxnafF591UQa JcczQOPA8YySbbtiaD_7oROfzj.mWoq3UDVZROkmbyihpXDT05b.ibAZP83r pKupgGpOFXM8la5GftW9pbY1Xy80rCc9ze3igoMoQxuAhd6zMU9SFz8WLJP5 6geHQK.KGxXMhKtY6aO9uQ.DJEntUudxg55.sOj.Mm7h8HSuAU3E6fuvAby2 pBBr3g7fGz7YUKzqbyQJzDI1iWwap5w6QwmcLlg4DuwBa_VnMzteWrRXWXyZ H.SLinMP6T1k5KXgV12zKnzOicF.XZWwJRFTD13HoviqmhvOsCmYZJNp6Qdr 2.KkWvg-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Wed, 01 Jun 2011 09:01:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com> Message-ID: <1306944117.46982.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 1 Jun 2011 09:01:57 -0700 (PDT) From: "William J. Mills" To: Kris Selden , Doug Tangren In-Reply-To: <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-842429024-1306944117=:46982" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:02:00 -0000 --0-842429024-1306944117=:46982 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > The biggest difference between a refresh token and a non-expiring access = token is that =0A> the refresh token=0A needs to be verified by the authori= zation server only whereas the =0A> access token needs to be verified by th= e resource servers.=0A=0AI just want to call out that use of short lifed ac= cess tokens with long lived refresh tokens allows your login/auth/refresh s= ervers to be a single point of control for expiring/invalidating tokens.=A0= A very good thing. =0A=0A=0A=0A________________________________=0AFrom: Kr= is Selden =0ATo: Doug Tangren = =0ACc: "oauth@ietf.org" =0ASent: Tuesday, May 31, 2011 11:4= 5 PM=0ASubject: Re: [OAUTH-WG] Text for Native Applications=0A=0A=0AI would= suspect that many users are overwhelmed when authorizing many fine grained= scopes and don't fully understand the risks. =A0Many popular sites ask for= offline access straight away upon connecting to Facebook (Foursquare, Quor= a, Instagram, etc). =A0This offline access token, has a higher chance of be= ing exposed, like if you use the cookie: true option in the Facebook JS SDK= (which Foursquare does), which sets a Javascript accessible non secure coo= kie on your domain which now means that if Foursquare makes a non secure ht= tp request to foursquare.com a non expiring bearer token will go out in pla= intext. =A0Foursquare is https only but many sites that use the JS SDK aren= 't.=0A=0AThe biggest difference between a refresh token and a non-expiring = access token is that the refresh token needs to be verified by the authoriz= ation server only whereas the access token needs to be verified by the reso= urce servers.=0A=0A-------=0A=0AHere is the rationale in Scalable OAuth Ext= ension (http://wiki.oauth.net/w/page/12238549/ScalableOAuth#RationaleforRen= ewableAccessTokensSessions) which was a=A0predecessor=A0to OAuth WRAP and O= Auth 2:=0A=0ARationale for Renewable Access Tokens (Sessions)=0A=0AMany Ser= vice Providers have the concept of a Session credential with a finite lifet= ime. Consumers authenticate with the Service Provider's Authentication Serv= ice to obtain a Session credential to access the Service=A0Provider's prote= cted resources. When the Session credential expires, the consumer is able t= o obtain a new Session credential by re-authenticating with the Authenticat= ion service. The primary benefit to this architecture is=A0that Session cre= dentials do not need to be revocable if they expire quickly, and that prote= cted resources can be returned without a database lookup to verify that the= consumer is still authorized.=0A=0ARationale for Auth Session (aka Refresh= Secret)=0A=0AService Providers often run their Authentication Service sepa= rately from other protected resources. The Authentication Service is usuall= y strictly monitored and controlled, while other Protected Resources may be= running=A0relatively new and unproven code.=0A=0AIn the event that a Prote= cted Resource is compromised (the SP gets hacked), it is desirable to preve= nt the intruder from being able to continue to compromise the system after = the vulnerability has been fixed. Issuing=A0credentials with a finite lifet= ime limits the duration that the intruder can continue to use compromised c= redentials. Issuing a credential to a Consumer that is not known by the Pro= tected Resource but is known by the=A0Authentication Service can enable an = Service Provider to revoke access to an intruder without requiring consumer= s to be reauthorized.=0A=0A------=0A=0AAnother related issue with Native Ap= ps like iPhone Apps that can't be shipped with a client secret is the end u= ser's expectation to stay "logged in." =A0=0A=0A=0AOn May 31, 2011, at 7:12= PM, Doug Tangren wrote:=0A=0A>=0A>"offline_access=A0permission."=0A>=0A>= =0A>If I read that right, that says the user has to opt into the access_tok= en not expiring. I believe this may be the smarted solution for now because= it uses the scope parameter to gain this additional access which is using = the actual protocol parameters as intended instead of hacking around them.= =0A_______________________________________________=0A>OAuth mailing list=0A= >OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A=0A___= ____________________________________________=0AOAuth mailing list=0AOAuth@i= etf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-842429024-1306944117=:46982 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>= The biggest difference between a=0A refresh token and a non-expiring acces= s token is that
> the refresh token=0A needs to be verified by the a= uthorization server only whereas the =0A
> access token needs to be v= erified by the resource servers.

I just want to call out that= use of short lifed access tokens with long lived refresh tokens allows you= r login/auth/refresh servers to be a single point of control for expiring/i= nvalidating tokens.  A very good thing.

From: Kris Selden <kris.selde= n@gmail.com>
To: Dou= g Tangren <d.tangren@gmail.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, May 31, 2011 11:45 PMSubject: Re: [OAUTH-WG] Text for Native Applications
=
=0A
I would suspect that many user= s are overwhelmed when authorizing many fine grained scopes and don't fully= understand the risks.  Many popular sites ask for offline access stra= ight away upon connecting to Facebook (Foursquare, Quora, Instagram, etc). =  This offline access token, has a higher chance of being exposed, like= if you use the cookie: true option in the Facebook JS SDK (which Foursquar= e does), which sets a Javascript accessible non secure cookie on your domai= n which now means that if Foursquare makes a non secure http request to foursquar= e.com a non expiring bearer token will go out in plaintext.  Fours= quare is https only but many sites that use the JS SDK aren't.
The biggest difference between a refresh token and a non-expir= ing access token is that the refresh token needs to be verified by the auth= orization server only whereas the access token needs to be verified by the resource = servers.

-------

Here is = the rationale in Scalable OAuth Extension (http://wiki.oauth.net/w/page/122= 38549/ScalableOAuth#RationaleforRenewableAccessTokensSessions) which was a&= nbsp;predecessor to OAuth WRAP and OAuth 2:

<= /div>
Rationale for Renewable Access Tokens (Sessions)

Many Serv= ice Providers have the concept of a Session credential with a finite lifeti= me. Consumers authenticate with the Service Provider's Authentication Servi= ce to obtain a Session credential to access the Service Provider's pro= tected resources. When the Session credential expires, the consumer is able= to obtain a new Session credential by re-authenticating with the Authentic= ation service. The primary benefit to this architecture is that Sessio= n credentials do not need to be revocable if they expire quickly, and that protected resources can be returned without a database lookup to = verify that the consumer is still authorized.

Rationale for Auth Ses= sion (aka Refresh Secret)

Service Providers often run their Authenti= cation Service separately from other protected resources. The Authenticatio= n Service is usually strictly monitored and controlled, while other Protect= ed Resources may be running relatively new and unproven code.

In the event that a Protected Resource is compromised (the SP gets ha= cked), it is desirable to prevent the intruder from being able to continue = to compromise the system after the vulnerability has been fixed. Issuing&nb= sp;credentials with a finite lifetime limits the duration that the intruder= can continue to use compromised credentials. Issuing a credential to a Con= sumer that is not known by the Protected Resource but is known by the = Authentication Service can enable an Service Provider to revoke access to an intruder without requiring consumers to be reauthorized.

------

Another related issue = with Native Apps like iPhone Apps that can't be shipped with a client secre= t is the end user's expectation to stay "logged in."  

<= /div>

On May 31, 2011, at 7:12 PM, Doug Tangren wro= te:
=

"offline_access permission."
=0A=0A

If I read that right, that says the user has to opt int= o the access_token not expiring. I believe this may be the smarted solution= for now because it uses the scope parameter to gain this additional access= which is using the actual protocol parameters as intended instead of hacki= ng around them.
=0A=0A
=0A_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth


--0-842429024-1306944117=:46982-- From wmills@yahoo-inc.com Wed Jun 1 09:11:39 2011 Return-Path: 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 6E6B5E084E for ; Wed, 1 Jun 2011 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.863 X-Spam-Level: X-Spam-Status: No, score=-16.863 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC4YAiP4FOEG for ; Wed, 1 Jun 2011 09:11:38 -0700 (PDT) Received: from web31816.mail.mud.yahoo.com (web31816.mail.mud.yahoo.com [68.142.206.169]) by ietfa.amsl.com (Postfix) with SMTP id 6ECFFE05D3 for ; Wed, 1 Jun 2011 09:11:38 -0700 (PDT) Received: (qmail 84973 invoked by uid 60001); 1 Jun 2011 16:11:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306944691; bh=hwlwLIsROhyYkmXmzUuWxGYd8GLH2YO6DWSsSlGHfwY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dIUDLrfFVgQLE2GZGP/Pn7lm3FS83HrqAIpxr3F92T3lpCH2jX9sLMrNaBZduwNeSFibvA32mvmUtVuwsCHMqfM6KwaBP3yIYbr/H5iAC1F9OhFC8AWx9PhXfWBUGDFBM2QZr4wEEfuXTTUV2PbSTtJZyZC53YNacJJYyAUFxy8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bpCsNZE+OqJyz3T+POxH1/HDYVQUyyxCelFZ3h09wdzY11iFDBt4kZyP5yRIALTnNeTGO5YOxPmA0p/5OQQ1QfoJk/Mqb2//xC/bHHMIjqpAHS6FcNlQLs7OREyfuArN/XhImGiVK6ERY6zJTs75+nnbJPDJ9OoVLLqII8DFu6E=; Message-ID: <755100.21182.qm@web31816.mail.mud.yahoo.com> X-YMail-OSG: 26EmBDkVM1lXykRmYJ2ygBD8393BN616WSJDhkJBAjNCqEX 1WT4a4PxLxajTX.FzkZf8Risi1TcNy77qGXGxwnRgvgNkHU2yxEi8x7CiR46 ILfE9ZiIPg.Qd2b71VNexipgj19nUPWXOS.KMM6eiRKyNCPwJgJaL9YDMAFj Mu6ayahTO6SJNab78EafXqRy9F5RKaniHgkJF_eg76xcC1JRHFvTq.rPZiYV xSIdpuWGrB3g1vJLMuLqMpjPYJV8u9joCTKvIHKJkS00FcLdV3Sj0Eo8YtLM y0ltrCLJSDFWUE2J0gSKnznVGfk40LEnMzQWFx8DmrQoELGLY0hKIPzCSJyl 3T4aeng88vWFKLhOaqTejdmR.Q6aO94QmBuMM_aAJE2U- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Wed, 01 Jun 2011 09:11:31 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.111.303096 References: <4DE5EE7F.4040907@lodderstedt.net> Date: Wed, 1 Jun 2011 09:11:31 -0700 (PDT) From: "William J. Mills" To: Brian Eaton , Torsten Lodderstedt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1122653328-1306944691=:21182" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:11:39 -0000 --0-1122653328-1306944691=:21182 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > - native apps always use the authorization code grant=0A=0A=0AI don't lik= e this if it means I can't use passwrd grant for stuff like IMAP clients.= =0A=0A=0A=0A________________________________=0AFrom: Brian Eaton =0ATo: Torsten Lodderstedt =0ACc: "oauth@= ietf.org" =0ASent: Wednesday, June 1, 2011 1:18 AM=0ASubjec= t: Re: [OAUTH-WG] Text for Native Applications=0A=0AOn Wed, Jun 1, 2011 at = 12:47 AM, Torsten Lodderstedt=0A wrote:=0A>> - ign= ore the problem and leave the spec vague and insecure.=0A>=0A> Could you pl= ease describe what you consider "insecure"?=0A=0AAs an example, optional cl= ient authentication in the authorization=0Acode flow makes the web server f= low much less secure.=A0 But it's=0Apermitted by the spec.=0A=0AThe confusi= on you mention about how to support native apps is also=0Agoing to create s= ecurity problems.=A0 You mentioned the risks of=0Aauto-approving token requ= ests from native apps.=0A=0A> I think we have the=0A> challenge to defining= a secure protocol while supporting the needs of=0A> different client types= .=0A=0A+1 to that.=0A=0A> Past versions of the spec entirely focused on cli= ent secrets as mechanism to=0A> validate a client's identity. This created = the false impression that native=0A> apps either...=0A=0A=0A=0AI think your efforts to clear this up in the s= ecurity considerations=0Aare so admirable that they should move into the ma= in body of the spec=0Ainstead. =3D)=0A=0AIn particular, I think the spec sh= ould say that:=0A=0A- native apps always use the authorization code grant= =0A- if authorization servers are comfortable issuing client secrets to=0An= ative apps, they may do so=0A- if authorization servers are not comfortable= issuing client secrets=0Ato installed apps, they may use a blank or well-k= nown client secret.=0A=0AThat would let us simplify the authorization code = protocol and the=0Arefresh token protocol, since parameters would move from= =0Asometimes-they-are-required-sometimes-not to being required.=0A=0AIt wou= ld also let us have a clear direction to point people who want=0Ato support= native apps.=0A=0AAnd it would meet the requirement of having a clear path= forward for=0Apeople who don't want to trust native apps to keep secrets r= eally=0Asecret.=0A_______________________________________________=0AOAuth m= ailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1122653328-1306944691=:21182 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>= - native apps always use the authorization code grant

I don't like this if it means I can't use passwrd grant for stuff = like IMAP clients.

From: Brian Eaton <beaton@google.com>
To: Torsten Lodderstedt <torsten@lo= dderstedt.net>
Cc: "= oauth@ietf.org" <oauth@ietf.org>
Sent: Wednesday, June 1, 2011 1:18 AM
Subject: Re: [OAUTH-WG] Text for Native Applications
=
=0AOn Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
<<= a ymailto=3D"mailto:torsten@lodderstedt.net" href=3D"mailto:torsten@lodders= tedt.net">torsten@lodderstedt.net> wrote:
>> - ignore the p= roblem and leave the spec vague and insecure.
>
> Could you ple= ase describe what you consider "insecure"?

As an example, optional c= lient authentication in the authorization
code flow makes the web server= flow much less secure.  But it's
permitted by the spec.

The= confusion you mention about how to support native apps is also
going to= create security problems.  You mentioned the risks of
auto-approvi= ng token requests from native apps.

> I think we have the
>= challenge to defining a secure protocol while supporting the needs of
&= gt; different client types.

+1 to that.

> Past versions of= the spec entirely focused on client secrets as mechanism to
> valida= te a client's identity. This created the false impression that native
> a= pps either...

<snip analysis of the consequences of the spec lang= uage and how the
security considerations tries to fix the spec>
I think your efforts to clear this up in the security considerations
a= re so admirable that they should move into the main body of the spec
ins= tead. =3D)

In particular, I think the spec should say that:

-= native apps always use the authorization code grant
- if authorization = servers are comfortable issuing client secrets to
native apps, they may = do so
- if authorization servers are not comfortable issuing client secr= ets
to installed apps, they may use a blank or well-known client secret.=

That would let us simplify the authorization code protocol and the<= br>refresh token protocol, since parameters would move from
sometimes-th= ey-are-required-sometimes-not to being required.

It would also let us have a clear direction to point people who want
to support nativ= e apps.

And it would meet the requirement of having a clear path for= ward for
people who don't want to trust native apps to keep secrets real= ly
secret.
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--0-1122653328-1306944691=:21182-- From beaton@google.com Wed Jun 1 09:48:40 2011 Return-Path: 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 E8357E06FB for ; Wed, 1 Jun 2011 09:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy+mbjnH2IAg for ; Wed, 1 Jun 2011 09:48:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DD027E06DC for ; Wed, 1 Jun 2011 09:48:39 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p51GmcqP009290 for ; Wed, 1 Jun 2011 09:48:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306946918; bh=xYZyY97Tmwbbbv4Gyxi26amwCqA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=r+PWJeZqJjQfWQ1VeJdGEcnltQktJdCMOHIrluieq2erQG36ubayY7jMV6emfXKJg YmkeibSgp7cKEMT/St58g== Received: from pzk26 (pzk26.prod.google.com [10.243.19.154]) by kpbe15.cbf.corp.google.com with ESMTP id p51GmaTo002666 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 09:48:36 -0700 Received: by pzk26 with SMTP id 26so3167388pzk.24 for ; Wed, 01 Jun 2011 09:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cs5enPekR9vBfu6j+59sMouJRmz1it4QRmXjzS0D22Q=; b=pX94IRnN73iq7BBVJ7I7AU91A+cSQrovvjJQOesa/T9d8r5ADls2TKENJCLWxuYFDs ny/+yI/c1J1edFiRN9zQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BR06BrB3fxw8K4Z/34sHq8c4eyKG0sG4KDaNO81Y7cP/w4Uj4ZsahNoSdydXaTciKy Vj1ylSIsrmuQH1OpJ7dQ== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr1304822wff.266.1306946916088; Wed, 01 Jun 2011 09:48:36 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 09:48:35 -0700 (PDT) In-Reply-To: <755100.21182.qm@web31816.mail.mud.yahoo.com> References: <4DE5EE7F.4040907@lodderstedt.net> <755100.21182.qm@web31816.mail.mud.yahoo.com> Date: Wed, 1 Jun 2011 09:48:35 -0700 Message-ID: From: Brian Eaton To: "William J. Mills" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:48:41 -0000 On Wed, Jun 1, 2011 at 9:11 AM, William J. Mills wrote: >> - native apps always use the authorization code grant > > I don't like this if it means I can't use passwrd grant for stuff like IMAP > clients. Sorry, didn't mean to suggest that password grants would go away. The business need is clearly there, no sense in forbidding it if people are going to do it anyway. =) From beaton@google.com Wed Jun 1 09:54:11 2011 Return-Path: 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 8B20DE076D for ; Wed, 1 Jun 2011 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.144 X-Spam-Level: X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeNmnSl1aJ7a for ; Wed, 1 Jun 2011 09:54:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEE0E0709 for ; Wed, 1 Jun 2011 09:54:10 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p51Gs9Mc014851 for ; Wed, 1 Jun 2011 09:54:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306947249; bh=8yY+kHWzWKcpd8WfMqk+ZNKyQMs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ngp/pTLJKPSXSZ9dM/Ybsg5zGupmJE3VmMYqhLpYnuxk6YmN/H9fJT3EhdpU1tOjx W4sqD1mZ05OqVQjttnvLg== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by wpaz13.hot.corp.google.com with ESMTP id p51GrlMp024506 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 09:54:08 -0700 Received: by pxi13 with SMTP id 13so2024869pxi.11 for ; Wed, 01 Jun 2011 09:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n97UgSRwORY2geY5Py8ezYMAF8MpVfLKOVnc/bIl9qw=; b=xWO+1UhJg8qyMqy04w8USIAU6b1atXlP39oknSGkGBJMw21KCWsB0MEs2ZGpoFSy03 VtxBEym0+CkLN9gxxJ0w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v1ZaWGVTs8rRHLKIkIRsT1bG1MMVygj9DJ6NLpQZHYLVSGB1diOqpARhAUP12eDXZ8 BVumJQXT67bmwjjIw7hQ== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr1305774wff.266.1306947247580; Wed, 01 Jun 2011 09:54:07 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 09:54:07 -0700 (PDT) In-Reply-To: References: <4DE5EE7F.4040907@lodderstedt.net> Date: Wed, 1 Jun 2011 09:54:07 -0700 Message-ID: From: Brian Eaton To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:54:11 -0000 On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward wrote: > Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on "apps that can keep secrets" and "apps that can't keep secrets," respectively. You might be on to something there. There are two ways clients are authenticated in the spec. - client credentials - registered callback URLs People are combining them in interesting ways. And there is stuff outside the spec, such as the app-to-app authentication built into smart phone platforms. (This is used heavily in the facebook developer platform. We use it on Android, not on iPhone yet.) I haven't tried it yet, but I suspect organizing the security considerations based on how your client authenticates would be constructive. > (Some web apps might not be able to keep secrets based on open development or deployment model). Can you clarify what you mean by this? What flows are you using for those apps? From dnelson@elbrys.com Wed Jun 1 10:17:46 2011 Return-Path: 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 22502E0897 for ; Wed, 1 Jun 2011 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3T6eA0Kckh8 for ; Wed, 1 Jun 2011 10:17:44 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with SMTP id 5040DE07E0 for ; Wed, 1 Jun 2011 10:17:17 -0700 (PDT) Received: from mail-yi0-f43.google.com ([209.85.218.43]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTeZ0HEyd+WSsknp//gRgr4ScjCC360F4@postini.com; Wed, 01 Jun 2011 10:17:17 PDT Received: by mail-yi0-f43.google.com with SMTP id 16so4614yie.30 for ; Wed, 01 Jun 2011 10:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.189.41 with SMTP id b29mr9215445yhn.251.1306948636575; Wed, 01 Jun 2011 10:17:16 -0700 (PDT) Received: by 10.236.161.40 with HTTP; Wed, 1 Jun 2011 10:17:16 -0700 (PDT) In-Reply-To: References: <4DE5EE7F.4040907@lodderstedt.net> Date: Wed, 1 Jun 2011 13:17:16 -0400 Message-ID: From: Dave Nelson To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:17:46 -0000 >=A0Most native apps will be forgeable ... I don't understand the rationale behind this assertion. Would you please point me to the discussion that elaborates on this point. Thanks! Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From mark.mcgloin@ie.ibm.com Wed Jun 1 11:29:20 2011 Return-Path: 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 33DE213003F for ; Wed, 1 Jun 2011 11:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1KWDisl02fJ for ; Wed, 1 Jun 2011 11:29:18 -0700 (PDT) Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B813002A for ; Wed, 1 Jun 2011 11:29:18 -0700 (PDT) Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p51ITArm022651 for ; Wed, 1 Jun 2011 18:29:10 GMT Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51ITAtd1773676 for ; Wed, 1 Jun 2011 19:29:10 +0100 Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51ITADf032575 for ; Wed, 1 Jun 2011 12:29:10 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51ITAwv032572; Wed, 1 Jun 2011 12:29:10 -0600 In-Reply-To: <4DE5F433.6090503@lodderstedt.net> References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE5F433.6090503@lodderstedt.net> X-KeepSent: F8C139AB:486ED3F6-802578A2:00567D68; type=4; name=$KeepSent To: Torsten Lodderstedt X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 1 Jun 2011 19:28:33 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/06/2011 19:28:34 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:29:20 -0000 Hi Torsten It was implicit that the state parameter would be secret and not guessable but that it probably worth spelling out, as you and Breno state. Here is a modified version CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The state parameter MUST be non-guessable and MUST be a secret only accessible to the client. The authorization server will send it in the response when redirecting the user to back to the client which MUST then validate the state parameter matches on the response. Regards Mark Torsten Lodderstedt wrote on 01/06/2011 09:11:31: > From: > > Torsten Lodderstedt > > To: > > Mark Mcgloin/Ireland/IBM@IBMIE > > Cc: > > oauth@ietf.org > > Date: > > 01/06/2011 09:11 > > Subject: > > Re: [OAUTH-WG] Draft 16 Security Considerations additions > > > Hi Mark, > > Am 31.05.2011 22:58, schrieb Mark Mcgloin: > > Eran > > > > Here are some additional sections to add to the next draft under security > > considerations > > > > CSRF > > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > > requests are transmitted from a user that the website trusts or has > > authenticated. CSRF attacks on OAuth approvals can allow an attacker to > > obtain authorization to OAuth Protected Resources without the consent of > > the User. > > The state parameter should be used to mitigate against CSRF attacks, > > particularly for login CSRF attacks. It is strongly RECOMMENDED that the > > client sends the state parameter with authorization requests to the > > authorization server. The authorization server will send it in the response > > when redirecting the user to back to the client which SHOULD then validate > > the state parameter matches on the response. > > As far as I understand, the goal of the countermeasure is to bind the > authz flow to a certain user agent (instance). So client must verify > that the state parameter (or any other URL parameter?) matches some data > found in the user agent itself before further processing the authz code. > > Breno explained it as follows: > ----- > - Client or user-agent generates a secret. > - The secret is stored in a location accessible only by the client or > the user agent (i.e., protected by same-origin policy). E.g.: DOM > variable (protected by javascript or other DOM-binding language's > enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. > - The secret is attached to the state before a request is issued by the > client > - When the response is received, before accepting the token or code, the > client consults the user agent state and rejects the response altogether > if the state does not match the user agent's stored value. > ---- > > I would suggest to incorporate this into the decription: > > It is strongly RECOMMENDED that the client sends the state parameter > with authorization requests to the authorization server. _The state > parameter MUST refer to a secret value retained at the user agent._ > The authorization server will send the _state parameter_ in the > response when redirecting the user to back to the client which > _MUST_ then validate the state parameter_'s value against the secret > value in the user agent_. > > > regards, > Torsten. > > > > > > > Clickjacking > > Clickjacking is the process of tricking users into revealing confidential > > information or taking control of their computer while clicking on seemingly > > innocuous web pages. In more detail, a malicious site loads the target site > > in a transparent iframe overlaid on top of a set of dummy buttons which are > > carefully constructed to be placed directly under important buttons on the > > target site. When a user clicks a visible button, they are actually > > clicking a button (such as an "Authorize" button) on the hidden page. > > To prevent clickjacking (and phishing attacks), native applications SHOULD > > use external browsers instead of embedding browsers in an iFrame when > > requesting end-user authorization. For newer browsers, avoidance of iFrames > > can be enforced server side by using the X-FRAME-OPTION header. This header > > can have two values, deny and sameorigin, which will block any framing or > > framing by sites with a different origin, respectively. For older browsers, > > javascript framebusting techniques can be used but may not be effective in > > all browsers. > > > > > > Regards > > Mark > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Wed Jun 1 11:43:24 2011 Return-Path: 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 4BD14E0717 for ; Wed, 1 Jun 2011 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP3XIGRSkvTo for ; Wed, 1 Jun 2011 11:43:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC65E06C0 for ; Wed, 1 Jun 2011 11:43:23 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A993E40046 for ; Wed, 1 Jun 2011 12:43:21 -0600 (MDT) Message-ID: <4DE68847.8090808@stpeter.im> Date: Wed, 01 Jun 2011 12:43:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010407020105040705010500" Subject: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:43:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010407020105040705010500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Last week I completed a review of draft-ietf-oauth-v2-16. Here are some comments. MAJOR ISSUES... Throughout the document, the various parameters (e.g., client_secret and client_id) are essentially undefined. There is no text about the length of these parameters, the allowable characters (e.g., alpha and digits only, all ASCII characters, full Unicode), internationalization considerations, preparation and comparison of strings, etc. I don't see how developers will build interoperable implementations without clear guidance here. Also, the scope parameter still strike me as extremly vague. Can we at least define the word "scope" and provide a few examples of how the parameter might be used? No rules are provided for URI matching (e.g., in Section 4.1 the redirection URI received needs to be checked against the URI used to redirect the client, but not guidance is provided). Perhaps a reference to RFC 3986 is in order here. Here also internationalization concerns might need to be covered (e.g., are IRIs allowed?). 4.1.2. Authorization Response OLD: If an authorization code is used more than once, the authorization server MAY revoke all tokens previously issued based on that authorization code. NEW: If an authorization code is used more than once, the authorization server SHOULD revoke all tokens previously issued based on that authorization code. RATIONALE: MAY seems weak here. 10.2. Client Impersonation The authorization server SHOULD require the client to pre-register its redirection URI and validate the value of the "redirect_uri" against the pre-registered value. How does this validation occur? OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? 10.3. Access Token Credentials The client SHOULD request access token credentials with the minimal scope and duration necessary. Is this enfoced by the authorization server? 10.6. Endpoints Authenticity In order to prevent man-in-the-middle and phishing attacks, the authorization server MUST implement and require TLS with server-side authentication in all exchanges. The client MUST verify the authorization server's TLS certificate, as well as the respective certificate chain. We need a reference to RFC 2818 here since it defines server verification procedures for HTTP. (Same for Section 10.8.) 10.9. Authorization Codes Authorization codes SHOULD be short lived and MUST be single use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD revoke all access tokens already granted based on the compromised authorization code. Is there a good reason why the authorization server would not revoke all the access tokens? If not, change to MUST. MINOR ISSUES... 1.4.1. Authorization Code OLD: Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client. NEW: Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials at the resource server are never shared with the client. RATIONALE: could the resource owner have credentials at the authorization server? 1.4.2. Implicit OLD: Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application) since it reduces the number of round trips required to obtain an access token. NEW: Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application) since they reduce the number of round trips required to obtain an access token. However, service providers need to weigh this convenience against the security properties of implicit grants (e.g., the fact that client authentication is not possible). RATIONALE: I think it would be good to mention that there's a balance here between convenience and security. 1.7 Notational Conventions I think it would be good to add an informational reference to RFC 4949 here, and to check our usage of certain terms against the definitions in that spec. Proposed text: Certain security-related terms are to be understood in the sense defined in [RFC4949]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify". 2.1. Authorization Endpoint OLD: Request and response parameters MUST NOT repeat more than once, unless noted otherwise. NEW: Request and response parameters MUST NOT be included more than once, unless noted otherwise. 4.1.2.1. Error Response OLD: error_description OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred. [[ add language and encoding information ]] NEW: error_description OPTIONAL. Descriptive text providing additional information, used to assist in the understanding and resolution of the error that has occurred. If included, it MUST be used only to provide descriptive or diagnostic information that supplements the meaning of an existing HTTP error code. It MUST NOT be interpreted programmatically by an application and MUST NOT be used as the error message presented to a human user, but MAY be used by application developers for debugging purposes. RATIONALE: If the error_description is not intended for humans and is to be used only by developers for debugging purposes, then we don't need language tags. (As explained in RFC 2277, "internationalization is for humans"; yes, developers are people too...) 4.2. Implicit Grant This section uses the term "web server"; I suggest "resource server" for consistency. 7.1. Access Token Types OLD: The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes). The client MUST NOT use an access token if it does not understand the token type. NEW: The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes). The client MUST NOT use an access token if it does not understand or does not trust the token type. RATIONALE: An application could understand a given token type but not trust it (or not trust it from the sender). 8.1. Defining Access Token Types 8.2. Defining New Endpoint Parameters Mention that the ALPHA and DIGIT rules come from RFC 5234. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010407020105040705010500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MTE4NDMxOVowIwYJKoZIhvcNAQkEMRYEFLV1O6Gbm94tCWGKPRsKVDZRrwQ5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAaW+yvezcT95sU6emcK/EZM6KaV5rBsaY44YLmx5KW5+rIkCJikoKn2lg6 EK81e8PcQkJQ3I6LFqH69lzk4eB1zem6uD+6MXGAIWlFiArudRKXwePjY5eqt3Ycay6a4cOD ecOZl4bVtPdsxMcxjwvwjBnnfy0Mjh3Qf+JzjmT7XX31jdx7URotuva0PWMuZaMw9Sj+WaEL diI39zyX9PIyT0BcmbizkzIFHBaiqRQGxWpf4OgVToOArQkUyLHw7yvDcNBa+NkhdiE5syXi f+JkvFrsJxzLSiH1GvYyBoeeHfMF9okdXmmjVzBiHFigkSo5ktCoidHer0/q0gVLwY4CAAAA AAAA --------------ms010407020105040705010500-- From beaton@google.com Wed Jun 1 12:06:32 2011 Return-Path: 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 2E85FE089A for ; Wed, 1 Jun 2011 12:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ljmJigjniU for ; Wed, 1 Jun 2011 12:06:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5154EE0711 for ; Wed, 1 Jun 2011 12:06:31 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p51J6U6w010879 for ; Wed, 1 Jun 2011 12:06:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306955190; bh=SMSbhJuwOBR5k7jpfnvtp+bUoy4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JW1ZLum6bR4+7Ssc45GFH6pVNLkDgpC3ANMGB5okd+Y+kJiqeRMuUgNJbVwlJMdGB 4zTxybe1FkjbznjidbQIw== Received: from pve37 (pve37.prod.google.com [10.241.210.37]) by wpaz21.hot.corp.google.com with ESMTP id p51J5bf1015999 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 12:06:29 -0700 Received: by pve37 with SMTP id 37so67396pve.21 for ; Wed, 01 Jun 2011 12:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MjrmFBbsp6oESFpBgtArN3B3lCTYcZpb8ZUpf66tmJ4=; b=GLHcRk6UFhuvALDnKGt/dHHuoZBZuWH7a/twTXIShq5D+LbFWQgY74sxAvHGJlJHo2 qVlud+q2ICabHJHQ3cZg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T4OBtDXUA1rb+oDqm4yidAsogXQAy3/hC5y7XalG0R0kbPgwbWtNuE6H08ojf11Pyx khCKasBQ7NAjTLu6k26A== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr1329166wff.266.1306955188998; Wed, 01 Jun 2011 12:06:28 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Wed, 1 Jun 2011 12:06:28 -0700 (PDT) In-Reply-To: <4DE68847.8090808@stpeter.im> References: <4DE68847.8090808@stpeter.im> Date: Wed, 1 Jun 2011 12:06:28 -0700 Message-ID: From: Brian Eaton To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd2df40c7161c04a4ab3748 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:06:32 -0000 --000e0cd2df40c7161c04a4ab3748 Content-Type: text/plain; charset=ISO-8859-1 Hey Peter - I haven't read all of your comments yet, but I wanted to clarify one point about client impersonation and installed apps. The cuirrent text is unrealistic, but your request would push it the wrong way. CC'ing Torsten as well. --------------------- OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? --------------------- We are most definitely recommending that clients that have no way of authenticating are issued long-lived credentials to access user data. Most installed applications work as follows: - they ask the user for their password - they save the password to disk That's a horrible security problem, because it means you cannot upgrade user authentication to anything stronger than a password. Client certificates, one time passwords, risk based authentication, throw it all out the window. If you're going to let installed apps authenticate with just a password, nothing else you do to improve authentication is going to help. This is a blocking issue for rolling out stronger forms of user authentication, and it's one of the main reasons I care about OAuth2. Think IMAP and XMPP clients running on Windows desktops. They are important, and we need a way to migrate them off of saving passwords. So the current text basically says that you should issue temporary credentials to native apps. That's not practical. Native apps end up needing permanent or near-permanent credentials. Expirations need to be measured in months. And the credentials are going to be issued to stock IMAP and XMPP clients that don't have any way of authenticating themselves. The advantage with OAuth2 over passwords is that a) the refresh tokens are unguessable. b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they are restricted to authorization servers. c) if you've got a managed machine (think Kerberos logins), you can create flows that bridge from those managed credentials to temporary access credentials. Cheers, Brian --000e0cd2df40c7161c04a4ab3748 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Peter -=A0

I haven't read all of your= comments yet, but I wanted to clarify one point about client impersonation= and installed apps. =A0The cuirrent text is unrealistic, but your request = would push it the wrong way. =A0CC'ing Torsten as well.

---------------------
OLD:
=A0 The authorization server SHOULD issue access tokens with limited
=A0= scope and duration to clients incapable of authenticating.

NEW:
= =A0 If the authorization server issues access tokens to clients
=A0 that= are incapable of authenticating, the scope and duration of
=A0 such tokens SHOULD be limited.

RATIONALE: We're not actively= RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recom= mending that clients that have no way of authenticating are issued long-liv= ed credentials to access user data.

Most installed= applications work as follows:
- they ask the user for their password
- they save the passw= ord to disk

That's a horrible security problem= , because it means you cannot upgrade user authentication to anything stron= ger than a password. =A0Client certificates, one time passwords, risk based= authentication, throw it all out the window. =A0If you're going to let= installed apps authenticate with just a password, nothing else you do to i= mprove authentication is going to help.

This is a blocking issue for rolling out stronger forms= of user authentication, and it's one of the main reasons I care about = OAuth2. =A0

Think IMAP and XMPP clients r= unning on Windows desktops. =A0They are important, and we need a way to mig= rate them off of saving passwords.

So the current text basically says that you should issue temporary credenti= als to native apps. =A0That's not practical. =A0Native apps end up need= ing permanent or near-permanent credentials. =A0Expirations need to be meas= ured in months. =A0And the credentials are going to be issued to stock IMAP= and XMPP clients that don't have any way of authenticating themselves.=

The advantage with OAuth2 over passwords is that
<= div>a) the refresh tokens are unguessable.
b) the refresh tokens = aren't sent directly to the IMAP and XMPP servers, they are restricted = to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you ca= n create flows that bridge from those managed credentials to temporary acce= ss credentials.

Cheers,
Brian
--000e0cd2df40c7161c04a4ab3748-- From skylar@kiva.org Wed Jun 1 12:17:53 2011 Return-Path: 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 65729E0814 for ; Wed, 1 Jun 2011 12:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.657 X-Spam-Level: X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1V9bJOnST2B for ; Wed, 1 Jun 2011 12:17:52 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 641C1E0711 for ; Wed, 1 Jun 2011 12:17:52 -0700 (PDT) Received: from mail-ww0-f48.google.com ([74.125.82.48]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKTeaQX8EIL8Z+2SWROSS2g0lGlTjw3MP9@postini.com; Wed, 01 Jun 2011 12:17:52 PDT Received: by mail-ww0-f48.google.com with SMTP id 18so95375wwi.5 for ; Wed, 01 Jun 2011 12:17:51 -0700 (PDT) Received: by 10.227.179.142 with SMTP id bq14mr3260270wbb.85.1306955870473; Wed, 01 Jun 2011 12:17:50 -0700 (PDT) Received: from [78.250.155.253] ([78.250.155.253]) by mx.google.com with ESMTPS id et5sm948994wbb.67.2011.06.01.12.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 12:17:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 1 Jun 2011 21:17:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE5EE7F.4040907@lodderstedt.net> To: Brian Eaton X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:17:53 -0000 On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote: >> (Some web apps might not be able to keep secrets based on open = development or deployment model). >=20 > Can you clarify what you mean by this? Simple really, I just mean for some developers it might be more = important to have an open development model (eg, over github) than to = secure secrets. Rather than request and manage a secret for their = project, they just choose to make the project a forgeable app. Let's say = it's a Rails app deployed to Heroku and for convenience the team doesn't = want to add a build step where a protected secret is brought down from a = private repo. It's not a native app, but because of how the team works = they can't (or won't) secure a secret. What's in production is exactly = whats in a public github branch. Systems like Heroku are blurring the line between source control and = deployment. So you can imagine 3rd party apps, especially voluntary = contributions and hack day output being totally transparent from code to = server. For some web apps it just won't be a priority to secure a = secret. That's all I'm implying. From mark.mcgloin@ie.ibm.com Wed Jun 1 12:25:22 2011 Return-Path: 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 3F390130055 for ; Wed, 1 Jun 2011 12:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9P24v4jc1Ae for ; Wed, 1 Jun 2011 12:25:20 -0700 (PDT) Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA8130052 for ; Wed, 1 Jun 2011 12:22:25 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p51JMNEO031019 for ; Wed, 1 Jun 2011 19:22:23 GMT Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51JMNb32257144 for ; Wed, 1 Jun 2011 20:22:23 +0100 Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51JMM4w024313 for ; Wed, 1 Jun 2011 13:22:22 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51JMMF5024309 for ; Wed, 1 Jun 2011 13:22:22 -0600 In-Reply-To: <1306883864.84178.YahooMailNeo@web31810.mail.mud.yahoo.com> References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org> <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1306883864.84178.YahooMailNeo@web31810.mail.mud.yahoo.com> X-KeepSent: 3751DD78:C84B8770-802578A2:0069F4AC; type=4; name=$KeepSent To: "William J. Mills" X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 1 Jun 2011 20:21:45 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/06/2011 20:21:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:25:22 -0000 Hi William Agree it is a good definition but I am not sure we need to spell out more details as we are trying to keep this section tight. Developers can look up CSRF if they are unsure. However, I will add the example of how it can happen Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated _(e.g., via HTTP redirects or HTML forms)_. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Regards Mark "William J. Mills" wrote on 01/06/2011 00:17:44: > From: > > "William J. Mills" > > To: > > Mark Mcgloin/Ireland/IBM@IBMIE, "oauth@ietf.org" > > Date: > > 01/06/2011 00:17 > > Subject: > > Re: [OAUTH-WG] Draft 16 Security Considerations additions > > http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF > definition, which I think is clearer. Perhaps that can be used to > touch up your first paragraph? > > From: Mark Mcgloin > To: oauth@ietf.org > Sent: Tuesday, May 31, 2011 1:58 PM > Subject: [OAUTH-WG] Draft 16 Security Considerations additions > > Eran > > Here are some additional sections to add to the next draft under security > considerations > > CSRF > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from a user that the website trusts or has > authenticated. CSRF attacks on OAuth approvals can allow an attacker to > obtain authorization to OAuth Protected Resources without the consent of > the User. > The state parameter should be used to mitigate against CSRF attacks, > particularly for login CSRF attacks. It is strongly RECOMMENDED that the > client sends the state parameter with authorization requests to the > authorization server. The authorization server will send it in the response > when redirecting the user to back to the client which SHOULD then validate > the state parameter matches on the response. > > Clickjacking > Clickjacking is the process of tricking users into revealing confidential > information or taking control of their computer while clicking on seemingly > innocuous web pages. In more detail, a malicious site loads the target site > in a transparent iframe overlaid on top of a set of dummy buttons which are > carefully constructed to be placed directly under important buttons on the > target site. When a user clicks a visible button, they are actually > clicking a button (such as an "Authorize" button) on the hidden page. > To prevent clickjacking (and phishing attacks), native applications SHOULD > use external browsers instead of embedding browsers in an iFrame when > requesting end-user authorization. For newer browsers, avoidance of iFrames > can be enforced server side by using the X-FRAME-OPTION header. This header > can have two values, deny and sameorigin, which will block any framing or > framing by sites with a different origin, respectively. For older browsers, > javascript framebusting techniques can be used but may not be effective in > all browsers. > > > Regards > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From skylar@kiva.org Wed Jun 1 12:25:26 2011 Return-Path: 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 7BE2413005F for ; Wed, 1 Jun 2011 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.653 X-Spam-Level: X-Spam-Status: No, score=-6.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCbjOreImx6a for ; Wed, 1 Jun 2011 12:25:25 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id A105A13006C for ; Wed, 1 Jun 2011 12:24:24 -0700 (PDT) Received: from mail-ww0-f43.google.com ([74.125.82.43]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKTeaR4qR/QUB9X/2pJPVGCl0CeVcqOMBl@postini.com; Wed, 01 Jun 2011 12:24:24 PDT Received: by wwb17 with SMTP id 17so120769wwb.12 for ; Wed, 01 Jun 2011 12:24:17 -0700 (PDT) Received: by 10.227.195.4 with SMTP id ea4mr7793451wbb.76.1306956257105; Wed, 01 Jun 2011 12:24:17 -0700 (PDT) Received: from [78.250.155.253] ([78.250.155.253]) by mx.google.com with ESMTPS id fw15sm959401wbb.10.2011.06.01.12.24.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 12:24:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 1 Jun 2011 21:24:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> References: <4DE5EE7F.4040907@lodderstedt.net> To: Dave Nelson X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:25:26 -0000 The group is operating under the assumption that most native apps are = publicly deployed or that copies of the app bundle/binary can at least = be obtained by a malicious party. Whether and open system or a high = protected system like Playstation 3 its always possible for the attacker = to disassemble the program and obtain the secret. The secret is the key = to an app proving its identity, so as soon as an attacker obtains the = secret it can forge the identity of an app in so far as the OAuth auth = server is concerned. On Jun 1, 2011, at 7:17 PM, Dave Nelson wrote: >> Most native apps will be forgeable ... >=20 > I don't understand the rationale behind this assertion. Would you > please point me to the discussion that elaborates on this point. > Thanks! >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 From dnelson@elbrys.com Wed Jun 1 12:44:00 2011 Return-Path: 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 8D43813006C for ; Wed, 1 Jun 2011 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvgqONRkbAZI for ; Wed, 1 Jun 2011 12:44:00 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id CEEBD130048 for ; Wed, 1 Jun 2011 12:43:59 -0700 (PDT) Received: from mail-yx0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTeaWfsJUZujJll4e0jsmsEmZczFaweYa@postini.com; Wed, 01 Jun 2011 12:43:59 PDT Received: by mail-yx0-f180.google.com with SMTP id 1so88356yxe.11 for ; Wed, 01 Jun 2011 12:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.189.41 with SMTP id b29mr9422732yhn.251.1306957438007; Wed, 01 Jun 2011 12:43:58 -0700 (PDT) Received: by 10.236.161.40 with HTTP; Wed, 1 Jun 2011 12:43:57 -0700 (PDT) In-Reply-To: <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> Date: Wed, 1 Jun 2011 15:43:57 -0400 Message-ID: From: Dave Nelson To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:44:00 -0000 > The group is operating under the assumption that most > native apps are publicly deployed or that copies of the > app bundle/binary can at least be obtained by a malicious > party. Agreed. > ... its always possible for the attacker to disassemble the > program and obtain the secret. Always possible? In theory, perhaps. As with any threat analysis, it depends on the resources available to the attacker and the motivations for mounting the attack. I firmly believe that secrets can be sufficiently obfuscated in code delivered in binary format without the benefit of a symbol table, so as to be sufficiently resistant to discovery via disassembly by attackers you'd expect to encounter in a typical commercial environment. I'm not talking about printable strings stored in contiguous memory. I think it's important, for a number of use cases, some of them of particular interest to me, for an application to be able to use this form of identification, when sufficient care has been taken to mitigate the threat model for the intended use. I'd rather see the risks inherent in providing secure storage of application credentials thoroughly discussed in the Security Considerations section, rather than discouraging it's use altogether in the normative protocol definition sections of the draft. I agree that there are many deployment scenarios in which secrets or passwords would not be an appropriate method of client identification, but I see some in which is clearly would be appropriate. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From skylar@kiva.org Wed Jun 1 13:07:44 2011 Return-Path: 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 248D0E08BD for ; Wed, 1 Jun 2011 13:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b0KkSCCUH2z for ; Wed, 1 Jun 2011 13:07:43 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id BD97FE07E4 for ; Wed, 1 Jun 2011 13:07:21 -0700 (PDT) Received: from mail-ww0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTeab+XKDZoSZio6sfdQlcIMIne75s7S2@postini.com; Wed, 01 Jun 2011 13:07:21 PDT Received: by mail-ww0-f41.google.com with SMTP id 18so3826481wwi.4 for ; Wed, 01 Jun 2011 13:07:20 -0700 (PDT) Received: by 10.227.12.18 with SMTP id v18mr7826704wbv.72.1306958840857; Wed, 01 Jun 2011 13:07:20 -0700 (PDT) Received: from [78.250.155.253] ([78.250.155.253]) by mx.google.com with ESMTPS id c17sm974642wbh.63.2011.06.01.13.07.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 13:07:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 1 Jun 2011 22:07:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> To: Dave Nelson X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:07:44 -0000 On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote: > for mounting the attack. I firmly believe that secrets can be > sufficiently obfuscated in code delivered in binary format without the > benefit of a symbol table, so as to be sufficiently resistant to > discovery via disassembly by attackers you'd expect to encounter in a > typical commercial environment. I'm not talking about printable I have empirical evidence to support this. At Yahoo! we devised one of = the most complex systems I've ever seen in a publicly distributed = program (Messenger). It was disassembled in 3 days. Scott Renfro (now = over with David at Facebook) and likely Bill Mills can also vouch for = the difficulty of this having also studied the case well. Moreover if a hardware-enforced system like that of Playstation 3 can be = broken, then so can most systems. The PS3 protection mechanisms are/were = very sophisticated. Even if a system is not yet cracked or is very hard, you have to assume = it can be cracked. History has shown this to be true nearly without = exception - at least to the point it is not worth considering for the = OAuth use cases. skylar From Michael.Jones@microsoft.com Wed Jun 1 13:14:41 2011 Return-Path: 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 77368E08A4 for ; Wed, 1 Jun 2011 13:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.71 X-Spam-Level: X-Spam-Status: No, score=-10.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbKS51OZ8inF for ; Wed, 1 Jun 2011 13:14:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 34E4FE06E9 for ; Wed, 1 Jun 2011 13:14:40 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 1 Jun 2011 13:14:34 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0289.008; Wed, 1 Jun 2011 13:14:34 -0700 From: Mike Jones To: David Recordon , George Fletcher Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type Thread-Index: AQHMEGLvUtk/Y41LJU+xw7NH/M+2opSa0CjQgAgtbYCABOk9gIAAwn+AgABmmeA= Date: Wed, 1 Jun 2011 20:14:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:14:41 -0000 If you can drive a consensus decision for the name "access_token", I'd be g= lad to change the name in the spec. I agree that the current names are con= fusing for developers. -- Mike -----Original Message----- From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Wednesday, June 01, 2011 12:06 AM To: George Fletcher Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan Subject: Re: [OAUTH-WG] consistency of token param name in bearer token typ= e Yeah, can understand how we got here. Just found it quite confusing when re= ading these two specifications together with an implementor's hat on. On Tue, May 31, 2011 at 12:29 PM, George Fletcher wrote: > Brief pointer to the "history" of this change. This change was adopted=20 > in draft 4 of the bearer spec as there were concerns with the previous=20 > parameter name of 'oauth_token'. The suggestion was made to use=20 > 'bearer_token' so that it matches the scheme used in the Authorization=20 > header. The thinking being that reading the bearer token spec would=20 > seem weird if the Authorization header used one name and the GET/POST=20 > methods used a different name. > > The 'bearer_token' name got a few +1 and no dissents. > > Full thread starts here [1]. Mike accepting the 'bearer_token' > recommendation is here [2]. > > Thanks, > George > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html > > On 5/28/11 12:30 PM, David Recordon wrote: > > Did a full read through of draft 16 and the bear token spec with Paul=20 > yesterday afternoon in order to do a manual diff from draft 10. The=20 > point Doug raised was actually confusing. Throughout the core spec=20 > it's referred to as access_token but then becomes bearer_token upon=20 > use. > > Just thinking through this from a developer documentation perspective,=20 > it's going to become confusing. Developer documentation focuses on=20 > getting an access token and then using that access token to interact=20 > with an API. Thus the code you're writing as a client developer will=20 > use variables, cache keys, and database columns named `access_token`. > But then when you're going to use it, you'll need to put this access=20 > token into a field named bearer_token. > > Feels quite a bit simpler to just name it access_token. Realize the=20 > core spec never did this since we didn't want to trample on protected=20 > resources which might already have a different type of access_token=20 > parameter. oauth_token was a good compromise since developers would=20 > already know that they were using OAuth and thus a new term wasn't=20 > being introduced. That's no longer true with bearer_token since 99% of=20 > developers will have never heard of a bearer token. > > Googling for "bearer token" turns up Eran's blog post titled "OAuth=20 > Bearer Tokens are a Terrible Idea" and there isn't a single result on=20 > the first page which explains what they are. Binging for "bearer=20 > token" is equally scary. > > --David > > > On Mon, May 23, 2011 at 11:38 AM, Mike Jones=20 > wrote: > > The working group explicitly decided that a different name should be=20 > used, to make it clear that other token types other than bearer tokens=20 > could also be used with OAuth 2. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Doug Tangren > Sent: Wednesday, May 11, 2011 10:09 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] consistency of token param name in bearer token=20 > type > > > > This may have come up before so I'm sorry if I'm repeating. Why does=20 > bearer token spec introduce a new name for oauth2 access tokens [1],=20 > "bearer_token", and before that [2], "oauth_token"? > > > > I=A0apologize=A0if this may sound shallow but, why introduce a new=20 > parameter name verses sticking with what the general oauth2 spec=20 > already defines, "access_token". It seems arbitrary for an auth server=20 > to hand a client an apple then have the client hand it off to the=20 > resource server and call it an orange. > > > > Was this just for the sake of differentiating the parameter name=20 > enough so that the bearer tokens may be used in other protocols=20 > without being confused with oauth2 access_tokens? > > > > [1]:=A0 > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 > > [2]:=A0 > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 > > > > -Doug Tangren > http://lessis.me > > _______________________________________________ > 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 > > > -- > Chief Architect AIM: gffletch > Identity Services Engineering Work: george.fletcher@teamaol.com > AOL Inc. Home: gffletch@aol.com > Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com > Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch > From cmortimore@salesforce.com Wed Jun 1 13:59:42 2011 Return-Path: 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 10900E0813 for ; Wed, 1 Jun 2011 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awJoClbSWcLo for ; Wed, 1 Jun 2011 13:59:40 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with SMTP id F142DE07CF for ; Wed, 1 Jun 2011 13:59:39 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKTeaoOt29xwSDBxkd6c0+JGpRiP5QV8fH@postini.com; Wed, 01 Jun 2011 13:59:40 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Wed, 1 Jun 2011 13:59:38 -0700 From: Chuck Mortimore To: Skylar Woodward , Brian Eaton Date: Wed, 1 Jun 2011 13:59:36 -0700 Thread-Topic: [OAUTH-WG] Text for Native Applications Thread-Index: AcwgkKC4tdATbuIkRHK2RGfHsHvG0gADi+qD Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA0BF6481AC35cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:59:42 -0000 --_000_CA0BF6481AC35cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We don't at all this recommend this type of deployment model for Heroku ( o= r any platform for that manner ). We support injecting environment vari= ables at runtime to avoid this problem. Example: $ heroku config:add S3_KEY=3D8N029N81 S3_SECRET=3D9s83109d3+583493190 Adding config vars: S3_KEY =3D> 8N029N81 S3_SECRET =3D> 9s83109d3+583493190 Restarting app...done. AWS::S3::Base.establish_connection!( :access_key_id =3D> ENV['S3_KEY'], :secret_access_key =3D> ENV['S3_SECRET'] ) I know Heroku isn't your specific gripe here, but I think it's important th= at we focus on providing guidance and a secure path for teams and platforms= that are doing the right thing. -cmort On 6/1/11 12:17 PM, "Skylar Woodward" wrote: On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote: >> (Some web apps might not be able to keep secrets based on open developme= nt or deployment model). > > Can you clarify what you mean by this? Simple really, I just mean for some developers it might be more important t= o have an open development model (eg, over github) than to secure secrets. = Rather than request and manage a secret for their project, they just choose= to make the project a forgeable app. Let's say it's a Rails app deployed t= o Heroku and for convenience the team doesn't want to add a build step wher= e a protected secret is brought down from a private repo. It's not a native= app, but because of how the team works they can't (or won't) secure a secr= et. What's in production is exactly whats in a public github branch. Systems like Heroku are blurring the line between source control and deploy= ment. So you can imagine 3rd party apps, especially voluntary contributions= and hack day output being totally transparent from code to server. For som= e web apps it just won't be a priority to secure a secret. That's all I'm i= mplying. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA0BF6481AC35cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Text for Native Applications We don’t = at all this recommend this type of deployment model for Heroku ( or any pla= tform for that manner ).     We support injecting envir= onment variables at runtime to avoid this problem.

Example:

$ heroku config:add S3_KEY=3D8N029N81 S3_SECRET=3D9s83109= d3+583493190
Adding config vars:
  S3_KEY    =3D> 8N029N81
  S3_SECRET =3D> 9s83109d3+583493190
Restarting app...done.

AWS::S3::Base.establish_connection!(
  = :access_key_id     =3D> ENV['S3_KEY'],   = :secret_access_key =3D> ENV[= 'S3_SECRET'<= /FONT>]
)

I know Heroku isn’t your specific gripe here, but I think it’s = important that we focus on providing guidance and a secure path for teams a= nd platforms that are doing the right thing.

-cmort


On 6/1/11 12:17 PM, "Skylar Woodward" <skylar@kiva.org> wrote:

On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote:

>> (Some web apps might not be able to keep secrets based on open dev= elopment or deployment model).
>
> Can you clarify what you mean by this?

Simple really, I just mean for some developers it might be more important t= o have an open development model (eg, over github) than to secure secrets. = Rather than request and manage a secret for their project, they just choose= to make the project a forgeable app. Let's say it's a Rails app deployed t= o Heroku and for convenience the team doesn't want to add a build step wher= e a protected secret is brought down from a private repo. It's not a native= app, but because of how the team works they can't (or won't) secure a secr= et. What's in production is exactly whats in a public github branch.

Systems like Heroku are blurring the line between source control and deploy= ment. So you can imagine 3rd party apps, especially voluntary contributions= and hack day output being totally transparent from code to server. For som= e web apps it just won't be a priority to secure a secret. That's all I'm i= mplying.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_CA0BF6481AC35cmortimoresalesforcecom_-- From skylar@kiva.org Wed Jun 1 16:20:21 2011 Return-Path: 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 D5537E0886 for ; Wed, 1 Jun 2011 16:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLwQPJSEx-6W for ; Wed, 1 Jun 2011 16:20:20 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 109B3E085D for ; Wed, 1 Jun 2011 16:20:19 -0700 (PDT) Received: from mail-wy0-f172.google.com ([74.125.82.172]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKTebJMtNeQ1wzMLS/51SEdVhIHtLiIMdQ@postini.com; Wed, 01 Jun 2011 16:20:20 PDT Received: by wyb29 with SMTP id 29so354865wyb.17 for ; Wed, 01 Jun 2011 16:20:17 -0700 (PDT) Received: by 10.227.5.205 with SMTP id 13mr63209wbw.31.1306970417523; Wed, 01 Jun 2011 16:20:17 -0700 (PDT) Received: from [78.250.155.253] ([78.250.155.253]) by mx.google.com with ESMTPS id gb6sm23260wbb.34.2011.06.01.16.20.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 16:20:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Skylar Woodward In-Reply-To: Date: Thu, 2 Jun 2011 01:20:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <005CFD91-A60C-4893-831B-79888A8AAAE7@kiva.org> References: To: Chuck Mortimore X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 23:20:22 -0000 Sure, but at the same time, imagine the context of a hackathon event = where people certainly make use of OAuth APIs and put very low priority = on security. It's bound to happen (and in fact, quick experimental apps = like these often consume the bulk of registered client IDs - as opposed = to sustained efforts with significant resources). Such apps should see = themselves as forgeable and not able (or willing) to keep secrets. But your point is valid. Apps that *can* keep secrets should make the = effort to do so and providers should encourage this behavior for most = apps. At the same time I don't see much difference between building a native = client or a secret-less web client, so long as the clients enjoy = equivalent (lack of) privilege/trust and precautions on a part of the = provider. For our provider we reserve some types of access only to = clients that can keep secrets. On Jun 1, 2011, at 10:59 PM, Chuck Mortimore wrote: > We don=92t at all this recommend this type of deployment model for = Heroku ( or any platform for that manner ). We support injecting = environment variables at runtime to avoid this problem. >=20 > Example: >=20 > $ heroku config:add S3_KEY=3D8N029N81 S3_SECRET=3D9s83109d3+583493190 > Adding config vars: > S3_KEY =3D> 8N029N81 > S3_SECRET =3D> 9s83109d3+583493190 > Restarting app...done. >=20 > AWS::S3::Base.establish_connection!( > :access_key_id =3D> ENV['S3_KEY'], > :secret_access_key =3D> ENV['S3_SECRET'] > ) >=20 > I know Heroku isn=92t your specific gripe here, but I think it=92s = important that we focus on providing guidance and a secure path for = teams and platforms that are doing the right thing. >=20 > -cmort >=20 >=20 > On 6/1/11 12:17 PM, "Skylar Woodward" wrote: >=20 > On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote: >=20 > >> (Some web apps might not be able to keep secrets based on open = development or deployment model). > > > > Can you clarify what you mean by this? >=20 > Simple really, I just mean for some developers it might be more = important to have an open development model (eg, over github) than to = secure secrets. Rather than request and manage a secret for their = project, they just choose to make the project a forgeable app. Let's say = it's a Rails app deployed to Heroku and for convenience the team doesn't = want to add a build step where a protected secret is brought down from a = private repo. It's not a native app, but because of how the team works = they can't (or won't) secure a secret. What's in production is exactly = whats in a public github branch. >=20 > Systems like Heroku are blurring the line between source control and = deployment. So you can imagine 3rd party apps, especially voluntary = contributions and hack day output being totally transparent from code to = server. For some web apps it just won't be a priority to secure a = secret. That's all I'm implying. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From mnot@mnot.net Wed Jun 1 17:15:48 2011 Return-Path: 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 A3002E0758; Wed, 1 Jun 2011 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[AWL=-2.511, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrE3nCJNmr6D; Wed, 1 Jun 2011 17:15:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76EE06EB; Wed, 1 Jun 2011 17:15:47 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5BC68509DB; Wed, 1 Jun 2011 20:15:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 2 Jun 2011 10:15:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:15:48 -0000 On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: > This was suggested before, but are there really attack vectors for = this? If not having a current, working attack to demonstrate is a valid way to = shrug off a security concern, that's great; it'll be a useful approach = to many of the discussions I have. :) > The problem is that content-type is a pretty flexible header, which = means normalization of the header will be required (case, parameter = order, white space, etc.). The media type is the important part, and it's much more constrained. > I would argue that if you are using MAC with body hash and an attacker = changing the media type can cause harm, you should use additional = methods to secure the content-type (such as making the body = self-describing). That seems like a step backwards, considering all of the work that Adam = has put into limiting the use of sniffing. Cheers, -- Mark Nottingham http://www.mnot.net/ From ietf@adambarth.com Wed Jun 1 18:26:27 2011 Return-Path: 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 F01C4E0796; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4q+OLj2WaGw; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 487D1E06A0; Wed, 1 Jun 2011 18:26:26 -0700 (PDT) Received: by yxk30 with SMTP id 30so203231yxk.31 for ; Wed, 01 Jun 2011 18:26:25 -0700 (PDT) Received: by 10.151.5.14 with SMTP id h14mr168197ybi.182.1306977985636; Wed, 01 Jun 2011 18:26:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id p23sm81293ybc.29.2011.06.01.18.26.24 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 18:26:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so206066gyf.31 for ; Wed, 01 Jun 2011 18:26:24 -0700 (PDT) Received: by 10.91.103.14 with SMTP id f14mr155271agm.125.1306977984068; Wed, 01 Jun 2011 18:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Wed, 1 Jun 2011 18:25:54 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Adam Barth Date: Wed, 1 Jun 2011 18:25:54 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , Ben Adida , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 01:26:27 -0000 On Wed, Jun 1, 2011 at 5:15 PM, Mark Nottingham wrote: > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >> This was suggested before, but are there really attack vectors for this? > > If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :) > > >> The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.). > > The media type is the important part, and it's much more constrained. > > >> I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing). > > That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing. Yeah, I tried to twist Eran's arm into including the media type in the body hash too. It's probably more important for responses than requests, however. Adam From matiasw@gmail.com Wed Jun 1 19:54:49 2011 Return-Path: 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 18095E0678 for ; Wed, 1 Jun 2011 19:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnseCiRnJLmL for ; Wed, 1 Jun 2011 19:54:48 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 937CDE065B for ; Wed, 1 Jun 2011 19:54:45 -0700 (PDT) Received: by pwi5 with SMTP id 5so340315pwi.31 for ; Wed, 01 Jun 2011 19:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/xHN6/RmtWBebWj6PrdG9jbRc9texyD6dY8t4OoUjQ0=; b=tvDGv4U8b60hP4CLJa0mPU27ZsjqU65FYmuSzoC6MNeSF/tgGMzn0++oMrCZ54F7oF F4evZ083Nl5SQ8r6X+8ufyfIPnMvINPlr7bqvlGiLICJSb/nZtVk+BRwlgNu+IK8BkEs o1BFwPXNayDTj6cgGaTo8ouFScrbtph8p7i2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F3YufvfVXslI4nD9nlTeT5spzXLAZ17GkMxMZ0xjcd/bsq3XuUIWP6XdEvmt5DLm4/ ojjza4H+f9Bmi2jM7lFr3KWVv2tYRn6SHsKDA0ODE+knsRcB9iy1mf5FLqWUXni+iBgU Asy8O3dFyncs2GAvoB1V8USmQYT8jJlGKaaCQ= MIME-Version: 1.0 Received: by 10.68.26.72 with SMTP id j8mr82293pbg.213.1306983285337; Wed, 01 Jun 2011 19:54:45 -0700 (PDT) Received: by 10.68.54.230 with HTTP; Wed, 1 Jun 2011 19:54:45 -0700 (PDT) Date: Wed, 1 Jun 2011 23:54:45 -0300 Message-ID: From: Matias Woloski To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=bcaec5215d8f732d4b04a4b1c275 Subject: [OAUTH-WG] Getting the authorization code - Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 03:00:30 -0000 --bcaec5215d8f732d4b04a4b1c275 Content-Type: text/plain; charset=ISO-8859-1 I've read the latest spec and some of the discussions around the user-agent flow and native apps. I've read about the different options to get the authz code (copy-paste, polling the title of the window, custom scheme, etc). I might be missing something but my question is: why can't we send a nonce in the initial request to the authz server and have the client app polling an endpoint until the authz code is generated and associated to that nonce? Why that is not a possible approach to get the authz code in the native client? Is it because the authz server might get several requests during the app polling? Or I am missing some security issue (assuming this all goes through TLS)? Thanks, Matias --bcaec5215d8f732d4b04a4b1c275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've read the latest spec and some of the discussions around the user-a= gent flow and native apps. I've read about the different options to get= the authz code (copy-paste, polling the title of the window, custom scheme= , etc).=A0

I might be missing something but my question is: why can'= ;t we send a nonce in the initial request to the authz server and have the = client app polling an endpoint until the authz code is generated and associ= ated to that nonce? Why that is not a possible approach to get the authz co= de in the native client? Is it because the authz server might get several r= equests during the app polling? Or I am missing some security issue (assumi= ng this all goes through TLS)?

Thanks,
Matias
--bcaec5215d8f732d4b04a4b1c275-- From torsten@lodderstedt.net Thu Jun 2 01:54:22 2011 Return-Path: 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 2AAE8E0704 for ; Thu, 2 Jun 2011 01:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu0xxCJeIZa8 for ; Thu, 2 Jun 2011 01:54:21 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 38226E0671 for ; Thu, 2 Jun 2011 01:54:20 -0700 (PDT) Received: from [79.253.17.180] (helo=[192.168.71.27]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QS3fW-0004pW-DW; Thu, 02 Jun 2011 10:54:18 +0200 Message-ID: <4DE74FBA.4040301@lodderstedt.net> Date: Thu, 02 Jun 2011 10:54:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Skylar Woodward References: <005CFD91-A60C-4893-831B-79888A8AAAE7@kiva.org> In-Reply-To: <005CFD91-A60C-4893-831B-79888A8AAAE7@kiva.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 08:54:22 -0000 I agree with Skylar. In the end, the most important point is how much the authorization server trusts the particular client and what privileges are associated with that client identity. In an open development model, I would not trust the client in the least and instead require the user to authorize access. Authenticity and trustworthiness of apps in general is not the task of an OAuth authorization server. I would put it the other way around. If a client wants/is supposed to have privileged access to resources (without or with less need for additional user authorization), it must be able authenticate itself in a reliable way. regards, Torsten. Am 02.06.2011 01:20, schrieb Skylar Woodward: > Sure, but at the same time, imagine the context of a hackathon event where people certainly make use of OAuth APIs and put very low priority on security. It's bound to happen (and in fact, quick experimental apps like these often consume the bulk of registered client IDs - as opposed to sustained efforts with significant resources). Such apps should see themselves as forgeable and not able (or willing) to keep secrets. > > But your point is valid. Apps that *can* keep secrets should make the effort to do so and providers should encourage this behavior for most apps. > > At the same time I don't see much difference between building a native client or a secret-less web client, so long as the clients enjoy equivalent (lack of) privilege/trust and precautions on a part of the provider. For our provider we reserve some types of access only to clients that can keep secrets. > > > > On Jun 1, 2011, at 10:59 PM, Chuck Mortimore wrote: > >> We don’t at all this recommend this type of deployment model for Heroku ( or any platform for that manner ). We support injecting environment variables at runtime to avoid this problem. >> >> Example: >> >> $ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190 >> Adding config vars: >> S3_KEY => 8N029N81 >> S3_SECRET => 9s83109d3+583493190 >> Restarting app...done. >> >> AWS::S3::Base.establish_connection!( >> :access_key_id => ENV['S3_KEY'], >> :secret_access_key => ENV['S3_SECRET'] >> ) >> >> I know Heroku isn’t your specific gripe here, but I think it’s important that we focus on providing guidance and a secure path for teams and platforms that are doing the right thing. >> >> -cmort >> >> >> On 6/1/11 12:17 PM, "Skylar Woodward" wrote: >> >> On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote: >> >>>> (Some web apps might not be able to keep secrets based on open development or deployment model). >>> Can you clarify what you mean by this? >> Simple really, I just mean for some developers it might be more important to have an open development model (eg, over github) than to secure secrets. Rather than request and manage a secret for their project, they just choose to make the project a forgeable app. Let's say it's a Rails app deployed to Heroku and for convenience the team doesn't want to add a build step where a protected secret is brought down from a private repo. It's not a native app, but because of how the team works they can't (or won't) secure a secret. What's in production is exactly whats in a public github branch. >> >> Systems like Heroku are blurring the line between source control and deployment. So you can imagine 3rd party apps, especially voluntary contributions and hack day output being totally transparent from code to server. For some web apps it just won't be a priority to secure a secret. That's all I'm implying. >> >> _______________________________________________ >> 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 From torsten@lodderstedt.net Thu Jun 2 01:59:57 2011 Return-Path: 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 4CECFE0720 for ; Thu, 2 Jun 2011 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4gEp4LcSCca for ; Thu, 2 Jun 2011 01:59:56 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF55E06AC for ; Thu, 2 Jun 2011 01:59:56 -0700 (PDT) Received: from [79.253.17.180] (helo=[192.168.71.27]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QS3kw-0002P0-8V; Thu, 02 Jun 2011 10:59:54 +0200 Message-ID: <4DE7510A.2000800@lodderstedt.net> Date: Thu, 02 Jun 2011 10:59:54 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Skylar Woodward References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> In-Reply-To: <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 08:59:57 -0000 Dave, Skylar, the assumption of the OAuth 2.0 security threat model (http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1) is that client secrets, which are distributed with applications, cannot reliably kept confidential. Therefore the advice is given to use other means to validate the client identity (e.g. user consent, platform security measures). I would highly appreciate if you would review this document and give us feedback. thanks in advance, Torsten. Am 01.06.2011 22:07, schrieb Skylar Woodward: > On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote: > >> for mounting the attack. I firmly believe that secrets can be >> sufficiently obfuscated in code delivered in binary format without the >> benefit of a symbol table, so as to be sufficiently resistant to >> discovery via disassembly by attackers you'd expect to encounter in a >> typical commercial environment. I'm not talking about printable > I have empirical evidence to support this. At Yahoo! we devised one of the most complex systems I've ever seen in a publicly distributed program (Messenger). It was disassembled in 3 days. Scott Renfro (now over with David at Facebook) and likely Bill Mills can also vouch for the difficulty of this having also studied the case well. > > Moreover if a hardware-enforced system like that of Playstation 3 can be broken, then so can most systems. The PS3 protection mechanisms are/were very sophisticated. > > Even if a system is not yet cracked or is very hard, you have to assume it can be cracked. History has shown this to be true nearly without exception - at least to the point it is not worth considering for the OAuth use cases. > > skylar > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Jun 2 02:09:47 2011 Return-Path: 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 8B6F9E0704 for ; Thu, 2 Jun 2011 02:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3-7PfW77IGy for ; Thu, 2 Jun 2011 02:09:46 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C3E062A for ; Thu, 2 Jun 2011 02:09:46 -0700 (PDT) Received: from [79.253.17.180] (helo=[192.168.71.27]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QS3uS-0008DA-TS; Thu, 02 Jun 2011 11:09:45 +0200 Message-ID: <4DE75359.6070109@lodderstedt.net> Date: Thu, 02 Jun 2011 11:09:45 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <4DE68847.8090808@stpeter.im> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010204020004080506080802" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 09:09:47 -0000 This is a multi-part message in MIME format. --------------010204020004080506080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I fully agree with Brian and would like to add some thoughts: Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Kerbereos has a concept of client authentication. In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the _user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches. regards, Torsten. Am 01.06.2011 21:06, schrieb Brian Eaton: > Hey Peter - > > I haven't read all of your comments yet, but I wanted to clarify one > point about client impersonation and installed apps. The cuirrent > text is unrealistic, but your request would push it the wrong way. > CC'ing Torsten as well. > > --------------------- > OLD: > The authorization server SHOULD issue access tokens with limited > scope and duration to clients incapable of authenticating. > > NEW: > If the authorization server issues access tokens to clients > that are incapable of authenticating, the scope and duration of > such tokens SHOULD be limited. > > RATIONALE: We're not actively RECOMMENDING authorization servers are to > issue such tokens, are we? > --------------------- > > We are most definitely recommending that clients that have no way of > authenticating are issued long-lived credentials to access user data. > > Most installed applications work as follows: > - they ask the user for their password > - they save the password to disk > > That's a horrible security problem, because it means you cannot > upgrade user authentication to anything stronger than a password. > Client certificates, one time passwords, risk based authentication, > throw it all out the window. If you're going to let installed apps > authenticate with just a password, nothing else you do to improve > authentication is going to help. > > This is a blocking issue for rolling out stronger forms of user > authentication, and it's one of the main reasons I care about OAuth2. > > Think IMAP and XMPP clients running on Windows desktops. They are > important, and we need a way to migrate them off of saving passwords. > > So the current text basically says that you should issue temporary > credentials to native apps. That's not practical. Native apps end up > needing permanent or near-permanent credentials. Expirations need to > be measured in months. And the credentials are going to be issued to > stock IMAP and XMPP clients that don't have any way of authenticating > themselves. > > The advantage with OAuth2 over passwords is that > a) the refresh tokens are unguessable. > b) the refresh tokens aren't sent directly to the IMAP and XMPP > servers, they are restricted to authorization servers. > c) if you've got a managed machine (think Kerberos logins), you can > create flows that bridge from those managed credentials to temporary > access credentials. > > Cheers, > Brian --------------010204020004080506080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the _user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter - 

I haven't read all of your comments yet, but I wanted to clarify one point about client impersonation and installed apps.  The cuirrent text is unrealistic, but your request would push it the wrong way.  CC'ing Torsten as well.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade user authentication to anything stronger than a password.  Client certificates, one time passwords, risk based authentication, throw it all out the window.  If you're going to let installed apps authenticate with just a password, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authentication, and it's one of the main reasons I care about OAuth2.  

Think IMAP and XMPP clients running on Windows desktops.  They are important, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credentials to native apps.  That's not practical.  Native apps end up needing permanent or near-permanent credentials.  Expirations need to be measured in months.  And the credentials are going to be issued to stock IMAP and XMPP clients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create flows that bridge from those managed credentials to temporary access credentials.

Cheers,
Brian
--------------010204020004080506080802-- From eran@hueniverse.com Thu Jun 2 08:46:19 2011 Return-Path: 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 452E1E07DD for ; Thu, 2 Jun 2011 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlbLaeAIxnLS for ; Thu, 2 Jun 2011 08:46:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5D76DE07FD for ; Thu, 2 Jun 2011 08:46:18 -0700 (PDT) Received: (qmail 11884 invoked from network); 2 Jun 2011 15:45:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Jun 2011 15:45:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 2 Jun 2011 08:45:04 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Thu, 2 Jun 2011 08:44:35 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: AcwgujliuTi4Kf4mRayjenHdrNw8EQAgXYFA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:46:19 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, June 01, 2011 5:16 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; > 'Adam Barth (adam@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >=20 >=20 > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >=20 > > This was suggested before, but are there really attack vectors for this= ? >=20 > If not having a current, working attack to demonstrate is a valid way to = shrug > off a security concern, that's great; it'll be a useful approach to many = of the > discussions I have. :) No, but its valid as long as it is fully documented. We're not going to sol= ve everything. > > The problem is that content-type is a pretty flexible header, which mea= ns > normalization of the header will be required (case, parameter order, whit= e > space, etc.). >=20 > The media type is the important part, and it's much more constrained. So include just the: type "/" subtype forced to lowercase? >=20 > > I would argue that if you are using MAC with body hash and an attacker > changing the media type can cause harm, you should use additional methods > to secure the content-type (such as making the body self-describing). >=20 >=20 > That seems like a step backwards, considering all of the work that Adam h= as > put into limiting the use of sniffing. I wasn't suggesting sniffing. EHL > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From zachary.zeltsan@alcatel-lucent.com Thu Jun 2 08:51:23 2011 Return-Path: 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 9D89AE07DD for ; Thu, 2 Jun 2011 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyqrIxG3Epme for ; Thu, 2 Jun 2011 08:51:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B8847E0805 for ; Thu, 2 Jun 2011 08:51:22 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p52FpKLu012558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 10:51:20 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52FpKpW005306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Jun 2011 10:51:20 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 2 Jun 2011 10:51:20 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Brian Eaton'" , Peter Saint-Andre Date: Thu, 2 Jun 2011 10:51:19 -0500 Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Thread-Index: AcwglGQaPTCm+5bmRJ6dd0Y9G4HQIQApDpVA Message-ID: <5710F82C0E73B04FA559560098BF95B12507584F01@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4DE68847.8090808@stpeter.im> In-Reply-To: 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_5710F82C0E73B04FA559560098BF95B12507584F01USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:51:23 -0000 --_000_5710F82C0E73B04FA559560098BF95B12507584F01USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Brian. One of the use cases that relies on the issuing tokens to an unauthenticate= d client is Mobile App (http://tools.ietf.org/html/draft-zeltsan-oauth-use-= cases-01#section-3.4). A use case's requirement is that "authorization shal= l be valid for a prolonged duration". Such long-term authorization relies = on the use of the refresh tokens. Zachary ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Wednesday, June 01, 2011 3:06 PM To: Peter Saint-Andre Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Hey Peter - I haven't read all of your comments yet, but I wanted to clarify one point = about client impersonation and installed apps. The cuirrent text is unreal= istic, but your request would push it the wrong way. CC'ing Torsten as wel= l. --------------------- OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? --------------------- We are most definitely recommending that clients that have no way of authen= ticating are issued long-lived credentials to access user data. Most installed applications work as follows: - they ask the user for their password - they save the password to disk That's a horrible security problem, because it means you cannot upgrade use= r authentication to anything stronger than a password. Client certificates= , one time passwords, risk based authentication, throw it all out the windo= w. If you're going to let installed apps authenticate with just a password= , nothing else you do to improve authentication is going to help. This is a blocking issue for rolling out stronger forms of user authenticat= ion, and it's one of the main reasons I care about OAuth2. Think IMAP and XMPP clients running on Windows desktops. They are importan= t, and we need a way to migrate them off of saving passwords. So the current text basically says that you should issue temporary credenti= als to native apps. That's not practical. Native apps end up needing perm= anent or near-permanent credentials. Expirations need to be measured in mo= nths. And the credentials are going to be issued to stock IMAP and XMPP cl= ients that don't have any way of authenticating themselves. The advantage with OAuth2 over passwords is that a) the refresh tokens are unguessable. b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th= ey are restricted to authorization servers. c) if you've got a managed machine (think Kerberos logins), you can create = flows that bridge from those managed credentials to temporary access creden= tials. Cheers, Brian --_000_5710F82C0E73B04FA559560098BF95B12507584F01USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Brian.
One of the use cases that relies on the issuing = tokens=20 to an unauthenticated client is Mobile App (http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01= #section-3.4).=20 A use case's requirement is that "authorization shall be valid for a=20 prolonged duration". Such long-term  authorization relies on = ;the=20 use of the refresh tokens. 
 
Zachary
 
From:=20 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Brian=20 Eaton
Sent: Wednesday, June 01, 2011 3:06 PM
To: Peter= =20 Saint-Andre
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review= of=20 draft-ietf-oauth-v2-16

Hey Peter - 

I haven't read all of your comments yet, but I wanted to clarify one p= oint=20 about client impersonation and installed apps.  The cuirrent text is=20 unrealistic, but your request would push it the wrong way.  CC'ing Tor= sten=20 as well.

---------------------
OLD:
 =20 The authorization server SHOULD issue access tokens with limited
  = scope=20 and duration to clients incapable of authenticating.

NEW:
  = If=20 the authorization server issues access tokens to clients
  that are= =20 incapable of authenticating, the scope and duration of
  such token= s=20 SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING=20 authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of=20 authenticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrad= e=20 user authentication to anything stronger than a password.  Client=20 certificates, one time passwords, risk based authentication, throw it all o= ut=20 the window.  If you're going to let installed apps authenticate with j= ust a=20 password, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user=20 authentication, and it's one of the main reasons I care about OAuth2.=20  

Think IMAP and XMPP clients running on Windows desktops.=20  They are important, and we need a way to migrate them off of saving=20 passwords.

So the current text basically says that you should issue temporary=20 credentials to native apps.  That's not practical.  Native apps e= nd up=20 needing permanent or near-permanent credentials.  Expirations need to = be=20 measured in months.  And the credentials are going to be issued to sto= ck=20 IMAP and XMPP clients that don't have any way of authenticating=20 themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP server= s,=20 they are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can cr= eate=20 flows that bridge from those managed credentials to temporary access=20 credentials.

Cheers,
Brian
--_000_5710F82C0E73B04FA559560098BF95B12507584F01USNAVSXCHMBSA_-- From mscurtescu@google.com Thu Jun 2 10:25:53 2011 Return-Path: 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 A530DE06FB for ; Thu, 2 Jun 2011 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUvUEXTM6Bfn for ; Thu, 2 Jun 2011 10:25:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 893B1E05D3 for ; Thu, 2 Jun 2011 10:25:52 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p52HPoAH007277 for ; Thu, 2 Jun 2011 10:25:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307035551; bh=cR0pUxRbp1tgJAs915rwq6kYiwQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TbTrF6L3/FOFb2p9KhXUCiQq3FnktZwXmzcrFLbCV9ojjEmjsuKezJvCNziHOjmzo 667GuVookjtmpZYckv61A== Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by kpbe12.cbf.corp.google.com with ESMTP id p52HOPSd010255 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 10:25:49 -0700 Received: by ywg8 with SMTP id 8so480530ywg.20 for ; Thu, 02 Jun 2011 10:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nG6+6HJ7mV2xfkL4gvN9xeKu4nV7AvdnNyXnCtyxAHY=; b=pkujAh4x4dqycVmYx0dq9E2ONUk7JQU3gptehi+dCqTAMBhLg+HqBckr8lVBd5qCUC OSK5wH/YHDEZfxN8fIQw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=LqXGToAzIp6eHsSCQVYnM4sTDSk0iKim3ejsxV0sV0zO53y1EWmqb+qdGGPQwT4TuX 7luAUXO9uQcqGzoBSgOQ== Received: by 10.101.19.8 with SMTP id w8mr654443ani.57.1307035549298; Thu, 02 Jun 2011 10:25:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.14.19 with HTTP; Thu, 2 Jun 2011 10:25:29 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 2 Jun 2011 10:25:29 -0700 Message-ID: To: Matias Woloski Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] Getting the authorization code - Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:25:53 -0000 On Wed, Jun 1, 2011 at 7:54 PM, Matias Woloski wrote: > I've read the latest spec and some of the discussions around the user-agent > flow and native apps. I've read about the different options to get the authz > code (copy-paste, polling the title of the window, custom scheme, etc). > I might be missing something but my question is: why can't we send a nonce > in the initial request to the authz server and have the client app polling > an endpoint until the authz code is generated and associated to that nonce? > Why that is not a possible approach to get the authz code in the native > client? Is it because the authz server might get several requests during the > app polling? Or I am missing some security issue (assuming this all goes > through TLS)? There is device profile extension and it works similar to what you describe above: http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 The device profile can be used by native apps as well, but the profile as a security issue similar to OAuth 1.0 vs OAuth 1.0a. An attacker can start the flow then save the link that takes the browser to the authorization page and trick another user in following it. When the victim approves, the attacker through polling can bind to his/her account. With the core flows this is much harder since the result cannot be obtained through polling, the browser is redirected to a pre-registered redirect URI (or one matching it). An open redirector must be exploited for similar results. Marius From hardjono@mit.edu Thu Jun 2 11:40:20 2011 Return-Path: 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 98507E07FD for ; Thu, 2 Jun 2011 11:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeUWFLhBh10m for ; Thu, 2 Jun 2011 11:40:20 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBD43E078F for ; Thu, 2 Jun 2011 11:40:19 -0700 (PDT) X-AuditID: 12074425-b7b82ae000000a2a-59-4de7d90228aa Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A1.F1.02602.209D7ED4; Thu, 2 Jun 2011 14:40:02 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p52IeIRr031517; Thu, 2 Jun 2011 14:40:18 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p52IeGhA023858; Thu, 2 Jun 2011 14:40:16 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Jun 2011 14:39:56 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Thu, 2 Jun 2011 14:40:16 -0400 From: Thomas Hardjono To: Torsten Lodderstedt Date: Thu, 2 Jun 2011 14:40:15 -0400 Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Thread-Index: AcwhBNUk9oyWxTu+TKmk0zc/BGzi8wATkmgw Message-ID: References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> In-Reply-To: <4DE75359.6070109@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGKsWRmVeSWpSXmKPExsUixCmqrct087mvweMzfBYn375is3h17CmL A5PHkiU/mTyO9fSzBjBFcdmkpOZklqUW6dslcGUsfLWIvWALR8WDW09ZGxhfsnUxcnJICJhI fPh3khXCFpO4cG89UJyLQ0hgH6NE58nLTCAJIYH9jBJ91/0hEkcZJeY9+sQE4WxhlNj4bjlU Sz+jxIunK8Fa2AQ0JM793ssOYosIGEq0T1zIDGIzC8hKrDl3CcxmEVCReDrpAdhuYQELiUU3 rgDVcwDVW0qs+xML0WokcXD5dLAxvAIBEov6trBD7JrKKHH7yzKwXZwC+hI/p75nAbEZgX74 fmoNE8QucYlbT+YzQfwmKLFo9h5mmD//7XrIBlEvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0Ms FpQ4OfMJywRGyVlIxs5C0jILScssJC0LGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW 6KWmlG5iBEUnu4vqDsYJh5QOMQpwMCrx8Kotfu4rxJpYVlyZe4hRkoNJSZRX8zpQiC8pP6Uy I7E4I76oNCe1+BCjBAezkgjvqkqgHG9KYmVValE+TEqag0VJnHe+pLqvkEB6YklqdmpqQWoR TFaGg0NJgjflBlCjYFFqempFWmZOCUKaiYMTZDgP0HB2kBre4oLE3OLMdIj8KUZFKXHeVpCE AEgiozQPrheWPF8xigO9Isw7AaSKB5h44bpfAQ1mAhpsoA42uCQRISXVwFj8Mlx7r+Y8zfzH gqZqS6+eSQoJ1/HwviQ0pa34RN4fqxKd5gLXR18zTu08blleH/9c0fSbUKoamxxr8CL9aUoq MZOsuT/dvXXBuHTNQ/GIBdPvp6893nDsEoMd0y3diT4WZ0/ddbjfbeLs9HRWnEllYfQvzUXP k69+WcAz2+Xrgze+8dLJKkosxRmJhlrMRcWJAF95+Z15AwAA Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:40:20 -0000 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, June 02, 2011 5:10 AM > To: Brian Eaton > Cc: OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 >=20 > I fully agree with Brian and would like to add some thoughts: >=20 > Not authenticating the client does not directly create a security > problem at all. If we would follow this line, every e-Mail client out > there would be considered insecure because the client itself is never > authenticated. Not even Kerbereos has a concept of client > authentication. Well, not to belabor this point :) but in Kerberos it is the proof of poss= ession of the client secret key which _is_ the authentication mechanism. Th= ere is also PKINIT (RFC4556) which can be used to "pre-authenticate" the us= er via Diffie-Hellman (anonymous) or a full X509 certificate. However, there is indeed the assumption in Kerberos/RFC4120 (and in the ori= ginal Needham-Schroeder protocol) that the "client" can keep secrets. /thomas/ From hardjono@mit.edu Thu Jun 2 12:17:12 2011 Return-Path: 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 E686FE078F for ; Thu, 2 Jun 2011 12:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cOTcM9NH7C4 for ; Thu, 2 Jun 2011 12:17:11 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 72B33E06BC for ; Thu, 2 Jun 2011 12:17:11 -0700 (PDT) X-AuditID: 1209190f-b7c4dae0000007bd-52-4de7e1b9f2c5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E8.54.01981.9B1E7ED4; Thu, 2 Jun 2011 15:17:13 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p52JHA2I005004; Thu, 2 Jun 2011 15:17:10 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p52JH8Bs019729; Thu, 2 Jun 2011 15:17:09 -0400 Received: from w92exhub6.exchange.mit.edu (18.7.73.12) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Jun 2011 15:16:48 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub6.exchange.mit.edu ([18.7.73.12]) with mapi; Thu, 2 Jun 2011 15:17:07 -0400 From: Thomas Hardjono To: Torsten Lodderstedt , Skylar Woodward Date: Thu, 2 Jun 2011 15:17:04 -0400 Thread-Topic: [OAUTH-WG] Text for Native Applications Thread-Index: AcwhA3QIhZwtjBFoTwed2BSbETRsHgAVB21Q Message-ID: References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> <4DE7510A.2000800@lodderstedt.net> In-Reply-To: <4DE7510A.2000800@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIKsWRmVeSWpSXmKPExsUixCmqrLvz4XNfgwdn+CxOvn3FZvH0+icm i1fHnrI4MHssWfKTyWPdosksHsd6+lkDmKO4bFJSczLLUov07RK4Ml7u/sJWcF+2Yu/uLsYG xh6JLkZODgkBE4n3x+4yQdhiEhfurWfrYuTiEBLYxyjxp/MFE4Szn1Hi/8/XLBDOZUaJhj/z oMq2MEqsnrOaHcLpZ5SY0tbMDDKMTUBD4tzvvewgtohAvMSSS0tYQGxmAVWJ9asvgi1kEVCR eH67DcwWBjrkQs9GJoh6U4mrZ58wQ9hGEg82PgazeQUCJDY8fAh1xk4WiSP7ZwAt4ODgFNCX +PJaAKSGEeiJ76fWMEHsEpe49WQ+1HOCEotm72GGefTfrodsEPWiEnfa1zNC1OtILNj9iQ3C 1pZYtvA11F5BiZMzn7BMYJSchWTsLCQts5C0zELSsoCRZRWjbEpulW5uYmZOcWqybnFyYl5e apGuiV5uZoleakrpJkZwzEry72D8dlDpEKMAB6MSD6/G4ue+QqyJZcWVuYcYJTmYlER5Jz8A CvEl5adUZiQWZ8QXleakFh9ilOBgVhLhXVUJlONNSaysSi3Kh0lJc7AoifPOklT3FRJITyxJ zU5NLUgtgsnKcHAoSfCKAlOTkGBRanpqRVpmTglCmomDE2Q4D9DwNyCLeYsLEnOLM9Mh8qcY FaXEeR+DJARAEhmleXC9sJT6ilEc6BVhXjaQFTzAdAzX/QpoMBPQYAN1sMEliQgpqQbGyOQb yrd6pG+/T8grC2DaLHbUZo2lUgOXywUvja0M7+ckhJ2qK1pikqLvfX3yk03aGaFx5+2XP3zs cHWl3cG8uYW9vw8krGTfJlJS/+Hh6RTRFVObclnuuKQzJJ1wVn7ulWA4eX7SnbisifYhmlIF W7dtNiqc6L/JcenSyr3fXx1142aZG+SnxFKckWioxVxUnAgA2kHyjYQDAAA= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:17:13 -0000 Hi Torsten, folks, I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and= also the text of Section 9 of oath-draft16. I think there seems to be a disconnect (may be its just me). (a) Oauth2.0 today is designed for low-assurance environments. So I think t= he WG is wasting a lot of time in trying to address whether the Client can = keep secrets. The WG should just assume that the problem of keeping secrets= is out of scope for Oauth. Unless we are trying to address high-assurance = environments (and start talking about smartcards, HSMs, TPMs, trusted execu= tion, trusted boot, etc), I think the WG should just move on.=20 ps. Section 4.1 is OK, but this WG will not be able to solve many of the pr= oblems listed in Section 4.1 (b) The current text of Section 9 says: ]]]] Native applications SHOULD use the authorization code=20 ]]]] grant type flow without client password credentials (due to their ]]]] inability to keep the credentials confidential) to obtain ]]]] short-lived access tokens, and use refresh tokens to maintain access. When it comes to "keeping secrets" I don't know why we are assuming that a = native application (software running in user-space managed by an OS) is any= worse than a browser (user-agent). Did I misunderstood the definition of a= native application? Thanks. /thomas/ _________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, June 02, 2011 5:00 AM > To: Skylar Woodward > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Text for Native Applications >=20 > Dave, Skylar, >=20 > the assumption of the OAuth 2.0 security threat model > (http://tools.ietf.org/html/draft-lodderstedt-oauth-security- > 01#section-4.1) > is that client secrets, which are distributed with applications, cannot > reliably kept confidential. Therefore the advice is given to use other > means to validate the client identity (e.g. user consent, platform > security measures). >=20 > I would highly appreciate if you would review this document and give us > feedback. >=20 > thanks in advance, > Torsten. >=20 > Am 01.06.2011 22:07, schrieb Skylar Woodward: > > On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote: > > > >> for mounting the attack. I firmly believe that secrets can be > >> sufficiently obfuscated in code delivered in binary format without > >> the benefit of a symbol table, so as to be sufficiently resistant to > >> discovery via disassembly by attackers you'd expect to encounter in > a > >> typical commercial environment. I'm not talking about printable > > I have empirical evidence to support this. At Yahoo! we devised one > of the most complex systems I've ever seen in a publicly distributed > program (Messenger). It was disassembled in 3 days. Scott Renfro (now > over with David at Facebook) and likely Bill Mills can also vouch for > the difficulty of this having also studied the case well. > > > > Moreover if a hardware-enforced system like that of Playstation 3 can > be broken, then so can most systems. The PS3 protection mechanisms > are/were very sophisticated. > > > > Even if a system is not yet cracked or is very hard, you have to > assume it can be cracked. History has shown this to be true nearly > without exception - at least to the point it is not worth considering > for the OAuth use cases. > > > > skylar > > > > _______________________________________________ > > 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 From igor.faynberg@alcatel-lucent.com Thu Jun 2 12:31:15 2011 Return-Path: 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 8622AE088E for ; Thu, 2 Jun 2011 12:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPKITErtT4q9 for ; Thu, 2 Jun 2011 12:31:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E70BBE0885 for ; Thu, 2 Jun 2011 12:31:14 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p52JVCaN015149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 14:31:12 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52JVBMm012556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2011 14:31:11 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p52JVBpk020100; Thu, 2 Jun 2011 14:31:11 -0500 (CDT) Message-ID: <4DE7E4FE.7090606@alcatel-lucent.com> Date: Thu, 02 Jun 2011 15:31:10 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Thomas Hardjono References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:31:15 -0000 Actually, for the devices that use smart cards (mobile devices, in particular), this assumption is quite appropriate. Igor Thomas Hardjono wrote: >> .... > ... > > However, there is indeed the assumption in Kerberos/RFC4120 (and in the original Needham-Schroeder protocol) that the "client" can keep secrets. > > /thomas/ > > > > _______________________________________________ > > From igor.faynberg@alcatel-lucent.com Thu Jun 2 12:44:01 2011 Return-Path: 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 3BCEEE089A for ; Thu, 2 Jun 2011 12:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRZyK-1nz+zh for ; Thu, 2 Jun 2011 12:44:00 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDEE0876 for ; Thu, 2 Jun 2011 12:44:00 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p52JhvMJ011350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 14:43:57 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52JhvmK030561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2011 14:43:57 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p52Jhupr000373; Thu, 2 Jun 2011 14:43:56 -0500 (CDT) Message-ID: <4DE7E7FC.7080401@alcatel-lucent.com> Date: Thu, 02 Jun 2011 15:43:56 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Thomas Hardjono References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> <4DE7510A.2000800@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:44:01 -0000 Thomas Hardjono wrote: > > (a) Oauth2.0 today is designed for low-assurance environments. I don't think that was an objective. At least, the charter does not say that... > So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on. > Yes, but the objective here was to document *considerations*, which I think the document has done very well. (By the way, personally I would very much like to address high-assurance environments, but I respect the consensus on getting 2.0 finished before this is addressed. All the more, it is important to point out the potential weaknesses in the security considerations section.) > ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1 > I have a different opinion on that, which is much more optimistic. But, again, the objective of considerations is posing the problems, and this is done very well, in my opinion. > > (b) The current text of Section 9 says: > > ]]]] Native applications SHOULD use the authorization code > ]]]] grant type flow without client password credentials (due to their > ]]]] inability to keep the credentials confidential) to obtain > ]]]] short-lived access tokens, and use refresh tokens to maintain access. > > When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misunderstood the definition of a native application? > Maybe I misunderstood something, but I think that native applications rely on OS for keeping secrets. Igor From beaton@google.com Thu Jun 2 12:45:39 2011 Return-Path: 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 B45C6E0876 for ; Thu, 2 Jun 2011 12:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.926 X-Spam-Level: X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuNFIfQKeYYT for ; Thu, 2 Jun 2011 12:45:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 15B70E089A for ; Thu, 2 Jun 2011 12:45:39 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p52JjX3m031862 for ; Thu, 2 Jun 2011 12:45:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307043938; bh=GuPCY6QodNeZuSvjUwS6SPN9k0Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=mcfoeVyNtXdrGQmgZK4yIwixl3mnQRgmo4AHoC5NF4S7zvMxwHssY1AY75k/DB5Py dOWQOai5GmvFh80PYexzw== Received: from pzk26 (pzk26.prod.google.com [10.243.19.154]) by wpaz21.hot.corp.google.com with ESMTP id p52JjQVj015308 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 12:45:27 -0700 Received: by pzk26 with SMTP id 26so665302pzk.24 for ; Thu, 02 Jun 2011 12:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rAZ6Z8cG1OEGFWcj99+JdP6ISpl7Ujtn9Dgfr3MWxRU=; b=BPuCjED/gmDeQjM0sZGITKc1n9HsyT7Dt5uTbBGg4Nb3v9cDVBCFe/E82XFjhfQn9O xOzyFmf0+NDA2TRq7gIw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q8fz4IlNFmCqGTJsXR2nDd6FpZM+tM1QAtyLz8nzUQTG5YBMwQlAuxZg4iGIhjNWjU ucuCfclBllnq0svDZysA== MIME-Version: 1.0 Received: by 10.142.221.1 with SMTP id t1mr185782wfg.437.1307043921267; Thu, 02 Jun 2011 12:45:21 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 2 Jun 2011 12:45:21 -0700 (PDT) In-Reply-To: References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> Date: Thu, 2 Jun 2011 12:45:21 -0700 Message-ID: From: Brian Eaton To: Thomas Hardjono Content-Type: multipart/alternative; boundary=000e0cd14696a20c5704a4bfe098 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:45:39 -0000 --000e0cd14696a20c5704a4bfe098 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono wrote: > Well, not to belabor this point :) but in Kerberos it is the proof of > possession of the client secret key which _is_ the authentication mechanism. > There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the > user via Diffie-Hellman (anonymous) or a full X509 certificate. > The kerberos notion of "client" is not the same thing as the OAuth notion of "client". The "client" in kerberos maps to the OAuth "user". The "client" in OAuth is the application the user is using. Kerberos does not, for example, try to authenticate the kinit binary. It just tries to authenticate the person using the kinit binary. Kerberos does have a notion of forwardable service tickets that authenticate both the user and the service they are using; that's a much closer match to what OAuth2 does. --000e0cd14696a20c5704a4bfe098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono <hardjono@mit.edu> wrote:
<= div class=3D"gmail_quote">
Well, not to belabor this point :) =A0but in Kerberos it = is the proof of possession of the client secret key which _is_ the authenti= cation mechanism. There is also PKINIT (RFC4556) which can be used to "= ;pre-authenticate" the user via Diffie-Hellman (anonymous) or a full X= 509 certificate.

The kerberos notion of "client" = is not the same thing as the OAuth notion of "client". =A0The &qu= ot;client" in kerberos maps to the OAuth "user". =A0The &quo= t;client" in OAuth is the application the user is using.

Kerberos does not, for example, try to authenticate the= kinit binary. =A0It just tries to authenticate the person using the kinit = binary.

Kerberos does have a notion of forwardable= service tickets that authenticate both the user and the service they are u= sing; that's a much closer match to what OAuth2 does.
--000e0cd14696a20c5704a4bfe098-- From beaton@google.com Thu Jun 2 12:51:33 2011 Return-Path: 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 6B381E0865 for ; Thu, 2 Jun 2011 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O53q-qgZKndg for ; Thu, 2 Jun 2011 12:51:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8C773E085D for ; Thu, 2 Jun 2011 12:51:32 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p52JpV12025038 for ; Thu, 2 Jun 2011 12:51:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307044291; bh=tNQYDUEp3q5CkhvM8K1IvNcCKu4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=i8kAXsuxSG9bA3kCIUA4aSHsDEkkj5XFIOR7l2nwHkbvIaXMD/xkhygKmSnTeAbHX Q3I8YS83e5wxDi+fe4G0Q== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz1.hot.corp.google.com with ESMTP id p52JpDq4004044 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 12:51:29 -0700 Received: by pwj9 with SMTP id 9so706677pwj.20 for ; Thu, 02 Jun 2011 12:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VviyXMBifSaaOJSfhlGITndjEbe5+Xbngh8NiSPMbcE=; b=RsQYL3nCLparw/wMPrVqaBdCUeX3nWjcFZm9zhzyQwz8xFyFuhLIa5wasmkQcc/z1J Qz+Fri9RkioOuq/K9NTg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ueQMk5Du/p8et5kwXK6QIXgUqI1FOm8NsDoandC7sD3zGoOQPPhmO6rPc4O7+idYko /7YJgquvZhOuDVHNTcOw== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr189536wff.266.1307044289329; Thu, 02 Jun 2011 12:51:29 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 2 Jun 2011 12:51:29 -0700 (PDT) In-Reply-To: References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> <4DE7510A.2000800@lodderstedt.net> Date: Thu, 2 Jun 2011 12:51:29 -0700 Message-ID: From: Brian Eaton To: Thomas Hardjono Content-Type: multipart/alternative; boundary=000e0cd2df40923b9904a4bff608 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:51:33 -0000 --000e0cd2df40923b9904a4bff608 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono wrote: > (a) Oauth2.0 today is designed for low-assurance environments. So I think > the WG is wasting a lot of time in trying to address whether the Client can > keep secrets. The WG should just assume that the problem of keeping secrets > is out of scope for Oauth. Unless we are trying to address high-assurance > environments (and start talking about smartcards, HSMs, TPMs, trusted > execution, trusted boot, etc), I think the WG should just move on. > In terms of support for things like HSMs, check out this web site: https://sites.google.com/site/oauthgoog/authenticate-google-app-engine-app I agree with you that the working group should probably move on from the topic of keeping secrets in native apps, because what we say on this topic is not going to change industry practice at all. But it is important that the protocol support higher security environments where secrets really are secrets. That's an area where protocol changes do have impact on industry practice, and we should be careful not to screw it up. --000e0cd2df40923b9904a4bff608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono <hardjono@mit.edu> wrote:
<= div class=3D"gmail_quote">
(a) Oauth2.0 today is designed for low-assurance environments. So I think t= he WG is wasting a lot of time in trying to address whether the Client can = keep secrets. The WG should just assume that the problem of keeping secrets= is out of scope for Oauth. Unless we are trying to address high-assurance = environments (and start talking about smartcards, HSMs, TPMs, trusted execu= tion, trusted boot, etc), I think the WG should just move on.

In terms of support for things like HSMs, = check out this web site:


I agree with you that the working group should probably= move on from the topic of keeping secrets in native apps, because what we = say on this topic is not going to change industry practice at all.

But it is important that the protocol support higher se= curity environments where secrets really are secrets. =A0That's an area= where protocol changes do have impact on industry practice, and we should = be careful not to screw it up.
--000e0cd2df40923b9904a4bff608-- From hardjono@mit.edu Thu Jun 2 13:13:28 2011 Return-Path: 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 BD028E083F for ; Thu, 2 Jun 2011 13:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlAZvicNXnL7 for ; Thu, 2 Jun 2011 13:13:28 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3367BE0830 for ; Thu, 2 Jun 2011 13:13:27 -0700 (PDT) X-AuditID: 12074423-b7ce8ae000000a29-1e-4de7eee15ec0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 28.16.02601.1EEE7ED4; Thu, 2 Jun 2011 16:13:21 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p52KDPaN016841; Thu, 2 Jun 2011 16:13:25 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p52KDOHq032092; Thu, 2 Jun 2011 16:13:25 -0400 Received: from w92exhub8.exchange.mit.edu (18.7.73.14) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Jun 2011 16:12:54 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub8.exchange.mit.edu ([18.7.73.14]) with mapi; Thu, 2 Jun 2011 16:13:24 -0400 From: Thomas Hardjono To: "igor.faynberg@alcatel-lucent.com" Date: Thu, 2 Jun 2011 16:13:22 -0400 Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Thread-Index: AcwhW6VIddgncmyvRySF/iEwVU4+pwABOspA Message-ID: References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> In-Reply-To: <4DE7E4FE.7090606@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CC213F.FCE4A180" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMJsWRmVeSWpSXmKPExsUixG6novvw3XNfg50NUhbn+z8yWZx8+4rN 4tWxpywOzB6tz/ayeixZ8pPJ41hPP2sAcxSXTUpqTmZZapG+XQJXxpHrfAUXXSrOXo9tYJzs 2MXIySEhYCJxffcbdghbTOLCvfVsXYxcHEIC+xglHt+fzA7h7GeUuHB3KiOEc4xRYvfdQywQ zhZGiT+bbzCB9AsJ9DNKTJrNBmKzCWhInPu9F2yuiICnxOTD8xlBbGYBH4nWKS9ZQWwWARWJ hdM3gtUIC1hILLpxBcjmAKq3lFj3Jxai1Uji5rErYOW8AgESm+dPhLqohUnizsmlLCAJTqCi e0u2gO1lBPrh+6k1TBC7xCVuPZnPBPGbiMTDi6fZYP78t+shVL2oxJ329WCfMQv0Mkos6fnE CLFNUOLkzCcsExglZiGZNQtZ3SwkdbOADmcW0JNo28gIUS8vsf3tHGYI21pixq+DbBC2osSU 7ofsELapxOujHxkXMHKsYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECI57F+Ud jH8OKh1iFOBgVOLhVVj83FeINbGsuDL3EKMkB5OSKK8mMGkI8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuHd8wYox5uSWFmVWpQPk5LmYFES550rqe4rJJCeWJKanZpakFoEk5Xh4FCS4K0CGSpY lJqeWpGWmVOCkGbi4AQZzgM0XBCkhre4IDG3ODMdIn+KUVFKnNcdJCEAksgozYPrhaXlV4zi QK8I86aBVPEAUzpc9yugwUxAgw3UwQaXJCKkpBoYV0rcKnjk4Kexe7rI1nOOmnulneZHlkXX s6jzvLv2QDpO/f4Km9ct3+Yu3iMX7G2fuNWoqMbxuuIBnwQXNR2BXguDRXblNTVx7394Hon2 41PkvMfDH8F38uiCcn0vHuX7a4548i74+D6sIaxGYHlwzUmzU+9f9Jo47PjOHTdjoq/Bz03/ u2yVWIozEg21mIuKEwFqTlavpgMAAA== Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:13:28 -0000 ------=_NextPart_000_0000_01CC213F.FCE4A180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Igor, If you bring smartcards into the picture, then it's a different ballgame :) If mobile phones are assumed to have smartcards (which is increasingly true today via USIMs), then OAUTH can assume that native apps (running on the phones) may have access to crypto-store. In this case the text in Section 9 of draft-16 would needs changes/clarifications. /thomas/ __________ > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > Sent: Thursday, June 02, 2011 3:31 PM > To: Thomas Hardjono > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > Actually, for the devices that use smart cards (mobile devices, in > particular), this assumption is quite appropriate. > > Igor > > Thomas Hardjono wrote: > >> .... > > ... > > > > However, there is indeed the assumption in Kerberos/RFC4120 (and in > the original Needham-Schroeder protocol) that the "client" can keep > secrets. > > > > /thomas/ > > > > > > > > _______________________________________________ > > > > ------=_NextPart_000_0000_01CC213F.FCE4A180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP4DCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTMMIIDtKADAgECAhA04y/94Vi/dkaC9/1NZ7F6MA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTEwMzAzMDAwMDAwWhcNMTIwMzAyMjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAqXFlCDKk41h+Qdsa43S4gLmnm78zrrujeF/9ehTTbO2xWpQN5RXC1iaqTH3yfqdzZVax ssJ5yg5adnNBJUjFgy5FbgEzthKGURl+CcLvWhAVAVsAJhu227qhK/2SPnIXGP43u1TlZD+8LU9E WngkY3M3AiKhcclB0G9hX31qXsUCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA3xiHqu8i5pWT418M2F07ZFN5tpHyOF2mJH8M M/mtUqkI6OpdT7X1YI68pv2UALawaTQIwLpFDDv2vTPyi9+yVANyngAUqe9QogpUhnVv0U6utNrE aFzIjwkoaPDpacOZRvz47yl4eN36rM2vGJ1i3eZfsEA8X0+aepIsUsX9zwZ69ocXyhs4+xNiEByQ YwBIUA2JUCf/bv5lIY4sX3XLHddtBgZ8vGPCjiJDu+1tXwdjqf2NyeHJRHk3TcNH7Nd3HSpR7Ojn fuMzpOtmRTuJ4N74J1+Ck4LWA3s6ZofXbGL/8qglffU1Wf+XW89L3hIKMfY4z3hf++YustE+Fmwj 1jCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq +mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9Ix slQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMD rho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n 0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UC AwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4a HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIw YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEf MB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD 9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0g RzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJ bOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeL eo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs 6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I 0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHML sbyg2lJY3QoOf8GCMYIEuDCCBLQCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MDIyMDEzMTlaMCMG CSqGSIb3DQEJBDEWBBQZFf2+x2JZ7BMxt2bqlT6F383uFTCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhA0 4y/94Vi/dkaC9/1NZ7F6MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQNOMv/eFYv3ZGgvf9TWexejANBgkq hkiG9w0BAQEFAASBgFoFYTU8Njg1Hu46zrhZzEqmIBTK97LEjBO77QQ46Njmf7yltQmpFM4S9ivL dMFN82qSSeLiCkMj90CXaHanBrv2OmuI29xZGD3dFjM1YJLdxa4BifdLQfDuQGfH2mNzNuVAVO7a YUDmbejyubdQd8u+ALnixNWI8BvXIvSzo/iDAAAAAAAA ------=_NextPart_000_0000_01CC213F.FCE4A180-- From phil.hunt@oracle.com Thu Jun 2 13:20:48 2011 Return-Path: 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 E0384E085D for ; Thu, 2 Jun 2011 13:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ver9kKKI7qc for ; Thu, 2 Jun 2011 13:20:48 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3F64AE081A for ; Thu, 2 Jun 2011 13:20:48 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p52KKiZx019240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 20:20:46 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p52KKh4q010702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 20:20:44 GMT Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p52KKcTu031444; Thu, 2 Jun 2011 15:20:38 -0500 Received: from [192.168.1.71] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Jun 2011 13:20:38 -0700 References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Phillip Hunt Date: Thu, 2 Jun 2011 13:20:33 -0700 To: Thomas Hardjono X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4DE7F09E.0151:SCFMA922111,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:20:49 -0000 The notion of client instance ids (eg as suggested) by USIMs suggested may b= e a slightly different identify then envisioned by client_id.=20 I have mentioned the same issue before of identifying software separately fr= om deployment instances which such a strong credential would map to.=20 They likely has to be addressed post 2.0.=20 Phil On 2011-06-02, at 13:13, Thomas Hardjono wrote: > Thanks Igor, >=20 > If you bring smartcards into the picture, then it's a different > ballgame :) >=20 > If mobile phones are assumed to have smartcards (which is increasingly > true today via USIMs), then OAUTH can assume that native apps (running > on the phones) may have access to crypto-store. In this case the text > in Section 9 of draft-16 would needs changes/clarifications. >=20 > /thomas/ >=20 >=20 > __________ >=20 >> -----Original Message----- >> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] >> Sent: Thursday, June 02, 2011 3:31 PM >> To: Thomas Hardjono >> Cc: Torsten Lodderstedt; OAuth WG >> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 >>=20 >> Actually, for the devices that use smart cards (mobile devices, in >> particular), this assumption is quite appropriate. >>=20 >> Igor >>=20 >> Thomas Hardjono wrote: >>>> .... >>> ... >>>=20 >>> However, there is indeed the assumption in Kerberos/RFC4120 (and > in >> the original Needham-Schroeder protocol) that the "client" can keep >> secrets. >>>=20 >>> /thomas/ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>>=20 >>>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hardjono@mit.edu Thu Jun 2 13:24:28 2011 Return-Path: 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 6D9E1E089B for ; Thu, 2 Jun 2011 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flLC3ku-yEA3 for ; Thu, 2 Jun 2011 13:24:27 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id AC61FE0899 for ; Thu, 2 Jun 2011 13:24:27 -0700 (PDT) X-AuditID: 1209190e-b7c39ae000000a8c-db-4de7f16dc212 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 02.95.02700.D61F7ED4; Thu, 2 Jun 2011 16:24:13 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p52KOO6e018416; Thu, 2 Jun 2011 16:24:24 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p52KONOo029508; Thu, 2 Jun 2011 16:24:23 -0400 Received: from oc11exhub1.exchange.mit.edu (18.9.3.11) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Jun 2011 16:23:54 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub1.exchange.mit.edu ([18.9.3.11]) with mapi; Thu, 2 Jun 2011 16:24:22 -0400 From: Thomas Hardjono To: Brian Eaton Date: Thu, 2 Jun 2011 16:24:22 -0400 Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Thread-Index: AcwhXaa7rD5IVH41Sk67L6LV+rcY/AAA/e4g Message-ID: References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRmVeSWpSXmKPExsUixG6nrpv78bmvQcsNeYtjT7ayWJx8+4rN gcljwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXztfctcsJinYlpvP0sD40fOLkZODgkBE4lT jReZIGwxiQv31rN1MXJxCAnsY5TY1fyaGcLZzyhxbOUrdgjnMqPEviW9jBDOFkaJF1+6oMr6 GSWmn9rDCjKMTUBD4tzvvewgtoiAssS5KYuZQWxmAVmJNecugdksAioSF04/A1suLGAhsejG FaB6DqB6S4l1f2IhWo0kdh9rZwIJ8woESFw+6A+xajGTxKmuB2BjOAUCJa783wg2hhHoh++n 1jBBrBKXuPVkPtRvghKLZu9hhvnz366HbBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNVg9L1Dv yZlPWCYwSs5CMnYWkpZZSFpmIWlZwMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81 pXQTIyg2OSX5djB+Pah0iFGAg1GJh1d28XNfIdbEsuLK3EOMkhxMSqK8C98BhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nw7nkDlONNSaysSi3Kh0lJc7AoifPOlFT3FRJITyxJzU5NLUgtgsnK cHAoSfBe/ADUKFiUmp5akZaZU4KQZuLgBBnOAzT883uQ4cUFibnFmekQ+VOMilLivPdAmgVA EhmleXC9sNT5ilEc6BVh3v0gVTzAtAvX/QpoMBPQYAN1sMEliQgpqQZGcRvHHRfrdXbNCTfk 88183VAx123F829PIpSOREjdm3Yo41ZobZRykav9hpSiVg3rcyl9kq3zzH3Y0l4dkPl20e8j w4oltzQExWYwKlVlbHpkvP+LpCHXChYFRWexqO1sej7nXL89nFw1717Snzi+hf9UxZXOd31q +uk2//yMyvLX0z4ebZFTYinOSDTUYi4qTgQA8I42Q3gDAAA= Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:24:29 -0000 > __________________________________________ >=20 > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, June 02, 2011 3:45 PM > To: Thomas Hardjono > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 >=20 > On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono > wrote: > Well, not to belabor this point :) but in Kerberos it is the proof of > possession of the client secret key which _is_ the authentication > mechanism. There is also PKINIT (RFC4556) which can be used to "pre- > authenticate" the user via Diffie-Hellman (anonymous) or a full X509 > certificate. >=20 > The kerberos notion of "client" is not the same thing as the OAuth > notion of "client". The "client" in kerberos maps to the OAuth > "user". The "client" in OAuth is the application the user is using. >=20 > Kerberos does not, for example, try to authenticate the kinit > binary. It just tries to authenticate the person using the kinit > binary. Oh ok, now I get what "authenticating the client" means here. My bad. Perha= ps the term "authenticating" is not accurate. Maybe "integrity verification= " of client code is a better phrase. And yes, integrity-verification of the kinit binary in MIT Kerberos is not = performed prior to execution (in Linux-based systems).=20 Actually, generally speaking integrity-verification of binaries (either in = store/disk or during run-time) is not the job of a client code like kinit. = The OS should be doing this. Thanks. /thomas/ From torsten@lodderstedt.net Thu Jun 2 14:01:24 2011 Return-Path: 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 B5CE1E08D7 for ; Thu, 2 Jun 2011 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCILmsWs1GKD for ; Thu, 2 Jun 2011 14:01:24 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id ED36CE08D5 for ; Thu, 2 Jun 2011 14:01:23 -0700 (PDT) Received: from [91.14.177.2] (helo=[192.168.1.250]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QSF16-000079-Jl; Thu, 02 Jun 2011 23:01:20 +0200 References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----0EJA2I0JYRU72W9HDLKP6SGF441IGJ" From: Torsten Lodderstedt Date: Thu, 02 Jun 2011 23:01:16 +0200 To: Thomas Hardjono , "igor.faynberg@alcatel-lucent.com" Message-ID: X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:01:24 -0000 ------0EJA2I0JYRU72W9HDLKP6SGF441IGJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit in my opinion, the problem with client authentication is more the secure distribution of the secret than the storage. How should a USIM help here? regards, Torsten. Thomas Hardjono schrieb: Thanks Igor, If you bring smartcards into the picture, then it's a different ballgame :) If mobile phones are assumed to have smartcards (which is increasingly true today via USIMs), then OAUTH can assume that native apps (running on the phones) may have access to crypto-store. In this case the text in Section 9 of draft-16 would needs changes/clarifications. /thomas/ __________ > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > Sent: Thursday, June 02, 2011 3:31 PM > To: Thomas Hardjono > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > Actually, for the devices that use smart cards (mobile devices, in > particular), this assumption is quite appropriate. > > Igor > > Thomas Hardjono wrote: > >> .... > > ... > > > > However, there is indeed the assumption in Kerberos/RFC4120 (and in > the original Needham-Schroeder protocol) that the "client" can keep > secrets. > > > > /thomas/ > > > > > > > >_____________________________________________ > > > > ------0EJA2I0JYRU72W9HDLKP6SGF441IGJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit in my opinion, the problem with client authentication is more the secure distribution of the secret than the storage. How should a USIM help here?

regards,
Torsten.



Thomas Hardjono <hardjono@MIT.EDU> schrieb:
Thanks Igor,

If you bring smartcards into the picture, then it's a different
ballgame :)

If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.

/thomas/


__________

> -----Original Message-----
> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
> Sent: Thursday, June 02, 2011 3:31 PM
> To: Thomas Hardjono
> Cc: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
> 
> Actually, for the devices that use smart cards (mobile devices, in
> particular), this assumption is quite appropriate.
>

> Igor
> 
> Thomas Hardjono wrote:
> >> ....
> > ...
> >
> > However, there is indeed the assumption in Kerberos/RFC4120 (and
in
> the original Needham-Schroeder protocol) that the "client" can keep
> secrets.
> >
> > /thomas/
> >
> >
> >
> >

> >
> >
------0EJA2I0JYRU72W9HDLKP6SGF441IGJ-- From wmills@yahoo-inc.com Thu Jun 2 14:31:15 2011 Return-Path: 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 BA82CE08A1 for ; Thu, 2 Jun 2011 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pju2BErKn7sB for ; Thu, 2 Jun 2011 14:31:14 -0700 (PDT) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by ietfa.amsl.com (Postfix) with SMTP id CBBA3E088F for ; Thu, 2 Jun 2011 14:31:14 -0700 (PDT) Received: from [98.139.91.70] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 21:31:11 -0000 Received: from [98.139.91.45] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 21:31:11 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 21:31:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 903912.67620.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 52232 invoked by uid 60001); 2 Jun 2011 21:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307050271; bh=0aukxx6YN6ZZ++vxnYxlKET7cCcyyocj8hcikuwc7HQ=; 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=FKLrQNx2Znkjug3eMRwYetbPnTS+ebWO6O3JIxW78auLTWEXB7aERwru1IGoyZM8pVURy5DaXYBHhsNJX8zn2aKfAxrAH/DzBJhvqdb7BtskNyjxD+hcugZuwBcJ0r9X2prt5c6rhWCgng2nuLZb27Y9Fb2KQX5SoXcEWBFwHWQ= 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=IEfcF+pajokCw6RYvJhSiMS0JSe8jaYck+VWqLFQec1yyTYgOmUA4zciUKzYmDDHjk00xFIer84DT7Wa/o/We3h4fqS6jeJa0QCGT+KZfOraaRXkmhphC1eOKp7vmB81QHanY3ydbkJ71gB6ZT6gfOVU8eGnkdcZYlYuOli7Wy0=; X-YMail-OSG: Ql_LUowVM1koqmCHJ8ChXaSL276dr2s64gy4r_DoNjqlGj5 ymruXIaizEGdUu6X_Nh8NZJ5sL34Y6xJ6d3CpCq5KBLNPGUXZX7g7Q2t5Dxj vLkwTMOuAvYtpBmUSOYm6G7NakETzdt3MYeK_woNYIpLdl6NRRJVBcBC81bN 3jcGCr7u2VrNmwoV5XVJmIafSZhKdH7h2y6fBTNlNF8_QWnpi7PW6E.9yvqF c8nQ73JpwAaM.btks3jeGgV9q1EDighgffkidLJ5JqPS3q_taRPIXc5htBbZ 7bi894lB7.1pdp1gwP.tRX7dFoQKbvqCKmvwHHdBLZTBaFHp0Dg9DD760i5M a9mBxEIwm.JvbusvaMT48ddpw5V6KzrwtF7kUn54ucZokQiSBSqtGqIw9MSP rvmDWuevrrb725wRbul3DvBJVayWSuOOPdFhbbA-- Received: from [216.145.52.206] by web31813.mail.mud.yahoo.com via HTTP; Thu, 02 Jun 2011 14:31:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> Message-ID: <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 2 Jun 2011 14:31:10 -0700 (PDT) From: "William J. Mills" To: Dave Nelson , Skylar Woodward In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-824203688-1307050270=:49342" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:31:15 -0000 --0-824203688-1307050270=:49342 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In theory this is true..=0A=0A=0A> I firmly believe that secrets can be suf= ficiently obfuscated =0A=0A> in code delivered in binary format without the= benefit of a =0A=0A> symbol table, so as to be sufficiently resistant todi= scovery =0A=0A> via disassembly by attackers you'd expect to encounter in a= =0A=0A> typical commercial environment.=0A=0AIn practice there are an extre= mely small number of cases where this is actually done right, and legions o= f cases where it's done wrong.=A0 Industry just doesn't get this right ofte= n enough to rely on it.=0A=0A-bill=0A=0A=0A=0A_____________________________= ___=0AFrom: Dave Nelson =0ATo: Skylar Woodward =0ACc: "oauth@ietf.org" =0ASent: Wednesday, June 1= , 2011 12:43 PM=0ASubject: Re: [OAUTH-WG] Text for Native Applications=0A= =0A> The group is operating under the assumption that most=0A> native apps = are publicly deployed or that copies of the=0A> app bundle/binary can at le= ast be obtained by a malicious=0A> party.=0A=0AAgreed.=0A=0A> ... its alway= s possible for the attacker to disassemble the=0A> program and obtain the s= ecret.=0A=0AAlways possible?=A0 In theory, perhaps.=A0 As with any threat a= nalysis, it=0Adepends on the resources available to the attacker and the mo= tivations=0Afor mounting the attack.=A0 I firmly believe that secrets can b= e=0Asufficiently obfuscated in code delivered in binary format without the= =0Abenefit of a symbol table, so as to be sufficiently resistant to=0Adisco= very via disassembly by attackers you'd expect to encounter in a=0Atypical = commercial environment.=A0 I'm not talking about printable=0Astrings stored= in contiguous memory.=0A=0AI think it's important, for a number of use cas= es, some of them of=0Aparticular interest to me, for an application to be a= ble to use this=0Aform of identification, when sufficient care has been tak= en to=0Amitigate the threat model for the intended use.=A0 I'd rather see t= he=0Arisks inherent in providing secure storage of application credentials= =0Athoroughly discussed in the Security Considerations section, rather=0Ath= an discouraging it's use altogether in the normative protocol=0Adefinition = sections of the draft.=A0 I agree that there are many=0Adeployment scenario= s in which secrets or passwords would not be an=0Aappropriate method of cli= ent identification, but I see some in which=0Ais clearly would be appropria= te.=0A=0ARegards,=0A=0ADave=0A=0ADavid B. Nelson=0ASr. Software Architect= =0AElbrys Networks, Inc.=0Awww.elbrys.com=0A+1.603.570.2636=0A_____________= __________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth --0-824203688-1307050270=:49342 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In t= heory this is true..

> I firmly believe tha= t secrets can be sufficiently obfuscated
> in code delive= red in binary format without the benefit of a
> symbol ta= ble, so as to be sufficiently resistant to discovery
> vi= a disassembly by attackers you'd expect to encounter in a
&g= t; typical commercial environment.

In practice the= re are an extremely small number of cases where this is actually done right= , and legions of cases where it's done wrong.  Industry just doesn't g= et this right often enough to rely on it.

-bill

From: Dave Nelson <dnelson@elbrys.com>
To: Skylar Woodward <skylar@kiva.org>
Cc: "oauth@ietf.org" <oauth@ietf= .org>
Sent: Wednesda= y, June 1, 2011 12:43 PM
Subject:<= /span> Re: [OAUTH-WG] Text for Native Applications

> T= he group is operating under the assumption that most
> native apps ar= e publicly deployed or that copies of the
> app bundle/binary can at = least be obtained by a malicious
> party.

Agreed.

> = ... its always possible for the attacker to disassemble the
> program= and obtain the secret.

Always possible?  In theory, perhaps.&n= bsp; As with any threat analysis, it
depends on the resources available to the = attacker and the motivations
for mounting the attack.  I firmly bel= ieve that secrets can be
sufficiently obfuscated in code delivered in bi= nary format without the
benefit of a symbol table, so as to be sufficien= tly resistant to
discovery via disassembly by attackers you'd expect to = encounter in a
typical commercial environment.  I'm not talking abo= ut printable
strings stored in contiguous memory.

I think it's im= portant, for a number of use cases, some of them of
particular interest = to me, for an application to be able to use this
form of identification,= when sufficient care has been taken to
mitigate the threat model for th= e intended use.  I'd rather see the
risks inherent in providing sec= ure storage of application credentials
thoroughly discussed in the Secur= ity Considerations section, rather
than discouraging it's use altogether in the normative protocol
definition sections of the draft.&= nbsp; I agree that there are many
deployment scenarios in which secrets = or passwords would not be an
appropriate method of client identification= , but I see some in which
is clearly would be appropriate.

Regard= s,

Dave

David B. Nelson
Sr. Software Architect
Elbrys N= etworks, Inc.
www.elbrys.com
+1.603.570.2636
_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth


--0-824203688-1307050270=:49342-- From wmills@yahoo-inc.com Thu Jun 2 14:33:48 2011 Return-Path: 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 34EB4E08D6 for ; Thu, 2 Jun 2011 14:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zRqugJfoGVW for ; Thu, 2 Jun 2011 14:33:47 -0700 (PDT) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with SMTP id 3AD91E08D1 for ; Thu, 2 Jun 2011 14:33:43 -0700 (PDT) Received: from [98.139.212.146] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2011 21:33:39 -0000 Received: from [98.139.212.251] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2011 21:33:39 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 02 Jun 2011 21:33:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 849072.33276.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 53990 invoked by uid 60001); 2 Jun 2011 21:33:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307050418; bh=UzcwQaD2gzLNQqNFNpEGkZX13x9I1yWm5ydnbi9y94g=; 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=mTyMig01kqRPU+E9k2iNv4fIYtUUDLNvZT82C4vzOc6QZ+f85M9skmD2qpAIRs0T/C2pP/rVoRcK9EFi3WnE7bP8SJj8WWVzoD40Ch/uWH3Daz3R1t25J1wTUaIBYVjuNlp1IjdvZFDNDgt+6Ke/LKlr+wLHYCeD9ybEs3kLYlg= 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=V8jqcnnCa/KiBx7oAdT6zb4yIvniOte/vEA87i6eUzoEZ9UvK7RzF4jDSdbrgLI0I9a/YesiCAYDu1mH+Ipu4vFaeJxd38RoFSDl//q5D0IWazP6HtHFlZvfqhmLXkdC/oB0iLLJnrjsPApYzBLeMKXQp2uRSb4Vl8CnoOGqQP4=; X-YMail-OSG: rVXRVBAVM1mng3p6PYWQlsn3cRcZcn2k0MlV1In7wd86_T8 AFN18AlIv2zzvY9BHLGpZ0_Cq3juiGQ3lixrLYLIOo8qNeeL7VLxfqPMjNxI mnFIa.m3q5fmqKP.WqCrgMyeVGyVXBzp37t0_ntFBnG2pIulcRj9KkDixLuI xg7sAUwuIodarce1Du1kpp0ZgnK_PbICZKXwXGRG7LnXlIlJH4FR_D4Azb5j 0EZM7iy5LorGNZaA2aDLXwJEbpt4eFtSMYJAEaRch6CqTZVTf9obUpvQxqaM 39nlKbKs7mWePOInedLgU_nujpU0cZoTxKqWJ6d7eg71pf.kROP0ttSRD47A TfH6LYQ78tXwxFJrRcmlSHzFfTvLWsrVnxV9trNM- Received: from [216.145.52.206] by web31813.mail.mud.yahoo.com via HTTP; Thu, 02 Jun 2011 14:33:38 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> Message-ID: <1307050418.73821.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 2 Jun 2011 14:33:38 -0700 (PDT) From: "William J. Mills" To: Skylar Woodward , Dave Nelson In-Reply-To: <9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1843195332-1307050418=:73821" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:33:48 -0000 --0-1843195332-1307050418=:73821 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I wish I could talk about it.=A0 You'll have to find someone who's not boun= d by stuff like employment contracts and trades secrets stuff to tell you t= he story.=0A=0A=0A=0A________________________________=0AFrom: Skylar Woodwa= rd =0ATo: Dave Nelson =0ACc: "oauth@ie= tf.org" =0ASent: Wednesday, June 1, 2011 1:07 PM=0ASubject:= Re: [OAUTH-WG] Text for Native Applications=0A=0AOn Jun 1, 2011, at 9:43 P= M, Dave Nelson wrote:=0A=0A> for mounting the attack.=A0 I firmly believe t= hat secrets can be=0A> sufficiently obfuscated in code delivered in binary = format without the=0A> benefit of a symbol table, so as to be sufficiently = resistant to=0A> discovery via disassembly by attackers you'd expect to enc= ounter in a=0A> typical commercial environment.=A0 I'm not talking about pr= intable=0A=0AI have empirical evidence to support this. At Yahoo! we devise= d one of the most complex systems I've ever seen in a publicly distributed = program (Messenger). It was disassembled in 3 days. Scott Renfro (now over = with David at Facebook) and likely Bill Mills can also vouch for the diffic= ulty of this having also studied the case well.=0A=0AMoreover if a hardware= -enforced system like that of Playstation 3 can be broken, then so can most= systems. The PS3 protection mechanisms are/were very sophisticated.=0A=0AE= ven if a system is not yet cracked or is very hard, you have to assume it c= an be cracked. History has shown this to be true nearly without exception -= at least to the point it is not worth considering for the OAuth use cases.= =0A=0Askylar=0A=0A_______________________________________________=0AOAuth m= ailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1843195332-1307050418=:73821 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1843195332-1307050418=:73821-- From igor.faynberg@alcatel-lucent.com Thu Jun 2 14:35:04 2011 Return-Path: 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 3525EE08BC for ; Thu, 2 Jun 2011 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcYaVGw+93a9 for ; Thu, 2 Jun 2011 14:35:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E2E087A for ; Thu, 2 Jun 2011 14:35:02 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p52LYx60017395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 16:34:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52LYw0Q016832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2011 16:34:59 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p52LYvM0000390; Thu, 2 Jun 2011 16:34:57 -0500 (CDT) Message-ID: <4DE80201.1020600@alcatel-lucent.com> Date: Thu, 02 Jun 2011 17:34:57 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Phillip Hunt References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:35:04 -0000 Absolutely! In fact, client_id, should be presumed to be TOTALLY different from the USIM (or ISIM) ID. The correlation of IDs is the network's job. (Hui-Lan and I, along with two other researchers, described how this can be done in a Bell Labs Technical Journal paper: http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/pdf.) Igor Phillip Hunt wrote: > The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id. > > I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to. > > They likely has to be addressed post 2.0. > > Phil > > On 2011-06-02, at 13:13, Thomas Hardjono wrote: > > >> Thanks Igor, >> >> If you bring smartcards into the picture, then it's a different >> ballgame :) >> >> If mobile phones are assumed to have smartcards (which is increasingly >> true today via USIMs), then OAUTH can assume that native apps (running >> on the phones) may have access to crypto-store. In this case the text >> in Section 9 of draft-16 would needs changes/clarifications. >> >> /thomas/ >> >> >> __________ >> >> >>> -----Original Message----- >>> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] >>> Sent: Thursday, June 02, 2011 3:31 PM >>> To: Thomas Hardjono >>> Cc: Torsten Lodderstedt; OAuth WG >>> Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 >>> >>> Actually, for the devices that use smart cards (mobile devices, in >>> particular), this assumption is quite appropriate. >>> >>> Igor >>> >>> Thomas Hardjono wrote: >>> >>>>> .... >>>>> >>>> ... >>>> >>>> However, there is indeed the assumption in Kerberos/RFC4120 (and >>>> >> in >> >>> the original Needham-Schroeder protocol) that the "client" can keep >>> secrets. >>> >>>> /thomas/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From beaton@google.com Thu Jun 2 14:40:28 2011 Return-Path: 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 02C8DE0833 for ; Thu, 2 Jun 2011 14:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.101 X-Spam-Level: X-Spam-Status: No, score=-106.101 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIFR5xAy1P7Y for ; Thu, 2 Jun 2011 14:40:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 169B8E08E9 for ; Thu, 2 Jun 2011 14:40:26 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p52LePdZ020105 for ; Thu, 2 Jun 2011 14:40:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307050826; bh=P/AOZ+X1puBbz/Hgg118QvN3Yds=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=P6HFizDa99uRLLmkXfusUafWmeo3Dvxh+5ZfFJ8zrnaG6C1QTuzerH2486JfOXwvW 00ZzbSIxrHBFSFnzrAzKg== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by hpaq12.eem.corp.google.com with ESMTP id p52LdwxE024395 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 14:40:19 -0700 Received: by yib2 with SMTP id 2so541000yib.10 for ; Thu, 02 Jun 2011 14:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wskAaYhJ/YVwZ0cs22WVdCRv57jtc23u4AdRIo7crHg=; b=JbEWcSql8mIF9GdEpecir3IKyHMPSzvq5BvjXzFPc2WS5uJl/Ef5VmFbSnc0rMC9qG Vau49DM2vW5obxaEhFBA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hDzQgcqpR2k7/Qq029IH2xI8IsPOiDzCSm9RutIoLeRRjci9seBsk+ToPKcg6UxSrc t7fN1TONlfEhcu68fipA== MIME-Version: 1.0 Received: by 10.90.238.14 with SMTP id l14mr1216744agh.8.1307050818794; Thu, 02 Jun 2011 14:40:18 -0700 (PDT) Received: by 10.91.219.18 with HTTP; Thu, 2 Jun 2011 14:40:18 -0700 (PDT) In-Reply-To: <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 2 Jun 2011 14:40:18 -0700 Message-ID: From: Brian Eaton To: "William J. Mills" Content-Type: multipart/alternative; boundary=001485f99cb0c1f52404a4c17b9c X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:40:28 -0000 --001485f99cb0c1f52404a4c17b9c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills wrote: > In practice there are an extremely small number of cases where this is > actually done right, and legions of cases where it's done wrong. Industry > just doesn't get this right often enough to rely on it. > Well, "rely" is a strong-term. I know of various teams who do this. I don't know of any teams that put a heavy reliance on it. --001485f99cb0c1f52404a4c17b9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills <wmills@yahoo-inc.com> wro= te:
In practice t= here are an extremely small number of cases where this is actually done rig= ht, and legions of cases where it's done wrong.=A0 Industry just doesn&= #39;t get this right often enough to rely on it.

Well, "rely" is a st= rong-term. =A0I know of various teams who do this. =A0I don't know of a= ny teams that put a heavy reliance on it.
--001485f99cb0c1f52404a4c17b9c-- From igor.faynberg@alcatel-lucent.com Thu Jun 2 14:43:52 2011 Return-Path: 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 21768E08BA for ; Thu, 2 Jun 2011 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLly8NwKjoSM for ; Thu, 2 Jun 2011 14:43:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 90E56E0833 for ; Thu, 2 Jun 2011 14:43:51 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p52LhnMa021898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 16:43:50 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52LhnpD019949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2011 16:43:49 -0500 Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p52Lhm0q006546; Thu, 2 Jun 2011 16:43:49 -0500 (CDT) Message-ID: <4DE80414.40106@alcatel-lucent.com> Date: Thu, 02 Jun 2011 17:43:48 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:43:52 -0000 As far the authentication goes, what I had in mind was that the network provider could authenticate the end-user. Alternatively, an application (not necessarily the USIM) on the smart card could hold the secret and perform all cryptographic operations (what Thomas calls crypto-store). In either case, only the provider and the card would share the secret. Igor Torsten Lodderstedt wrote: > in my opinion, the problem with client authentication is more the > secure distribution of the secret than the storage. How should a USIM > help here? > > regards, > Torsten. > > > > Thomas Hardjono schrieb: > > Thanks Igor, > > If you bring smartcards into the picture, then it's a different > ballgame :) > > If mobile phones are assumed to have smartcards (which is increasingly > true today via USIMs), then OAUTH can assume that native apps (running > on the phones) may have access to crypto-store. In this case the text > in Section 9 of draft-16 would needs changes/clarifications. > > /thomas/ > > > __________ > > > -----Original Message----- > > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > > Sent: Thursday, June 02, 2011 3:31 PM > > To: Thomas Hardjono > > Cc: Torsten Lodderstedt; OAuth WG > > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > > > Actually, for the devices that use smart cards (mobile devices, in > > particular), this assumption is quite appropriate.> > > > Igor > > > > Thomas Hardjono wrote: > > >> .... > > > ... > > > > > > However, there is indeed the assumption in Kerberos/RFC4120 (and > in > > the original Needham-Schroeder protocol) that the "client" can keep > > secrets. > > > > > > /thomas/ > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > From dnelson@elbrys.com Thu Jun 2 14:51:37 2011 Return-Path: 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 9EA31E08EE for ; Thu, 2 Jun 2011 14:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APeGvUqflJsc for ; Thu, 2 Jun 2011 14:51:35 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with SMTP id 57F2FE07AE for ; Thu, 2 Jun 2011 14:51:34 -0700 (PDT) Received: from mail-gw0-f50.google.com ([74.125.83.50]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTegF5TPdQd3OEjixg/4MozI8pXKj9x3L@postini.com; Thu, 02 Jun 2011 14:51:34 PDT Received: by mail-gw0-f50.google.com with SMTP id 16so553249gwj.9 for ; Thu, 02 Jun 2011 14:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.85.66 with SMTP id t42mr1739558yhe.50.1307051491789; Thu, 02 Jun 2011 14:51:31 -0700 (PDT) Received: by 10.236.161.40 with HTTP; Thu, 2 Jun 2011 14:51:31 -0700 (PDT) In-Reply-To: References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> Date: Thu, 2 Jun 2011 17:51:31 -0400 Message-ID: From: Dave Nelson To: Thomas Hardjono Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:51:37 -0000 On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono wrote: > Oh ok, now I get what "authenticating the client" means here. My bad. > Perhaps the term "authenticating" is not accurate. Maybe "integrity > verification" of client code is a better phrase. It *may* include integrity verification of the client binary, but in the use cases I'm envisioning it's more a verification of the identity of the application publisher, and that the publisher has a business relationship with the OAuth authorization provider, such as a developer registration. In some case that matters. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From dnelson@elbrys.com Thu Jun 2 14:54:48 2011 Return-Path: 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 616AFE08F7 for ; Thu, 2 Jun 2011 14:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg+qGU01dBml for ; Thu, 2 Jun 2011 14:54:47 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 837FFE07AE for ; Thu, 2 Jun 2011 14:54:47 -0700 (PDT) Received: from mail-gw0-f48.google.com ([74.125.83.48]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTegGoyARXghpshhGBagxsEutA6l8YweW@postini.com; Thu, 02 Jun 2011 14:54:47 PDT Received: by mail-gw0-f48.google.com with SMTP id 22so692003gwj.7 for ; Thu, 02 Jun 2011 14:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.115.170 with SMTP id e30mr1411617yhh.452.1307051682935; Thu, 02 Jun 2011 14:54:42 -0700 (PDT) Received: by 10.236.161.40 with HTTP; Thu, 2 Jun 2011 14:54:42 -0700 (PDT) In-Reply-To: References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 2 Jun 2011 17:54:42 -0400 Message-ID: From: Dave Nelson To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:54:48 -0000 On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: > Well, "rely" is a strong-term. =A0I know of various teams who do this. = =A0I > don't know of any teams that put a heavy reliance on it. It might validly be just one element of a defense-in-depth strategy. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From stpeter@stpeter.im Thu Jun 2 15:01:36 2011 Return-Path: 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 36217E06BC for ; Thu, 2 Jun 2011 15:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gnGOl3W0Joq for ; Thu, 2 Jun 2011 15:01:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 664A3E06AB for ; Thu, 2 Jun 2011 15:01:35 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 941F140046; Thu, 2 Jun 2011 16:01:34 -0600 (MDT) Message-ID: <4DE8083D.10907@stpeter.im> Date: Thu, 02 Jun 2011 16:01:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <4DE68847.8090808@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010103020504000408020505" Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:01:36 -0000 This is a cryptographically signed message in MIME format. --------------ms010103020504000408020505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/1/11 1:06 PM, Brian Eaton wrote: > Hey Peter -=20 >=20 > I haven't read all of your comments yet, but I wanted to clarify one > point about client impersonation and installed apps. The cuirrent text= > is unrealistic, but your request would push it the wrong way. CC'ing > Torsten as well. >=20 > --------------------- > OLD: > The authorization server SHOULD issue access tokens with limited > scope and duration to clients incapable of authenticating. >=20 > NEW: > If the authorization server issues access tokens to clients > that are incapable of authenticating, the scope and duration of > such tokens SHOULD be limited. >=20 > RATIONALE: We're not actively RECOMMENDING authorization servers are to= > issue such tokens, are we? > --------------------- >=20 > We are most definitely recommending that clients that have no way of > authenticating are issued long-lived credentials to access user data. I think I might have misunderstood that text -- I took it to be talking about the client's authentication with the authorization server, not the client's authentication with the resource server. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010103020504000408020505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MjIyMDEzM1owIwYJKoZIhvcNAQkEMRYEFKFEdw85tBxycr1Q+khvnqaplZzgMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC3NGjeNPt4RBcPGg0yZ0uxXpkO/YOUy87MB3moH9gdNSfiM9e0hS0GuyO2 Jhc+Arl1F1eae6a2zErJ9CXSTmikR8l+rp10Wa1VHjaT1oUrh6bKoWGeineicAZitnYiXq2Y Z4Wt4xyW79gMkC5qkXsGcu42zz8rCAJSudhwmVVa0r6uVUu/SmPSCKgCrjAHD/hBoqKqOx/o hsVCjswyUK901oc7Vzl5GUkvhfRfjcaag2lzgJYr0sN1rpn7+M2wQ+ZiR6s587Pz60+2CNbx r/5Py1HuEgyT0Al/1f6nuGlCvL0jzC8fXiufdLAI366a9rWGbBwyCY0DAE0GaF6ECx9fAAAA AAAA --------------ms010103020504000408020505-- From beaton@google.com Thu Jun 2 15:11:43 2011 Return-Path: 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 DDD35E07FD for ; Thu, 2 Jun 2011 15:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.088 X-Spam-Level: X-Spam-Status: No, score=-106.088 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHzFOEbsbiGe for ; Thu, 2 Jun 2011 15:11:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F20B0E0688 for ; Thu, 2 Jun 2011 15:11:38 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p52MBcbg009740 for ; Thu, 2 Jun 2011 15:11:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307052698; bh=Pi2wEDWerE8O0oI2HwGjQCovZTE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=L/eA0KIMdGhYM+0cmOxmCAEW1Hq/MoqiRjfu3WtPDMXb3v6ZivqvQvH3DZO3SYGhu qe6jdkK0H8zjNqyjrgrLw== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by hpaq12.eem.corp.google.com with ESMTP id p52MBanr024092 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 15:11:36 -0700 Received: by ywo7 with SMTP id 7so720991ywo.25 for ; Thu, 02 Jun 2011 15:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cb8sdSGWJ1LOMf7cTymswjN/GlDu6iPnF0MyH0PXePU=; b=kP+23LSfFXOjbOGXWtCGSra8V/8PSUT7uGTdgBAKb5ed4aDcE/Rsh+klO3AVv8BIGM LOjXJoVEGKMrJ83GYdsA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DckG51nMqbrbuNbnwm5GGUUP5nuSF25j1NLEUeJ59a4ehDs0RIJj8tsHfI1OFnu7jk F8N9Bq8dUHcY5PrE/a/g== MIME-Version: 1.0 Received: by 10.90.124.11 with SMTP id w11mr1110485agc.89.1307052695711; Thu, 02 Jun 2011 15:11:35 -0700 (PDT) Received: by 10.91.219.18 with HTTP; Thu, 2 Jun 2011 15:11:35 -0700 (PDT) In-Reply-To: <4DE8083D.10907@stpeter.im> References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> Date: Thu, 2 Jun 2011 15:11:35 -0700 Message-ID: From: Brian Eaton To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=00163630f7fda16fc404a4c1ebc8 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:11:44 -0000 --00163630f7fda16fc404a4c1ebc8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre wrote: > I think I might have misunderstood that text -- I took it to be talking > about the client's authentication with the authorization server, not the > client's authentication with the resource server. No, you understand perfectly. We're talking about giving extremely powerful and near-permanent credentials to clients we can't authenticate. We're pretty sure this is a good idea. =) We authenticate the user and get their consent. If they say yes, the client gets something that is almost, but not quite, equivalent to an alternate password for the user. --00163630f7fda16fc404a4c1ebc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:=
I think I might have misunderstood that text -- I took it= to be talking
about the client's authentication with the authorization server, not th= e
client's authentication with the resource server.

=
No, you understand perfectly. =A0We're talking about giving = extremely powerful and near-permanent credentials to clients we can't a= uthenticate. =A0We're pretty sure this is a good idea. =3D)

We authenticate the user and get their consent. =A0If t= hey say yes, the client gets something that is almost, but not quite, equiv= alent to an alternate password for the user.
--00163630f7fda16fc404a4c1ebc8-- From dhc@dcrocker.net Thu Jun 2 14:16:44 2011 Return-Path: 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 528C1E08BD; Thu, 2 Jun 2011 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRyOR0rfJk53; Thu, 2 Jun 2011 14:16:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A98F1E06FC; Thu, 2 Jun 2011 14:16:43 -0700 (PDT) Received: from [192.168.1.8] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p52LGW9q002436 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 14:16:38 -0700 Message-ID: <4DE7FDA7.8030300@dcrocker.net> Date: Thu, 02 Jun 2011 14:16:23 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE62D93.7040009@cs.tcd.ie> In-Reply-To: <4DE62D93.7040009@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 02 Jun 2011 14:16:39 -0700 (PDT) X-Mailman-Approved-At: Thu, 02 Jun 2011 15:33:29 -0700 Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:16:44 -0000 Stephen, On 6/1/2011 5:16 AM, Stephen Farrell wrote: > Just on DOSETA - that's not currently got any official > home in the IETF so its not something that would be right > to reference at this point (unless the oauth WG wanted to > adopt DOSETA but I'd be very surprised if that were the > case for timing reasons). I'm confused on two counts. (To be honest, of course, I'm confused about many points, but two of them are relevant to this thread...) One, of course, is that I've been actively raising DOSETA in various IETF venues for the different groups to considering adopting and/or adapting it. As such, discussion of DOSETA permits exploring the possibility of adoption and/or adaptation. The second is that you appear to be stating a policy that a working group is only permitted to reference things which are currently and officially IETF work items. I suspect that that is not what you meant, so at the least, please clarify what you do mean. If you really do mean anything like the interpretation I just summarized, please explain its basis. > To be clear, as an individual, I do think that "something > like DOSETA" is a really good idea and maybe DOSETA will > turn out to be that something, I don't know. If it is not acceptable to 'reference' DOSETA now and here, then how will the determination of its utility be made? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Thu Jun 2 16:21:51 2011 Return-Path: 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 A9067E0709; Thu, 2 Jun 2011 16:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.089 X-Spam-Level: X-Spam-Status: No, score=-105.089 tagged_above=-999 required=5 tests=[AWL=-2.490, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0vi4daJ2NNH; Thu, 2 Jun 2011 16:21:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DF821E06AB; Thu, 2 Jun 2011 16:21:50 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 637C8509DB; Thu, 2 Jun 2011 19:21:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 3 Jun 2011 09:21:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8AEC97B7-D39F-4234-A33C-533906E8485E@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447583CA782@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:21:51 -0000 On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Wednesday, June 01, 2011 5:16 PM >> To: Eran Hammer-Lahav >> Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG; >> 'Adam Barth (adam@adambarth.com)'; HTTP Working Group >> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >>=20 >>=20 >> On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >>=20 >>> This was suggested before, but are there really attack vectors for = this? >>=20 >> If not having a current, working attack to demonstrate is a valid way = to shrug >> off a security concern, that's great; it'll be a useful approach to = many of the >> discussions I have. :) >=20 > No, but its valid as long as it is fully documented. We're not going = to solve everything. >=20 >>> The problem is that content-type is a pretty flexible header, which = means >> normalization of the header will be required (case, parameter order, = white >> space, etc.). >>=20 >> The media type is the important part, and it's much more constrained. >=20 > So include just the: >=20 > type "/" subtype >=20 > forced to lowercase? Think so. >=20 >>=20 >>> I would argue that if you are using MAC with body hash and an = attacker >> changing the media type can cause harm, you should use additional = methods >> to secure the content-type (such as making the body self-describing). >>=20 >>=20 >> That seems like a step backwards, considering all of the work that = Adam has >> put into limiting the use of sniffing. >=20 > I wasn't suggesting sniffing. >=20 > EHL >=20 >> Cheers, >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Thu Jun 2 17:08:10 2011 Return-Path: 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 0FC9AE06FC for ; Thu, 2 Jun 2011 17:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBfR9Pnj2iZq for ; Thu, 2 Jun 2011 17:08:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 49523E06D7 for ; Thu, 2 Jun 2011 17:08:09 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E92B40046; Thu, 2 Jun 2011 18:08:08 -0600 (MDT) Message-ID: <4DE825E6.1040509@stpeter.im> Date: Thu, 02 Jun 2011 18:08:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040702020908080009040807" Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 00:08:10 -0000 This is a cryptographically signed message in MIME format. --------------ms040702020908080009040807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/2/11 4:11 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre > wrote: >=20 > I think I might have misunderstood that text -- I took it to be tal= king > about the client's authentication with the authorization server, no= t the > client's authentication with the resource server. >=20 >=20 > No, you understand perfectly. We're talking about giving extremely > powerful and near-permanent credentials to clients we can't > authenticate. We're pretty sure this is a good idea. =3D) >=20 > We authenticate the user and get their consent. If they say yes, the > client gets something that is almost, but not quite, equivalent to an > alternate password for the user. Sure, that's the classic OAuth pattern. I think the SHOULD we had originally is probably fine -- with the understanding that "SHOULD" means "you really ought to do this unless you have a good reason not to". I think one such really good reason might be a authorization server that doesn't allow unauthenticated clients (i.e., clients that are not pre-registered or don't have certificates or whatever). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040702020908080009040807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MzAwMDgwNlowIwYJKoZIhvcNAQkEMRYEFKfw1Ie/HGg2iaw5JZqRoG4fNtrAMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAze6bbh7a3F+mTyhKH8H8ZENw772aV3qYHj9nT4nGCHkLhF/OYlENUPIVO xX/LGfOgbag7j/WnUHJ7YE8vgg72+b4PhRZg8BS/nY4anFiR+3UM170HdSGOFPBlepQmPVAw Kq7ywrDJBzoD5YFDbr0RViNSqwi9yaPHr5wZSw2XAUnRYWtPpUKNBvTltZml7Q0UtvepWTCp AothuRHQ8J/o9rfxztGvbrRy9dsuF9vhRE9Q2Nk1vbDsHHoKUtG/MvIcKcNGXuLTB3luGIiP d9nWxfhuKZjMNxr2kOfi7ZqyZsIC1sm+wPX+cqI1DxzA+giggYi7ri08vb7VZi1ASlpBAAAA AAAA --------------ms040702020908080009040807-- From beaton@google.com Thu Jun 2 17:48:46 2011 Return-Path: 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 BF515E085A for ; Thu, 2 Jun 2011 17:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.933 X-Spam-Level: X-Spam-Status: No, score=-105.933 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+V0hvVbgitc for ; Thu, 2 Jun 2011 17:48:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0BE07E3 for ; Thu, 2 Jun 2011 17:48:45 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p530mifZ029391 for ; Thu, 2 Jun 2011 17:48:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307062125; bh=nPsJQzcvt1UId1zgt7IYDw+6L9o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qwJtQAEVcXmz0C1Z1JCAcynrQsuuO8oYtE71vyzpVkMhBwSLmZtDgulLor1/9nY8v PKK6AhlUEqoWJZrteI1gg== Received: from pvg3 (pvg3.prod.google.com [10.241.210.131]) by hpaq12.eem.corp.google.com with ESMTP id p530loVC010413 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 17:48:43 -0700 Received: by pvg3 with SMTP id 3so699852pvg.4 for ; Thu, 02 Jun 2011 17:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r2e8yW0VjC+xwVQPbnUXeUjkY4FtISimFuP0xitw7PQ=; b=apxGthfUaUVfY6uMm78Qeyk6tvew59vqXbMQI/jfyPnZkD1fQZ/Tm6DXV9wRI9NAwy SDuWsKSqdCu3geCnUD+g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BzEaxzjGicHo2pcaial9D83fqzHNlNgE/PiTcCONP+/YaA4xAzzGcGmt2gShas5SuU 869D7aZcojfTxKppXLBg== MIME-Version: 1.0 Received: by 10.143.154.11 with SMTP id g11mr269171wfo.38.1307062122645; Thu, 02 Jun 2011 17:48:42 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 2 Jun 2011 17:48:42 -0700 (PDT) In-Reply-To: <4DE825E6.1040509@stpeter.im> References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> <4DE825E6.1040509@stpeter.im> Date: Thu, 2 Jun 2011 17:48:42 -0700 Message-ID: From: Brian Eaton To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001636e0b96985094604a4c41df5 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 00:48:46 -0000 --001636e0b96985094604a4c41df5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre wrote: > I think the SHOULD we had originally is probably fine -- with the > understanding that "SHOULD" means "you really ought to do this unless > you have a good reason not to". I think one such really good reason > might be a authorization server that doesn't allow unauthenticated > clients (i.e., clients that are not pre-registered or don't have > certificates or whatever). Really? What are you thinking of as "limited duration" credentials for a desktop application? --001636e0b96985094604a4c41df5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:=
I think the SHOULD we had originally is probably fine -- = with the
understanding that "SHOULD" means "you really ought to do th= is unless
you have a good reason not to". I think one such really good reason might be a authorization server that doesn't allow unauthenticated
clients (i.e., clients that are not pre-registered or don't have
certificates or whatever).

Really? =A0What = are you thinking of as "limited duration" credentials for a deskt= op application?
--001636e0b96985094604a4c41df5-- From stpeter@stpeter.im Thu Jun 2 19:13:50 2011 Return-Path: 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 4483FE06A0 for ; Thu, 2 Jun 2011 19:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xal0QjvpVbgf for ; Thu, 2 Jun 2011 19:13:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74BE0717 for ; Thu, 2 Jun 2011 19:13:45 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EF6740046; Thu, 2 Jun 2011 20:13:44 -0600 (MDT) Message-ID: <4DE84355.8000303@stpeter.im> Date: Thu, 02 Jun 2011 20:13:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> <4DE825E6.1040509@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090908030902030101020302" Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:13:50 -0000 This is a cryptographically signed message in MIME format. --------------ms090908030902030101020302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/2/11 6:48 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre > wrote: >=20 > I think the SHOULD we had originally is probably fine -- with the > understanding that "SHOULD" means "you really ought to do this unle= ss > you have a good reason not to". I think one such really good reason= > might be a authorization server that doesn't allow unauthenticated > clients (i.e., clients that are not pre-registered or don't have > certificates or whatever). >=20 >=20 > Really? What are you thinking of as "limited duration" credentials for= > a desktop application? I'm not thinking about your use case, but things like enterprise deployments in high-security environments where every person and every software application has a certificate or is otherwise provisioned for authentication with the authorization server. However, I'm not saying we should change or add any text to the spec, because the SHOULD allows such deployments to not issue tokens to clients that are incapable of authenticating. So I don't particularly see a reason to keep discussing the matter. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090908030902030101020302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MzAyMTM0MVowIwYJKoZIhvcNAQkEMRYEFP7q1MKeeq049yI0n4scPXUL2QB5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCZUvOrW1urKo287ZjLNZOoaD9kAweoxjwoi74X/AVtQj91lSB8En4W/Su1 zil2HsP2yhJUs+OJQOV+8iokAtPkzJqIvMKROQZvmQVDL5tNSW21GWmv99mvbGdMOCrmyR88 HeR3Lp9oa4e4L5rAa9GCp+nP5vjJUALSgJkGwPkgvxzf8urs63IWfNzLLk+Nl7NrcUwxDIuH I7zLx4btVEB/3Akm5BHvnGTg18uS+W3KSWXl4Ns4Juv7nYgSjzOa1wJ7A0u2G1vG9ucZAj30 Nbu9LPvQrxVYX077OaXb1n8tq1BukouTIqHOGgvcDE8prNMAg1mMNikOmP0YtGPXRkmaAAAA AAAA --------------ms090908030902030101020302-- From beaton@google.com Thu Jun 2 19:38:23 2011 Return-Path: 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 15AA4E0674 for ; Thu, 2 Jun 2011 19:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZznrspNguci for ; Thu, 2 Jun 2011 19:38:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA48E06A0 for ; Thu, 2 Jun 2011 19:38:17 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p532cGkC023630 for ; Thu, 2 Jun 2011 19:38:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307068696; bh=SqW0n+3yqIkmOf5F2bzUHYXBIm4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=e9aP3ztPeKJQLZH6oMYOZ51XpquUJq2/B9H6Toz6SnW0F+vwqHGK7jHBpTvHwt3g1 wTBOv9o2zVQ1IyK2/sOwQ== Received: from pzk35 (pzk35.prod.google.com [10.243.19.163]) by kpbe14.cbf.corp.google.com with ESMTP id p532cEGm001350 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Jun 2011 19:38:15 -0700 Received: by pzk35 with SMTP id 35so663109pzk.25 for ; Thu, 02 Jun 2011 19:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qO6c9WpOa7lr0Um0bZSDjluLQDOY3Ak7xjthvZTyHlM=; b=MNnpIG1B0jSMljDRP7q+8DlTdSrV4v3yAY4YCmn52AFYon6BEdIb2j3DU3IsPEm/bx j6T2o3EhhusxmJ+j6RPg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=geeRXb8OLrLsL4/apukZRwHP4Y5ff2XHWwrM9+aE4BcazWKrHqG02VuTYG+32AY1PP fySgG65bgWNSg0l9hEgA== MIME-Version: 1.0 Received: by 10.142.221.1 with SMTP id t1mr243636wfg.437.1307068694283; Thu, 02 Jun 2011 19:38:14 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Thu, 2 Jun 2011 19:38:14 -0700 (PDT) In-Reply-To: <4DE84355.8000303@stpeter.im> References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> <4DE825E6.1040509@stpeter.im> <4DE84355.8000303@stpeter.im> Date: Thu, 2 Jun 2011 19:38:14 -0700 Message-ID: From: Brian Eaton To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd146963846c204a4c5a5b2 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:38:23 -0000 --000e0cd146963846c204a4c5a5b2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre wrote: > I'm not thinking about your use case, but things like enterprise > deployments in high-security environments where every person and every > software application has a certificate or is otherwise provisioned for > authentication with the authorization server. > I actually care quite a bit about that use case. =) > However, I'm not saying we should change or add any text to the spec, > because the SHOULD allows such deployments to not issue tokens to > clients that are incapable of authenticating. So I don't particularly > see a reason to keep discussing the matter. OK, I understand the confusion now. I'm going to continue to push for the security considerations to be broken up more cleanly by use case, in part to avoid confusion like this. --000e0cd146963846c204a4c5a5b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:=
I'm not thinking about your use case, but things like= enterprise
deployments in high-security environments where every person and every
software application has a certificate or is otherwise provisioned for
authentication with the authorization server.

I actually care quite a bit about that use case. =3D)
=A0<= /div>
However, I'm not saying we should change or add any text to the spec, because the SHOULD allows such deployments to not issue tokens to
clients that are incapable of authenticating. So I don't particularly see a reason to keep discussing the matter.

OK, I understand the confusion now.

I'm going= to continue to push for the security considerations to be broken up more c= leanly by use case, in part to avoid confusion like this.
--000e0cd146963846c204a4c5a5b2-- From stpeter@stpeter.im Thu Jun 2 19:53:33 2011 Return-Path: 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 3CB1AE0717 for ; Thu, 2 Jun 2011 19:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDRhmOrA-KDX for ; Thu, 2 Jun 2011 19:53:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 653F6E0674 for ; Thu, 2 Jun 2011 19:53:27 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CDA740046; Thu, 2 Jun 2011 20:53:26 -0600 (MDT) Message-ID: <4DE84CA3.9010002@stpeter.im> Date: Thu, 02 Jun 2011 20:53:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Eaton References: <4DE68847.8090808@stpeter.im> <4DE8083D.10907@stpeter.im> <4DE825E6.1040509@stpeter.im> <4DE84355.8000303@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060702050906090302020709" Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 02:53:33 -0000 This is a cryptographically signed message in MIME format. --------------ms060702050906090302020709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/2/11 8:38 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre > wrote: >=20 > I'm not thinking about your use case, but things like enterprise > deployments in high-security environments where every person and ev= ery > software application has a certificate or is otherwise provisioned = for > authentication with the authorization server. >=20 >=20 > I actually care quite a bit about that use case. =3D) I'm happy to hear it. There are so many interesting use cases in the world, aren't there? ;-) > However, I'm not saying we should change or add any text to the spe= c, > because the SHOULD allows such deployments to not issue tokens to > clients that are incapable of authenticating. So I don't particular= ly > see a reason to keep discussing the matter. >=20 >=20 > OK, I understand the confusion now. >=20 > I'm going to continue to push for the security considerations to be > broken up more cleanly by use case, in part to avoid confusion like thi= s. Probably a good idea. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060702050906090302020709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw MzAyNTMyM1owIwYJKoZIhvcNAQkEMRYEFA2UNBrfePW0Q4ugx2GLNysF9HGzMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAjQJ+HcXU9aEeB+buS+dP648rrGlSXx8dHfsaXa19ZH6YzQiU+nC5gL8fT dmVIHvOF49gB8Pl9GF+cN+pzx1y1bkTlYkqC71YFdNYyK/5zsSI5l3gYqE1RZNe+lJYbWY22 GkBRcU4zQ84gAj3eE/kqSuN+3amC0BrqJZMdxzMsLdDk6ZnIIPXJKQqy92aIED5l28KMvaQ6 a4plng0hIKr79z9qIPACpIj4uPgErT9bfk59l6Y7WKzuuf+bX8IrEurjmCv4e6/XfEnh9uIL 4SmYHJ7GQUNkaxyIUkhY9PX9CKcEiWh7LGH9mpwJhFS2Hcn5vA9ddPB0iRqtUvOhegwBAAAA AAAA --------------ms060702050906090302020709-- From sweeden@au1.ibm.com Thu Jun 2 23:05:34 2011 Return-Path: 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 91587E06A1 for ; Thu, 2 Jun 2011 23:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XJSPou5KTyf for ; Thu, 2 Jun 2011 23:05:34 -0700 (PDT) Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA9E068E for ; Thu, 2 Jun 2011 23:05:33 -0700 (PDT) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp08.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5360DDl020973 for ; Fri, 3 Jun 2011 16:00:13 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5365KQN1069260 for ; Fri, 3 Jun 2011 16:05:20 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5365KTC008674 for ; Fri, 3 Jun 2011 16:05:20 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5365JTK008648 for ; Fri, 3 Jun 2011 16:05:19 +1000 In-Reply-To: <1306944117.46982.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com> <1306944117.46982.YahooMailNeo@web31808.mail.mud.yahoo.com> X-KeepSent: 2DF5628A:B68CC335-4A2578A4:001EDD1A; type=4; name=$KeepSent To: oauth@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Shane B Weeden Date: Fri, 3 Jun 2011 16:05:16 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4|July 25, 2010) at 03/06/2011 16:08:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OAUTH-WG] Client Credentials and Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 06:05:34 -0000 Would anyone care to explain what the value of a refresh token is for peer to peer applications utilizing the client_credentials grant type, or validate if my explanation is the intended use case? Recall: * it is required to provide client credentials to get an access token [and refresh token] * it is also required to provide client credentials to exchange a refresh token for an access token (small assumption here based on recent discussions ... but I think it had better be for the client_credentials flow) * unlike the authorization code flow, there is no authorization step with the user involved that makes obtaining a new access token directly from the client credentials any less onerous than using a refresh token About the only use case I can contrive that makes any sense is when multiple instances of apps use the same client credentials (already a bad idea) and you want to revoke access to a subset of them. To do the revocation you would need to simultaneously: 1. Revoke the refresh token and any access tokens issued to compromised instances 2. Update the client secret (or whatever authentication method clients have) on those client instances that are still considered ok. In a deployment where each client has it's own credentials, which should be "situation normal" from a security perspective, I don't see any value for the refresh token. I also cringe at the idea of someone suggesting that refresh token can be presented without client credentials - in this case that's like saying client X has n passwords, where n is the number of issued refresh tokens. Better to create n sets of client credentials in the first place. Thanks, Shane. From torsten@lodderstedt.net Thu Jun 2 23:09:22 2011 Return-Path: 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 65142E068E for ; Thu, 2 Jun 2011 23:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RkqlswdT-2W for ; Thu, 2 Jun 2011 23:09:21 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id E3982E069C for ; Thu, 2 Jun 2011 23:09:20 -0700 (PDT) Received: from [91.14.186.238] (helo=[192.168.1.250]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QSNZN-0002X3-Ub; Fri, 03 Jun 2011 08:09:18 +0200 References: <4DE68847.8090808@stpeter.im> <4DE75359.6070109@lodderstedt.net> <4DE7E4FE.7090606@alcatel-lucent.com> <4DE80414.40106@alcatel-lucent.com> User-Agent: K-9 Mail for Android In-Reply-To: <4DE80414.40106@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----IBYAYMN6DQ3L97SJ2OB2V9X3T3EO69" From: Torsten Lodderstedt Date: Fri, 03 Jun 2011 08:09:13 +0200 To: igor.faynberg@alcatel-lucent.com Message-ID: <5edabcec-d73c-4dfc-94a4-97d89af84699@email.android.com> X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 06:09:22 -0000 ------IBYAYMN6DQ3L97SJ2OB2V9X3T3EO69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Got it. End-user authentication via USIM is indeed secure (and convenient). regards, Torsten. Igor Faynberg schrieb: As far the authentication goes, what I had in mind was that the network provider could authenticate the end-user. Alternatively, an application (not necessarily the USIM) on the smart card could hold the secret and perform all cryptographic operations (what Thomas calls crypto-store). In either case, only the provider and the card would share the secret. Igor Torsten Lodderstedt wrote: > in my opinion, the problem with client authentication is more the > secure distribution of the secret than the storage. How should a USIM > help here? > > regards, > Torsten. > > > > Thomas Hardjono schrieb: > > Thanks Igor, > > If you bring smartcards into the picture, then it's a different > ballgame :) > > If mobile phones are assumed to have smartcards (which is increasingly > true today via USIMs), then OAUTH can assume that native apps (running > on the phones) may have access to crypto-store. In this case the text > in Section 9 of draft-16 would needs changes/clarifications. > > /thomas/ > > > __________ > > > -----Original Message----- > > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > > Sent: Thursday, June 02, 2011 3:31 PM > > To: Thomas Hardjono > > Cc: Torsten Lodderstedt; OAuth WG > > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > > > Actually, for the devices that use smart cards (mobile devices, in > > particular), this assumption is quite appropriate.> > > > Igor > > > > Thomas Hardjono wrote: > > >> .... > > > ... > > > > > > However, there is indeed the assumption in Kerberos/RFC4120 (and > in > > the original Needham-Schroeder protocol) that the "client" can keep > > secrets. > > > > > > /thomas/ > > > > > > > > > > > > >_____________________________________________ > > > > > > > > > ------IBYAYMN6DQ3L97SJ2OB2V9X3T3EO69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Got it. End-user authentication via USIM is indeed secure (and convenient).

regards,
Torsten.



Igor Faynberg <igor.faynberg@alcatel-lucent.com> schrieb:
As far the authentication goes, what I had in mind was that the network 
provider could authenticate  the end-user. Alternatively, an application 
(not necessarily the USIM) on the smart card could hold the secret and 
perform all cryptographic operations (what Thomas calls crypto-store). 
In either case, only the provider and the card would share the secret.

Igor

Torsten Lodderstedt wrote:
> in my opinion, the problem with client authentication is more the 
> secure distribution of the secret than the storage. How should a USIM 
> help here?
>
> regards,
> Torsten.
>
>
>
> Thomas Hardjono <hardjono@MIT.EDU> schrieb:
>
>     Thanks Igor,
>
>     If you bring smartcards into the picture, then it's a different
>     ballgame :)
>
>     If mobile phones are assumed to have smartcards (which is increasingly
>     true today via USIMs), then OAUTH can assume that native apps (running
>     on the phones) may have access to crypto-store. In this case the text
>     in Section 9 of draft-16 would needs changes/clarifications.
>
>     /thomas/
>
>
>     __________
>
>     > -----Original Message-----
>     > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
>     > Sent: Thursday, June 02, 2011 3:31 PM
>     > To: Thomas Hardjono
>     > Cc: Torsten Lodderstedt; OAuth WG
>     > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
>     > 
>     > Actually, for the devices that use smart cards (mobile devices, in
>     > particular), this assumption is quite appropriate.>
>
>     > Igor<
 br
/>>     > 
>     > Thomas Hardjono wrote:
>     > >> ....
>     > > ...
>     > >
>     > > However, there is indeed the assumption in Kerberos/RFC4120 (and
>     in
>     > the original Needham-Schroeder protocol) that the "client" can keep
>     > secrets.
>     > >
>     > > /thomas/
>     > >
>     > >
>     > >
>     > >
>

>
>     > >
>     > >
>         
>
------IBYAYMN6DQ3L97SJ2OB2V9X3T3EO69-- From skylar@kiva.org Fri Jun 3 01:46:21 2011 Return-Path: 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 3DB94E0696 for ; Fri, 3 Jun 2011 01:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwVmz7dYCKXx for ; Fri, 3 Jun 2011 01:46:20 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 1F6D1E068B for ; Fri, 3 Jun 2011 01:46:19 -0700 (PDT) Received: from mail-wy0-f174.google.com ([74.125.82.174]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTeifWpBwD8qXyhwOHOL5ROqVgNX+tjUv@postini.com; Fri, 03 Jun 2011 01:46:20 PDT Received: by wya21 with SMTP id 21so1876982wya.33 for ; Fri, 03 Jun 2011 01:46:17 -0700 (PDT) Received: by 10.216.221.29 with SMTP id q29mr7034820wep.6.1307090777125; Fri, 03 Jun 2011 01:46:17 -0700 (PDT) Received: from scrito.lan (85-168-239-169.rev.numericable.fr [85.168.239.169]) by mx.google.com with ESMTPS id ge4sm885987wbb.13.2011.06.03.01.46.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2011 01:46:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Fri, 3 Jun 2011 10:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <203CA1F3-E5AB-4B92-91E6-EBC08CD9EF96@kiva.org> References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> To: Dave Nelson X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:46:21 -0000 This may be true for a "secret" of sorts in some applications, but not = for the client_credential in OAuth. The client secret is the only = element that can secure the identity of the app and if it is compromised = then so is the ability of the app to assert its identity. There's no way = a software program on a open mass-market runtime can secure the secret = as a part of its own software distribution (and likely true for any = mass-distirbuted system) . So we should stick with the advisement that = apps that can't keep secrets not be issued them - its a big win for = setting the correct expectations to developers and users over 1.0. If the client_secret were merely one element in protecting access maybe = this your suggestion would be true. However, given the difficulty of = embedding and obfuscating a secret in a hard-to-find way, and the = requirement that every developer would have to do this in his own = proprietary and secret way, it seems not a scalable solution for the = multitudes of apps that will be OAuth clients. It's better for = developers to consider other mechanisms - starting with secure = distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: >=20 >> Well, "rely" is a strong-term. I know of various teams who do this. = I >> don't know of any teams that put a heavy reliance on it. >=20 > It might validly be just one element of a defense-in-depth strategy. >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 From torsten@lodderstedt.net Fri Jun 3 01:58:48 2011 Return-Path: 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 101F8E0701 for ; Fri, 3 Jun 2011 01:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5t5h1YJYIek for ; Fri, 3 Jun 2011 01:58:47 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5FE06F1 for ; Fri, 3 Jun 2011 01:58:46 -0700 (PDT) Received: from [80.187.96.122] (helo=nothing) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QSQDL-0005Dj-Ry; Fri, 03 Jun 2011 10:58:44 +0200 References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> <203CA1F3-E5AB-4B92-91E6-EBC08CD9EF96@kiva.org> User-Agent: K-9 Mail for Android In-Reply-To: <203CA1F3-E5AB-4B92-91E6-EBC08CD9EF96@kiva.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----CKLE4VR0J0J44QCDDG8LWCX83AKISC" From: Torsten Lodderstedt Date: Fri, 03 Jun 2011 10:58:36 +0200 To: Skylar Woodward ,Dave Nelson Message-ID: X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:58:48 -0000 ------CKLE4VR0J0J44QCDDG8LWCX83AKISC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit +1 Skylar Woodward schrieb: This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: > >> Well, "rely" is a strong-term. I know of various teams who do this. I >> don't know of any teams that put a heavy reliance on it. > > It might validly be just one element of a defense-in-depth strategy. > > Regards, > > Dave > > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 _____________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------CKLE4VR0J0J44QCDDG8LWCX83AKISC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1



Skylar Woodward <skylar@kiva.org> schrieb:
This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0.

If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his 
 own
proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software.

skylar


On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote:

> On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton <beaton@google.com> wrote:
> 
>> Well, "rely" is a strong-term.  I know of various teams who do this.  I
>> don't know of any teams that put a heavy reliance on it.
> 
> It might validly be just one element of a defense-in-depth strategy.
> 
> Regards,
> 
> Dave
> 
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------CKLE4VR0J0J44QCDDG8LWCX83AKISC-- From stephen.farrell@cs.tcd.ie Fri Jun 3 05:26:59 2011 Return-Path: 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 C2180E0714; Fri, 3 Jun 2011 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpMnUKF7BM61; Fri, 3 Jun 2011 05:26:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B4A26E06D3; Fri, 3 Jun 2011 05:26:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 49D41171C30; Fri, 3 Jun 2011 13:26:55 +0100 (IST) 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=1307104014; bh=Q+JdJI1kXBA9eH 9b6Y2qCB0QRbUR9H7RHhiWCvjUFeo=; b=N1PKaHRptFYeLUajLdGdur0Ld5LqE0 HDQhAvu/rkDmIz/pMpxIsn/xp0YhfCrvAtZDQ3Ckz4pe0PGUSRB/b4TyISIpNk5L Ut6/1asppg+oA4/BTDaK78mO9wd+TvhUXp45fQ5C764h2n3xdmNcKfbnZbap8KtZ w03WP+l5n27LTfv+KLoMWQh5V4zDTyrv1FUqQCAf2rucEmDlcg4DiDs1ALGWn4Cf 9Eqqh8HCNRD5t6jl9vTvgXxHrLf4RKyiJMqyuocfjGBvW2eHosPx7zAymzl94dZP cLIcOHy7dXl/cfTDl5J6kf4W2VdZayPXy0jVKKodwzKxu9IK0tMPlWEQ== 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 bBe2TUES7iDn; Fri, 3 Jun 2011 13:26:54 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 74227171C2E; Fri, 3 Jun 2011 13:26:51 +0100 (IST) Message-ID: <4DE8D2F4.1050103@cs.tcd.ie> Date: Fri, 03 Jun 2011 13:26:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE62D93.7040009@cs.tcd.ie> <4DE7FDA7.8030300@dcrocker.net> In-Reply-To: <4DE7FDA7.8030300@dcrocker.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dave CROCKER , OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:26:59 -0000 Hi Dave, On 02/06/11 22:16, Dave CROCKER wrote: > Stephen, > > On 6/1/2011 5:16 AM, Stephen Farrell wrote: >> Just on DOSETA - that's not currently got any official >> home in the IETF so its not something that would be right >> to reference at this point (unless the oauth WG wanted to >> adopt DOSETA but I'd be very surprised if that were the >> case for timing reasons). > > I'm confused on two counts. (To be honest, of course, I'm confused > about many points, but two of them are relevant to this thread...) > > One, of course, is that I've been actively raising DOSETA in various > IETF venues for the different groups to considering adopting and/or > adapting it. As such, discussion of DOSETA permits exploring the > possibility of adoption and/or adaptation. I don't get the confusion aspect there, but the rest below might clarify. > The second is that you appear to be stating a policy that a working > group is only permitted to reference things which are currently and > officially IETF work items. I suspect that that is not what you meant, > so at the least, please clarify what you do mean. Right. I wasn't stating any general policy. What I meant was that the oauth WG needs to get oauth2.0 done and that seems to require also getting the mac scheme done, so adding a dependency to something at an early stage of development (like DOSETA) at this point would not be a good plan for oauth. That's all. Exploring whether DOSETA or something similar is useful is a fine thing to do, its just a bit early for oauth. > If you really do mean anything like the interpretation I just > summarized, please explain its basis. > >> To be clear, as an individual, I do think that "something >> like DOSETA" is a really good idea and maybe DOSETA will >> turn out to be that something, I don't know. > > If it is not acceptable to 'reference' DOSETA now and here, then how > will the determination of its utility be made? Following our usual highly-predictable process I guess;-) I assume that the next step would be for a bunch of interested folks to figure out where and when it might make sense to do more on DOSETA. S. > > > Thanks. > > d/ > From hannes.tschofenig@gmx.net Fri Jun 3 05:45:55 2011 Return-Path: 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 DCFF1E069E for ; Fri, 3 Jun 2011 05:45:55 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSxeNReCaMim for ; Fri, 3 Jun 2011 05:45:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9F20BE0714 for ; Fri, 3 Jun 2011 05:45:54 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2011 12:45:51 -0000 Received: from unknown (EHLO [10.255.129.99]) [192.100.123.77] by mail.gmx.net (mp035) with SMTP; 03 Jun 2011 14:45:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/oc2kQqsjoc69ce4RDkmjyuVxm9dIMK8lc7KsyPl y19jALTjgFEYPx From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2011 15:45:48 +0300 Message-Id: <851C8F84-373C-47A4-A6CA-A169F870FC71@gmx.net> To: oauth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth Interim Meeting: Polished Meeting Notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:45:56 -0000 Meeting Minutes, OAuth Interim Meeting, 23rd May 2011 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Scribe: Bill Mills (post-processing by Hannes Tschofenig) Participants:=20 ** in person **=20 - Hannes Tschofenig=20 - Jonas Hogberg - Bill Mills - Marius Scurtescu - Andrew Wansley=20 - Breno de Medeiros=20 - Thomas Roessler - Mike Jones - Kihara Boku - Hayashi Tatsuya - Yutaka Oiwa - Harry Halpin - David Recordon - Tony Nadalin - Matthew Sutkus - David Robinson - Skylar Woodward - Chuck Mortimore - Phil Hunt - Dale Olds - Paul Tarjan ** on the conference bridge ** - Lucy Lynch - Brian Campbell - Igor Faynberg - Peter Saint-Andre - Axel Nennker - Karen O'Donoghue - Doug Tangren =20 Agenda:=20 1. draft-ietf-oauth-v2-16 ------------------------- *** Client Authentication ***=20 Concern that Section 3 and 3.1 do not clearly show a way for a native = client to provide client_id (to identify the client only) without doign = authentication. Proposed new text, insert in bold: =20 "In addition, the authorization server MAY allow unauthenticated = access token requests when the client identity does not matter (e.g. = anonymous client), when client authenitcation is not practical, or when = the client identity is established via other means." Last paragraph, section 3, proposed new text, reversing the order, = putting "since ..." at the end of the sentence: The authorization server MUST require the use of a transport-layer = security mechanism when sending requests to exchange an the token = endpoint since requests using a method other than client password this = authentication method result in the transmission of clear-text = credentials. 3.1 edit first paragraph Delete: "(the client identifier together with a shared symmetric secret = secret)" *** Error Description ***=20 Agreement among the participants that the error codes are meant for = consumption by the developer rather than the end user. Hence, language = codes are not important nor a human readable version that is supposed to = be understood by end users.=20 Section 4.1.2.1. Error Response -- Character set for error_description=20= becomes "OPTIONAL. Human-readable UTF-8 encoded text providing = additional information, used to assist to the developer in understanding = the error that occurred." Section 4.1.2.1. Error URI -- "resource owner" becomes "developer" *** Error URIs ***=20 Agreement among the participants that the error codes are meant for = consumption by the developer rather than the end user. =20 error_uri OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the developer with additional information about the error. *** Error Response Codes *** This is considered a possible area for confusion between the HTTP error = code and the error code returned in protocol. The agreement among the participants was to remove all HTTP error codes = and to investigate whether there is a need to add new error codes.=20 TODO: Eran H-L to look at which HTTP error codes should be mapped in to = protocol specific error codes. Section 4.1.2.1. Error -- remove HTTP 4xx and 5xx error code as an = allowed "error" value =20 Section 4.2.2.1. Error Response -- ibid *** Security *** Section 10.10 Session fixation... Breno does not feel that session fixation is properly described nor = dealt with. =20 Igor is providing reference links to session fixation description (mail = to the list). TODO: Breno@google.com is working on new draft language.=20 Section 10.13. XSRF/CSRF Prevention TODO: Breno and Bill M. working on new draft text. *** Native applications *** Objections that this recommends against things that are extant = implementations. TODO: Chuck N. to draft revised text. Discussion on the list: = http://www.ietf.org/mail-archive/web/oauth/current/msg06394.html Followed by = http://www.ietf.org/mail-archive/web/oauth/current/msg06444.html *** Extensibility *** TODO: Hannes will look at policy for using IETF URN TODO: Mike J./Chuck N. to draft 4.5.1 subsection on assertions. = Clarifying the use case there and suggested behavior. Discussion on the list: = http://www.ietf.org/mail-archive/web/oauth/current/msg06387.html - Proposed additions=20 - "Immediate Mode" with display=3D and response=3D - response_type=3D{none, cookie} TODO: Paul Tarjan to send proposed requirements to the list. TODO: Eran to add extensibilty language for this based on requirements. *** Redirect URI ***=20 Recommendation made that "RedirectURI" should be optional TODO: Eran to send mail to the list proposing language changes to either = change this from REQUIRED to OPTIONAL and add clarifying language, or = leave as required and add a pre-defined value for "we're not actually = using this". Discussion on the list: = http://www.ietf.org/mail-archive/web/oauth/current/msg06419.html *** Encoding *** Section 4.3 (and 3.1) Username/Password: Need to figure out what the = encoding will be here, since these can be outside the ascii charset. TODO: Peter St.A to review the language. Peter's more complete review is here: = http://www.ietf.org/mail-archive/web/oauth/current/msg06520.html *** Client credentials ***=20 TODO: Tony N./Chuck N. to propose new spec to handle assertions both = for authentication and authorization. *** Client ID ***=20 Client ID is not specified. Discussion on the list: = http://www.ietf.org/mail-archive/web/oauth/current/msg06389.html 2. draft-ietf-oauth-v2-bearer-05=20 -------------------------------- MIke J. reviewing changes in Draft 5. - 2. Authenticated requests Discussed possible language change and oped for no change. - 400 vs 401 return TODO: Mike Jones to follow up with HTTP WG or representatives and ask = whether there are objections. NOTE: Mark Nottingham (in the HTTP community says that either 400 or = 401 are acceptible in most cases. - can we move from 403 to 401? Eran's statement is that 403 is sematically correct in HTTP. Probably = true. 3. draft-ietf-oauth-v2-http-mac-00=20 ---------------------------------- Eran ran through the current status. Only significant issue at this time is body hash. Seems to be a thorny = issue, he is looking for actual implementer experience. 4. draft-ietf-oauth-saml2-bearer-04=20 ----------------------------------- Brian Campbell: No recent feedback on the list. Not sure whether that's = good or just no attention on SAML. From d.tangren@gmail.com Fri Jun 3 06:42:34 2011 Return-Path: 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 D4AC7E069E for ; Fri, 3 Jun 2011 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A7e5aADsHi5 for ; Fri, 3 Jun 2011 06:42:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B782E065D for ; Fri, 3 Jun 2011 06:42:34 -0700 (PDT) Received: by iyn15 with SMTP id 15so1987639iyn.31 for ; Fri, 03 Jun 2011 06:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sXi2jvAryW0oSEzi9akhCbIppmpH/YVbx+q7+8z0oRo=; b=ViL5G5vJaCCb+nBQOZCPvemcNG3qZDbRZrhRd+faNmE1k57MQozZfFRZDZ9uQ45bWr oXeocfARPBETAJt3+DWKPMN2yegVNcdiB3F8E7J2TxPVx6ybbYcY2INvKzyV/9UwKxli keXoB8+pCid3KSezkS2He0hnBtHUiB3Ym8H+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=cU1dAfNXKSZRQyuxF9TPF4Lxd5/RTPDVGcrP4SYtJevoCWVW79wcmDwA2w+mIpEVXk hM26UyEyiSw+eeNMXPxq61PFSoVW+QDTe/LVrieWl/qmnC0vwSk1fev9/GYDuuuhDp6y Bt0iZ8JemvPGmFE2/FIq2coJ6bdQI0kNbVJcU= Received: by 10.42.212.8 with SMTP id gq8mr3589571icb.392.1307108553131; Fri, 03 Jun 2011 06:42:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Fri, 3 Jun 2011 06:42:13 -0700 (PDT) In-Reply-To: <851C8F84-373C-47A4-A6CA-A169F870FC71@gmx.net> References: <851C8F84-373C-47A4-A6CA-A169F870FC71@gmx.net> From: Doug Tangren Date: Fri, 3 Jun 2011 09:42:13 -0400 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=20cf301d43b0fe084704a4ceecbb Cc: oauth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting: Polished Meeting Notes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 13:42:34 -0000 --20cf301d43b0fe084704a4ceecbb Content-Type: text/plain; charset=UTF-8 Thanks for posting this Hannes -Doug Tangren http://lessis.me On Fri, Jun 3, 2011 at 8:45 AM, Hannes Tschofenig wrote: > Bill Mills (post-processi --20cf301d43b0fe084704a4ceecbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for posting this Hannes

-Doug Tangren
http://lessis.me


On Fri, Jun 3, 2011 at 8:45 AM, Hannes T= schofenig <hannes.tschofenig@gmx.net> wrote:
Bill Mills (post-processi

--20cf301d43b0fe084704a4ceecbb-- From wmills@yahoo-inc.com Fri Jun 3 08:02:49 2011 Return-Path: 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 1ABC5E06F7 for ; Fri, 3 Jun 2011 08:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.01 X-Spam-Level: X-Spam-Status: No, score=-17.01 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW7yi-Crvq-n for ; Fri, 3 Jun 2011 08:02:48 -0700 (PDT) Received: from nm2-vm6.bullet.mail.ne1.yahoo.com (nm2-vm6.bullet.mail.ne1.yahoo.com [98.138.91.254]) by ietfa.amsl.com (Postfix) with SMTP id B6B41E06E9 for ; Fri, 3 Jun 2011 08:02:47 -0700 (PDT) Received: from [98.138.90.57] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2011 15:02:47 -0000 Received: from [98.138.87.5] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2011 15:02:47 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 03 Jun 2011 15:02:36 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 893864.53278.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 92754 invoked by uid 60001); 3 Jun 2011 15:02:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307113356; bh=7NSyJFxIqpQcARzeJ73tVgYdLCdS16bZFeUN5F3Om/A=; 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=GrHTcziU6IHhRs/Jmf/TzL7JWj8Qqx3wbLigDej6qR4N88fsje/qITRkd2AnL1QNR6tQ4FgU4smqHf9QonTw96ynAkPp+c3L7mQ6mpyDuUetvtQIRglIVCF/Yb0Nn9LzYmPEQBYBqsDdY2JSv2f+TvpkTJXdZi7nHeVkvEv7Cgo= 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=i0WcRnW+z1qZ1ZFHgGoftcHSYOei/LdoighkM/ZKXDBwMtCSujg9yp2lXT3RB6PI+KRI1oFaw4lWbzw6ti+CbMIh2LvKxepPi316gSTXW5Z7wvV1BKYq4K7pK8qflOigwOpC9yEo+upmMxcRf/0LZ1zSbqUspKqexVKM/QktCIA=; X-YMail-OSG: wdIxtC8VM1lYAoEKFbaOptacrBospp6OmUA5Q8eZIv4kqDv r04pEaQrSHz8OD5.C1IEkmIWjUR6EcWi4ancFc7K6oQlFdUWBOwvS938Vflh g5o572BbvArl5f_IA7xMPR2llg1fjJYGYc5nBchYB_D57Gmd199OgIvR5ytO VA55EUDziR8NcxvrSYOH0tMGyZ3JtuvSbgCkeJKoPYtIPCWFmKx3b1XmBKpC LWzlBgG0Ptpxg2mq1hs0MKnFBWhdjIv6CQblv6h14f4OWzpyKeYUE7UK.RS4 hl5jLyBql7n5wuiiDfjtyXZdUlU7FMzq13kIKpbdKEB6NRKOxEBaF7IbuVzH z1GkxAeDi2Rp4nBQDNwDTo1asDX6zMpcSyg7lMN0dw5oTVAiScXBR2V_vdXj Vqd5elmg1xY9S9X7H_Kd4NALolLGe3887948glEA- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Fri, 03 Jun 2011 08:02:36 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <4DE5EE7F.4040907@lodderstedt.net> <28715F7E-4774-4940-872B-66E512BA6091@kiva.org> <1307050270.49342.YahooMailNeo@web31813.mail.mud.yahoo.com> <203CA1F3-E5AB-4B92-91E6-EBC08CD9EF96@kiva.org> Message-ID: <1307113356.87890.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 3 Jun 2011 08:02:36 -0700 (PDT) From: "William J. Mills" To: Torsten Lodderstedt , Skylar Woodward , Dave Nelson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1324568453-1307113356=:87890" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:02:49 -0000 --0-1324568453-1307113356=:87890 Content-Type: text/plain; charset=us-ascii +1 ________________________________ From: Torsten Lodderstedt To: Skylar Woodward ; Dave Nelson Cc: "oauth@ietf.org" Sent: Friday, June 3, 2011 1:58 AM Subject: Re: [OAUTH-WG] Text for Native Applications +1 Skylar Woodward schrieb: This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. > >If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. > >skylar > > >On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > >> On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: >> >>> Well, "rely" is a strong-term. I know of various teams who do this. I >>> don't know of any teams that put a heavy reliance on it. >> >> It might validly be just one element of a defense-in-depth strategy. >> >> Regards, >> >> Dave >> >> David B. Nelson >> Sr. Software Architect >> Elbrys Networks, Inc. >> www.elbrys.com >> +1.603.570.2636 > >>________________________________ > >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 --0-1324568453-1307113356=:87890 Content-Type: text/html; charset=us-ascii
+1

From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Skylar Woodward <skylar@kiva.org>; Dave Nelson <dnelson@elbrys.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, June 3, 2011 1:58 AM
Subject: Re: [OAUTH-WG] Text for Native Applications

+1



Skylar Woodward <skylar@kiva.org> schrieb:
This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0.

If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would
 have to do this in his 
 own
proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software.

skylar


On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote:

> On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton <beaton@google.com> wrote:
> 
>> Well, "rely" is a strong-term.  I know of various teams who do this.  I
>> don't know of any teams that put a heavy reliance on it.
> 
> It might validly be just one element of a defense-in-depth strategy.
> 
> Regards,
> 
> Dave
> 
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636


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


--0-1324568453-1307113356=:87890-- From mscurtescu@google.com Fri Jun 3 09:45:56 2011 Return-Path: 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 51E9AE07AC for ; Fri, 3 Jun 2011 09:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfHT-3rIdS6G for ; Fri, 3 Jun 2011 09:45:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id EAF30E06D5 for ; Fri, 3 Jun 2011 09:45:48 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p53GjlEO019799 for ; Fri, 3 Jun 2011 09:45:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307119547; bh=erbWL6FKSwR+zIJpR8Rv/TBQNL8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=J0QU027/XK8lh2T79k2zggHD0uj9vQTicOw2fAr3l/k24a5lKjGYDLH5JIy1XiIeV He56PV/rErEy5zglMmGng== Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by hpaq11.eem.corp.google.com with ESMTP id p53GjTuA011526 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2011 09:45:46 -0700 Received: by ywa6 with SMTP id 6so1122450ywa.16 for ; Fri, 03 Jun 2011 09:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Nb2Qmnn1NkmKN7f0c3kpPD2ZnFDZnj7Id6KFNhmhezs=; b=qvyVWPJ9dp49TL+MhiIfXrRy2LuCddO2h2XCinBgKsCH59hUBp3DcusYmbALqBJwts uDKYEJecHVQp4OsOvjrg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=XO+6cgUgR7ecUroULjrrDvKHXNUo4lTFWpaVXPuJ7ylJoQC6dSZyACQq83C+XucFFR deyWjY9XNiWVOLAHWxmQ== Received: by 10.100.201.3 with SMTP id y3mr1580947anf.13.1307119546135; Fri, 03 Jun 2011 09:45:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.14.19 with HTTP; Fri, 3 Jun 2011 09:45:26 -0700 (PDT) In-Reply-To: References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com> <1306944117.46982.YahooMailNeo@web31808.mail.mud.yahoo.com> From: Marius Scurtescu Date: Fri, 3 Jun 2011 09:45:26 -0700 Message-ID: To: Shane B Weeden Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Client Credentials and Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:45:56 -0000 On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden wrote= : > Would anyone care to explain what the value of a refresh token is for pee= r > to peer applications utilizing the client_credentials grant type, =A0or > validate if my explanation is the intended use case? Are you asking why would an authorization server issue a refresh token when the client credentials grant type is used? My guess is that in most cases authorization servers will not issue a refresh token in this case. Refresh tokens are optional, see sections 4.4.3 and 5.1. I think that the example in 4.4.3 should show only an access token. Also, section 4.4.3 should probably state that in this case the authorization server SHOULD not issue a refresh token. Section numbers are for draft 16. Marius > > Recall: > * it is required to provide client credentials to get an access token [an= d > refresh token] > * it is also required to provide client credentials to exchange a refresh > token for an access token (small assumption here based on recent > discussions ... but I think it had better be for the client_credentials > flow) > * unlike the authorization code flow, there is no authorization step with > the user involved that makes obtaining a new access token directly from t= he > client credentials any less onerous than using a refresh token > > About the only use case I can contrive that makes any sense is when > multiple instances of apps use the same client credentials (already a bad > idea) and you want to revoke access to a subset of them. To do the > revocation you would need to simultaneously: > 1. Revoke the refresh token and any access tokens issued to compromised > instances > 2. Update the client secret (or whatever authentication method clients > have) on those client instances that are still considered ok. > > In a deployment where each client has it's own credentials, which should = be > "situation normal" from a security perspective, I don't see any value for > the refresh token. I also cringe at the idea of someone suggesting that > refresh token can be presented without client credentials - in this case > that's like saying client X has n passwords, where n is the number of > issued refresh tokens. Better to create n sets of client credentials in t= he > first place. > > Thanks, > Shane. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Fri Jun 3 10:09:36 2011 Return-Path: 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 5B070E078B for ; Fri, 3 Jun 2011 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.077 X-Spam-Level: X-Spam-Status: No, score=-106.077 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjfzA158P8jp for ; Fri, 3 Jun 2011 10:09:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 71534E0784 for ; Fri, 3 Jun 2011 10:09:35 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p53H9Y94007679 for ; Fri, 3 Jun 2011 10:09:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307120974; bh=DPLZq4SgC9FPyqsXANIfqPiEhw0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Mfr0NmgJtauR88XeeX2AuntZf8sV2gv7DxY09LrCEz2X2K7gl+mlAg2it+NekhC4s sR4bdhEwa2gDaGF7wYdOQ== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq1.eem.corp.google.com with ESMTP id p53H9FKA007911 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2011 10:09:33 -0700 Received: by pwj8 with SMTP id 8so1765991pwj.27 for ; Fri, 03 Jun 2011 10:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nemTBSP7acylIsG86woxq7q9VKmghnKn5WYs3s+OWbg=; b=L1A8lBT2v4MqSof7ND22l0OHoNJZmTBw/TI5NR5fGIS4tl6RreHui7WVVgqIVf1Eu0 fnmjvDMlqMwxRrVBxfZA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MGj5t8Rv4LnqoSyNmv2X78miXasRGlabPMLUKbyI4ehzLqT2Zcuki0n8n9rK+3NneX ip6wLibO3MkxUngVe9/w== MIME-Version: 1.0 Received: by 10.142.248.41 with SMTP id v41mr376501wfh.323.1307120972621; Fri, 03 Jun 2011 10:09:32 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Fri, 3 Jun 2011 10:09:32 -0700 (PDT) In-Reply-To: References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com> <1306944117.46982.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 3 Jun 2011 10:09:32 -0700 Message-ID: From: Brian Eaton To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Client Credentials and Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 17:09:36 -0000 Agreed, it's nuts to return a refresh token for that flow. Eran, why is this still in the spec? =A0You agreed to remove it almost a year ago. It's come up multiple times since then. http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html Cheers, Brian On Fri, Jun 3, 2011 at 9:45 AM, Marius Scurtescu wr= ote: > > On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden wro= te: > > Would anyone care to explain what the value of a refresh token is for p= eer > > to peer applications utilizing the client_credentials grant type, =A0or > > validate if my explanation is the intended use case? > > Are you asking why would an authorization server issue a refresh token > when the client credentials grant type is used? > > My guess is that in most cases authorization servers will not issue a > refresh token in this case. Refresh tokens are optional, see sections > 4.4.3 and 5.1. > > I think that the example in 4.4.3 should show only an access token. > Also, section 4.4.3 should probably state that in this case the > authorization server SHOULD not issue a refresh token. > > Section numbers are for draft 16. > > Marius > > > > > Recall: > > * it is required to provide client credentials to get an access token [= and > > refresh token] > > * it is also required to provide client credentials to exchange a refre= sh > > token for an access token (small assumption here based on recent > > discussions ... but I think it had better be for the client_credentials > > flow) > > * unlike the authorization code flow, there is no authorization step wi= th > > the user involved that makes obtaining a new access token directly from= the > > client credentials any less onerous than using a refresh token > > > > About the only use case I can contrive that makes any sense is when > > multiple instances of apps use the same client credentials (already a b= ad > > idea) and you want to revoke access to a subset of them. To do the > > revocation you would need to simultaneously: > > 1. Revoke the refresh token and any access tokens issued to compromised > > instances > > 2. Update the client secret (or whatever authentication method clients > > have) on those client instances that are still considered ok. > > > > In a deployment where each client has it's own credentials, which shoul= d be > > "situation normal" from a security perspective, I don't see any value f= or > > the refresh token. I also cringe at the idea of someone suggesting that > > refresh token can be presented without client credentials - in this cas= e > > that's like saying client X has n passwords, where n is the number of > > issued refresh tokens. Better to create n sets of client credentials in= the > > first place. > > > > Thanks, > > Shane. > > > > _______________________________________________ > > 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 From hannes.tschofenig@gmx.net Mon Jun 6 05:45:57 2011 Return-Path: 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 E368511E813B for ; Mon, 6 Jun 2011 05:45:57 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hCj+ekqmZOB for ; Mon, 6 Jun 2011 05:45:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E2B0C11E8138 for ; Mon, 6 Jun 2011 05:45:56 -0700 (PDT) Received: (qmail invoked by alias); 06 Jun 2011 12:45:55 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.2]) [194.29.195.214] by mail.gmx.net (mp049) with SMTP; 06 Jun 2011 14:45:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+5btIU/pm5wrWAH/rhGz06ZhsRmnH9iUb34vU8H4 RlJFcN0VkkQ4xS From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 15:45:54 +0300 Message-Id: <5899C1EA-CB43-4306-BC57-4C06F7D2D540@gmx.net> To: oauth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth WG session for Quebec City requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:45:58 -0000 Just to let you know. I have requested a meeting slow for the upcoming = IETF meeting.=20 More details about the meeting can be found here: = http://www.ietf.org/meeting/81/index.html If you have already some ideas what you would like to present, or try to = accomplish during the meeting please let us know.=20 We are quite flexible in what we could do during the IETF week.=20 Ciao Hannes =20= From jricher@mitre.org Mon Jun 6 13:25:00 2011 Return-Path: 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 B68E611E816B for ; Mon, 6 Jun 2011 13:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFNiXWohRB8i for ; Mon, 6 Jun 2011 13:24:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B6E3711E8071 for ; Mon, 6 Jun 2011 13:24:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0407E21B11FD; Mon, 6 Jun 2011 16:24:59 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EF85621B1088; Mon, 6 Jun 2011 16:24:58 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.159.2; Mon, 6 Jun 2011 16:24:58 -0400 From: Justin Richer To: David Recordon In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 6 Jun 2011 16:23:20 -0400 Message-ID: <1307391800.1727.31.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:25:00 -0000 The biggest problem that I can see are the examples and terminology in the core doc, which tries very hard to not look like it is binding to any particular use-a-token spec or token format. That plus the history that George pointed out below (which I still very strongly believe that 'oauth_token' should not be used as that's been claimed by OAuth1) got us here today. One of the downsides to splitting this into three specs is that we need to be more consistent across them. -- Justin On Wed, 2011-06-01 at 03:06 -0400, David Recordon wrote: > Yeah, can understand how we got here. Just found it quite confusing > when reading these two specifications together with an implementor's > hat on. > > On Tue, May 31, 2011 at 12:29 PM, George Fletcher wrote: > > Brief pointer to the "history" of this change. This change was adopted in > > draft 4 of the bearer spec as there were concerns with the previous > > parameter name of 'oauth_token'. The suggestion was made to use > > 'bearer_token' so that it matches the scheme used in the Authorization > > header. The thinking being that reading the bearer token spec would seem > > weird if the Authorization header used one name and the GET/POST methods > > used a different name. > > > > The 'bearer_token' name got a few +1 and no dissents. > > > > Full thread starts here [1]. Mike accepting the 'bearer_token' > > recommendation is here [2]. > > > > Thanks, > > George > > > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html > > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html > > > > On 5/28/11 12:30 PM, David Recordon wrote: > > > > Did a full read through of draft 16 and the bear token spec with Paul > > yesterday afternoon in order to do a manual diff from draft 10. The > > point Doug raised was actually confusing. Throughout the core spec > > it's referred to as access_token but then becomes bearer_token upon > > use. > > > > Just thinking through this from a developer documentation perspective, > > it's going to become confusing. Developer documentation focuses on > > getting an access token and then using that access token to interact > > with an API. Thus the code you're writing as a client developer will > > use variables, cache keys, and database columns named `access_token`. > > But then when you're going to use it, you'll need to put this access > > token into a field named bearer_token. > > > > Feels quite a bit simpler to just name it access_token. Realize the > > core spec never did this since we didn't want to trample on protected > > resources which might already have a different type of access_token > > parameter. oauth_token was a good compromise since developers would > > already know that they were using OAuth and thus a new term wasn't > > being introduced. That's no longer true with bearer_token since 99% of > > developers will have never heard of a bearer token. > > > > Googling for "bearer token" turns up Eran's blog post titled "OAuth > > Bearer Tokens are a Terrible Idea" and there isn't a single result on > > the first page which explains what they are. Binging for "bearer > > token" is equally scary. > > > > --David > > > > > > On Mon, May 23, 2011 at 11:38 AM, Mike Jones > > wrote: > > > > The working group explicitly decided that a different name should be used, > > to make it clear that other token types other than bearer tokens could also > > be used with OAuth 2. > > > > > > > > -- Mike > > > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > > Doug Tangren > > Sent: Wednesday, May 11, 2011 10:09 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] consistency of token param name in bearer token type > > > > > > > > This may have come up before so I'm sorry if I'm repeating. Why does bearer > > token spec introduce a new name for oauth2 access tokens [1], > > "bearer_token", and before that [2], "oauth_token"? > > > > > > > > I apologize if this may sound shallow but, why introduce a new parameter > > name verses sticking with what the general oauth2 spec already defines, > > "access_token". It seems arbitrary for an auth server to hand a client an > > apple then have the client hand it off to the resource server and call it an > > orange. > > > > > > > > Was this just for the sake of differentiating the parameter name enough so > > that the bearer tokens may be used in other protocols without being confused > > with oauth2 access_tokens? > > > > > > > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 > > > > [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 > > > > > > > > -Doug Tangren > > http://lessis.me > > > > _______________________________________________ > > 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 > > > > > > -- > > Chief Architect AIM: gffletch > > Identity Services Engineering Work: george.fletcher@teamaol.com > > AOL Inc. Home: gffletch@aol.com > > Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com > > Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pt@fb.com Mon Jun 6 18:53:41 2011 Return-Path: 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 2A97721F857E for ; Mon, 6 Jun 2011 18:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvEECpq1Hj9N for ; Mon, 6 Jun 2011 18:53:40 -0700 (PDT) Received: from mail.thefacebook.com (corpout1.snc1.tfbnw.net [66.220.144.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5480621F857B for ; Mon, 6 Jun 2011 18:53:40 -0700 (PDT) Received: from SC-MBX02-4.TheFacebook.com ([fe80::e1f0:42de:c867:1385]) by sc-hub03.TheFacebook.com ([192.168.18.198]) with mapi id 14.01.0289.001; Mon, 6 Jun 2011 18:53:39 -0700 From: Paul Tarjan To: "oauth@ietf.org" Thread-Topic: Proposed OAuth Extensions Thread-Index: AQHMJLW4SIIJpv1stkerla7mpXQKVA== Date: Tue, 7 Jun 2011 01:53:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [192.168.18.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <705ED7B745857840AF73111F4EA9E466@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Proposed OAuth Extensions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:53:41 -0000 Hi fellow OAuthers, As we discussed at the meeting there are a few extensions that we'd like to implement. To do this, we'd like the response_type to be extensible. We are proposing two new values. "none" and "signed_request token" (and "token signed_request" for symmetry). Or if you want to turn response_type into a space separated list, that would work too. I'm also including our other extension parameters so you can see what we are planning incase others need similar functionality. --- response_type=3Dnone If this is specified then no code nor token is passed to the redirect_uri. This is very useful when the authentication will be done via other means (like the display=3Dnone parameter, or Facebook's canvas iframe). Example: http://www.facebook.com/dialog/OAuth? client_id=3D150629244948164& redirect_uri=3Dhttp://apps.facebook.com/ptarjan/& response_type=3Dnone (shows user the permission dialog then redirects to) http://apps.facebook.com/ptarjan/ (or if they click cancel) http://apps.facebook.com/ptarjan/? error=3Daccess_denied& error_description=3D...& state=3D... --- response_type=3Dsigned_request This response type is used to tie the Javascript SDK to a server-side SDK. It is used in conjunction with response_type=3Dtoken and display=3Dnone. It sends a "signed_request" along with the response, which is a signed blob that we expect the JS library to dump into a cookie for the server SDK to read and validate. The JS SDK will also look inside of it (without verifying the signature) to see the user's ID. That is safe because the JS SDK uses state and only handles responses it's expecting. The signed_request will contain: user_id (provider specific id string) issued_at (UNIXTIME) code (optional. OAuth code issued with redirect_uri set to "" since the server won't know which URL it was issued on) client_id (optional. Needed by Google for 4th party auth) audience (optional. Google's public key crypto) ... (other provider specific data) Example: http://www.facebook.com/dialog/OAuth? client_id=3D150629244948164& redirect_uri=3Dhttps://s-static.ak.fbcdn.net/connect/xd_proxy.php#& display=3Dnone& response_type=3Dtoken signed_request 302s to https://s-static.ak.fbcdn.net/connect/xd_proxy.php# access_token=3D...& expires_in=3D...& signed_request=3Dabcd... And the JS SDK then does setcookie("fbc_"+client_id, signed_request) --- display=3Dnone This means the user never will see a dialog and is meant to be opened in an iframe by javascript to asynchronously get an access_token or discover the user's state. Example: http://www.facebook.com/dialog/OAuth? client_id=3D150629244948164& redirect_uri=3Dhttps://example.com/& display=3Dnone& response_type=3Dtoken If the user is not logged into Facebook, this endpoint 302s to https://example.com/# error=3Dunknown_user If the user is logged in but hasn't authorized this app, it 302s to https://example.com/# error=3Dnot_authorized If the user has authorized the app then it 302s to the normal OAuth output https://example.com/# access_token=3D...& expires_in=3D... --- prompt=3D A parameter that changes some things with the OAuth prompt. These can be specified as a space/comma separated string. prompt=3Dlogin This forces the user to enter their password again. prompt=3Dconsent This always shows the "Do you allow this app" dialog, even if they consented before. Google will only issue long lived tokens when the user clicks something. prompt=3Dsecure The user must be verified by secure (https) cookies. This protects the app from firesheep attacks. prompt=3Dselect_account The user will be shown a dialog to select amongst their connected accounts (Google wants this for multiple connected accounts). --- nonce=3D If this parameter is specified, the nonce is encoded in the access_token, which is then accessible via a "Token Info Endpoint". This is paired with prompt=3Dlogin to guarantee the user put in their password before they buy something expensive with their paypal account. It is limited to a 20 character opaque string, but we recommend base64url encoding a set of random bits. Example: http://www.facebook.com/dialog/OAuth? client_id=3D150629244948164& redirect_uri=3D... nonce=3Dsome_string response_type=3Dcode Does exactly the same OAuth flow, except when they hit https//graph.facebook.com/access_token?access_token=3D... They get back json with a key "nonce" being the nonce encoded inside the Token. From sweeden@au1.ibm.com Mon Jun 6 20:25:51 2011 Return-Path: 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 176F111E8097 for ; Mon, 6 Jun 2011 20:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpXG2u9JGhi5 for ; Mon, 6 Jun 2011 20:25:50 -0700 (PDT) Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) by ietfa.amsl.com (Postfix) with ESMTP id A962411E80AC for ; Mon, 6 Jun 2011 20:25:49 -0700 (PDT) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp07.au.ibm.com (8.14.4/8.13.1) with ESMTP id p573PdUu030700 for ; Tue, 7 Jun 2011 13:25:39 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p573Onni581692 for ; Tue, 7 Jun 2011 13:24:49 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p573PSnx016155 for ; Tue, 7 Jun 2011 13:25:38 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p573GHRQ027189; Tue, 7 Jun 2011 13:16:17 +1000 In-Reply-To: References: X-KeepSent: 45A42968:F1037D68-4A2578A8:001025AD; type=4; name=$KeepSent To: Paul Tarjan X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Shane B Weeden Date: Tue, 7 Jun 2011 13:16:03 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4|July 25, 2010) at 07/06/2011 13:19:39 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed OAuth Extensions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 03:25:51 -0000 Just an observation - some of this function seems to have direct parallels in OpenID. E.g. display=none sounds very much like checkid_immediate prompt=xxx seems like a direct correlation to the PAPE extension Could things like signed_request and nonce be considered part of a custom token format in a separate token spec rather than part of the core - provided the client can be token-type-aware? From: Paul Tarjan To: "oauth@ietf.org" Date: 07-06-11 11:57 AM Subject: [OAUTH-WG] Proposed OAuth Extensions Sent by: oauth-bounces@ietf.org Hi fellow OAuthers, As we discussed at the meeting there are a few extensions that we'd like to implement. To do this, we'd like the response_type to be extensible. We are proposing two new values. "none" and "signed_request token" (and "token signed_request" for symmetry). Or if you want to turn response_type into a space separated list, that would work too. I'm also including our other extension parameters so you can see what we are planning incase others need similar functionality. --- response_type=none If this is specified then no code nor token is passed to the redirect_uri. This is very useful when the authentication will be done via other means (like the display=none parameter, or Facebook's canvas iframe). Example: http://www.facebook.com/dialog/OAuth? client_id=150629244948164& redirect_uri=http://apps.facebook.com/ptarjan/& response_type=none (shows user the permission dialog then redirects to) http://apps.facebook.com/ptarjan/ (or if they click cancel) http://apps.facebook.com/ptarjan/? error=access_denied& error_description=...& state=... --- response_type=signed_request This response type is used to tie the Javascript SDK to a server-side SDK. It is used in conjunction with response_type=token and display=none. It sends a "signed_request" along with the response, which is a signed blob that we expect the JS library to dump into a cookie for the server SDK to read and validate. The JS SDK will also look inside of it (without verifying the signature) to see the user's ID. That is safe because the JS SDK uses state and only handles responses it's expecting. The signed_request will contain: user_id (provider specific id string) issued_at (UNIXTIME) code (optional. OAuth code issued with redirect_uri set to "" since the server won't know which URL it was issued on) client_id (optional. Needed by Google for 4th party auth) audience (optional. Google's public key crypto) ... (other provider specific data) Example: http://www.facebook.com/dialog/OAuth? client_id=150629244948164& redirect_uri=https://s-static.ak.fbcdn.net/connect/xd_proxy.php#& display=none& response_type=token signed_request 302s to https://s-static.ak.fbcdn.net/connect/xd_proxy.php# access_token=...& expires_in=...& signed_request=abcd... And the JS SDK then does setcookie("fbc_"+client_id, signed_request) --- display=none This means the user never will see a dialog and is meant to be opened in an iframe by javascript to asynchronously get an access_token or discover the user's state. Example: http://www.facebook.com/dialog/OAuth? client_id=150629244948164& redirect_uri=https://example.com/& display=none& response_type=token If the user is not logged into Facebook, this endpoint 302s to https://example.com/# error=unknown_user If the user is logged in but hasn't authorized this app, it 302s to https://example.com/# error=not_authorized If the user has authorized the app then it 302s to the normal OAuth output https://example.com/# access_token=...& expires_in=... --- prompt= A parameter that changes some things with the OAuth prompt. These can be specified as a space/comma separated string. prompt=login This forces the user to enter their password again. prompt=consent This always shows the "Do you allow this app" dialog, even if they consented before. Google will only issue long lived tokens when the user clicks something. prompt=secure The user must be verified by secure (https) cookies. This protects the app from firesheep attacks. prompt=select_account The user will be shown a dialog to select amongst their connected accounts (Google wants this for multiple connected accounts). --- nonce= If this parameter is specified, the nonce is encoded in the access_token, which is then accessible via a "Token Info Endpoint". This is paired with prompt=login to guarantee the user put in their password before they buy something expensive with their paypal account. It is limited to a 20 character opaque string, but we recommend base64url encoding a set of random bits. Example: http://www.facebook.com/dialog/OAuth? client_id=150629244948164& redirect_uri=... nonce=some_string response_type=code Does exactly the same OAuth flow, except when they hit https//graph.facebook.com/access_token?access_token=... They get back json with a key "nonce" being the nonce encoded inside the Token. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From paulej@packetizer.com Mon Jun 6 20:26:13 2011 Return-Path: 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 AA22E11E8151; Mon, 6 Jun 2011 20:26:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yonClR2e1Ev9; Mon, 6 Jun 2011 20:26:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7789B11E8097; Mon, 6 Jun 2011 20:26:12 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p573Pw77008885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 23:26:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307417165; bh=jV52Ps4tuBilrdVoLwOntDyoyy8VqHJU8rKf8rGCbhs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iATpPDFOH+ap5GbsUPzczIe3OKiBpEFzoUQ0R55MRLW6YA2f9Y7ftYn8G+am2rJqH pbRBfmWKJ77UkCpKQNM+DkyIIoUSrbPLyNSX7O4MiYKGUbWa85U+rGdIZ3r3+ZIkjX nQ9/X4zvoTeTBgVFsYs1EKfbc5UxRyDmLVaRRsQE= From: "Paul E. Jones" To: "'Nico Williams'" , "'Eran Hammer-Lahav'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Date: Mon, 6 Jun 2011 23:25:54 -0400 Message-ID: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJuZniGB/7VI7fQeF44Yd3wW4or/QFyB4gcAph0XNqTTGN1IA== Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 03:26:13 -0000 Nico, Sorry for coming into this so late, but I just saw this message. I don't have all of the background, but when I saw this message header and some of the dialog, it seems there is a desire to provide some level of authentication to requests and/or responses between the clients and servers. Gonzalo and I worked on this: https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 This may not be entirely complete, but the idea was to allow a client and server to establish an association so that requests and responses could be authenticated. Is this something along the lines of what you are discussing, or is this an entirely different application? Paul > -----Original Message----- > From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] > On Behalf Of Nico Williams > Sent: Friday, May 20, 2011 4:25 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; Ben Adida; Adam Barth (adam@adambarth.com); > http-state@ietf.org; HTTP Working Group; OAuth WG > Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme > > Additional comments: > > - Using nonces for replay protection is heavy-duty. It is difficult to > implement a reliable, secure, high-performance replay cache. (It is > easy to implement just a high-performance replay cache: use > memcache.) > > I recommend an option to use sequence numbers at the server's choice, > understanding, of course, that requests will not be received in > sequence. The use of a sliding sequence number window makes it possible > to do at least as well as when using nonce, and probably faster while > still being secure. > > - In an open wifi environment active attacks may not be very difficult, > thus an option to secure more than just a handful of bits from the > request, would be nice (all of the request and all of the response, > say). The hard part is how to decide when to use one or the other. > Ideally browsers can request more protection when the network is > reconfigured such that there's one or more clear wifi interfaces. > > Nico > -- > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state From bkihara.l@gmail.com Tue Jun 7 03:09:26 2011 Return-Path: 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 C682411E80C4; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvnhDgiyA-kw; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2879711E80BF; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: by pwi5 with SMTP id 5so2893093pwi.31 for ; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=r1sHsORBGJUl1zuAXFf0vNvc3svdFmbZ3pj+423sxUQ=; b=m5g80NQo+cZGXo7GQ3niMzh/3TUIf3a3BFBabP1EoOUnD0p9TLwchA14NXRGdRVKly oKEbGvrW4Di298cnsMsYKuXOj8zWtM+iTBb/2qBCUu2If+kMSVmYiU8myvOgDxjv4IDo Rqm2dobVVJzo6BivHkfo2bBjMWMUQ1lRrTx0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V786vpDuw6ktQcsrXSmiLUmtoWyZySIEWy99/XQmuJDVrcSzkBzV73ZGJMSebu/aqA N8D9ZCJwkyEmGdaA9cGCplOFLLoZfQERL/DT6Ex+S7gxr5QZjK89CZtL5gKvW+Bi2/6k CH1fNirDyvX/mnyHUUAqFBuMUDM96UxjpA20Q= MIME-Version: 1.0 Received: by 10.142.248.35 with SMTP id v35mr38393wfh.245.1307441365610; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) Received: by 10.142.164.3 with HTTP; Tue, 7 Jun 2011 03:09:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 19:09:25 +0900 Message-ID: From: "KIHARA, Boku" To: saag@ietf.org, websec@ietf.org, oauth@ietf.org, public-identity@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: [http-auth] REST-GSS I-D posted X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:09:26 -0000 FYI ---------- Forwarded message ---------- From: Nico Williams Date: 2011/6/7 Subject: [http-auth] REST-GSS I-D posted To: http-auth@ietf.org http://www.ietf.org/id/draft-williams-rest-gss-00.txt This is to go with the slides and paper presented almost two weeks ago at the W3C workshop on identity in the browser: http://www.w3.org/2011/identity-ws/agenda.html I would like to add some co-authors. =A0Anyone interested? Cheers, Nico -- _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth From nico@cryptonector.com Tue Jun 7 10:35:55 2011 Return-Path: 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 5E2D51F0C39; Tue, 7 Jun 2011 10:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxdZ496aZXFB; Tue, 7 Jun 2011 10:35:54 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6481F0C36; Tue, 7 Jun 2011 10:35:54 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C35D11B4078; Tue, 7 Jun 2011 10:35:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=w8IK2aGMWRP9XrsrgfCDepvGOFww6Y8qqUz9zVWp6f3M rryvqeEjSMsmkbkLFA1ty80S+oOFsZ6DWgKjlplQ+3cW/BMa0Gy7bgLrEulPkuqt V+9Smxm24Qu3/7jHi3M8CEIV2bofVEnulb4YmpT9qq7A4OvIY95tJVofpmFENMU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=btKLDXJPPjTq3XZvKHfUdtb6H/A=; b=NzPxHv8LHsd 6CJrUKAMDSHIJIQ9+86/zXngVBVfNmvh/tc++dv2TfUgZAWFYJ6huSam02gQzzAQ 0JBS51TterCU1Rxn0M1Ahr6AVasLptnQ8rH/ixjkAMPWHgPPyieel25RvfnORUlj wtPVAov7F+9/wZXT5EFWuLt575INmwXw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 96C8C1B406F; Tue, 7 Jun 2011 10:35:53 -0700 (PDT) Received: by pzk5 with SMTP id 5so2920439pzk.31 for ; Tue, 07 Jun 2011 10:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr295077pbj.456.1307468153080; Tue, 07 Jun 2011 10:35:53 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 10:35:52 -0700 (PDT) In-Reply-To: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 12:35:52 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:35:55 -0000 On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrot= e: > Nico, > > Sorry for coming into this so late, but I just saw this message. > > I don't have all of the background, but when I saw this message header an= d > some of the dialog, it seems there is a desire to provide some level of > authentication to requests and/or responses between the clients and serve= rs. > > Gonzalo and I worked on this: > https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 > > This may not be entirely complete, but the idea was to allow a client and > server to establish an association so that requests and responses could b= e > authenticated. =C2=A0Is this something along the lines of what you are > discussing, or is this an entirely different application? I'm completely on-board with session state[*]. My comments were particularly in regards to threat models. I believe that eavesdroppers and active attackers both need to be considered, particularly as we have so many open wifi networks. To me the simplest way to address the Internet threat model is to always use TLS (except, maybe, for images and such elements that have little or no security value, though one must be careful when making that determination) and to use channel binding. See the I-D referenced below. [*] See, for example: http://www.ietf.org/id/draft-williams-rest-gss-00.tx= t Nico -- From ietf@adambarth.com Tue Jun 7 11:30:46 2011 Return-Path: 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 4A0BE11E818F; Tue, 7 Jun 2011 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVXebRqn0uVr; Tue, 7 Jun 2011 11:30:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91EFF11E8166; Tue, 7 Jun 2011 11:30:45 -0700 (PDT) Received: by gyf3 with SMTP id 3so2861189gyf.31 for ; Tue, 07 Jun 2011 11:30:45 -0700 (PDT) Received: by 10.236.136.164 with SMTP id w24mr1418916yhi.171.1307471445065; Tue, 07 Jun 2011 11:30:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id w70sm296093yhl.3.2011.06.07.11.30.42 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 11:30:42 -0700 (PDT) Received: by gyf3 with SMTP id 3so2861155gyf.31 for ; Tue, 07 Jun 2011 11:30:42 -0700 (PDT) Received: by 10.91.198.17 with SMTP id a17mr5984674agq.44.1307471442099; Tue, 07 Jun 2011 11:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Tue, 7 Jun 2011 11:30:12 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> From: Adam Barth Date: Tue, 7 Jun 2011 11:30:12 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:30:46 -0000 On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrot= e: > On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wr= ote: >> Nico, >> >> Sorry for coming into this so late, but I just saw this message. >> >> I don't have all of the background, but when I saw this message header a= nd >> some of the dialog, it seems there is a desire to provide some level of >> authentication to requests and/or responses between the clients and serv= ers. >> >> Gonzalo and I worked on this: >> https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 >> >> This may not be entirely complete, but the idea was to allow a client an= d >> server to establish an association so that requests and responses could = be >> authenticated. =A0Is this something along the lines of what you are >> discussing, or is this an entirely different application? > > I'm completely on-board with session state[*]. =A0My comments were > particularly in regards to threat models. =A0I believe that > eavesdroppers and active attackers both need to be considered, > particularly as we have so many open wifi networks. Sorry. We can't address active attackers using this mechanism. If you need protection from active attackers, please use TLS. > To me the simplest way to address the Internet threat model is to > always use TLS (except, maybe, for images and such elements that have > little or no security value, though one must be careful when making > that determination) and to use channel binding. =A0See the I-D > referenced below. Indeed. This mechanism is for folks who cannot or will not deploy TLS. Adam From igor.faynberg@alcatel-lucent.com Tue Jun 7 11:41:53 2011 Return-Path: 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 B1033228007; Tue, 7 Jun 2011 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYgeQDqPEq9e; Tue, 7 Jun 2011 11:41:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC65021F8564; Tue, 7 Jun 2011 11:41:52 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p57Ifkgp025162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2011 13:41:46 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p57IfjcQ008947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2011 13:41:46 -0500 Received: from [135.244.5.22] (faynberg.lra.lucent.com [135.244.5.22]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p57IfhCF003676; Tue, 7 Jun 2011 13:41:43 -0500 (CDT) Message-ID: <4DEE70E6.90602@alcatel-lucent.com> Date: Tue, 07 Jun 2011 14:41:42 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Barth References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , Nico Williams , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:41:53 -0000 Adam Barth wrote: > On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote: > >> On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrote: >> >>> ... >>> >> I'm completely on-board with session state[*]. My comments were >> particularly in regards to threat models. I believe that >> eavesdroppers and active attackers both need to be considered, >> particularly as we have so many open wifi networks. >> > > Sorry. We can't address active attackers using this mechanism. If > you need protection from active attackers, please use TLS. > Actually, IPsec will work here (with WiFi networks) just as well. It is also true that we COULD develop both the authentication and confidentiality mechanisms that would offer protection from both active and passive attackers; it is just that we CHOSE (in opinion, correctly) not to do that because other Internet protocols already do that. Igor From nico@cryptonector.com Tue Jun 7 14:17:43 2011 Return-Path: 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 6B1BD11E80CC; Tue, 7 Jun 2011 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2XfefYX-LcR; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1811E80C2; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 9406543807C; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=A+CIUGyKNSbymLMArkpGnX0oaqW2ZWVs1JISqMrjmeGg uQJBZwmmPSNglbYLbh6rXf8QoxSMF67XJCD4p2Sn9BJprL/fYkmI3goQ2T6PUC++ +KZnCu4GTeb3Tr0A5u/1peMyvOQuZmUXkPwwNLhWtF5lI3sUvPWMJ3M6S5PcNgc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=c1O9EsvOTcCw3PxOhd33itaxmWg=; b=eSeYMt1hBjf vT30PS7dcZVVlQr9YXFWD7Rt0yoXKtWdtKaIXNiUtdyGmVIsOlTh3DtTq/Rf6BP9 8UQXn4DS++Q5RN07EF82IaaSGz0fvKRSSPakhLNc3K1k7HCJxR0phbmuAIBJVlVG Ft99hy44xIi/iN6PQmqnnxOVPT6WlUtY= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 642F3438072; Tue, 7 Jun 2011 14:17:42 -0700 (PDT) Received: by pxi20 with SMTP id 20so4535056pxi.27 for ; Tue, 07 Jun 2011 14:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr577932pbb.255.1307481461766; Tue, 07 Jun 2011 14:17:41 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 14:17:41 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 16:17:41 -0500 Message-ID: From: Nico Williams To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:17:43 -0000 On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote: > On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wr= ote: >> I'm completely on-board with session state[*]. =C2=A0My comments were >> particularly in regards to threat models. =C2=A0I believe that >> eavesdroppers and active attackers both need to be considered, >> particularly as we have so many open wifi networks. > > Sorry. =C2=A0We can't address active attackers using this mechanism. =C2= =A0If > you need protection from active attackers, please use TLS. I've already said as much now several times. However, I want channel binding to TLS too. >> To me the simplest way to address the Internet threat model is to >> always use TLS (except, maybe, for images and such elements that have >> little or no security value, though one must be careful when making >> that determination) and to use channel binding. =C2=A0See the I-D >> referenced below. > > Indeed. =C2=A0This mechanism is for folks who cannot or will not deploy T= LS. It has value outside TLS as well. Particularly if you're using an authentication mechanism that can provide mutual authentication (which OAuth doesn't do today, but I hear there's work in progress to add mutual auth to it). And then you realize that you might want to do something similar with other non-OAuth authentication methods, thus the urge to generalize. Nico -- From nico@cryptonector.com Tue Jun 7 14:20:54 2011 Return-Path: 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 D028B11E8132; Tue, 7 Jun 2011 14:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpY2U1+oFk6J; Tue, 7 Jun 2011 14:20:52 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC5B11E80C2; Tue, 7 Jun 2011 14:20:52 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id CDA31350079; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=SmrAffH1meiUfZiFx2JEFJ0JBF/RqGmcy9QTOcXaAx+F diHmCBIzbZIEwJxyy7x4dhCeBeZQr6cxqK81vF2Wgc371fCrinRgZcs3czX9CgMS OSTlwDjWJwKIJJdAmVrA8sj2aO9M9Rg9jpd2QJ6KdR24kcooghv0dcOliel1N3o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=pp0EJ7zweYfXbLyZMx7md3xj7dY=; b=P00JbqVkyva YR9fZCAehX084AC2Lun5zPrYa1Z0bzM+d98VK406tD5u5LDkEKYlzQMLhhOrfjTW 0n0ENVRi107M1BC12432wSal8+XmOVqfRoItFAWlGOh+CxHAbE2EHj1VDdDBB8l7 sUQRPgr62rElGtPZo8ju8y8x68gI+/Fk= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 9C967350078; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) Received: by pvh18 with SMTP id 18so1199081pvh.31 for ; Tue, 07 Jun 2011 14:20:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr434791pbc.523.1307481651289; Tue, 07 Jun 2011 14:20:51 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 14:20:51 -0700 (PDT) In-Reply-To: <4DEE70E6.90602@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <4DEE70E6.90602@alcatel-lucent.com> Date: Tue, 7 Jun 2011 16:20:51 -0500 Message-ID: From: Nico Williams To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:20:54 -0000 On Tue, Jun 7, 2011 at 1:41 PM, Igor Faynberg wrote: > Adam Barth wrote: >> Sorry. =C2=A0We can't address active attackers using this mechanism. =C2= =A0If >> you need protection from active attackers, please use TLS. > > Actually, IPsec will work here (with WiFi networks) just as well. =C2=A0I= t is Not really. See RFCs 5660, 5386, and 5387. If only RFC5660 were widely implemented... but it's not. > also true that we COULD develop both the authentication and confidentiali= ty > mechanisms that would offer protection from both active and passive > attackers; it is just that we CHOSE (in opinion, correctly) not to do tha= t > because other Internet protocols already do that. And rightly so. As we've learned from SASL, having an option for security layers (the "SL" in SASL) at multiple network layers only adds unnecessary complications. Nico -- From ietf@adambarth.com Tue Jun 7 14:24:44 2011 Return-Path: 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 346F41F0C36; Tue, 7 Jun 2011 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqAO8ic83vEo; Tue, 7 Jun 2011 14:24:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABC1F0657; Tue, 7 Jun 2011 14:24:43 -0700 (PDT) Received: by iyn15 with SMTP id 15so6346666iyn.31 for ; Tue, 07 Jun 2011 14:24:42 -0700 (PDT) Received: by 10.42.1.82 with SMTP id 18mr11300549icf.274.1307481882488; Tue, 07 Jun 2011 14:24:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id w11sm2321212ibw.41.2011.06.07.14.24.41 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 14:24:41 -0700 (PDT) Received: by iyn15 with SMTP id 15so6346595iyn.31 for ; Tue, 07 Jun 2011 14:24:41 -0700 (PDT) Received: by 10.42.177.4 with SMTP id bg4mr10324481icb.164.1307481881104; Tue, 07 Jun 2011 14:24:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.229.196 with HTTP; Tue, 7 Jun 2011 14:24:10 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> From: Adam Barth Date: Tue, 7 Jun 2011 14:24:10 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:24:44 -0000 On Tue, Jun 7, 2011 at 2:17 PM, Nico Williams wrote= : > On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote: >> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams w= rote: >>> I'm completely on-board with session state[*]. =A0My comments were >>> particularly in regards to threat models. =A0I believe that >>> eavesdroppers and active attackers both need to be considered, >>> particularly as we have so many open wifi networks. >> >> Sorry. =A0We can't address active attackers using this mechanism. =A0If >> you need protection from active attackers, please use TLS. > > I've already said as much now several times. =A0However, I want channel > binding to TLS too. I'm not sure that's appropriate for this mechanism. What problem does channel binding solve? Adam >>> To me the simplest way to address the Internet threat model is to >>> always use TLS (except, maybe, for images and such elements that have >>> little or no security value, though one must be careful when making >>> that determination) and to use channel binding. =A0See the I-D >>> referenced below. >> >> Indeed. =A0This mechanism is for folks who cannot or will not deploy TLS= . > > It has value outside TLS as well. =A0Particularly if you're using an > authentication mechanism that can provide mutual authentication (which > OAuth doesn't do today, but I hear there's work in progress to add > mutual auth to it). =A0And then you realize that you might want to do > something similar with other non-OAuth authentication methods, thus > the urge to generalize. > > Nico > -- > From paulej@packetizer.com Tue Jun 7 14:59:43 2011 Return-Path: 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 87EC311E817D; Tue, 7 Jun 2011 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuUYpWUCu7Bd; Tue, 7 Jun 2011 14:59:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A98E411E8071; Tue, 7 Jun 2011 14:59:42 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p57LxSSU026304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 17:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307483975; bh=vAymWHB3vMQrUVrj09s12KmZ5xj9/zFu66TKvHefjnc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P2Ly20UN2MnQdVu9fxOgahTjEqfr4w9UM967g3OJzK+yeQB44k5sgOeKeTIDDtLNO bvywhKoLntceXy9npodJTLIPDUjiNkA7Geib65yX/I7rd+4+Qc3Y3zCP37jrGJbCGX iV6cB7agKi1Q4amxLwBj/qo3iEU//lFk0yLkpZBU= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> In-Reply-To: Date: Tue, 7 Jun 2011 17:59:23 -0400 Message-ID: <00f101cc255e$2d426020$87c72060$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpJUw+Lnw Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:59:43 -0000 Nico, > > Gonzalo and I worked on this: > > = https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04 > > > > This may not be entirely complete, but the idea was to allow a = client > > and server to establish an association so that requests and = responses > > could be authenticated. Is this something along the lines of what = you > > are discussing, or is this an entirely different application? >=20 > I'm completely on-board with session state[*]. My comments were > particularly in regards to threat models. I believe that = eavesdroppers > and active attackers both need to be considered, particularly as we = have > so many open wifi networks. >=20 > To me the simplest way to address the Internet threat model is to = always > use TLS (except, maybe, for images and such elements that have little = or > no security value, though one must be careful when making that > determination) and to use channel binding. See the I-D referenced > below. >=20 > [*] See, for example: http://www.ietf.org/id/draft-williams-rest-gss- > 00.txt I fully agree with you that using TLS is usually preferred. That said, = we encounter situations where there were a large number of client/server = interactions and the data conveyed is not confidential information in = any way. Using TLS can significantly decreases server performance, = particularly when there are a number of separate connections that are = established and broken. So, we were trying to find a non-TLS solution that still provides a way = to ensure the server can identify the user and that both can verify that = data has not been tampered in flight. (It would still be preferred to = establish security relations with TLS, though we were open to other = solutions.) Paul From nico@cryptonector.com Tue Jun 7 15:33:38 2011 Return-Path: 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 77D3811E8084; Tue, 7 Jun 2011 15:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0EizRmivHBn; Tue, 7 Jun 2011 15:33:37 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D807911E8072; Tue, 7 Jun 2011 15:33:35 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 40D651F0083; Tue, 7 Jun 2011 15:33:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=chqaBCti5o446gpVly0Tx8eDlUkn17K1DAKHIL0wHuqL dZMVrOsjyLl5fVlxZCdkomJzhW08U68aGQivwtqNfKlR9YJppHcZ8jVW2BbsNSXI utxv8ExFOfg+yk1DXj4C973r32EKtUBjIxNiojJ1fQZn0ZLqVojG81Am5rtTZak= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=CaY172oGfQ/cmxWYif9ddWcAy4o=; b=uMnpvd5CaRO 8jG5foIflgTxdmLsXn6vjvs8HTdPsV1CQ7XsT9OC5F0tT9PuS46Bh6BK/v7D+3zU uKYIaLEMGlgohibt223Ure61cuVVyFNsXIKl6aklmySb+WUJjICIPqjx5JFTveXN XgZjlFGlU3kS7Lh36qsaEpudgTcBblAY= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 032151F0081; Tue, 7 Jun 2011 15:33:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so3062072pzk.31 for ; Tue, 07 Jun 2011 15:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr439492pbj.456.1307486014688; Tue, 07 Jun 2011 15:33:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:33:34 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> Date: Tue, 7 Jun 2011 17:33:34 -0500 Message-ID: From: Nico Williams To: Adam Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:33:38 -0000 On Tue, Jun 7, 2011 at 4:24 PM, Adam Barth wrote: > I'm not sure that's appropriate for this mechanism. =C2=A0What problem do= es > channel binding solve? CB is not appropriate for OAuth today, no, because OAuth doesn't give you mutual authentication, which means channel binding can't be done either (well, not with any security guarantees). You missed my point however: I don't really want to see a specific purpose MAC here because I do believe it's generalizable, and if we don't generalize it now we'll just have more special casing in code later. For a general MAC I'd want an option for CB (when TLS is used, of course). Nico -- From nico@cryptonector.com Tue Jun 7 15:35:33 2011 Return-Path: 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 239EE11E8106; Tue, 7 Jun 2011 15:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57W7uQ8AqLLf; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 76BAB11E8101; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4BC8758406E; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=JEyiIBgiin5z8haGINQAbeKV7LnYLLj9la/5VqpGmtiC HqABRuY2t78iKmycNevV70Y5p0mldhjlVYo+JMbzeuIANn+AXjUzbzrDSoc/4/9f deQButTh+mP8finqk4MDtWPeMMp7LihyfE3EO77MIojlrI5KOaJ/jl1BVyxSLRQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8HZt5XI9AHWjWME8qN2YQPuzDtI=; b=KO60gFwsH88 GwmJvpm0CWkAk8Rj08qwgZzOMkRtUiQ0k7o8WemQLD0mSnhFGRxcxrKKkh6e2uEb kApEk2o734qMMG7oIH9WjGwWYO7ADlydSUwBBgLiEDkD1Y5pqXI9/8ug7+BWYktl PLg3HyPrs0wykTfEODAFaD6nfp8wfCbM= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 2169A584059; Tue, 7 Jun 2011 15:35:32 -0700 (PDT) Received: by pvh18 with SMTP id 18so1223953pvh.31 for ; Tue, 07 Jun 2011 15:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr461586pbc.523.1307486131806; Tue, 07 Jun 2011 15:35:31 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:35:31 -0700 (PDT) In-Reply-To: <00f101cc255e$2d426020$87c72060$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> Date: Tue, 7 Jun 2011 17:35:31 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:35:33 -0000 On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones wrote= : > I fully agree with you that using TLS is usually preferred. =C2=A0That sa= id, we encounter situations where there were a large number of client/serve= r interactions and the data conveyed is not confidential information in any= way. =C2=A0Using TLS can significantly decreases server performance, parti= cularly when there are a number of separate connections that are establishe= d and broken. > > So, we were trying to find a non-TLS solution that still provides a way t= o ensure the server can identify the user and that both can verify that dat= a has not been tampered in flight. =C2=A0(It would still be preferred to es= tablish security relations with TLS, though we were open to other solutions= .) I don't see the point of having a MAC instead of a cookie for HTTP requests sent without TLS, not unless you cover enough of the request (and response). Of course, you'll want two different cookies -- one for HTTP and one for HTTPS. I think you've just convinced me that this MAC adds no value whatsoever. Nico -- From wmills@yahoo-inc.com Tue Jun 7 15:43:22 2011 Return-Path: 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 C782D11E80CF for ; Tue, 7 Jun 2011 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPqqmNFbprVC for ; Tue, 7 Jun 2011 15:43:22 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id 432E011E8103 for ; Tue, 7 Jun 2011 15:43:22 -0700 (PDT) Received: from [98.139.91.69] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 Received: from [98.139.91.8] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 22:43:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 337523.74471.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 86697 invoked by uid 60001); 7 Jun 2011 22:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307486600; bh=+2VRbgPF+M1tYu3PXLrJxNrET7XInG8vxHJCwHhVU5U=; 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=gXEF+Fpug9+wDPDlAfEB7L26mTKD/AC2tuqZdEKMgvbOrntZlrWZ5CosqBUg0aRax9RL2CNBFm2Ho4kdQSFb06D63LhSmqb88BTU/3kjRy8hR13kB6ZdJPKFSoGU/KukOSNr/Wum0X2iOhbrcvbbPMm0hQkdd8V9ZK+9SJaek1s= 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=tJURKFvzQqxC0JdM6NL+q6M4LeoLf4PykmLlwcf4J3S6KHrjPVXudAJ9KGKt8noQp2gO/Y+w8WijKJms+VF+VsN3D0yJ8BvSVOMH66RU1AEBPx7ZDPcOszJikQ6W/rZr5FKeP7s/a+sd9W1M5Z5nCNqcAbTsvsIzS+CXf+vgjnQ=; X-YMail-OSG: 9vFg2EUVM1kPwDsdeLAwvl2uh_bot3pb1HgYgZuM9kQj5MI 2JoUITQrRUigiKmpnpIMyLZ.yRhZ31fHulo2muqkAIiD5zsf1U36e9lsuWaO uFDD2Qdd9.f.LEkPVPYgImYpgnV0Sqs9C3NLZzck.v3YGLu.RIqWo86ZQmbO 5RbqKimDXgRhG4F2HHoa9l8Db5g8PwPznUHIFMNZeEE2_Ev_hA0JdxAR.rZ. MMCJ.yNK64pS5AYXa0iRvYqYdo7LjhtjYYgPQz.M6cFKL7YdPuMupcoF_yMY FwrgNPRnvWs4j.IrC_hpz8pKBDqMIK10bzPxXefkhzOJStpVCv7adva5f_Rj APD.onAL3.Y.pWcNjL4ZKEsrwCh3O8__dtUvw Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2011 15:43:20 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> Message-ID: <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 15:43:20 -0700 (PDT) From: "William J. Mills" To: Nico Williams , "Paul E. Jones" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-935686083-1307486600=:48324" Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:43:22 -0000 --0-935686083-1307486600=:48324 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MAC adds security if the initial secret exchange is secure, and it provides= a definition for signing payload as part of the request.=0A=0A=0A=0A______= __________________________=0AFrom: Nico Williams =0A= To: Paul E. Jones =0ACc: apps-discuss@ietf.org; Ben = Adida ; Adam Barth ; http-state@ietf.org= ; HTTP Working Group ; OAuth WG =0ASen= t: Tuesday, June 7, 2011 3:35 PM=0ASubject: Re: [OAUTH-WG] [http-state] [ap= ps-discuss] HTTP MAC Authentication Scheme=0A=0AOn Tue, Jun 7, 2011 at 4:59= PM, Paul E. Jones wrote:=0A> I fully agree with yo= u that using TLS is usually preferred. =A0That said, we encounter situation= s where there were a large number of client/server interactions and the dat= a conveyed is not confidential information in any way. =A0Using TLS can sig= nificantly decreases server performance, particularly when there are a numb= er of separate connections that are established and broken.=0A>=0A> So, we = were trying to find a non-TLS solution that still provides a way to ensure = the server can identify the user and that both can verify that data has not= been tampered in flight. =A0(It would still be preferred to establish secu= rity relations with TLS, though we were open to other solutions.)=0A=0AI do= n't see the point of having a MAC instead of a cookie for HTTP=0Arequests s= ent without TLS, not unless you cover enough of the request=0A(and response= ).=A0 Of course, you'll want two different cookies -- one=0Afor HTTP and on= e for HTTPS.=0A=0AI think you've just convinced me that this MAC adds no va= lue whatsoever.=0A=0ANico=0A--=0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth --0-935686083-1307486600=:48324 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
MAC adds security if the initial secret exchange is secure, and it provid= es a definition for signing payload as part of the request.

=
From: Nico = Williams <nico@cryptonector.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: apps-discuss@ietf.org; Ben Adi= da <ben@adida.net>; Adam Barth <adam@adambarth.com>; http-state= @ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, June 7, 2011 3:35 PM
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC = Authentication=0A=09Scheme

=0AOn Tue, Jun 7, 2011 at 4:59 PM,= Paul E. Jones <paulej@packetizer.com> wrote:
> I fu= lly agree with you that using TLS is usually preferred.  That said, we= encounter situations where there were a large number of client/server inte= ractions and the data conveyed is not confidential information in any way. =  Using TLS can significantly decreases server performance, particularl= y when there are a number of separate connections that are established and = broken.
>
> So, we were trying to find a non-TLS solution that = still provides a way to ensure the server can identify the user and that bo= th can verify that data has not been tampered in flight.  (It would st= ill be preferred to establish security relations with TLS, though we were o= pen to other solutions.)

I don't see the point of having a MAC inste= ad of a cookie for HTTP
requests sent without TLS, not unless you cover enough of the request
(and response).=   Of course, you'll want two different cookies -- one
for HTTP and = one for HTTPS.

I think you've just convinced me that this MAC adds n= o value whatsoever.

Nico
--
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


--0-935686083-1307486600=:48324-- From nico@cryptonector.com Tue Jun 7 15:57:01 2011 Return-Path: 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 9C98311E81C9; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SjVEoMxQuFN; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 03D8A11E80CF; Tue, 7 Jun 2011 15:57:01 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D3864678062; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Jcjadx0we/+FYjNkC5Z/q 8pA9HxFpJbSgQsrxTSvLmBQzFf7AMWpyGAjCe8JplI1PGo2OiIv1/hN2rj80rqDh QEkr4Ry8vMSDSEQgSclWugz1eRV4TPUAt5OU8K3ru0kzIHaNmXkgo0ADPoF72ggQ jLTa2xprmP7gdv7jQI8FEA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tkn5ldRCD2ME+hplUIi1 u66Ly3M=; b=G+5+iYV8gwBpIBA0fVd/WeJ1QJ9n1VME+rWXq9Bk8TX2zmfZ2zkF ug9kzhKHzB7gUYM/qHOrwvWBsRz0ZyPOUn+tvCrs+xg62ffWGxL6OKDPmZqZynpm TjosLkE1HVYSdpAD2R1mqsxstwqC5/jsqiUKf2zCezeXXQnc0wJs84k= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id A91F0678056; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) Received: by pxi20 with SMTP id 20so4585098pxi.27 for ; Tue, 07 Jun 2011 15:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr446071pbe.121.1307487420276; Tue, 07 Jun 2011 15:57:00 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:57:00 -0700 (PDT) In-Reply-To: <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 17:57:00 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:57:01 -0000 On Tue, Jun 7, 2011 at 5:43 PM, William J. Mills wrote: > MAC adds security if the initial secret exchange is secure, and it provides > a definition for signing payload as part of the request. Not if the MAC doesn't protect enough of the request _and_ response to prevent active attacks. Unless you don't care about those attacks (which some of you have indicated), in which case why bother with the MAC at all? Nico -- From nico@cryptonector.com Tue Jun 7 16:09:44 2011 Return-Path: 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 0D4C211E8072; Tue, 7 Jun 2011 16:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHkmy3WubpgE; Tue, 7 Jun 2011 16:09:43 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B51E511E8101; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 814A36B007C; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=QLYkrGySk//VPWRH3vMHrMV8l2HEQvF1xxPvYlBiRmAE Jxq9R0DFm3wvipjvYpLqQl08u5WRzRD1h32LEaU3dKWEBF3B0HMuri4j+V7f01t4 +QE0YmqDfugwYrZuEsZYkN47HG0JDUN/2L8GxShEc+uSVYTx5I5By9Mepcg5Eks= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=4lDtf11LS1OMOrjp2f2TD2cUC94=; b=CwhMt7cv39b CP5Ha23E9xNjqKS7kvE96MhkupEMyW1fVjd9gn122BzPLaanpyzeuiZWZqPYruwX FJdSjt9cEyHm1XTnA7y8NtYmkypvMlhGXJVefZ6NzTJlrBrHPMwc3ytz4lYDrEdW mYwwCxJcpfhrV8bchie14zU+ABEI07NE= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 4EC866B007B; Tue, 7 Jun 2011 16:09:35 -0700 (PDT) Received: by pvh18 with SMTP id 18so1233930pvh.31 for ; Tue, 07 Jun 2011 16:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.135 with SMTP id a7mr506451pbi.54.1307488174872; Tue, 07 Jun 2011 16:09:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 16:09:34 -0700 (PDT) In-Reply-To: <4DEEAD76.2090800@adida.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 18:09:34 -0500 Message-ID: From: Nico Williams To: Ben Adida Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:09:44 -0000 On Tue, Jun 7, 2011 at 6:00 PM, Ben Adida wrote: > On 6/7/11 3:57 PM, Nico Williams wrote: >> >> Not if the MAC doesn't protect enough of the request _and_ response to >> prevent active attacks. =C2=A0Unless you don't care about those attacks >> (which some of you have indicated), in which case why bother with the >> MAC at all? > > A passive attacker can sniff your cookie and thus hijack your session. Al= l > you need to accomplish that attack is connect to any open wifi network an= d > use Firesheep. It's a good bit harder to be an active attacker, even on a= n > open wireless network. Yes, but only for resources that you've already stated you don't care about= . If you cared about those resources you'd protect more of the request _and_ response, or you'd use TLS. But you don't want to protect the response and you don't want to use TLS and you don't even want to protect the request body. What you're proposing adds a very marginal degree of security that will be trivial to defeat on open wifi (particularly once the toolset for doing it gets published). Are we serious about security? Or it this just for show? Or am I missing something? Nico -- From tim-projects@sentinelchicken.org Tue Jun 7 16:48:13 2011 Return-Path: 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 170A121F84EE for ; Tue, 7 Jun 2011 16:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2rhppIcYHnr for ; Tue, 7 Jun 2011 16:48:12 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id B23F921F84ED for ; Tue, 7 Jun 2011 16:48:12 -0700 (PDT) Received: (qmail 14026 invoked from network); 7 Jun 2011 23:41:31 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jun 2011 23:41:31 -0000 Received: (qmail 26041 invoked from network); 7 Jun 2011 23:42:48 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 7 Jun 2011 23:42:48 -0000 Received: (nullmailer pid 17134 invoked by uid 1000); Tue, 07 Jun 2011 23:41:31 -0000 Date: Tue, 7 Jun 2011 16:41:31 -0700 From: Tim To: Nico Williams Message-ID: <20110607234131.GI1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 07 Jun 2011 17:01:09 -0700 Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:48:13 -0000 > > A passive attacker can sniff your cookie and thus hijack your session. All > > you need to accomplish that attack is connect to any open wifi network and > > use Firesheep. It's a good bit harder to be an active attacker, even on an > > open wireless network. > > Yes, but only for resources that you've already stated you don't care about. > > If you cared about those resources you'd protect more of the request > _and_ response, or you'd use TLS. But you don't want to protect the > response and you don't want to use TLS and you don't even want to > protect the request body. What you're proposing adds a very marginal > degree of security that will be trivial to defeat on open wifi > (particularly once the toolset for doing it gets published). > > Are we serious about security? Or it this just for show? > > Or am I missing something? I have to agree with Nico here. In almost all cases I assert that, on typical modern networks: let P = difficulty of passive attack let M = difficulty of active (man-in-the-middle) attack O(P) = O(M) . This isn't to say the "real world" difficulty of an active attack is just as easy, but it is within a constant factor. If someone has published a tool that conducts MitM attacks for the specific protocol you're dealing with, the difference in difficulty clearly becomes marginal. Consider the complexity of the attacks implemented by sslstrip and yet the relative ease with which you can use it to MitM all SSL connections. I didn't bring this up before because I didn't understand any of the context behind the MAC proposal, but I will now, at risk of sounding ignorant: What is the MAC Authentication proposal intended to accomplish, in a security sense, above and beyond HTTP Digest? Yes, the HTTP Digest spec is, shall we say, a little rough around the edges, but would it make more sense to simply *fix* the minor problems with it and slightly extend it to integrate with OAuth? Note that it already does allow for arbitrary encrypted blob values to be attached to the digest... Ignoring the integration details for a minute though, how does MAC improve on Digest from a security persepctive? tim From nico@cryptonector.com Tue Jun 7 17:07:40 2011 Return-Path: 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 BD6F211E813F; Tue, 7 Jun 2011 17:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cefikWRneL9D; Tue, 7 Jun 2011 17:07:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id F202211E80B2; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id C4C2F67C06D; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Qp2Tej8sQu6p8GCJ3ViGASnUPPlA230lKv1LANp9H1ID f1b1rdAJuJm56m60LpnKP7fyGKGgHO5FvKLrmt10ji3SjXyVPSEtcZ3TRuihLlXS x5C5eTz1sXes0GCCNaMjQQ6NwCyyx84OpO7WaHUEsFZOX1JCC1cM3TRmU0ugVUo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=H6jQsCDKAW1ELuHLEHnpEBnUiNs=; b=T52XUZRkd0e 6GZgKOxowzNbcf3syhQcaBoUm/CwIjYPQV6a32koBZwQI8n+U4rWA01RUayiKU4J RxKyu9La76RjkabYTJYYGxGyfpGHz4aLE0MeFjkptSpa7vqeHnNcIlojkLoz7w9G Q4fMKh2Q/JR5eA70pgr1X+MJgW6p88Ho= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9FCF067C069; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) Received: by pzk5 with SMTP id 5so2867pzk.31 for ; Tue, 07 Jun 2011 17:07:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr636701pbb.255.1307491659198; Tue, 07 Jun 2011 17:07:39 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 17:07:39 -0700 (PDT) In-Reply-To: <20110607234131.GI1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Tue, 7 Jun 2011 19:07:39 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG , HTTP Working Group , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 00:07:40 -0000 On Tue, Jun 7, 2011 at 6:41 PM, Tim wrot= e: > I have to agree with Nico here. =C2=A0In almost all cases I assert that, = on > typical modern networks: > > =C2=A0let P =3D difficulty of passive attack > =C2=A0let M =3D difficulty of active (man-in-the-middle) attack > > O(P) =3D O(M) > . > > This isn't to say the "real world" difficulty of an active attack is > just as easy, but it is within a constant factor. =C2=A0If someone has > published a tool that conducts MitM attacks for the specific protocol > you're dealing with, the difference in difficulty clearly becomes > marginal. =C2=A0Consider the complexity of the attacks implemented by > sslstrip and yet the relative ease with which you can use it to MitM > all SSL connections. Exactly, and very well put. Active attacks sound harder, and they do actually require more work, but in many cases that work can be automated, and once automated there can be no difference in effort required to mount an active attack versus a passive one. Do we suppose that this proposal can get past secdir, IESG, and IETF reviews as-is? I doubt it. Here's another issue: some of you are saying that an application using this extension will be using TLS for some things but not others, which presumes a TLS session. Does using TLS _with_ session resumption _and_ HTTP/1.1 pipelining for all requests really cost that much more in latency and compute (and electric) power than the proposed alternative? I seriously doubt it, and I'd like to see some real analysis showing that I'm wrong before I'd accept such a rationale for this sort of proposal. Or perhaps the motivation relates to accidental leakage of "secure" cookies in non-secure contexts. But why not just fix the clients in that case? Nico -- From nico@cryptonector.com Tue Jun 7 18:22:05 2011 Return-Path: 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 3CE8111E8153; Tue, 7 Jun 2011 18:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuR9xz6PGLW2; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 800AE11E80FE; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 51EE46B0078; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dDjqdD+Ai35GrrIFdxLEjX0o7vLxXrewoJkw9M5BnP3K f4GtSOhqNN+ZXOI1lDbyNJ8OJJ3wkpOR9izCa/AOqVkVa7sV7t8fJsDry7E1CgH2 b3pjpxxR0FTNAJLagerEE96DWUAiaARx1sPC6HK3oW7Mimhhcs5qE/2ywxhh4ug= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=LLMXHPcMoJJiak5gDNxcrRWfRXY=; b=bHPsiZLUI6q g1fmiEjAS2ncEg27mtBAtEgeO4cefRAxI/3bi9SVxmotixxL0rzCRM0I7uC3jQKr Ua3kEg6Nnzf2TccGXP4LlBQgRIuNCb4mUmwJmZ0iLQpqWxSAnXokv7flrk8MJYaN mDLYCWxQ9imY6NsFgDbzRpvuvEZ653Zc= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 2319A6B0059; Tue, 7 Jun 2011 18:22:04 -0700 (PDT) Received: by pzk5 with SMTP id 5so12781pzk.31 for ; Tue, 07 Jun 2011 18:22:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr486208pbj.456.1307496123808; Tue, 07 Jun 2011 18:22:03 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 18:22:03 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 20:22:03 -0500 Message-ID: From: Nico Williams To: Randy Fischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 01:22:05 -0000 On Tue, Jun 7, 2011 at 8:05 PM, Randy Fischer wro= te: > On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wro= te: >> Or am I missing something? > > Well, last I tried it under apache, at least, there was a hard limit > on the length of > a TLS stream. =C2=A0 Since I use HTTP for a storage system for multi-GB f= iles, =C2=A0I'd > really love to see alternatives. Really? But if it'd have to be pretty short for the cost of the subsequent TLS session resumption to add up to so much latency and compute cost that you'd want to avoid using TLS. Also, that sounds like a fixable bug. If you can implement this MAC proposal, you can fix that bug. Nico -- From wmills@yahoo-inc.com Tue Jun 7 19:40:07 2011 Return-Path: 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 4107021F8482 for ; Tue, 7 Jun 2011 19:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHOEfTDmvApo for ; Tue, 7 Jun 2011 19:40:07 -0700 (PDT) Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by ietfa.amsl.com (Postfix) with SMTP id D889A11E8072 for ; Tue, 7 Jun 2011 19:40:06 -0700 (PDT) Received: from [98.139.52.193] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 Received: from [98.139.52.174] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 08 Jun 2011 02:40:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 421047.60612.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 30367 invoked by uid 60001); 8 Jun 2011 02:40:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1307500800; bh=igtgdMlafKNXXXgX0IJWz0qWyJjefq/o4nz+eZJ8Njs=; 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=QMbedK2JX62LFEbS+zWvILP2CdIoynZPpV3H35GlUjcLPeNnX19h04w/zc5kVkroL5wZQkUZKcDWlVv+epC96q8ZaB7vFdmtxpeoMkb4Ir/88EUQLigwNjGeQC+oBBza4qHZWhYgIpvg6psw+FxP5J1r0hnsa2ZYEEZmPTy1m+U= 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=gDxobXeIAY7NJCP6JKQT14sMq9ajpYx29amaX8rr8ETR2T5OORe22Xd7Ki5VZe2/RlrgQfIWxBQor6vRTmM2UJIdViq9hK97+IezI1gDlsqaCdI4x5vFmjy35ZrQeLAwuzmUi2voyHtUto+C2ZEeXCPoORDT7pgnElJJ5jl+10Y=; X-YMail-OSG: Pq_6HkcVM1ktF0rmBX3uAidfzEbiW6Mq.rhQCYHB2.OReUV ya.C2GO76l6OqwvPIkhCZqlsV_6nmZQPO.QUVeYjt.Re4vjAoNsuHtqMbqLg nD.VbM05Y7ezyBs1hHwONQJVqoel3gmPoKv9Erj1itzhyA.552kZ.ReoTG5t aCIZD5KT6NVIpzPGhZpEI3.UwvISIVLxPetiOnfxRvjpwBzPTlTgyPLyyzYE Iyf12Zdk2hm1CKlVzrQIjv3gJF8bYl3dL7VTkpCjf5TAgckz8yIltuyaB8uL 1GSFXMG_1iab2aZzwf7EQ.vazYPl6xWIZ_qRcf766ceZ75XfvbY177TpKKvH Bb5d_L3.fwAh9oC738M6OC19IxiDbPTmQBbUV Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 07 Jun 2011 19:40:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.112.307740 References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Message-ID: <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 19:40:00 -0700 (PDT) From: "William J. Mills" To: Tim , Nico Williams In-Reply-To: <20110607234131.GI1565@sentinelchicken.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-787661544-1307500800=:70339" Cc: "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 02:40:07 -0000 --0-787661544-1307500800=:70339 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is possible to implement decent security with MAC, it is also possible t= o screw it up.=A0 It is far more difficult (impossible?) to implement decen= t security with cookies over HTTP.=0A=0A=0A=0A_____________________________= ___=0AFrom: Tim =0ATo: Nico Williams =0ACc: OAuth WG ; HTTP Working Group ; "apps-discuss@ietf.org" ; "http-= state@ietf.org" =0ASent: Tuesday, June 7, 2011 4:41 PM= =0ASubject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authenticat= ion Scheme=0A=0A=0A> > A passive attacker can sniff your cookie and thus hi= jack your session. All=0A> > you need to accomplish that attack is connect = to any open wifi network and=0A> > use Firesheep. It's a good bit harder to= be an active attacker, even on an=0A> > open wireless network.=0A> =0A> Ye= s, but only for resources that you've already stated you don't care about.= =0A> =0A> If you cared about those resources you'd protect more of the requ= est=0A> _and_ response, or you'd use TLS.=A0 But you don't want to protect = the=0A> response and you don't want to use TLS and you don't even want to= =0A> protect the request body.=A0 What you're proposing adds a very margina= l=0A> degree of security that will be trivial to defeat on open wifi=0A> (p= articularly once the toolset for doing it gets published).=0A> =0A> Are we = serious about security?=A0 Or it this just for show?=0A> =0A> Or am I missi= ng something?=0A=0A=0AI have to agree with Nico here.=A0 In almost all case= s I assert that, on=0Atypical modern networks:=0A=0A=A0 let P =3D difficult= y of passive attack=0A=A0 let M =3D difficulty of active (man-in-the-middle= ) attack=0A=0AO(P) =3D O(M)=0A.=0A=0A=0AThis isn't to say the "real world" = difficulty of an active attack is=0Ajust as easy, but it is within a consta= nt factor.=A0 If someone has=0Apublished a tool that conducts MitM attacks = for the specific protocol=0Ayou're dealing with, the difference in difficul= ty clearly becomes=0Amarginal.=A0 Consider the complexity of the attacks im= plemented by=0Asslstrip and yet the relative ease with which you can use it= to MitM=0Aall SSL connections.=0A=0A=0AI didn't bring this up before becau= se I didn't understand any of the=0Acontext behind the MAC proposal, but I = will now, at risk of sounding=0Aignorant: =0A=0A=A0 What is the MAC Authent= ication proposal intended to accomplish, in a=0Asecurity sense, above and b= eyond HTTP Digest?=A0 =0A=0AYes, the HTTP Digest spec is, shall we say, a l= ittle rough around the=0Aedges, but would it make more sense to simply *fix= * the minor problems=0Awith it and slightly extend it to integrate with OAu= th?=A0 Note that it=0Aalready does allow for arbitrary encrypted blob value= s to be attached=0Ato the digest...=A0 Ignoring the integration details for= a minute=0Athough, how does MAC improve on Digest from a security persepct= ive?=0A=0Atim=0A_______________________________________________=0AOAuth mai= ling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-787661544-1307500800=:70339 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is possible to implement decent security with MAC, it is also possible= to screw it up.  It is far more difficult (impossible?) to implement = decent security with cookies over HTTP.

From: Tim <tim-projects@sent= inelchicken.org>
To:= Nico Williams <nico@cryptonector.com>
Cc: OAuth WG <oauth@ietf.org>; HTTP Working Gro= up <ietf-http-wg@w3.org>; "apps-discuss@ietf.org" <apps-discuss@ie= tf.org>; "http-state@ietf.org" <http-state@ietf.org>
Sent: Tuesday, June 7, 2011 4:41 PM
Subject: Re: [OAUTH-WG] [http-stat= e] [apps-discuss] HTTP MAC Authentication=0A Scheme


> = > A passive attacker can sniff your cookie and thus hijack your session.= All
> > you need to accomplish that attack is connect to any open= wifi network and
> > use Firesheep. It's a good bit harder to be = an active attacker, even on an
> > open wireless network.
> =
> Yes, but only for resources that you've already stated you don't c= are about.
>
> If you cared about those resources you'd protec= t more of the request
> _and_ response, or you'd use TLS.  But y= ou don't want to protect the
> response and you don't want to use TLS= and you don't even want to
> protect the request body.  What yo= u're proposing adds a very marginal
> degree of security that will be= trivial to defeat on open wifi
> (particularly once the toolset for = doing it gets published).
>
> Are we serious about security?&n= bsp; Or it this just for show?
>
> Or am I missing something?


I have to agr= ee with Nico here.  In almost all cases I assert that, on
typical m= odern networks:

  let P =3D difficulty of passive attack
&nb= sp; let M =3D difficulty of active (man-in-the-middle) attack

O(P) = =3D O(M)
.


This isn't to say the "real world" difficulty of a= n active attack is
just as easy, but it is within a constant factor.&nbs= p; If someone has
published a tool that conducts MitM attacks for the sp= ecific protocol
you're dealing with, the difference in difficulty clearl= y becomes
marginal.  Consider the complexity of the attacks impleme= nted by
sslstrip and yet the relative ease with which you can use it to = MitM
all SSL connections.


I didn't bring this up before becau= se I didn't understand any of the
context behind the MAC proposal, but I= will now, at risk of sounding
ignorant:

  What is the MAC Authentication proposal intended to accomplish, in a
security sense, ab= ove and beyond HTTP Digest? 

Yes, the HTTP Digest spec is, sha= ll we say, a little rough around the
edges, but would it make more sense= to simply *fix* the minor problems
with it and slightly extend it to in= tegrate with OAuth?  Note that it
already does allow for arbitrary = encrypted blob values to be attached
to the digest...  Ignoring the= integration details for a minute
though, how does MAC improve on Digest= from a security persepctive?

tim
_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


--0-787661544-1307500800=:70339-- From nico@cryptonector.com Tue Jun 7 20:17:49 2011 Return-Path: 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 AB5BC11E8072; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es0YgEAaevRd; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0911E8071; Tue, 7 Jun 2011 20:17:49 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id A078021DE77; Tue, 7 Jun 2011 20:17:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dy/V6Vq49DKQUKR8Tu5YvJOyUDc/2cL0izV6EkSUvegF S+7H48vhvq5X+AoZCfVz4l+C1OasHL9A4dYu4DuKBWRA6s4nWqXP7MjANzSTxWyC 0lqbMoDmcvxwhSo2fDMnaewC5w8m4Hdxgf+W8ifVKBoNgI6o18pzFu1ZT/nuclQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Gi28YkJLenZ65hJkPHLi3wF5pfo=; b=BgPP1WhxxyR Gzut5IEzhILbW0byB821vvp3uPMFv0RVUQmNO0S6SdHWE2oEu3UXmX9aIyTzhqMT DCpJsfj9Q3AsH+O0Q0aYmsAkJ3lnVAHKHJqyTmBeAiEo+BlsQx76ekA+63lFt+pU +zktF8vpdQbHp96jyPu/nLdnpEAQ3Vt4= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 5A89521DE71; Tue, 7 Jun 2011 20:17:48 -0700 (PDT) Received: by pxi20 with SMTP id 20so68988pxi.27 for ; Tue, 07 Jun 2011 20:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr697477pbb.255.1307503068005; Tue, 07 Jun 2011 20:17:48 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 20:17:47 -0700 (PDT) In-Reply-To: <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 7 Jun 2011 22:17:47 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 03:17:49 -0000 On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills wro= te: > It is possible to implement decent security with MAC, it is also possible= to Not as specified. See earlier posts regarding active attacks. > screw it up.=C2=A0 It is far more difficult (impossible?) to implement de= cent > security with cookies over HTTP. Assuming well-behaved browsers that understand the distinction between "secure" and non-secure cookies, and assuming that active attacks are often no more difficult than passive attacks, what does MAC without TLS add that cookies don't provide? Nico -- From mnot@mnot.net Tue Jun 7 20:26:20 2011 Return-Path: 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 DDE9F11E807C; Tue, 7 Jun 2011 20:26:20 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-6trkkkAyGs; Tue, 7 Jun 2011 20:26:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 720B211E8072; Tue, 7 Jun 2011 20:26:19 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [203.122.208.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DB368509D9; Tue, 7 Jun 2011 23:26:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 8 Jun 2011 13:26:05 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3D7340ED-C6F5-464D-BD14-1A606B7D8228@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> <1307500800.70339.YahooMailNeo@web31810.mail.mud.yahoo.com> To: Nico Williams , "William J. Mills" , Tim X-Mailer: Apple Mail (2.1084) Cc: HTTP Working Group , OAuth WG , "apps-discuss@ietf.org Discuss" , http-state@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "apps-discuss@ietf.org Discuss" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 03:26:21 -0000 This is an interesting discussion, but a bit much to cross-post to four = different lists.=20 I've set followups to apps-discuss (since it's the most general). Cheers, On 08/06/2011, at 1:17 PM, Nico Williams wrote: > On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills = wrote: >> It is possible to implement decent security with MAC, it is also = possible to >=20 > Not as specified. See earlier posts regarding active attacks. >=20 >> screw it up. It is far more difficult (impossible?) to implement = decent >> security with cookies over HTTP. >=20 > Assuming well-behaved browsers that understand the distinction between > "secure" and non-secure cookies, and assuming that active attacks are > often no more difficult than passive attacks, what does MAC without > TLS add that cookies don't provide? >=20 > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From randy.fischer@gmail.com Tue Jun 7 18:05:53 2011 Return-Path: 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 BA42311E8169; Tue, 7 Jun 2011 18:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZFKTlgRcCfe; Tue, 7 Jun 2011 18:05:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8D11E8154; Tue, 7 Jun 2011 18:05:52 -0700 (PDT) Received: by eye13 with SMTP id 13so7213eye.31 for ; Tue, 07 Jun 2011 18:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zWUBEWDsEim3T3uROAtyiYrb74HcVJGxmn5fllGZeoA=; b=elj0QzMOORMz98wvXUMU7auOGAmAK1vKE1rKLTU2m9A1XtPtpHkXstC46Egv9L5FJT x8n3F3fKD0+U5+mEylbne50gXstVPkEkLCc6qHawTr7ZNh7hjdQH4Q2xQzDE6wbm3zHl ukf+gTVdICsnypzo7HOKNxJf3j61dLoM6HokQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l1Vz0ptlBcmd6V1wgL+IJVv93lmCQRBTfwjzcEk6X0CnyuuQya65kw4BhWcv8ZYCQl F8EAU2AkX8kKRcHCohfZBMatw4qskj5eeTnKFGNelS8jkm1+ccHAMtKrG/UnX6HqvoBf xMZbvmZPCEx5f1oa7hvoPsDEH8+xVfvnECVdY= MIME-Version: 1.0 Received: by 10.213.15.6 with SMTP id i6mr11009eba.148.1307495151605; Tue, 07 Jun 2011 18:05:51 -0700 (PDT) Received: by 10.213.23.2 with HTTP; Tue, 7 Jun 2011 18:05:51 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> Date: Tue, 7 Jun 2011 21:05:51 -0400 Message-ID: From: Randy Fischer To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 08 Jun 2011 00:06:58 -0700 Cc: "apps-discuss@ietf.org" , Ben Adida , Adam Barth , "http-state@ietf.org" , HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 01:07:57 -0000 On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote: > Or am I missing something? Well, last I tried it under apache, at least, there was a hard limit on the length of a TLS stream. Since I use HTTP for a storage system for multi-GB files, I'd really love to see alternatives. -Randy Fischer From paulej@packetizer.com Wed Jun 8 00:09:56 2011 Return-Path: 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 60C4F11E809F; Wed, 8 Jun 2011 00:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUcKNzOTuoWw; Wed, 8 Jun 2011 00:09:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C668F11E80B6; Wed, 8 Jun 2011 00:09:48 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5879Zvs026255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2011 03:09:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307516981; bh=EqA8sObHvgjD2JNx49j1AwimuPqnmf948JUMPiOdJ4w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HeYerh+ds7j3Bquz1AhEPWr47ADnZ3Mr5/baHDx0CJHBvy+QAQRFX9hZlsygDUdQ/ WJ4obHlhlGjjky7KWtRK+hb/oVxc/ckCLKsow96uWg1Z3grWMNRBA+ZE5LaCvKKgFU KQWHrjiX/Bi57G/cyjaSt6C6zKTlMMLY8qIWV0ac= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> In-Reply-To: Date: Wed, 8 Jun 2011 03:09:29 -0400 Message-ID: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDCVCDS9sA== Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , 'Adam Barth' , http-state@ietf.org, 'HTTP Working Group' , 'OAuth WG' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:09:56 -0000 Nico, Cookies would still be employed. A cookie would be used to identify the = particular user, for example. However, it's important to make sure that = the cookie provided by the client to the server is not stolen. It's = important to ensure that the client provided by the server to the client = is not modified. That's the reason for the MAC. Once we can ensure the = integrity of the message exchange, then the existing cookie mechanism = can provide us with the secure state management capability we need. Paul > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Tuesday, June 07, 2011 6:36 PM > To: Paul E. Jones > Cc: Eran Hammer-Lahav; apps-discuss@ietf.org; Ben Adida; Adam Barth; > http-state@ietf.org; HTTP Working Group; OAuth WG > Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication = Scheme >=20 > On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones > wrote: > > I fully agree with you that using TLS is usually preferred. That > said, we encounter situations where there were a large number of > client/server interactions and the data conveyed is not confidential > information in any way. Using TLS can significantly decreases server > performance, particularly when there are a number of separate > connections that are established and broken. > > > > So, we were trying to find a non-TLS solution that still provides a > > way to ensure the server can identify the user and that both can > > verify that data has not been tampered in flight. (It would still = be > > preferred to establish security relations with TLS, though we were > > open to other solutions.) >=20 > I don't see the point of having a MAC instead of a cookie for HTTP > requests sent without TLS, not unless you cover enough of the request > (and response). Of course, you'll want two different cookies -- one = for > HTTP and one for HTTPS. >=20 > I think you've just convinced me that this MAC adds no value = whatsoever. >=20 > Nico > -- From nico@cryptonector.com Wed Jun 8 07:54:35 2011 Return-Path: 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 EDF1121F84E0; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIhATiHWBWlm; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5121F84DE; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 42A3242807A; Wed, 8 Jun 2011 07:54:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=POqsYsC7GUNGirMoCVtHK gNfjM6dAbE9+/asiDdq30aavjlxB8a9zQSC5MrEbMF6VLUeCjP3wtiVORGhxQgII l4d/nCMDWQRfx7EBbrzPvF+1F0Tr/wxEmVJgC+W6uL7ytlV/rybBErLZMo2ZxTqP BQfpSLx2kueO6WnXbpxvgs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=MWIpQm+nK1ebSht6Ppx7 DUz0oGQ=; b=dtXGJiQkjsdMz6VPu1qQHIjEUnpznn91/uQYkPnzsNLjvSA9poDV Gosrzqh2+zM2+NxmzQRsQblcUT7BIWcFfHKBwgvTn00FsRmPR30N3exXRtEp5X6E S9UtbWqVud7wr9wre1dc+jmX6aajBcVBvDu74rO4us+3+e7ooSKnJI0= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id DDFF0428078; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) Received: by pvh18 with SMTP id 18so313627pvh.31 for ; Wed, 08 Jun 2011 07:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.33 with SMTP id d1mr823108pbk.389.1307544874582; Wed, 08 Jun 2011 07:54:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 07:54:34 -0700 (PDT) In-Reply-To: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> Date: Wed, 8 Jun 2011 09:54:34 -0500 Message-ID: From: Nico Williams To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec520e845c7038c04a53483df Cc: apps-discuss@ietf.org, Ben Adida , Adam Barth , http-state@ietf.org, HTTP Working Group , Nico Williams , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:54:36 -0000 --bcaec520e845c7038c04a53483df Content-Type: text/plain; charset=UTF-8 On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote: > > Nico, > > Cookies would still be employed. A cookie would be used to identify the particular user, for example. However, it's important to make sure that the cookie provided by the client to the server is not stolen. It's important to ensure that the client provided by the server to the client is not modified. That's the reason for the MAC. Once we can ensure the integrity of the message exchange, then the existing cookie mechanism can provide us with the secure state management capability we need. You're still not addressing the issues raised. Nico -- --bcaec520e845c7038c04a53483df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 8, 2011 2:09 AM, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Nico,
>
> Cookies would still be employed. =C2=A0A cookie would be used to ident= ify the particular user, for example. =C2=A0However, it's important to = make sure that the cookie provided by the client to the server is not stole= n. =C2=A0It's important to ensure that the client provided by the serve= r to the client is not modified. =C2=A0That's the reason for the MAC. = =C2=A0Once we can ensure the integrity of the message exchange, then the ex= isting cookie mechanism can provide us with the secure state management cap= ability we need.

You're still not addressing the issues raised.

Nico
--

--bcaec520e845c7038c04a53483df-- From tim-projects@sentinelchicken.org Wed Jun 8 08:32:40 2011 Return-Path: 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 203A811E811D for ; Wed, 8 Jun 2011 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31hDHnmTjbnI for ; Wed, 8 Jun 2011 08:32:39 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E08711E8112 for ; Wed, 8 Jun 2011 08:32:38 -0700 (PDT) Received: (qmail 18907 invoked from network); 8 Jun 2011 15:32:25 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Jun 2011 15:32:25 -0000 Received: (qmail 4385 invoked from network); 8 Jun 2011 15:33:39 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 8 Jun 2011 15:33:39 -0000 Received: (nullmailer pid 21338 invoked by uid 1000); Wed, 08 Jun 2011 15:32:25 -0000 Date: Wed, 8 Jun 2011 08:32:25 -0700 From: Tim To: "Paul E\. Jones" Message-ID: <20110608153225.GL1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015801cc25ab$063a2150$12ae63f0$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' , 'Nico Williams' , 'OAuth WG' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:32:40 -0000 Hi Paul, > That's the reason for the MAC. Once we can ensure the integrity of > the message exchange, then the existing cookie mechanism can provide > us with the secure state management capability we need. Maybe I'm missing something in the MAC authentication draft, but I don't see how it provides integrity for the "exchange". In particular, the body of request messages may be optionally hashed to protect their integrity, but no such facility seems to be provided for responses from the server. In many modern web applications, this could be trivially exploited by an attacker to inject malicious script into a server response. HTTP Digest authentication provides an option (auth-int) for integrity protection of both requests and responses and for every request/response after the initial authentication. In fact if servers change nonces each time, reuse of hashes becomes difficult. Some level of mutual authentication is also provided and the opaque string can be used to pass arbitrary extra data between clients and servers. IIRC, this value can be passed *cross domain* based on a defined white list. At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? That is not just rhetorical, it is a genuine question. What is HTTP Digest missing that you need? tim From eran@hueniverse.com Wed Jun 8 10:33:04 2011 Return-Path: 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 4833F11E816E for ; Wed, 8 Jun 2011 10:33:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REcteIjEOO2q for ; Wed, 8 Jun 2011 10:33:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DEBBC11E8080 for ; Wed, 8 Jun 2011 10:33:02 -0700 (PDT) Received: (qmail 11392 invoked from network); 8 Jun 2011 17:33:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jun 2011 17:33:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 8 Jun 2011 10:32:56 -0700 From: Eran Hammer-Lahav To: Tim , "Paul E. Jones" Date: Wed, 8 Jun 2011 10:32:50 -0700 Thread-Topic: [http-state] [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: Acwl8UxVsvuTiAXMQdeQ4L4C/3sh6QAEDGxg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> In-Reply-To: <20110608153225.GL1565@sentinelchicken.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Nico Williams' , 'OAuth WG' , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:33:04 -0000 > -----Original Message----- > From: Tim [mailto:tim-projects@sentinelchicken.org] > Sent: Wednesday, June 08, 2011 8:32 AM > At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? > That is not just rhetorical, it is a genuine question. What is HTTP Dige= st > missing that you need? The latest version of this draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 Includes a Design Constraints section which tries to explain this: Unlike the HTTP Digest authentication scheme, this mechanism does not require interacting with the server to prevent replay attacks. Instead, the client provides both a nonce and a timestamp, which the server can use to prevent replay attacks using a bounded amount of storage. Also unlike Digest, this mechanism is not intended to protect the user's password itself because the client and server both have access to the key material in the clear. Instead, servers should issue a short-lived derivative credential for this mechanism during the initial TLS setup phase. EHL From denadai2@gmail.com Wed Jun 8 13:27:29 2011 Return-Path: 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 DEED811E80E4 for ; Wed, 8 Jun 2011 13:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp024rwjgwDn for ; Wed, 8 Jun 2011 13:27:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A952211E80DB for ; Wed, 8 Jun 2011 13:27:28 -0700 (PDT) Received: by qwc23 with SMTP id 23so587417qwc.31 for ; Wed, 08 Jun 2011 13:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6Z7DTiljqRUvQc9QyIOK+m6gLKbQhyi2N42qhfkJXOQ=; b=qt/1CRfebrlsA9WB6SESWxsLcF4fXWl7L4TDh/JCIdpTvjjnsrY6Mz441hhPaOLIJj XQyE3Vs7K9eQ3cnVmWyR7cDqAv16Y218Yl9SsBD5gEJ2B2I+2+zHSTALEMpFm+7C282T YKERBRCDk/eBC1Yzwos+wj102fHs4tfHAf6Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rB4rmY0KdqkrsML432BGGtQyIyt5+IDPmyfzt3ZYrZDq7l8KHHTdrrU8UHtqSocwuS pHPEP8DbUIaTsrIOA1amRSBgoxr++rClJG1nrUTFFhrgi0JicjCLf1LehHsL/9RsMToJ F9hXLydtUwdEGHcnv6WFYdCeRwrldmt4rXEHw= Received: by 10.224.214.5 with SMTP id gy5mr4013585qab.386.1307564848071; Wed, 08 Jun 2011 13:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.94.149 with HTTP; Wed, 8 Jun 2011 13:27:07 -0700 (PDT) In-Reply-To: References: From: denadai2 Date: Wed, 8 Jun 2011 22:27:07 +0200 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=20cf3005df4c4a455004a5392a96 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 20:27:30 -0000 --20cf3005df4c4a455004a5392a96 Content-Type: text/plain; charset=ISO-8859-1 Perfect, thank you. I made a sequence diagram for Authorization code. I want to explain the MINIMAL authorization requisites. http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png I explained in red the REQUIRED TLS connections. Is that all right? Thank you 2011/5/22 Eran Hammer-Lahav > > > From: denadai2 > Date: Sun, 22 May 2011 08:27:41 -0700 > To: Eran Hammer-lahav > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand > > Ok thank you. I will be more specific: > > 1- Client -> Authorization server. (via TLS) > I build the authorization request with response_type = "code", > client_id, redirect_uri. > > 2- Authorization server -> Client. (without TLS) > I grant access with an authorization code generated (for example) with > enc(client_id || redirect_uri, secret). redirect_uri > is the uri of the authorization request and secret is a diffie-hellman > secret shared with the Client in a previous step. > > 3- Client -> Authorization server. (without TLS) > I request the access token with grant_type = "authorization_code", > client_id, code = "[authorization code of step 2]", > redirect_uri = [redirect_uri of step 2]. > The Authorization server now will check that the authorization code was > issued to that client and will verify that the uri matches the > redirection URI with: dec(authorization_code, secret). > > > TLS Required > > > 4- Authorization server -> Client. (without TLS) > Authorization code will return the access_token: > access_token = "..." > token_type = "mac" > mac_key= "..." > mac_algorithm = "hmac-sha-256". > The access_token is generated with sha-256(random_string()) > > > TLS Required > > > 5- Client -> resource owner (without TLS) > The client request a resource with access_token obtained in step 4 and > Authorization header: MAC id="[access_token provided in step 4]" > nonce="[age]:[randomstring]" > > mac=hmac-sha-256(normalized_string, [mac_key provided in step4]) > The resource owner will asks to the Authorization server if the > access_token is valid (if it belongs to the client and if it > not expired, if the scope is allowed etc). > > > Not the resource owner, the resource server. > > > 6- resource owner - > Client (without TLS) > It will provide the resouce requested > > > Resource server, not owner. > > - Did I understand? > > > Overall yes. > > - how would you generate a token? > > > That's outside the scope of the protocol. It can be a self encoded string, > or an identifier used to DB lookup. > > - Is the id field the access_token provided in the authorization response? > > > Yes. > > EHL > > > Thank you. Is very difficult to verify a protocol that has so many variants > :) > > 2011/5/22 Eran Hammer-Lahav > >> You need to be more specific about what is confusing you. V2-16 7.1 is >> just an example. For using MAC you need to refer to the MAC spec. >> >> >> >> How you generate your access token string is an internal detail but your >> use of the authorization code in the algorithm is odd, IMO. >> >> >> >> The MAC is calculated based on the normalized string as defined in the MAC >> spec (and it does not include the access token). >> >> >> >> If you want help, you need to give a real example for the wire requests >> and responses. >> >> >> >> EHL >> >> >> >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf >> Of *denadai2 >> *Sent:* Saturday, May 21, 2011 11:16 AM >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand >> >> >> >> I'm trying to formal verify the OAuth 2.0 draft 16 protocol. >> >> >> >> I want to try OAuth 2.0 with hmac token type (). >> >> >> >> In the "Authorization Code" mode i have the response token as this: >> >> - access_token: [access_token] >> >> - token_type: mac >> >> - mac_key: buabuabua >> >> - mac_algorithm: hmac-sha-256 >> >> The access_token is calculated with hmac(client_id || authorization_code, >> secret). right? >> >> >> >> Now there is my problem. I want to access to a resource controlled by a >> resource owner. Do i need to do this >> >> GET /resource/1 HTTP/1.1 >> >> Host: example.com >> >> Authorization: MAC id = [access_token provided in the first pass] >> >> nonce = "274312:dj83hs92" >> >> mac = "ASDDFGDFGDG" >> >> with mac calculated with hmac(nonce || GET || url || host || access_token, >> secret) >> >> >> >> ? >> >> >> >> I don't undestand. There is too much confusion from this: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-7.1 and this >> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00#section-1.2 >> > > --20cf3005df4c4a455004a5392a96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perfect, thank you. I made a sequence diagram for Authorization code. I wan= t to explain the MINIMAL authorization requisites.

I explained in red the REQUIRED TLS connections. Is that all right?

Thank you

2011/5/2= 2 Eran Hammer-Lahav <eran@hueniverse.com>

<= div>
From: denadai2 <denadai2@gmail.com>
Date: Sun, 22 May 2011 08:27:41 -0700<= br> To: Eran Hammer-lahav <eran@hueniverse.com&g= t;
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken d= raft 6. I don't undestand

Ok thank you. I will be m= ore specific:

1- Client -> Authorization server= . (via TLS)
=A0 =A0 I build the authorization request with response_type =3D "= ;code", client_id, redirect_uri.

2- Authoriza= tion server -> Client. (without TLS)
=A0 =A0 I grant access wi= th an authorization code generated (for example) with enc(client_id || redi= rect_uri, secret). redirect_uri=A0
=A0 =A0 is the uri of the authorization request and secret is a diffie-hell= man secret shared with the Client in a previous step.

<= div>3-=A0Client -> Authorization server. (without TLS)
=A0 =A0= I request the access token with grant_type =3D "authorization_code&qu= ot;, client_id, code =3D "[authorization code of step 2]",
=A0 =A0 redirect_uri =3D [redirect_uri of step 2].
=A0 =A0 T= he Authorization server now will check that the authorization code was issu= ed to that client and will verify that the uri =A0 =A0 =A0 matches the redi= rection URI with: dec(authorization_code, secret).=A0

TLS Required


4- Authorization ser= ver -> Client. (without TLS)
=A0 =A0 Authorization code will return the access_token:=A0
= =A0 =A0 =A0 =A0access_token =3D "..."
=A0 =A0 =A0 =A0to= ken_type =3D "mac"
=A0 =A0 =A0 =A0mac_key=3D "...&= quot;
=A0 =A0 =A0 =A0mac_algorithm =3D "hmac-sha-256".= =A0
=A0 =A0 The access_token is generated with sha-256(random_string())

TLS Required


5- Client -> resource owner (without TLS)
= =A0 =A0 The client request a resource with access_token obtained in step 4 = and=A0
=A0 =A0 =A0 =A0Authorization header: MAC id=3D"[acces= s_token provided in step 4]"=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0nonce=3D"[age]:[randomstring]"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0mac=3Dhmac-sha-256(normalized_string, [mac_key provi= ded in step4])
=A0 =A0 The resource owner will asks to the Authorization server if the acc= ess_token is valid (if it belongs to the client and if it=A0
=A0 = =A0 not expired, if the scope is allowed etc).

Not the resource owner, the resource server.


6- resource owner = - > Client (without TLS)
=A0 =A0 It will provide the resouce requested

Resource server, not owner.

=
- Did I understand?

Overa= ll yes.

- how would you g= enerate a token?=A0

That's outside the scope of the protoc= ol. It can be a self encoded string, or an identifier used to DB lookup.

- Is the id field the access_token provided in th= e authorization response?

Yes.

= EHL


Thank you. Is very difficult to ve= rify a protocol that has so many variants :)

2011/5/22 Eran Hammer-Lahav <eran@hueniverse.com>

You need to be more spec= ific about what is confusing you. V2-16 7.1 is just an example. For using M= AC you need to refer to the MAC spec.

=A0

How you generate your access token string is an internal detail but you= r use of the authorization code in the algorithm is odd, IMO.

=A0

The MAC is calculated based on the normalized string as defined in the = MAC spec (and it does not include the access token).

=A0

If you want help, you need to give a real example for the wire requests= and responses.

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of denadai2
Sent: Saturday, May 21, 2011 11:16 AM
To: oauth@ietf.org
Subject: [= OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand

=A0

I'm trying to formal verify the OAuth 2.0 =A0draft 16 protoc= ol.=A0

=A0

I want to try OAuth 2.0 with hmac token type ().

=A0

In the "Authorizat= ion Code" mode i have the response token as this:

- access_token: [access_token]

- token= _type: mac

- mac_key: buabuabua

- mac_algorithm: hmac-sha-256

=

The access_token is calculated with hmac(client_id || authorization_code, s= ecret). right?

=A0

Now there is my problem. I want to access to a = resource controlled by a resource owner. Do i need to do this

GET /resource/1 HTTP/1.1

Host: example.com

<= /div>

Authorization: MAC id =3D [access_token pr= ovided in the first pass]

=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nonce =3D "274312:dj83h= s92"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0mac =3D "ASDDFGDFGDG"

with mac calculated with hmac(nonce || GET || url || host ||= access_token, secret)

=A0

?

=

=A0


I wish I could talk about it.  You'll have to find someone who's not= bound by stuff like employment contracts and trades secrets stuff to tell = you the story.

From: Skylar Woodward <skylar@kiva.org>
To: Dave Nelson <dnelson@elbry= s.com>
Cc: "oauth@ie= tf.org" <oauth@ietf.org>
Sen= t: Wednesday, June 1, 2011 1:07 PM
Subject: Re: [OAUTH-WG] Text for Native Applications
=
=0AOn Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:

> fo= r mounting the attack.  I firmly believe that secrets can be
> s= ufficiently obfuscated in code delivered in binary format without the
&g= t; benefit of a symbol table, so as to be sufficiently resistant to
>= discovery via disassembly by attackers you'd expect to encounter in a
&= gt; typical commercial environment.  I'm not talking about printable
I have empirical evidence to support this. At Yahoo! we devised one o= f the most complex systems I've ever seen in a publicly distributed program= (Messenger). It was disassembled in 3 days. Scott Renfro (now over with Da= vid at Facebook) and likely Bill Mills can also vouch for the difficulty of= this having also studied the case well.

Moreover if a hardware-enfo= rced system like that of Playstation 3 can be broken, then so can most syst= ems. The PS3 protection mechanisms are/were very sophisticated.

Even= if a system is not yet cracked or is very hard, you have to assume it can be cr= acked. History has shown this to be true nearly without exception - at leas= t to the point it is not worth considering for the OAuth use cases.

= skylar

_______________________________________________
OAuth mail= ing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--20cf3005df4c4a455004a5392a96-- From breno@google.com Wed Jun 8 15:26:17 2011 Return-Path: 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 1DEE31F0C41 for ; Wed, 8 Jun 2011 15:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXifJl84PNLU for ; Wed, 8 Jun 2011 15:26:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA2531F0C3E for ; Wed, 8 Jun 2011 15:26:15 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p58MQ5nk024507 for ; Wed, 8 Jun 2011 15:26:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307571969; bh=Eh29TvEYVQ8aLUKnXlMEK0zOZd0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=h6VRWUR27JrpY3dy2wq2S4QAMIuV07F44BHuSlusA5GEqMFmsKkypUQH/8K1QkmUV hs3qxS1loMSXE6IqRXTFA== Received: from yxj19 (yxj19.prod.google.com [10.190.3.83]) by hpaq1.eem.corp.google.com with ESMTP id p58MPrbA031739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 8 Jun 2011 15:26:04 -0700 Received: by yxj19 with SMTP id 19so560762yxj.4 for ; Wed, 08 Jun 2011 15:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZEsXVsGWrIac74D30ZKaoEDizHGk1RowbHXYAqBKR1M=; b=MfLx12RjC8/hLjbuSlfKkp92zufQaTO3AE6AWph30mgZJN97DEOZSbInUf7pbUGL0W wvmKwbN2oSxq/xF926fg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EQA+Ot4PSZWr110iCbLGG7r5IGrdwo2SnOwovSDOaNjJLPnJz/9Ps9Wn0gaFqFOVtD jQyxtsbKEY3dnWZ1F/JQ== MIME-Version: 1.0 Received: by 10.101.1.2 with SMTP id d2mr16581ani.9.1307571963776; Wed, 08 Jun 2011 15:26:03 -0700 (PDT) Received: by 10.100.244.26 with HTTP; Wed, 8 Jun 2011 15:26:03 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Wed, 8 Jun 2011 15:26:03 -0700 Message-ID: From: Breno de Medeiros To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 22:26:17 -0000 On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote: > On Tue, Jun 7, 2011 at 6:41 PM, Tim wr= ote: >> I have to agree with Nico here. =A0In almost all cases I assert that, on >> typical modern networks: >> >> =A0let P =3D difficulty of passive attack >> =A0let M =3D difficulty of active (man-in-the-middle) attack >> >> O(P) =3D O(M) >> . >> >> This isn't to say the "real world" difficulty of an active attack is >> just as easy, but it is within a constant factor. =A0If someone has >> published a tool that conducts MitM attacks for the specific protocol >> you're dealing with, the difference in difficulty clearly becomes >> marginal. =A0Consider the complexity of the attacks implemented by >> sslstrip and yet the relative ease with which you can use it to MitM >> all SSL connections. > > Exactly, and very well put. > > Active attacks sound harder, and they do actually require more work, > but in many cases that work can be automated, and once automated there > can be no difference in effort required to mount an active attack > versus a passive one. > > Do we suppose that this proposal can get past secdir, IESG, and IETF > reviews as-is? =A0I doubt it. > > Here's another issue: some of you are saying that an application using > this extension will be using TLS for some things but not others, which > presumes a TLS session. =A0Does using TLS _with_ session resumption > _and_ HTTP/1.1 pipelining for all requests really cost that much more > in latency and compute (and electric) power than the proposed > alternative? =A0I seriously doubt it, and I'd like to see some real > analysis showing that I'm wrong before I'd accept such a rationale for > this sort of proposal. Google has performed detailed analysis of SSL performance after several optimizations and we have concluded that the answer is 'no significant overhead' as you suggest. Indeed, in some workload situations it may be actually cheaper to serve SSL traffic because there is reduction in network latency by avoiding bad proxies. We have published some results here: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html > > Or perhaps the motivation relates to accidental leakage of "secure" > cookies in non-secure contexts. =A0But why not just fix the clients in > that case? > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 --Breno From nico@cryptonector.com Wed Jun 8 15:30:19 2011 Return-Path: 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 025D721F8490; Wed, 8 Jun 2011 15:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gxrb-ocgHXn; Wed, 8 Jun 2011 15:30:18 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6521F848F; Wed, 8 Jun 2011 15:30:18 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id C16E635007A; Wed, 8 Jun 2011 15:30:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xvMSouKYJD7Mhn9JGzAqPoQxa9Qnv3MRnUWqyLqoE7Qf z++bCKQ+7zVjDqeXeZt3Wp0s1e9KrWOlgWT2kKFpHYkfuh/Y6VKyZxV3FIzU8ZND aR2FxDtzkEoNIXKS/C3lbR4EfEc6erYUmIQVTaIKMM/+mLo81/TuYC/5n02V9Kk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kd1WcEXZG0a9WviCNc7RPHRJbk0=; b=GVTcmGLFqnV i87bhDF1h8ddigZFgMCyn2zWtxECXIwIyPkVPDcxk4cImAXH+vD2M9eAX6EGFjVj EQhsMszWDxX4Zq3lTRnhc65HDqZgK4qBaRiFMAh/ywA3A0mnfevVIolboXG2kUDH DFbqMXbVjIOtmqwlNoA2RvFw4w8f8Zxk= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 93CE9350058; Wed, 8 Jun 2011 15:30:17 -0700 (PDT) Received: by pvh18 with SMTP id 18so505009pvh.31 for ; Wed, 08 Jun 2011 15:30:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr1122589pbc.523.1307572217268; Wed, 08 Jun 2011 15:30:17 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 15:30:16 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Wed, 8 Jun 2011 17:30:16 -0500 Message-ID: From: Nico Williams To: Breno de Medeiros Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim , "http-state@ietf.org" , OAuth WG , "apps-discuss@ietf.org" , HTTP Working Group Subject: Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 22:30:19 -0000 On Wed, Jun 8, 2011 at 5:26 PM, Breno de Medeiros wrote: > On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote= : >> Here's another issue: some of you are saying that an application using >> this extension will be using TLS for some things but not others, which >> presumes a TLS session. =C2=A0Does using TLS _with_ session resumption >> _and_ HTTP/1.1 pipelining for all requests really cost that much more >> in latency and compute (and electric) power than the proposed >> alternative? =C2=A0I seriously doubt it, and I'd like to see some real >> analysis showing that I'm wrong before I'd accept such a rationale for >> this sort of proposal. > > Google has performed detailed analysis of SSL performance after > several optimizations and we have concluded that the answer is 'no > significant overhead' as you suggest. Indeed, in some workload > situations it may be actually cheaper to serve SSL traffic because > there is reduction in network latency by avoiding bad proxies. We have > published some results here: > http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Sweet! Thanks for confirming my intuition, and then some. I like the idea that using TLS actually reduces latency -- I'd not have imagined it. Nico -- From eran@hueniverse.com Wed Jun 8 16:14:44 2011 Return-Path: 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 4DAC021F84CC for ; Wed, 8 Jun 2011 16:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwivHSIuXhwv for ; Wed, 8 Jun 2011 16:14:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 662A721F84AF for ; Wed, 8 Jun 2011 16:14:42 -0700 (PDT) Received: (qmail 22612 invoked from network); 8 Jun 2011 23:14:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jun 2011 23:14:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 8 Jun 2011 16:13:10 -0700 From: Eran Hammer-Lahav To: denadai2 Date: Wed, 8 Jun 2011 16:14:28 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand Thread-Index: AcwmGn6P69v2gDPSS6qXDy8yMO/GdQAF0YEA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E773DCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: 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_90C41DD21FB7C64BB94121FBBC2E7234475E773DCEP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:14:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234475E773DCEP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The last part, refresh token, is with the authorization server, not resourc= e server. EHL From: denadai2 [mailto:denadai2@gmail.com] Sent: Wednesday, June 08, 2011 1:27 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand Perfect, thank you. I made a sequence diagram for Authorization code. I wan= t to explain the MINIMAL authorization requisites. http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png I explained in red the REQUIRED TLS connections. Is that all right? Thank you 2011/5/22 Eran Hammer-Lahav > From: denadai2 > Date: Sun, 22 May 2011 08:27:41 -0700 To: Eran Hammer-lahav > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand Ok thank you. I will be more specific: 1- Client -> Authorization server. (via TLS) I build the authorization request with response_type =3D "code", client= _id, redirect_uri. 2- Authorization server -> Client. (without TLS) I grant access with an authorization code generated (for example) with = enc(client_id || redirect_uri, secret). redirect_uri is the uri of the authorization request and secret is a diffie-hellman = secret shared with the Client in a previous step. 3- Client -> Authorization server. (without TLS) I request the access token with grant_type =3D "authorization_code", cl= ient_id, code =3D "[authorization code of step 2]", redirect_uri =3D [redirect_uri of step 2]. The Authorization server now will check that the authorization code was= issued to that client and will verify that the uri matches the redir= ection URI with: dec(authorization_code, secret). TLS Required 4- Authorization server -> Client. (without TLS) Authorization code will return the access_token: access_token =3D "..." token_type =3D "mac" mac_key=3D "..." mac_algorithm =3D "hmac-sha-256". The access_token is generated with sha-256(random_string()) TLS Required 5- Client -> resource owner (without TLS) The client request a resource with access_token obtained in step 4 and Authorization header: MAC id=3D"[access_token provided in step 4]" nonce=3D"[age]:[randomstring= ]" mac=3Dhmac-sha-256(normalize= d_string, [mac_key provided in step4]) The resource owner will asks to the Authorization server if the access_= token is valid (if it belongs to the client and if it not expired, if the scope is allowed etc). Not the resource owner, the resource server. 6- resource owner - > Client (without TLS) It will provide the resouce requested Resource server, not owner. - Did I understand? Overall yes. - how would you generate a token? That's outside the scope of the protocol. It can be a self encoded string, = or an identifier used to DB lookup. - Is the id field the access_token provided in the authorization response? Yes. EHL Thank you. Is very difficult to verify a protocol that has so many variants= :) 2011/5/22 Eran Hammer-Lahav > You need to be more specific about what is confusing you. V2-16 7.1 is just= an example. For using MAC you need to refer to the MAC spec. How you generate your access token string is an internal detail but your us= e of the authorization code in the algorithm is odd, IMO. The MAC is calculated based on the normalized string as defined in the MAC = spec (and it does not include the access token). If you want help, you need to give a real example for the wire requests and= responses. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of denadai2 Sent: Saturday, May 21, 2011 11:16 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand I'm trying to formal verify the OAuth 2.0 draft 16 protocol. I want to try OAuth 2.0 with hmac token type (). In the "Authorization Code" mode i have the response token as this: - access_token: [access_token] - token_type: mac - mac_key: buabuabua - mac_algorithm: hmac-sha-256 The access_token is calculated with hmac(client_id || authorization_code, s= ecret). right? Now there is my problem. I want to access to a resource controlled by a res= ource owner. Do i need to do this GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC id =3D [access_token provided in the first pass] nonce =3D "274312:dj83hs92" mac =3D "ASDDFGDFGDG" with mac calculated with hmac(nonce || GET || url || host || access_token, = secret) ? I don't undestand. There is too much confusion from this: http://tools.ietf= .org/html/draft-ietf-oauth-v2-16#section-7.1 and this http://tools.ietf.org= /html/draft-ietf-oauth-v2-http-mac-00#section-1.2 --_000_90C41DD21FB7C64BB94121FBBC2E7234475E773DCEP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The last = part, refresh token, is with the authorization server, not resource server.=

 <= /p>

EHL

 

F= rom: denadai2 [mailto:denadai2@gmail.com]
Sent: Wednesday, Ju= ne 08, 2011 1:27 PM
To: Eran Hammer-Lahav
Cc: oauth@iet= f.org
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I = don't undestand

=  

Perfect, thank you. I made a sequence = diagram for Authorization code. I want to explain the MINIMAL authorization= requisites.

 

<= /div>

I explai= ned in red the REQUIRED TLS connections. Is that all right?

<= /div>

 

Thank you

2011/5/22 Eran Hammer-Lahav <eran@hueniverse.com>

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

From: denadai2 <denadai2@gmail.com>
Date: Sun, 22 May 201= 1 08:27:41 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: "oauth@ietf.org<= /a>" <oauth@iet= f.org>
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken dra= ft 6. I don't undestand

 

Ok thank you. I will= be more specific:

 

1- Cli= ent -> Authorization server. (via TLS)

<= p class=3DMsoNormal>    I build the authorization request wi= th response_type =3D "code", client_id, redirect_uri.<= /span>

 

=

2- Authorization server -> Client. = (without TLS)

&nb= sp;   I grant access with an authorization code generated (for example= ) with enc(client_id || redirect_uri, secret). redirect_uri 

    is the uri o= f the authorization request and secret is a diffie-hellman secret shared wi= th the Client in a previous step.

 

3- Client -> Authorization server. (without TLS)=

    I request the= access token with grant_type =3D "authorization_code", client_id= , code =3D "[authorization code of step 2]",

    redirect_uri =3D [redir= ect_uri of step 2].

    The Authorization server now will check that the authoriza= tion code was issued to that client and will verify that the uri   &nb= sp;   matches the redirection URI with: dec(authorization_code, secret= ). 

 

TLS Required

 

 

4- Authorization server -> Client. (w= ithout TLS)

 = ;   Authorization code will return the access_token: <= /span>

       a= ccess_token =3D "..."

       token_type =3D "mac"

     = ;  mac_key=3D "..."

       mac_algorithm =3D "hmac-s= ha-256". 

    The access_token is generated with sha-256(random_string()= )

 

TLS Re= quired

=  

 

5- Client -> resource owner (without TLS)

    The c= lient request a resource with access_token obtained in step 4 and 

     =  Authorization header: MAC id=3D"[access_token provided in step = 4]" 

&n= bsp;                     =                      = ;    nonce=3D"[age]:[randomstring]"

          &= nbsp;                    =                mac=3Dhmac-sha-256(= normalized_string, [mac_key provided in step4])

=

    The resource owner will asks t= o the Authorization server if the access_token is valid (if it belongs to t= he client and if it 

    not expired, if the scope is allowed etc).

 

Not the resource = owner, the resource server.

 

 

6- resource owner - >= Client (without TLS)

=     It will provide the resouce requested<= /p>

 

Resource server, not owner= .

 

- Did I understand?

=

 

Overall yes.

<= div>

 

- = how would you generate a token? 

 

That's outside the scope of the protocol. It can be= a self encoded string, or an identifier used to DB lookup.

 

=

- Is the id field the access_token provided in the = authorization response?

 

Yes.

 

EHL

 

 =

Thank you. Is very difficult = to verify a protocol that has so many variants :)

 

2011/5/22 Eran Hammer-Lahav <eran@hueniverse.com>

=

You need to= be more specific about what is confusing you. V2-16 7.1 is just an example= . For using MAC you need to refer to the MAC spec.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>How you generate your = access token string is an internal detail but your use of the authorization= code in the algorithm is odd, IMO.=

&nbs= p;

The MAC is calculated based on the no= rmalized string as defined in the MAC spec (and it does not include the acc= ess token).

=  

If you want help, you need to give a real example for the wir= e requests and responses.

 <= span style=3D'color:black'>

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of denadai2
Sent: Saturday, May 21, 2011 11:16 = AM
To: oauth@= ietf.org
Subject: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6.= I don't undestand

=

 <= /span>

I'm trying to formal verify th= e OAuth 2.0  draft 16 protocol. 

 

= I want to try OAuth 2.0 with hmac token type ()= .

 =

In the = "Authorization Code" mode i have the response token as this:=

- access_tok= en: [access_token]

- token_type: mac

- mac_key: buabuabua

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>- mac_algorithm: hmac-sha-256<= /span>

The access_token is= calculated with hmac(client_id || authorization_code, secret). right?=

 

Now there is my problem. I want to= access to a resource controlled by a resource owner. Do i need to do this<= o:p>

GET /res= ource/1 HTTP/1.1

Aut= horization: MAC id =3D [access_token provided in the first pass]=

    &nbs= p;                     &n= bsp;  nonce =3D "274312:dj83hs92"

         =                    mac = =3D "ASDDFGDFGDG"

with mac calculated with hmac(nonce || GET || url || ho= st || access_token, secret)

 

?

 

&= nbsp;

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234475E773DCEP3PW5EX1MB01E_-- From mscurtescu@google.com Wed Jun 8 16:50:29 2011 Return-Path: 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 E36C021F8500 for ; Wed, 8 Jun 2011 16:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Py-BvUvqDe for ; Wed, 8 Jun 2011 16:50:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB221F84FF for ; Wed, 8 Jun 2011 16:50:28 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p58NoS3H006943 for ; Wed, 8 Jun 2011 16:50:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307577028; bh=6vQW3tV8q90OgK52hFzVoV625rY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=U5EEX2ErqfUA7s805hWYdvDHedZGPRYW2R4DpLJJ0AvVDaaMHnU1BiJlBPUisIvNk 0LNPunIpE/U+HnGoyTjcw== Received: from yia13 (yia13.prod.google.com [10.243.65.13]) by wpaz17.hot.corp.google.com with ESMTP id p58NoO3M006994 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 8 Jun 2011 16:50:27 -0700 Received: by yia13 with SMTP id 13so459708yia.28 for ; Wed, 08 Jun 2011 16:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=XwYmntsiGknbhBMNaMrGP7zZ2Jy9KaWSWFpZQIcex1k=; b=U5RyDIUA9bZntzGN+QXUqL+OSJMleTNQykns3+sItkYs5eLjGCGkjGMdgy3AxziDk6 k3wPYcWDQNSEtJiHXJDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gbup4cEe4DCi32VK4bCBVJlvUv7g4nf50/SUV1UtIgSubgplH4hRWYZ0AqcfJ7l3gq 8yuOth3+CW9oi8C+s4RA== Received: by 10.101.147.20 with SMTP id z20mr46814ann.79.1307577027091; Wed, 08 Jun 2011 16:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.14.19 with HTTP; Wed, 8 Jun 2011 16:50:07 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Wed, 8 Jun 2011 16:50:07 -0700 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:50:30 -0000 On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones wr= ote: > If you can drive a consensus decision for the name "access_token", I'd be= glad to change the name in the spec. =A0I agree that the current names are= confusing for developers. At Google we are getting the same feedback, that it is confusing for developers. It would definitely help if we could change the name to "access_token". Marius From svartman95@gmail.com Wed Jun 8 17:24:28 2011 Return-Path: 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 6AC6611E809E; Wed, 8 Jun 2011 17:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8Zm9RP2daKP; Wed, 8 Jun 2011 17:24:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7911E8080; Wed, 8 Jun 2011 17:24:27 -0700 (PDT) Received: by gxk19 with SMTP id 19so647769gxk.31 for ; Wed, 08 Jun 2011 17:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=566QAG7CNN/tVaKePByWyGGCc6puSRwhNRUG+WxTV1Q=; b=U1WaseFwTD/Wm7SHzYmU7EUjrBrFd5sv1Vz16EnRc2Isu8a3nYKsX4CamYrcLIu2Tl EUgLpVjMHJiUd0Q6/lFdSekNj3ISsW59wyG19zhRiRJcUnSnyVAITtaiQ5vZTyLaaW4r sErnQ09Fy59ooISUziIaPYXhqBy5NMFmS5bIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XF9yZ+u4/LaP+5IbVz5E3C1mjF6hhhgJSfVifeu2RI4WuAPmVSJ24wnlblI5OPpivG 09LCU8nhAj8vDNSQbiInA4dSdmbpazbCG6X5/M9YbaEiudDvKB+tZwKWG/gbobHsYDHb 5yGU2rtw7VXnr361OGFBICI/QFKxhyTRsmC7g= MIME-Version: 1.0 Received: by 10.236.186.38 with SMTP id v26mr65736yhm.415.1307579066953; Wed, 08 Jun 2011 17:24:26 -0700 (PDT) Received: by 10.236.47.228 with HTTP; Wed, 8 Jun 2011 17:24:25 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <1307486600.48324.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DEEAD76.2090800@adida.net> <20110607234131.GI1565@sentinelchicken.org> Date: Thu, 9 Jun 2011 00:24:25 +0000 Message-ID: From: Bjartur Thorlacius To: Nico Williams Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 08 Jun 2011 17:57:03 -0700 Cc: Tim , HTTP Working Group , OAuth WG , "apps-discuss@ietf.org" , "http-state@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 00:24:28 -0000 On 6/8/11, Nico Williams wrote: > Sweet! Thanks for confirming my intuition, and then some. I like the > idea that using TLS actually reduces latency -- I'd not have imagined > it. > Well, it's the enforcement of the end-to-end principle that reduces latency, not the TLS protocol per se. You'd get the same effect if HTTP didn't support proxies in the first place. From sayrer@gmail.com Wed Jun 8 20:53:13 2011 Return-Path: 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 D6EF611E8084; Wed, 8 Jun 2011 20:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEMT+rGY9S1w; Wed, 8 Jun 2011 20:53:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 465C011E8078; Wed, 8 Jun 2011 20:53:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so1219782vxg.31 for ; Wed, 08 Jun 2011 20:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7+OuI7nMzSdOiI4TY2x7oxBl9Cr0FcxkduNdE1pceI4=; b=Ikf0HLeEhmJQMQYywovgv9WA94Klipy2XQ7vKKKReWeRQS6FFJQnfVgcn5QfdE2Y5I Ha9diz3mr1GajlvWyr1J/itE8luPFRHNUeVFb+zP0raryjOBBgzXxUbxNcNoQyViowKp BLTEpFbySq1PvNe8m5DTqdgsdtigBDqrtGW0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cH4Y3ug7EpA/Ig2xWO40p9Kh49NA+S6dCac/ZHKP/FVOKz/u3xUZvqbI+DxKFodiSh 7e+I1fOtwEA2QUXD8vdJioK1R+4gEg0Y2/kXIxu3YLPRMJ0A78ww7ZmCZ05XNvLFcLDU KMtUtAf8Cr46h7W61UBXxGpoYWKSbhIwT+irY= MIME-Version: 1.0 Received: by 10.52.76.10 with SMTP id g10mr310749vdw.252.1307591590090; Wed, 08 Jun 2011 20:53:10 -0700 (PDT) Received: by 10.52.111.169 with HTTP; Wed, 8 Jun 2011 20:53:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 8 Jun 2011 20:53:10 -0700 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim , OAuth WG , "apps-discuss@ietf.org" , Nico Williams Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 03:53:13 -0000 On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: Tim [mailto:tim-projects@sentinelchicken.org] >> Sent: Wednesday, June 08, 2011 8:32 AM > >> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? >> That is not just rhetorical, it is a genuine question. What is HTTP Digest >> missing that you need? Digest has a bunch of problems. See this document http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2 for a short tour of them. > The latest version of this draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 > > Includes a Design Constraints section which tries to explain this: > > Unlike the HTTP Digest authentication scheme, this mechanism does not > require interacting with the server to prevent replay attacks. > Instead, the client provides both a nonce and a timestamp, which the > server can use to prevent replay attacks using a bounded amount of > storage. It's not obvious to me why the mechanism in the draft is better than a server-generated nonce and/or opaque string, as found in Digest. The mechanism in the draft can be bitten by clock skew problems, and having the server send a nonce doesn't necessarily require an unbounded amount of storage. I'm sorry if I've missed previous discussion on this issue, but could someone explain? > Also unlike Digest, this mechanism is not intended to > protect the user's password itself because the client and server both > have access to the key material in the clear. Instead, servers > should issue a short-lived derivative credential for this mechanism > during the initial TLS setup phase. That makes sense. I'm having trouble reconciling the Design Constraints section (1.1) with the section on Entropy of MAC Keys (7.5). How long are these keys supposed to be around in practice? Also, Adam wrote "this mechanism is for folks who cannot or will not deploy TLS". How does that statement fit here? - Rob From paulej@packetizer.com Wed Jun 8 22:04:00 2011 Return-Path: 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 0A96811E8074; Wed, 8 Jun 2011 22:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQF-pv-jrl7m; Wed, 8 Jun 2011 22:03:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7407111E80A1; Wed, 8 Jun 2011 22:03:57 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5953hAL023650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:03:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307595829; bh=bHUS1hrduBOhmVFiZU6VBRq2kMVBuAuYbE74ZGGRx8c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=epqzw1+fBL5v7YSl+6SHpNmcKgiGq3AQOac3v7bKnxDPSEGp4mHZZBtr6efZD+RmO SeV3yDxMFF4LJdc8W1BW3lQm6AumAdv24K+FvL5ZjN1jEkArFJW5B1LnYLOH2F/5zf ndZukHsMv+FSYo9RMrLVSodAa4GA+s4566kvYYSI= From: "Paul E. Jones" To: "'Nico Williams'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> In-Reply-To: Date: Thu, 9 Jun 2011 01:03:35 -0400 Message-ID: <02c401cc2662$9a21d220$ce657660$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C5_01CC2641.13103220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QI7UtjxlOx2sXA= Content-Language: en-us Cc: apps-discuss@ietf.org, 'Ben Adida' , http-state@ietf.org, 'Adam Barth' , 'OAuth WG' , 'HTTP Working Group' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 05:04:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C5_01CC2641.13103220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What issues, specifically. (Messages are all over the place and I = don=E2=80=99t know exactly what issues you=E2=80=99re raising. Is it = with the approach we=E2=80=99re proposing or something else?) =20 Paul =20 From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: Wednesday, June 08, 2011 10:55 AM To: Paul E. Jones Cc: apps-discuss@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; = Ben Adida; Adam Barth; Eran Hammer-Lahav; http-state@ietf.org Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme =20 On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote: > > Nico, > > Cookies would still be employed. A cookie would be used to identify = the particular user, for example. However, it's important to make sure = that the cookie provided by the client to the server is not stolen. = It's important to ensure that the client provided by the server to the = client is not modified. That's the reason for the MAC. Once we can = ensure the integrity of the message exchange, then the existing cookie = mechanism can provide us with the secure state management capability we = need. You're still not addressing the issues raised. Nico --=20 ------=_NextPart_000_02C5_01CC2641.13103220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What issues, specifically.=C2=A0 (Messages are all over the place and = I don=E2=80=99t know exactly what issues you=E2=80=99re raising.=C2=A0 = Is it with the approach we=E2=80=99re proposing or something = else?)

 

Paul

 

From:= = Nico Williams [mailto:nico@cryptonector.com]
Sent: Wednesday, = June 08, 2011 10:55 AM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; Ben = Adida; Adam Barth; Eran Hammer-Lahav; = http-state@ietf.org
Subject: RE: [http-state] [apps-discuss] = HTTP MAC Authentication Scheme

 


On Jun 8, 2011 2:09 AM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:
>
> Nico,
>
> Cookies would still be = employed.  A cookie would be used to identify the particular user, = for example.  However, it's important to make sure that the cookie = provided by the client to the server is not stolen.  It's important = to ensure that the client provided by the server to the client is not = modified.  That's the reason for the MAC.  Once we can ensure = the integrity of the message exchange, then the existing cookie = mechanism can provide us with the secure state management capability we = need.

You're still not addressing the issues = raised.

Nico
-- =

------=_NextPart_000_02C5_01CC2641.13103220-- From paulej@packetizer.com Wed Jun 8 22:13:21 2011 Return-Path: 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 CAB0B11E80A1; Wed, 8 Jun 2011 22:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWNlOPCX6C02; Wed, 8 Jun 2011 22:13:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE411E808D; Wed, 8 Jun 2011 22:13:20 -0700 (PDT) Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p595DCHV024090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:13:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307596397; bh=slx2jdY6CfKAWo//nDtH0XhGc+XjcXkUrBdSyGAS4t4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LoFlQNxAfimVGF8/HQnsk92vMbGZdUSpuvjny1jNF8leCFTPBBMcoWbcoStQ7Pnf/ 5ZMMjdWHiCzeCHWWe8FbwAxbpMbWpNZyVAm1cO/urIT0UyikmqhmvBDJNuHSvBlqjH +osK1DrzqWwkUq7zHsQ4FRd1R+HN6lyhmjIW0RXY= From: "Paul E. Jones" To: "'Tim'" References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> In-Reply-To: <20110608153225.GL1565@sentinelchicken.org> Date: Thu, 9 Jun 2011 01:13:04 -0400 Message-ID: <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QFg30tslPNKqlA= Content-Language: en-us Cc: apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' , 'Nico Williams' , 'OAuth WG' Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 05:13:21 -0000 Tim, > Hi Paul, > > > That's the reason for the MAC. Once we can ensure the integrity of > > the message exchange, then the existing cookie mechanism can provide > > us with the secure state management capability we need. > > Maybe I'm missing something in the MAC authentication draft, but I don't > see how it provides integrity for the "exchange". In particular, the > body of request messages may be optionally hashed to protect their > integrity, but no such facility seems to be provided for responses from > the server. In many modern web applications, this could be trivially > exploited by an attacker to inject malicious script into a server > response. You are referring to draft-salgueiro-secure-state-management-04? In that document, Section 6 covers responses from the server. The server may hash any part of the message it wishes, including the body and selected header. It's possible to also have an empty body and including that in the hash will ensure that no body is inserted where one shouldn't have been. > HTTP Digest authentication provides an option (auth-int) for integrity > protection of both requests and responses and for every request/response > after the initial authentication. In fact if servers change nonces each > time, reuse of hashes becomes difficult. Some level of mutual > authentication is also provided and the opaque string can be used to > pass arbitrary extra data between clients and servers. > IIRC, this value can be passed *cross domain* based on a defined white > list. > > At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? > That is not just rhetorical, it is a genuine question. What is HTTP > Digest missing that you need? We've not looked at HTTP Digest and we were not targeting OAuth with our document. Just so that I'm looking at the right "HTTP Digest" text, can you tell me the document name? I found several when I did a search. Paul From ietf@adambarth.com Wed Jun 8 23:31:03 2011 Return-Path: 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 C90B411E8082 for ; Wed, 8 Jun 2011 23:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwDy5sNcv0ds for ; Wed, 8 Jun 2011 23:31:03 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D500611E8070 for ; Wed, 8 Jun 2011 23:31:02 -0700 (PDT) Received: by yib18 with SMTP id 18so899127yib.31 for ; Wed, 08 Jun 2011 23:31:02 -0700 (PDT) Received: by 10.236.189.103 with SMTP id b67mr415420yhn.369.1307601060461; Wed, 08 Jun 2011 23:31:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id i61sm724722yhe.47.2011.06.08.23.30.58 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 23:30:59 -0700 (PDT) Received: by yib18 with SMTP id 18so899076yib.31 for ; Wed, 08 Jun 2011 23:30:58 -0700 (PDT) Received: by 10.91.96.2 with SMTP id y2mr1506923agl.179.1307601058197; Wed, 08 Jun 2011 23:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Wed, 8 Jun 2011 23:30:28 -0700 (PDT) From: Adam Barth Date: Wed, 8 Jun 2011 23:30:28 -0700 Message-ID: To: Robert Sayre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 06:31:03 -0000 [Trimming the CC to just the OAuth WG.] On Wed, Jun 8, 2011 at 8:53 PM, Robert Sayre wrote: > On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav = wrote: >>> -----Original Message----- >>> From: Tim [mailto:tim-projects@sentinelchicken.org] >>> Sent: Wednesday, June 08, 2011 8:32 AM >> >>> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth? >>> That is not just rhetorical, it is a genuine question. =A0What is HTTP = Digest >>> missing that you need? > > Digest has a bunch of problems. See this document > > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#sect= ion-2.2.2 > > for a short tour of them. > >> The latest version of this draft: >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 >> >> Includes a Design Constraints section which tries to explain this: >> >> =A0 Unlike the HTTP Digest authentication scheme, this mechanism does no= t >> =A0 require interacting with the server to prevent replay attacks. >> =A0 Instead, the client provides both a nonce and a timestamp, which the >> =A0 server can use to prevent replay attacks using a bounded amount of >> =A0 storage. > > It's not obvious to me why the mechanism in the draft is better than a > server-generated nonce and/or opaque string, as found in Digest. Maybe I'm not completely clear how a mechanism with a server-supplied nonce would work. How do you avoid having to make a round-trip to the server for every request? > The mechanism in the draft can be bitten by clock skew problems, and > having the server send a nonce doesn't necessarily require an > unbounded amount of storage. I'm sorry if I've missed previous > discussion on this issue, but could someone explain? I think we've handled most of the clock skew problems by using relative time rather than absolute time. I'd certainly consider a mechanism with a server-supplied nonce if you have one in mind. >> =A0 Also unlike Digest, this mechanism is not intended to >> =A0 protect the user's password itself because the client and server bot= h >> =A0 have access to the key material in the clear. =A0Instead, servers >> =A0 should issue a short-lived derivative credential for this mechanism >> =A0 during the initial TLS setup phase. > > That makes sense. I'm having trouble reconciling the Design > Constraints section (1.1) with the section on Entropy of MAC Keys > (7.5). How long are these keys supposed to be around in practice? I'd recommend using a MAC key of roughly the same length as the block size of the MAC. For example, for hmac-sha-1, I'd use 20 bytes. > Also, Adam wrote "this mechanism is for folks who cannot or will not > deploy TLS". How does that statement fit here? Often the issues surrounding deploying TLS revolve around third-party integrations, such as advertisements. This mechanism side-steps those issues, albeit providing less security than TLS. Adam From denadai2@gmail.com Thu Jun 9 04:11:54 2011 Return-Path: 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 248E111E8093 for ; Thu, 9 Jun 2011 04:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjd8D7W7gLSB for ; Thu, 9 Jun 2011 04:11:52 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58611E80B5 for ; Thu, 9 Jun 2011 04:11:45 -0700 (PDT) Received: by qyk7 with SMTP id 7so860393qyk.10 for ; Thu, 09 Jun 2011 04:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pAW+4YbWDFGDzMAWR/sD7sZNgE8GZXlojcbrwl8mYug=; b=xh1IE9MNJhG73XJJfch08kdgcUWu1vZHBzo+rfNV6R/iIDEfrrB0xxpOsHRjqKdWze AkWPnZM02uFUjzdlTgSX9IlpVR6ZD3VqxtMtWEv9xBouX7/+aq+KLpEfF4OMlbmNhz6a 8n2/ukd36/sfaopwG31FtUgkI0PPYrRVMtRmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=i7LKhSpJMhBykpVEXc1fBsAo7keHCia7noeMMElRpNKqOtub2AM8XOJn9LFZmgBqn2 MuF75zcbal9LKV/KswMTHhVD/iPHqFwSBg9ukzYTillXi4f18YvmNeNwMhPN1juR+zmZ wkua16Pe+39PykSjH6eOyZliKNmMMIsTfhfcc= Received: by 10.229.63.151 with SMTP id b23mr371773qci.289.1307617905314; Thu, 09 Jun 2011 04:11:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.94.149 with HTTP; Thu, 9 Jun 2011 04:11:25 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E773DCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234475E773DCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: denadai2 Date: Thu, 9 Jun 2011 13:11:25 +0200 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e65dc8ecbf8b1104a5458433 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 11:11:54 -0000 --0016e65dc8ecbf8b1104a5458433 Content-Type: text/plain; charset=ISO-8859-1 yeah, sorry. http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png 2011/6/9 Eran Hammer-Lahav > The last part, refresh token, is with the authorization server, not > resource server. > > > > EHL > > > > *From:* denadai2 [mailto:denadai2@gmail.com] > *Sent:* Wednesday, June 08, 2011 1:27 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't > undestand > > > > Perfect, thank you. I made a sequence diagram for Authorization code. I > want to explain the MINIMAL authorization requisites. > > > > http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png > > I explained in red the REQUIRED TLS connections. Is that all right? > > > > Thank you > > 2011/5/22 Eran Hammer-Lahav > > > > > > *From: *denadai2 > *Date: *Sun, 22 May 2011 08:27:41 -0700 > *To: *Eran Hammer-lahav > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't > undestand > > > > Ok thank you. I will be more specific: > > > > 1- Client -> Authorization server. (via TLS) > > I build the authorization request with response_type = "code", > client_id, redirect_uri. > > > > 2- Authorization server -> Client. (without TLS) > > I grant access with an authorization code generated (for example) with > enc(client_id || redirect_uri, secret). redirect_uri > > is the uri of the authorization request and secret is a diffie-hellman > secret shared with the Client in a previous step. > > > > 3- Client -> Authorization server. (without TLS) > > I request the access token with grant_type = "authorization_code", > client_id, code = "[authorization code of step 2]", > > redirect_uri = [redirect_uri of step 2]. > > The Authorization server now will check that the authorization code was > issued to that client and will verify that the uri matches the > redirection URI with: dec(authorization_code, secret). > > > > TLS Required > > > > > > 4- Authorization server -> Client. (without TLS) > > Authorization code will return the access_token: > > access_token = "..." > > token_type = "mac" > > mac_key= "..." > > mac_algorithm = "hmac-sha-256". > > The access_token is generated with sha-256(random_string()) > > > > TLS Required > > > > > > 5- Client -> resource owner (without TLS) > > The client request a resource with access_token obtained in step 4 and > > Authorization header: MAC id="[access_token provided in step 4]" > > nonce="[age]:[randomstring]" > > > mac=hmac-sha-256(normalized_string, [mac_key provided in step4]) > > The resource owner will asks to the Authorization server if the > access_token is valid (if it belongs to the client and if it > > not expired, if the scope is allowed etc). > > > > Not the resource owner, the resource server. > > > > > > 6- resource owner - > Client (without TLS) > > It will provide the resouce requested > > > > Resource server, not owner. > > > > - Did I understand? > > > > Overall yes. > > > > - how would you generate a token? > > > > That's outside the scope of the protocol. It can be a self encoded string, > or an identifier used to DB lookup. > > > > - Is the id field the access_token provided in the authorization response? > > > > Yes. > > > > EHL > > > > > > Thank you. Is very difficult to verify a protocol that has so many variants > :) > > > > 2011/5/22 Eran Hammer-Lahav > > You need to be more specific about what is confusing you. V2-16 7.1 is just > an example. For using MAC you need to refer to the MAC spec. > > > > How you generate your access token string is an internal detail but your > use of the authorization code in the algorithm is odd, IMO. > > > > The MAC is calculated based on the normalized string as defined in the MAC > spec (and it does not include the access token). > > > > If you want help, you need to give a real example for the wire requests and > responses. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *denadai2 > *Sent:* Saturday, May 21, 2011 11:16 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand > > > > I'm trying to formal verify the OAuth 2.0 draft 16 protocol. > > > > I want to try OAuth 2.0 with hmac token type (). > > > > In the "Authorization Code" mode i have the response token as this: > > - access_token: [access_token] > > - token_type: mac > > - mac_key: buabuabua > > - mac_algorithm: hmac-sha-256 > > The access_token is calculated with hmac(client_id || authorization_code, > secret). right? > > > > Now there is my problem. I want to access to a resource controlled by a > resource owner. Do i need to do this > > GET /resource/1 HTTP/1.1 > > Host: example.com > > Authorization: MAC id = [access_token provided in the first pass] > > nonce = "274312:dj83hs92" > > mac = "ASDDFGDFGDG" > > with mac calculated with hmac(nonce || GET || url || host || access_token, > secret) > > > > ? > > > > I don't undestand. There is too much confusion from this: > http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-7.1 and this > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00#section-1.2 > > > > > --0016e65dc8ecbf8b1104a5458433 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yeah, sorry.=A0http://dl.dropbox.com/u/1118905/oauth2-authorization-code.png=

2011/6/9 Eran Hammer-Lahav <eran@hueniverse.com= >

The last part, refresh token, is with the authorization server, not= resource server.

=A0

EHL

=A0

From: denadai2 [mailto:denadai2@gmail.com= ]
Sent: Wednesday, June 08, 2011 1:27 PM
To: Eran Hammer-Lah= av
Cc: oauth@= ietf.org


Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand

=A0

Perfect, thank you. I made a sequence = diagram for Authorization code. I want to explain the MINIMAL authorization= requisites.

=A0

I explained in red the REQUIRED TLS connections= . Is that all right?

=A0

Thank you

2011/5/22 Eran Hammer-Lahav <eran@hueniverse.com>

=A0

=A0

<= p class=3D"MsoNormal">From:= denadai2 <denadai2@gmail.com&g= t;
Date: Sun, 22 May 2011 08:27:41 -0700
To: Eran Hammer-laha= v <eran@huenive= rse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't= undestand

=A0

Ok= thank you. I will be more specific:

=A0

1- Client -> Authorization = server. (via TLS)

=A0 =A0 I build the authorization request= with response_type =3D "code", client_id, redirect_uri.

=A0

2- Authorization server -> Client. (without TLS)

=A0 =A0 I grant access with an authorization code generated (for exampl= e) with enc(client_id || redirect_uri, secret). redirect_uri=A0

<= /div>

=A0 =A0= is the uri of the authorization request and secret is a diffie-hellman sec= ret shared with the Client in a previous step.

=A0

3-=A0Client = -> Authorization server. (without TLS)

=A0 =A0 I request the access t= oken with grant_type =3D "authorization_code", client_id, code = =3D "[authorization code of step 2]",

=A0 =A0 redirect_uri =3D [redi= rect_uri of step 2].

=A0 =A0 The Authorization server now wil= l check that the authorization code was issued to that client and will veri= fy that the uri =A0 =A0 =A0 matches the redirection URI with: dec(authoriza= tion_code, secret).=A0

=A0

TLS Required

=

=A0

=A0

4- Authorization server -> Client. (without TLS)

=A0 = =A0 Authorization code will return the access_token:=A0

=A0 =A0 =A0 =A0access_token =3D "..."

=A0 =A0 = =A0 =A0token_type =3D "mac"

=A0 =A0 =A0 =A0mac_key=3D "..."

=A0 =A0 =A0 =A0= mac_algorithm =3D "hmac-sha-256".=A0

=A0 =A0 The access_token is generated with sha-256(random_string())

=A0

TLS Required

=A0

= =A0

5- Client -> resource owner (without TLS)

=A0 =A0= The client request a resource with access_token obtained in step 4 and=A0<= /span>

=A0 =A0 =A0 =A0Authorization header: MAC id=3D"[access_t= oken provided in step 4]"=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0nonce=3D"[age]:[randomstring]"

=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0mac=3Dhmac-sha-256(normalized_string, [mac_key prov= ided in step4])

=A0 =A0 The resource owner will asks to the Authorization server if the= access_token is valid (if it belongs to the client and if it=A0

=

= =A0 =A0 not expired, if the scope is allowed etc).

=A0

Not the resource owner, the resource server.

= =A0

=A0

6- reso= urce owner - > Client (without TLS)

=A0 =A0 It will provid= e the resouce requested

=A0

Resource server, not owner.=

= =A0

- Did I understand?

=

=A0

Overall yes.

=A0

- how w= ould you generate a token?=A0

=A0

That's outside the scope o= f the protocol. It can be a self encoded string, or an identifier used to D= B lookup.

=A0

<= p class=3D"MsoNormal">- Is the= id field the access_token provided in the authorization response?

=A0

Yes.

<= div>

=A0

EHL=

=A0

<= p class=3D"MsoNormal">=A0

Thank you. Is very difficult to verify a protocol that has so many vari= ants :)

=A0

20= 11/5/22 Eran Hammer-Lahav <eran@hueniverse.com>

You need to be more specific= about what is confusing you. V2-16 7.1 is just an example. For using MAC y= ou need to refer to the MAC spec.=

=A0

How you generate your access token s= tring is an internal detail but your use of the authorization code in the a= lgorithm is odd, IMO.

=A0

The MAC is calculated based on the n= ormalized string as defined in the MAC spec (and it does not include the ac= cess token).

=A0

If you want help, you need to give a= real example for the wire requests and responses.

=A0

EHL

=A0

From= : oauth-bounces@ietf.org [mail= to:oauth-bounce= s@ietf.org] On Behalf Of denadai2
Sent: Saturday, May 21, 2011 11:16 AM
To: oauth@ietf.org
Subject: [= OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand

= =A0

I'm tr= ying to formal verify the OAuth 2.0 =A0draft 16 protocol.=A0

=A0

I want to try OAuth 2.0 with hmac token type (= ).

= =A0

In the "= Authorization Code" mode i have the response token as this:

=

- access_toke= n: [access_token]

- token_type:= mac

- mac_key: buabuabua

- mac_algorithm: hmac-sha-256

The access_to= ken is calculated with hmac(client_id || authorization_code, secret). right= ?

=A0

Now there is = my problem. I want to access to a resource controlled by a resource owner. = Do i need to do this

GET /resource/1 HTTP/1.1

<= div>

Authorization: MAC i= d =3D [access_token provided in the first pass]

=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nonce =3D "274312:dj83h= s92"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mac =3D &= quot;ASDDFGDFGDG"

with mac calc= ulated with hmac(nonce || GET || url || host || access_token, secret)

=A0

?

<= /div>

=A0

=

=A0

<= /div>

=A0


--0016e65dc8ecbf8b1104a5458433-- From tim-projects@sentinelchicken.org Thu Jun 9 07:30:07 2011 Return-Path: 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 11B8111E80D2 for ; Thu, 9 Jun 2011 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.389, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id angV38BnOdV1 for ; Thu, 9 Jun 2011 07:30:05 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4140911E808B for ; Thu, 9 Jun 2011 07:30:04 -0700 (PDT) Received: (qmail 24243 invoked from network); 9 Jun 2011 14:30:01 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2011 14:30:01 -0000 Received: (qmail 19446 invoked from network); 9 Jun 2011 14:31:11 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 9 Jun 2011 14:31:11 -0000 Received: (nullmailer pid 28089 invoked by uid 1000); Thu, 09 Jun 2011 14:30:00 -0000 Date: Thu, 9 Jun 2011 07:30:00 -0700 From: Tim To: "Paul E\. Jones" Message-ID: <20110609143000.GQ1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d101cc2663$eceb6790$c6c236b0$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'OAuth WG' , 'HTTP Working Group' , apps-discuss@ietf.org, http-state@ietf.org Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:30:07 -0000 > You are referring to draft-salgueiro-secure-state-management-04? > > In that document, Section 6 covers responses from the server. The server > may hash any part of the message it wishes, including the body and selected > header. It's possible to also have an empty body and including that in the > hash will ensure that no body is inserted where one shouldn't have been. No, throughout this discussion I'm just looking at: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token Does this tie in to the secure state management draft? If so, can you point me to the section in the MAC draft so I can get up to speed? > We've not looked at HTTP Digest and we were not targeting OAuth with our > document. Just so that I'm looking at the right "HTTP Digest" text, can you > tell me the document name? I found several when I did a search. Just the (latest?) RFC: http://www.ietf.org/rfc/rfc2617.txt thanks, tim From tim-projects@sentinelchicken.org Thu Jun 9 07:42:29 2011 Return-Path: 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 5C1A721F8476 for ; Thu, 9 Jun 2011 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRFD6htw6M41 for ; Thu, 9 Jun 2011 07:42:25 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2163621F847C for ; Thu, 9 Jun 2011 07:42:25 -0700 (PDT) Received: (qmail 24292 invoked from network); 9 Jun 2011 14:42:24 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2011 14:42:24 -0000 Received: (qmail 19503 invoked from network); 9 Jun 2011 14:43:35 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 9 Jun 2011 14:43:35 -0000 Received: (nullmailer pid 28192 invoked by uid 1000); Thu, 09 Jun 2011 14:42:24 -0000 Date: Thu, 9 Jun 2011 07:42:24 -0700 From: Tim To: Robert Sayre Message-ID: <20110609144224.GR1565@sentinelchicken.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "apps-discuss@ietf.org" , OAuth WG Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:42:29 -0000 > Digest has a bunch of problems. See this document > > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2 > > for a short tour of them. Thanks for the link. I totally agree with all of this, and in fact there are more MitM attacks possible than are alluded to in that document. This is one of the two reasons I brought up Digest initially. The MAC proposal does not appear to provide any additional security over Digest, and yet Digest is still susceptible to MitM attacks. We can pick and prod at the MAC proposal all we want from a security perspective, but we'll probably end up at the same place that Digest is at, security-wise. We'll still have a protocol that can't defend against MitM attacks. So what is the point in providing integrity again? We need to use TLS. Everywhere. The more you look at advanced web attacks (MitM downgrade attacks, DNS rebinding attacks, etc), the more you realize that most of these are addressed by TLS if only it were used everywhere. It's fine to bring out special-purpose authentication protocols. Authentication can happen in a variety of ways either within TLS or tunneled over it (hopefully with channel binding), but don't pretend you'll be doing anyone favors by trying to provide partial integrity protection that is ultimately ineffective. Just focus on better authentication and key/certificate management and let TLS do the rest. tim From sayrer@gmail.com Thu Jun 9 19:03:38 2011 Return-Path: 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 7D1FB11E8080 for ; Thu, 9 Jun 2011 19:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjHT80+y8LJ7 for ; Thu, 9 Jun 2011 19:03:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B366F11E8073 for ; Thu, 9 Jun 2011 19:03:37 -0700 (PDT) Received: by vws12 with SMTP id 12so2398492vws.31 for ; Thu, 09 Jun 2011 19:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HvBqzW3uBuzF1pn+ja1Fve1WuLPGArVwd5tfD5g2f34=; b=CpL4aB8+wqsiuWQLogbb7QCZYjcrso23ObYbH003dm3uuYPV4nsRsynb4RBLzJAgiJ KcY4ExBAL0QNg1mEWwA8kShVy4jObaVgS4bhFoW2L1pVfPtoDMhfc3dXKK7XqL5kH75K xpQipwqjEUrllsPdoeVWO/Fo7ZeniKTkMZUgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bVc5cbCfA+/qxR3KnD3qnXEgqnQLvbjp4RigDmXY4lU8W3JeUaQZzlngdxVWrAi4ip VT2pXzybqaDVCrz/cPfK9pGxEvlHw8EcOwu7+a6q4/oXSZmGIGNNxTZ8IJ3SLJmnDTF8 j3bFAe8i80nWmEn9guiwDJjnNkVrBfTxvWvxU= MIME-Version: 1.0 Received: by 10.52.74.74 with SMTP id r10mr447800vdv.212.1307671417225; Thu, 09 Jun 2011 19:03:37 -0700 (PDT) Received: by 10.52.111.169 with HTTP; Thu, 9 Jun 2011 19:03:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jun 2011 19:03:37 -0700 Message-ID: From: Robert Sayre To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 02:03:38 -0000 On Wed, Jun 8, 2011 at 11:30 PM, Adam Barth wrote: > > Maybe I'm not completely clear how a mechanism with a server-supplied > nonce would work. =A0How do you avoid having to make a round-trip to the > server for every request? Maybe I'm confused about the expected flow here. It's not clear to me where the initial credentials are coming from, or how much the server knows about the MAC credentials. The specification has multiple servers (resource servers and authorization servers) in play sometimes, but other times it refers to "the server". Also, section 4 makes it seem like quite a lot coordination is expected between the authorization server and the resource server. This might all be obvious to someone who lives and breathes OAuth, but I think it is worth clarifying. Here's what I was thinking: The example in section 1.1 includes an initial 401 response. If that initial 401 response is expected, then the server can include some domain-wide data in the WWW-Authenticate header, and refresh it at will, even in successful responses. GET /resource/1 HTTP/1.1 Host: example.com ... HTTP/1.1 401 Unauthorized WWW-Authenticate: MAC opaque=3D"abc123abc123" ... GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC ... opaque=3D"abc123abc123" ... HTTP/1.1 200 OK WWW-Authenticate: MAC opaque=3D"def456def456" ... GET /resource/2 HTTP/1.1 Host: example.com Authorization: MAC ... opaque=3D"def456def456" That opaque string can be anything the server wants, and it can change with every request, or less often. Adding this field could help servers even if it doesn't , in cases where a misbehaving client is getting the client nonce wrong. If the goal of the scheme is to avoid encountering a 401 even for the initial request, then I suggest updating the example in section 1.1. >> >> That makes sense. I'm having trouble reconciling the Design >> Constraints section (1.1) with the section on Entropy of MAC Keys >> (7.5). How long are these keys supposed to be around in practice? > > I'd recommend using a MAC key of roughly the same length as the block > size of the MAC. =A0For example, for hmac-sha-1, I'd use 20 bytes. > I was asking about how often keys might expire. Section 7.5 says something like 2 weeks. What can we reasonably expect from the use cases we have in mind? - Rob From ietf@adambarth.com Thu Jun 9 22:26:22 2011 Return-Path: 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 E124211E80A1 for ; Thu, 9 Jun 2011 22:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7rUiv4HQyxX for ; Thu, 9 Jun 2011 22:26:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14A11E8078 for ; Thu, 9 Jun 2011 22:26:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so1854358gxk.31 for ; Thu, 09 Jun 2011 22:26:21 -0700 (PDT) Received: by 10.236.5.140 with SMTP id 12mr1981935yhl.433.1307683580074; Thu, 09 Jun 2011 22:26:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id k10sm1167604yhj.8.2011.06.09.22.26.18 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 22:26:18 -0700 (PDT) Received: by gxk19 with SMTP id 19so1854300gxk.31 for ; Thu, 09 Jun 2011 22:26:18 -0700 (PDT) Received: by 10.91.208.29 with SMTP id k29mr2694158agq.71.1307683578058; Thu, 09 Jun 2011 22:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Thu, 9 Jun 2011 22:25:48 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Thu, 9 Jun 2011 22:25:48 -0700 Message-ID: To: Robert Sayre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 05:26:23 -0000 On Thu, Jun 9, 2011 at 7:03 PM, Robert Sayre wrote: > On Wed, Jun 8, 2011 at 11:30 PM, Adam Barth wrote: >> >> Maybe I'm not completely clear how a mechanism with a server-supplied >> nonce would work. =A0How do you avoid having to make a round-trip to the >> server for every request? > > Maybe I'm confused about the expected flow here. It's not clear to me > where the initial credentials are coming from, or how much the server > knows about the MAC credentials. The specification has multiple > servers (resource servers and authorization servers) in play > sometimes, but other times it refers to "the server". Also, section 4 > makes it seem like quite a lot coordination is expected between the > authorization server and the resource server. This might all be > obvious to someone who lives and breathes OAuth, but I think it is > worth clarifying. > > Here's what I was thinking: The example in section 1.1 includes an > initial 401 response. If that initial 401 response is expected, then > the server can include some domain-wide data in the WWW-Authenticate > header, and refresh it at will, even in successful responses. > > GET /resource/1 HTTP/1.1 > Host: example.com > > ... > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: MAC opaque=3D"abc123abc123" > > ... > > GET /resource/1 HTTP/1.1 > Host: example.com > Authorization: MAC ... opaque=3D"abc123abc123" > > ... > > HTTP/1.1 200 OK > WWW-Authenticate: MAC opaque=3D"def456def456" > > ... > > GET /resource/2 HTTP/1.1 > Host: example.com > Authorization: MAC ... opaque=3D"def456def456" > > > That opaque string can be anything the server wants, and it can change > with every request, or less often. Adding this field could help > servers even if it doesn't , in cases where a misbehaving client is > getting the client nonce wrong. > > If the goal of the scheme is to avoid encountering a 401 even for the > initial request, then I suggest updating the example in section 1.1. What happens when the client wants to send more than one request at a time to the server? For example, when loading a web page, browsers often open multiple sockets to send multiple request in parallel to improve performance. The normal flow in the browser setting does not use 401 and is as follows: Client ----> Server (HTTPS) GET /login Server ----> Client (HTTPS) 200 OK Set-Cookie: SID=3D3048jhseofhoesdfdf; MAC-Key=3DOIneoiunf; MAC-Algorithm=3Dhmac-sha-1; Path=3D/ Client ----> Server (HTTPS) POST /login Authorization: MAC id=3D"SID", nonce=3D"2:ion308r32"; mac=3D"ow8fnwnougview= 4t0=3D" username=3Dsayrer&password=3Dtacotacotaco The session is now established. Commonly, we'd expect the session to contain a mix of HTTP and HTTPS requests. Each request comes with a new nonce and a mac, etc. >>> That makes sense. I'm having trouble reconciling the Design >>> Constraints section (1.1) with the section on Entropy of MAC Keys >>> (7.5). How long are these keys supposed to be around in practice? >> >> I'd recommend using a MAC key of roughly the same length as the block >> size of the MAC. =A0For example, for hmac-sha-1, I'd use 20 bytes. > > I was asking about how often keys might expire. Section 7.5 says > something like 2 weeks. What can we reasonably expect from the use > cases we have in mind? Yes. Their lifetime should be commensurate with session cookies. (This mechanism really just adds a little more security to session cookies.) Adam From recordond@gmail.com Fri Jun 10 01:20:19 2011 Return-Path: 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 F326F11E80D2 for ; Fri, 10 Jun 2011 01:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E63SgdxUlUGt for ; Fri, 10 Jun 2011 01:20:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 393E911E8070 for ; Fri, 10 Jun 2011 01:20:18 -0700 (PDT) Received: by vxg33 with SMTP id 33so2656980vxg.31 for ; Fri, 10 Jun 2011 01:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=34dVwnq9KNUdvUW4UKU0DnF5jbh9iIdxE9YWxTScxc0=; b=eRQ4gANldtf4KdXrJ7O3l2Z4xPQnkvfUk94jrFbge4r/aAe7sTE5FN7478pzRaEtUj MzD660qSDn+NWO3t6pHd66fnBsqMXv9eQ+NiuaTLLwNCUmlxb/VKw+V0o5BVyLZ2mg+H RQqCAixB1WhZO0S1vMCRk68ORJ59BbpRyoOX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rlH4FKwA8ThTVXTBT9FrktWUQIwsUrGVH8SiH+ak2XmFoYoS3j/9jfTyVqlOOtBigH 2VfewZtGMAbNPgklwUxegm4eIyqSw+jZQCqx8N8PXIjp5QyN4bM4WfcC4HKge8bEMrH6 Q7WCrKAXyfTIgTn7l0n5LB71NDbdTpgg+NwPE= MIME-Version: 1.0 Received: by 10.52.98.40 with SMTP id ef8mr1210407vdb.54.1307694017404; Fri, 10 Jun 2011 01:20:17 -0700 (PDT) Received: by 10.52.157.5 with HTTP; Fri, 10 Jun 2011 01:20:17 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> Date: Fri, 10 Jun 2011 01:20:17 -0700 Message-ID: From: David Recordon To: George Fletcher , Eran Hammer-Lahav , Doug Tangren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 08:20:19 -0000 George, Doug and Eran are you alright with the Bearer token spec using the parameter name "access_token" as well? On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu wr= ote: > On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones = wrote: >> If you can drive a consensus decision for the name "access_token", I'd b= e glad to change the name in the spec. =A0I agree that the current names ar= e confusing for developers. > > At Google we are getting the same feedback, that it is confusing for > developers. It would definitely help if we could change the name to > "access_token". > > Marius > From gffletch@aol.com Fri Jun 10 04:58:58 2011 Return-Path: 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 F071A11E8099 for ; Fri, 10 Jun 2011 04:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IleMOtqMXdHZ for ; Fri, 10 Jun 2011 04:58:55 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2F11E8072 for ; Fri, 10 Jun 2011 04:58:54 -0700 (PDT) Received: from mtaout-ma04.r1000.mx.aol.com (mtaout-ma04.r1000.mx.aol.com [172.29.41.4]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id p5ABwWLU012772; Fri, 10 Jun 2011 07:58:32 -0400 Received: from palantir.local (unknown [10.172.1.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C9F0DE000105; Fri, 10 Jun 2011 07:58:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1307707112; bh=DDcb9QxV4CJHhTDveUNfTCEA2AZyeTlaGZuXUXjzyKE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=qKosoQgAl1BOYFHcMY4h/9wJCxBRFrgTr4HrcmMvzFqb9gZ0pBwDmaBaoP7RD/Dli Myfbcs1CPo+Yn+ZIqr6OQvwIts4+y/on2r3fG5QciGF6zLvSGXrEjm5KXpBCgjRy6m ekGlwUSD8kHmUaUfm43dU8Is1+Lxy7ZNFF9vipb4= Message-ID: <4DF206E7.3040401@aol.com> Date: Fri, 10 Jun 2011 07:58:31 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Recordon References: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE541B5.6080605@aol.com> <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010902040205000302030909" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:443202048:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29044df206e71ad0 X-AOL-IP: 10.172.1.50 Cc: paul Tarjan , "oauth@ietf.org" Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:58:59 -0000 This is a multi-part message in MIME format. --------------010902040205000302030909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Yes, that's fine with me. Thanks, George On 6/10/11 4:20 AM, David Recordon wrote: > George, Doug and Eran are you alright with the Bearer token spec using > the parameter name "access_token" as well? > > > On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu wrote: >> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones wrote: >>> If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec. I agree that the current names are confusing for developers. >> At Google we are getting the same feedback, that it is confusing for >> developers. It would definitely help if we could change the name to >> "access_token". >> >> Marius >> --------------010902040205000302030909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes, that's fine with me.

Thanks,
George

On 6/10/11 4:20 AM, David Recordon wrote: 
George, Doug and Eran are you alright with the Bearer token spec using
the parameter name "access_token" as well?


On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec.  I agree that the current names are confusing for developers.

At Google we are getting the same feedback, that it is confusing for
developers. It would definitely help if we could change the name to
"access_token".

Marius



    

    

  


--------------010902040205000302030909--

From john@jkemp.net  Fri Jun 10 05:35:56 2011
Return-Path: 
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 780BE11E8118 for ; Fri, 10 Jun 2011 05:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level: 
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCux4rDZku0t for ; Fri, 10 Jun 2011 05:35:55 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 91C6211E810D for ; Fri, 10 Jun 2011 05:35:55 -0700 (PDT)
Received: (qmail 23354 invoked by uid 0); 10 Jun 2011 12:35:55 -0000
Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 10 Jun 2011 12:35:55 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=wyCS1WGGBgh2PJ9bnjsIH+XCKvV+LSfBjZ2MsXQPfQyIj8hgxAMrcujFzk6VLbsPcaCXGDqLFmRE1xrdOp2jW36AmsSVq/nu22dKB1T6LKM6SG321iT9dTbLhNoQjqZ/;
Received: from [192.100.124.156] (helo=[10.180.251.33]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QV0wM-0003zB-K4; Fri, 10 Jun 2011 06:35:55 -0600
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: John Kemp 
In-Reply-To: <4DF206E7.3040401@aol.com>
Date: Fri, 10 Jun 2011 15:35:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>	  <4DF206E7.3040401@aol.com>
To: George Fletcher , David Recordon , paul Tarjan 
X-Mailer: Apple Mail (2.1084)
X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 192.100.124.156 authed with john+jkemp.net}
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 12:35:56 -0000

What does this mean for the HTTP Authorization header naming scheme for =
bearer tokens?

As I understand this decision, we are discussing whether to standardize =
on the name "access_token" when a bearer token is sent as either a URL =
query parameter, or in a form POSTed body?=20

Currently the HTTP Authorization header looks like this (from =
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05):

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT

Is the proposal then that we have:

1. GET /resource?access_token=3DvF9dft4qmT
2. POST /resource

access_token=3DvF9dft4qmT&...

3.=20

GET /resource HTTP/1.1
Host: server.example.com
Authorization: access_token vF9dft4qmT

Can someone actually give the details of the proposal, or agree/disagree =
with the examples above?

- John

On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:

> Yes, that's fine with me.=20
>=20
> Thanks,
> George
>=20
> On 6/10/11 4:20 AM, David Recordon wrote:
>> George, Doug and Eran are you alright with the Bearer token spec =
using
>> the parameter name "access_token" as well?
>>=20
>>=20
>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu=20
>> 
>>  wrote:
>>=20
>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones =

>>>  wrote:
>>>=20
>>>> If you can drive a consensus decision for the name "access_token", =
I'd be glad to change the name in the spec.  I agree that the current =
names are confusing for developers.
>>>>=20
>>> At Google we are getting the same feedback, that it is confusing for
>>> developers. It would definitely help if we could change the name to
>>> "access_token".
>>>=20
>>> Marius
>>>=20
>>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From gffletch@aol.com  Fri Jun 10 06:11:50 2011
Return-Path: 
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 8B1D211E814A for ; Fri, 10 Jun 2011 06:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DOvyHr0rLo9 for ; Fri, 10 Jun 2011 06:11:49 -0700 (PDT)
Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE411E80F8 for ; Fri, 10 Jun 2011 06:11:49 -0700 (PDT)
Received: from mtaout-da05.r1000.mx.aol.com (mtaout-da05.r1000.mx.aol.com [172.29.51.133]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id p5ADBUe4032524; Fri, 10 Jun 2011 09:11:30 -0400
Received: from palantir.local (unknown [10.172.1.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 159DDE00010F; Fri, 10 Jun 2011 09:11:30 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1307711490; bh=CzoMloxee7WjuoKMSNtHL503ft5xJ6yUl0zL6TSXt40=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=MzfpQBUbriQ8UX7ySD3bn76vnDLthV6EAlYin2hBaFRJFjWtGf2Zzw8BKNrx8LZzo 80pGZNZBEtAvugDgInKaAKKTuAj1pKh/fj8Qix+csE8n8x4VlaNVFCOf+B0nUkOUUR GYK5m/fcT1d8l5UJCr6Tet7fqxZ2/mooh9BArwH8=
Message-ID: <4DF21800.9090302@aol.com>
Date: Fri, 10 Jun 2011 09:11:28 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John Kemp 
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>	  <4DF206E7.3040401@aol.com> <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>
In-Reply-To: <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>
Content-Type: multipart/alternative; boundary="------------060205010301030705060708"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:461435904:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d33854df21802769e
X-AOL-IP: 10.172.1.50
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 13:11:50 -0000

This is a multi-part message in MIME format.
--------------060205010301030705060708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I definitely don't want to change the Authorization header naming 
scheme. I believe it should stay 'Bearer' because that's what the token 
is. We could make it...

Authorization: Bearer access_token=vF9dft4qmT

If that helps with consistency. I don't think we should be associating 
the term 'access_token' with the bearer security mechanism.

Thanks,
George

On 6/10/11 8:35 AM, John Kemp wrote:
> What does this mean for the HTTP Authorization header naming scheme for bearer tokens?
>
> As I understand this decision, we are discussing whether to standardize on the name "access_token" when a bearer token is sent as either a URL query parameter, or in a form POSTed body?
>
> Currently the HTTP Authorization header looks like this (from http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05):
>
> GET /resource HTTP/1.1
> Host: server.example.com
> Authorization: Bearer vF9dft4qmT
>
> Is the proposal then that we have:
>
> 1. GET /resource?access_token=vF9dft4qmT
> 2. POST /resource
>
> access_token=vF9dft4qmT&...
>
> 3.
>
> GET /resource HTTP/1.1
> Host: server.example.com
> Authorization: access_token vF9dft4qmT
>
> Can someone actually give the details of the proposal, or agree/disagree with the examples above?
>
> - John
>
> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>
>> Yes, that's fine with me.
>>
>> Thanks,
>> George
>>
>> On 6/10/11 4:20 AM, David Recordon wrote:
>>> George, Doug and Eran are you alright with the Bearer token spec using
>>> the parameter name "access_token" as well?
>>>
>>>
>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>> 
>>>   wrote:
>>>
>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones
>>>>   wrote:
>>>>
>>>>> If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec.  I agree that the current names are confusing for developers.
>>>>>
>>>> At Google we are getting the same feedback, that it is confusing for
>>>> developers. It would definitely help if we could change the name to
>>>> "access_token".
>>>>
>>>> Marius
>>>>
>>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--------------060205010301030705060708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    I definitely don't want to
      change the Authorization header naming scheme. I believe it should
      stay 'Bearer' because that's what the token is. We could make
      it...

      

      Authorization: Bearer access_token=vF9dft4qmT

      

      If that helps with consistency. I don't think we should be
      associating the term 'access_token' with the bearer security
      mechanism.

      

      Thanks,

      George

    

    On 6/10/11 8:35 AM, John Kemp wrote:
    

      
What does this mean for the HTTP Authorization header naming scheme for bearer tokens?

As I understand this decision, we are discussing whether to standardize on the name "access_token" when a bearer token is sent as either a URL query parameter, or in a form POSTed body? 

Currently the HTTP Authorization header looks like this (from http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05):

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT

Is the proposal then that we have:

1. GET /resource?access_token=vF9dft4qmT
2. POST /resource

access_token=vF9dft4qmT&...

3. 

GET /resource HTTP/1.1
Host: server.example.com
Authorization: access_token vF9dft4qmT

Can someone actually give the details of the proposal, or agree/disagree with the examples above?

- John

On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:



      

        
Yes, that's fine with me. 

Thanks,
George

On 6/10/11 4:20 AM, David Recordon wrote:


        

          
George, Doug and Eran are you alright with the Bearer token spec using
the parameter name "access_token" as well?


On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu 
<mscurtescu@google.com>
 wrote:



          

            
On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones <Michael.Jones@microsoft.com>
 wrote:



            

              
If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec.  I agree that the current names are confusing for developers.



            

            
At Google we are getting the same feedback, that it is confusing for
developers. It would definitely help if we could change the name to
"access_token".

Marius




          

        

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


      

      

    

    

  


--------------060205010301030705060708--

From d.tangren@gmail.com  Fri Jun 10 06:23:32 2011
Return-Path: 
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 D328D1F0C51 for ; Fri, 10 Jun 2011 06:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okaReSpGbC7K for ; Fri, 10 Jun 2011 06:23:32 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47D641F0C40 for ; Fri, 10 Jun 2011 06:23:32 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2905196iwn.31 for ; Fri, 10 Jun 2011 06:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tU9iIOl8DTX2Wd/AYjQYPC3u32GQMpo6c2duiSH0zZk=; b=prk1ho4W/mLBP/RyGoB284MYk47Eobse1z7Ew34gpOmJQ4DUAFcjeS0uE7I8WoCK8s wo62s94IWTnZbPCNzknEqPJIv0X/f740xS6ZIgSfAMxezG2iSxNt2IrA/xlz1FuHPChG GhGv5XiVMKGF/hF4DlariZXU0O/I1j53dhVWQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lIQVN/SOC+0feimOMipq/2a+DCQuYJLpiZSlAGbk8ackmKR5tZ5Kx8P0/oxktpIm9s /24xbpafPu8oGogphIbvgsw/TNoB/Imp2kx4uI1iQkpIWz/5uj34zhsrsyaSAE3IiVS8 bhsEpXLJxdN8Sxd7JCDTIc80DD4S5b3/qGHgY=
Received: by 10.42.132.129 with SMTP id d1mr2218535ict.526.1307712211077; Fri, 10 Jun 2011 06:23:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Fri, 10 Jun 2011 06:23:11 -0700 (PDT)
In-Reply-To: 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>  
From: Doug Tangren 
Date: Fri, 10 Jun 2011 09:23:11 -0400
Message-ID: 
To: David Recordon 
Content-Type: multipart/alternative; boundary=90e6ba3fcec5cf4a7304a55b7993
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 13:23:33 -0000

--90e6ba3fcec5cf4a7304a55b7993
Content-Type: text/plain; charset=UTF-8

-Doug Tangren
http://lessis.me


On Fri, Jun 10, 2011 at 4:20 AM, David Recordon  wrote:

> George, Doug and Eran are you alright with the Bearer token spec using
> the parameter name "access_token" as well?
>
>
Consistency is good and less confusing for developers writing generic client
libraries.
+1. I hope hope that if it changes again this time, it doesn't change again
:)!

--90e6ba3fcec5cf4a7304a55b7993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


-Doug Tangren
http://lessis.me



On Fri, Jun 10, 2011 at 4:20 AM, David R=
ecordon <record=
ond@gmail.com> wrote:


George, Doug and Eran are you alright with the Bearer token spec using

the parameter name "access_token" as well?




Consistency is good and less confusing for developers writing gener=
ic client libraries.
+1. I hope hope that if it changes again thi=
s time, it doesn't change again :)!=C2=A0





--90e6ba3fcec5cf4a7304a55b7993--

From gffletch@aol.com  Fri Jun 10 06:50:45 2011
Return-Path: 
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 33EF111E81C8 for ; Fri, 10 Jun 2011 06:50:44 -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=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZBpdMOzRloZ for ; Fri, 10 Jun 2011 06:50:43 -0700 (PDT)
Received: from imr-da05.mx.aol.com (imr-da05.mx.aol.com [205.188.105.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1511E81A2 for ; Fri, 10 Jun 2011 06:50:22 -0700 (PDT)
Received: from mtaout-da01.r1000.mx.aol.com (mtaout-da01.r1000.mx.aol.com [172.29.51.129]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id p5ADo153010240; Fri, 10 Jun 2011 09:50:01 -0400
Received: from palantir.local (unknown [10.172.1.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EB3AFE000089; Fri, 10 Jun 2011 09:50:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1307713801; bh=ncWL03ez9r9Po0XKGAMsuSgBXIVjTEuihGVehZx4qSE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=byg0pTykr7LOl3dvzSqN2dcMUy4ydNCgCeM517FNjKltTM3I+QYrI3cAZPuqT3mmF XMGg4PY6dCnJy2l7oQivL8aBXtfj3IBZkatuGtgA402m5KUYYExubNGAyAlEXClE0E Ks14OJN7DDSBcqhp/m4wCWZFK9IKiQBHYjfpq/9c=
Message-ID: <4DF22108.7000704@aol.com>
Date: Fri, 10 Jun 2011 09:50:00 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Doug Tangren 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:456208480:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d33814df22108303f
X-AOL-IP: 10.172.1.50
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 13:50:45 -0000

+1 :)

On 6/10/11 9:23 AM, Doug Tangren wrote:
>
> I hope hope that if it changes again this time, it doesn't change 
> again :)! 


From frumiousjohn@gmail.com  Fri Jun 10 09:34:08 2011
Return-Path: 
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 D17FE11E8090 for ; Fri, 10 Jun 2011 09:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLjI0Ku4kpCJ for ; Fri, 10 Jun 2011 09:34:08 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB96C11E807C for ; Fri, 10 Jun 2011 09:34:07 -0700 (PDT)
Received: by bwz13 with SMTP id 13so2766253bwz.31 for ; Fri, 10 Jun 2011 09:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=5DchJ0bDqBRF+YoozHS72WxPcLLL+n5je0EcMz82j6Q=; b=LTRLt/surGyMjsJKMx4s1PkMhafF8oZ6c/GczT1CH+YzVF0FOoSSMH1hLQAfEusM2b FXDj21nQVoZdMzLMdow7vZ5oA/OxTd8aqC4+mu7dr5r7uWLvIysYmv/LgPZdwObl/ZwF hjn1/dLOW6uo9VaL/LX0UappBZTlXf2wom7HI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WVR9gs+cIJstwJTX8TfeGN7V5r8/Hamw9RjEVY47R4y7293gJNN+pYwSY85JwK+aZK 7q4Ytz8RfPDWWfF+iws0PIMXiEZMLeevBt7LkEisLgw7bxt6ienOt99S2y85W5bc1EaM +wegJD2d8P3JxpLP6tZkxgLacD36Au1/URN/A=
Received: by 10.204.7.209 with SMTP id e17mr2198950bke.162.1307723646779; Fri, 10 Jun 2011 09:34:06 -0700 (PDT)
Received: from [192.168.158.27] (80-248-241-2.cust.suomicom.fi [80.248.241.2]) by mx.google.com with ESMTPS id ag6sm2730801bkc.18.2011.06.10.09.34.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2011 09:34:05 -0700 (PDT)
Sender: John Kemp 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: John Kemp 
In-Reply-To: <4DF21800.9090302@aol.com>
Date: Fri, 10 Jun 2011 19:34:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>	  <4DF206E7.3040401@aol.com> <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.1084)
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 16:34:09 -0000

George,

On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:

> I definitely don't want to change the Authorization header naming =
scheme. I believe it should stay 'Bearer' because that's what the token =
is. We could make it...
>=20
> Authorization: Bearer access_token=3DvF9dft4qmT
>=20
> If that helps with consistency.

Well, it might seem more consistent, but I'm not sure it's worthwhile to =
make the change just for that reason.=20

Is it possible that the Bearer HTTP mechanism would ever take multiple =
parameters? In which case, having the ability to name the parameters of =
the Bearer mechanism might become more interesting.

- John

> I don't think we should be associating the term 'access_token' with =
the bearer security mechanism.
>=20
> Thanks,
> George
>=20
> On 6/10/11 8:35 AM, John Kemp wrote:
>> What does this mean for the HTTP Authorization header naming scheme =
for bearer tokens?
>>=20
>> As I understand this decision, we are discussing whether to =
standardize on the name "access_token" when a bearer token is sent as =
either a URL query parameter, or in a form POSTed body?=20
>>=20
>> Currently the HTTP Authorization header looks like this (from=20
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>> ):
>>=20
>> GET /resource HTTP/1.1
>> Host: server.example.com
>> Authorization: Bearer vF9dft4qmT
>>=20
>> Is the proposal then that we have:
>>=20
>> 1. GET /resource?access_token=3DvF9dft4qmT
>> 2. POST /resource
>>=20
>> access_token=3DvF9dft4qmT&...
>>=20
>> 3.=20
>>=20
>> GET /resource HTTP/1.1
>> Host: server.example.com
>> Authorization: access_token vF9dft4qmT
>>=20
>> Can someone actually give the details of the proposal, or =
agree/disagree with the examples above?
>>=20
>> - John
>>=20
>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>=20
>>=20
>>> Yes, that's fine with me.=20
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>=20
>>>> George, Doug and Eran are you alright with the Bearer token spec =
using
>>>> the parameter name "access_token" as well?
>>>>=20
>>>>=20
>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu=20
>>>>=20
>>>> 
>>>>=20
>>>> wrote:
>>>>=20
>>>>=20
>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones =

>>>>>=20
>>>>> wrote:
>>>>>=20
>>>>>=20
>>>>>> If you can drive a consensus decision for the name =
"access_token", I'd be glad to change the name in the spec.  I agree =
that the current names are confusing for developers.
>>>>>>=20
>>>>>>=20
>>>>> At Google we are getting the same feedback, that it is confusing =
for
>>>>> developers. It would definitely help if we could change the name =
to
>>>>> "access_token".
>>>>>=20
>>>>> Marius
>>>>>=20
>>>>>=20
>>>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>>=20
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From eran@hueniverse.com  Fri Jun 10 09:41:11 2011
Return-Path: 
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 7CA451F0C56 for ; Fri, 10 Jun 2011 09:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et94vyvSOE3A for ; Fri, 10 Jun 2011 09:41:11 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 076BE1F0C52 for ; Fri, 10 Jun 2011 09:41:11 -0700 (PDT)
Received: (qmail 11576 invoked from network); 10 Jun 2011 16:41:10 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jun 2011 16:41:10 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 10 Jun 2011 09:41:02 -0700
From: Eran Hammer-Lahav 
To: David Recordon , George Fletcher ,  Doug Tangren 
Date: Fri, 10 Jun 2011 09:40:50 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AcwnRzw1IVbv45caSo+KV1mzNU/FNgAReSAw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E7741A4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 16:41:11 -0000

Don't care. Will never use it. :-)

EHL

> -----Original Message-----
> From: David Recordon [mailto:recordond@gmail.com]
> Sent: Friday, June 10, 2011 1:20 AM
> To: George Fletcher; Eran Hammer-Lahav; Doug Tangren
> Cc: Mike Jones; paul Tarjan; oauth@ietf.org; Marius Scurtescu
> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
> George, Doug and Eran are you alright with the Bearer token spec using th=
e
> parameter name "access_token" as well?
>=20
>=20
> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>  wrote:
> > On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones
>  wrote:
> >> If you can drive a consensus decision for the name "access_token", I'd=
 be
> glad to change the name in the spec. =A0I agree that the current names ar=
e
> confusing for developers.
> >
> > At Google we are getting the same feedback, that it is confusing for
> > developers. It would definitely help if we could change the name to
> > "access_token".
> >
> > Marius
> >

From recordond@gmail.com  Fri Jun 10 09:45:59 2011
Return-Path: 
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 E613D21F8491 for ; Fri, 10 Jun 2011 09:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA-wUzWrbyJL for ; Fri, 10 Jun 2011 09:45:59 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 260E321F849A for ; Fri, 10 Jun 2011 09:45:57 -0700 (PDT)
Received: by vws12 with SMTP id 12so3258613vws.31 for ; Fri, 10 Jun 2011 09:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=16jKl+HVKtgxKziH0bCUlkjXxzXnRCEMMGc0urvs6rM=; b=cw5YuQOULw41dMVbmZ/NuXwa3vOcj04vCV7i2WSnabRfZDmriqECpAIBG07Fkj1JYh zxV4k37wdXgQCh2EaBfG5HZiTVaUqU0ljR1/nDgDtNYUrVOMR8/EhNye2iU2qOMRuKtx E0IIvPUlD7kfqC2vDPXHrFAOYCI8fcfi81PL4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T4r16iJQe+mcQu1u8tPUjhkfmyxa5UDegd+WLp/nJZKHLVS1Ue5cS0G5UdKl2ZaTxU XIUUCUu3icRxosRIdAgvGTxEBodJFTS1SejujCxbEm0RVDs7uXjFf5FheHaXlDrBMslS YqqlNhtEc2gxBYodka72h6oJXCIDGtrmC3uD4=
MIME-Version: 1.0
Received: by 10.52.115.10 with SMTP id jk10mr3241884vdb.294.1307724355027; Fri, 10 Jun 2011 09:45:55 -0700 (PDT)
Received: by 10.52.157.5 with HTTP; Fri, 10 Jun 2011 09:45:54 -0700 (PDT)
In-Reply-To: <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   <4DF206E7.3040401@aol.com> <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com> <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>
Date: Fri, 10 Jun 2011 09:45:54 -0700
Message-ID: 
From: David Recordon 
To: John Kemp 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 16:46:00 -0000

I think it's vital to have the GET and POST parameters make sense to
every developer. I worry less about the authorization header since a
developer implementing it will honestly be a stronger engineer.

Here's what I said earlier in the thread about my motivation:
> Did a full read through of draft 16 and the bear token spec with Paul
> yesterday afternoon in order to do a manual diff from draft 10. The
> point Doug raised was actually confusing. Throughout the core spec
> it's referred to as access_token but then becomes bearer_token upon
> use.
>
> Just thinking through this from a developer documentation perspective,
> it's going to become confusing. Developer documentation focuses on
> getting an access token and then using that access token to interact
> with an API. Thus the code you're writing as a client developer will
> use variables, cache keys, and database columns named `access_token`.
> But then when you're going to use it, you'll need to put this access
> token into a field named bearer_token.
>
> Feels quite a bit simpler to just name it access_token. Realize the
> core spec never did this since we didn't want to trample on protected
> resources which might already have a different type of access_token
> parameter. oauth_token was a good compromise since developers would
> already know that they were using OAuth and thus a new term wasn't
> being introduced. That's no longer true with bearer_token since 99% of
> developers will have never heard of a bearer token.
>
> Googling for "bearer token" turns up Eran's blog post titled "OAuth
> Bearer Tokens are a Terrible Idea" and there isn't a single result on
> the first page which explains what they are. Binging for "bearer
> token" is equally scary.

--David


On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
> George,
>
> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>
>> I definitely don't want to change the Authorization header naming scheme=
. I believe it should stay 'Bearer' because that's what the token is. We co=
uld make it...
>>
>> Authorization: Bearer access_token=3DvF9dft4qmT
>>
>> If that helps with consistency.
>
> Well, it might seem more consistent, but I'm not sure it's worthwhile to =
make the change just for that reason.
>
> Is it possible that the Bearer HTTP mechanism would ever take multiple pa=
rameters? In which case, having the ability to name the parameters of the B=
earer mechanism might become more interesting.
>
> - John
>
>> I don't think we should be associating the term 'access_token' with the =
bearer security mechanism.
>>
>> Thanks,
>> George
>>
>> On 6/10/11 8:35 AM, John Kemp wrote:
>>> What does this mean for the HTTP Authorization header naming scheme for=
 bearer tokens?
>>>
>>> As I understand this decision, we are discussing whether to standardize=
 on the name "access_token" when a bearer token is sent as either a URL que=
ry parameter, or in a form POSTed body?
>>>
>>> Currently the HTTP Authorization header looks like this (from
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>> ):
>>>
>>> GET /resource HTTP/1.1
>>> Host: server.example.com
>>> Authorization: Bearer vF9dft4qmT
>>>
>>> Is the proposal then that we have:
>>>
>>> 1. GET /resource?access_token=3DvF9dft4qmT
>>> 2. POST /resource
>>>
>>> access_token=3DvF9dft4qmT&...
>>>
>>> 3.
>>>
>>> GET /resource HTTP/1.1
>>> Host: server.example.com
>>> Authorization: access_token vF9dft4qmT
>>>
>>> Can someone actually give the details of the proposal, or agree/disagre=
e with the examples above?
>>>
>>> - John
>>>
>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>
>>>
>>>> Yes, that's fine with me.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>
>>>>> George, Doug and Eran are you alright with the Bearer token spec usin=
g
>>>>> the parameter name "access_token" as well?
>>>>>
>>>>>
>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>
>>>>> 
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones 
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> If you can drive a consensus decision for the name "access_token", =
I'd be glad to change the name in the spec. =A0I agree that the current nam=
es are confusing for developers.
>>>>>>>
>>>>>>>
>>>>>> At Google we are getting the same feedback, that it is confusing for
>>>>>> developers. It would definitely help if we could change the name to
>>>>>> "access_token".
>>>>>>
>>>>>> Marius
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>

From nico@cryptonector.com  Fri Jun 10 10:36:43 2011
Return-Path: 
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 E150C11E80B1; Fri, 10 Jun 2011 10:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.087
X-Spam-Level: 
X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 208vBsYuTKkI; Fri, 10 Jun 2011 10:36:43 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7011E81A6; Fri, 10 Jun 2011 10:36:43 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 544CF21DE82; Fri, 10 Jun 2011 10:36:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GYpPq5RJTqWHu2GhBAPXD8lw0ad1N/eR4W4C1BTSocB5 Ysng1dmlX0nEhkZpuqwgkjZo4Tuq13d2eHcmPoKMsZAIrNjD0MkkbNtnzNeJgFbc 1A1qmyCIkjUnq80Ozl/gsJP65DxGdth0HfEGDBbVrPolRUtulRELuq8rqoSK0cc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ogMqrLJYBNMpf2sdZYydrvyFAcs=; b=M+vUWCC5Wui orFhCufVJ+e0WjyPSIDns2IdhjdKlCID9mgeyHHSCkCzCcQeA5WrTZxIA/XMliOp L04Z01RcRqr5B27E3mTJaSWdFbgwYhk6YFlXt4wx9wO+/QeASMkjMRod/edyqpXM 4RPjqIjHaGkKIhnLJ6RindfVfA/t33vo=
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id D25C121DE8E;  Fri, 10 Jun 2011 10:36:30 -0700 (PDT)
Received: by pzk5 with SMTP id 5so1476613pzk.31 for ; Fri, 10 Jun 2011 10:36:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.0.7 with SMTP id 7mr1214506pba.188.1307727390261; Fri, 10 Jun 2011 10:36:30 -0700 (PDT)
Received: by 10.68.50.39 with HTTP; Fri, 10 Jun 2011 10:36:30 -0700 (PDT)
In-Reply-To: <02c401cc2662$9a21d220$ce657660$@packetizer.com>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com>  <02c401cc2662$9a21d220$ce657660$@packetizer.com>
Date: Fri, 10 Jun 2011 12:36:30 -0500
Message-ID: 
From: Nico Williams 
To: "Paul E. Jones" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Ben Adida , Adam Barth , OAuth WG , apps-discuss@ietf.org
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 17:36:44 -0000

[Dropped a few lists.]

On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones  wrot=
e:
> What issues, specifically.=C2=A0 (Messages are all over the place and I d=
on=E2=80=99t
> know exactly what issues you=E2=80=99re raising.=C2=A0 Is it with the app=
roach we=E2=80=99re
> proposing or something else?)

The fundamental issue is that protecting the cookie alone is not
enough.  On open wifi networks it's a fair assumption that the
difficulty of active attacks is about the same as the difficulty of
passive attacks.  Therefore you need to provide integrity protection
for most of the request and most of the response, including the
bodies.

Nico
--

From mscurtescu@google.com  Fri Jun 10 10:39:00 2011
Return-Path: 
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 13CD711E81C0 for ; Fri, 10 Jun 2011 10:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPdzXCR72DQx for ; Fri, 10 Jun 2011 10:38:59 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F391711E81B0 for ; Fri, 10 Jun 2011 10:38:58 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p5AHcvbK012231 for ; Fri, 10 Jun 2011 10:38:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307727538; bh=YUvEkW5AG27hgj2f8WA50gwmHzo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MEjqquEV2DSm0CHGB+NHrhOB3juo2Scic0dT61H4fXB+0Um7qfWH7odgu0kvrjb4g 8sXrET78QdKhAE3rpAAzA==
Received: from yxn35 (yxn35.prod.google.com [10.190.4.99]) by hpaq5.eem.corp.google.com with ESMTP id p5AHc59Y007343 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Jun 2011 10:38:56 -0700
Received: by yxn35 with SMTP id 35so797154yxn.28 for ; Fri, 10 Jun 2011 10:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w+oLu3NxpLFl53UoWbLF+TgHYDN2Tbrt5Ms7cEOhKTA=; b=qly2HlrJMK+XJJkXyYIe3SSdI83KMHAmyioyMWrz9zqGHwmbKUN1WYs6St9KnGVD6Y OqIzpwP8ZaQh3KOVscSw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QYPP+ma/QBn/5UejJnyz8aq4rGjv4yXMzfTbITkJjwhzCifyiFoROiSyeeX2U/X8j+ dhzRyqUEcJGrbsVxTmqA==
Received: by 10.101.147.20 with SMTP id z20mr2172229ann.79.1307727535892; Fri, 10 Jun 2011 10:38:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.14.19 with HTTP; Fri, 10 Jun 2011 10:38:35 -0700 (PDT)
In-Reply-To: <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   <4DF206E7.3040401@aol.com> <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com> <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>
From: Marius Scurtescu 
Date: Fri, 10 Jun 2011 10:38:35 -0700
Message-ID: 
To: John Kemp 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 17:39:00 -0000

On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
> George,
>
> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>
>> I definitely don't want to change the Authorization header naming scheme. I believe it should stay 'Bearer' because that's what the token is. We could make it...
>>
>> Authorization: Bearer access_token=vF9dft4qmT
>>
>> If that helps with consistency.
>
> Well, it might seem more consistent, but I'm not sure it's worthwhile to make the change just for that reason.
>
> Is it possible that the Bearer HTTP mechanism would ever take multiple parameters? In which case, having the ability to name the parameters of the Bearer mechanism might become more interesting.

Hard to say, but using a proper name/value pair has several advantages:
- permits extensibility
- no need to limit or define character set of access tokens (name is
either "token" or "quoted string")
- HTTP header parsers can properly deal with name/value pairs

If we make changes to the GET/POST parameter name then I think we
should also consider the header as well.

Marius

From sayrer@gmail.com  Fri Jun 10 10:42:06 2011
Return-Path: 
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 1938311E80C3 for ; Fri, 10 Jun 2011 10:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyEb8oSPK5tx for ; Fri, 10 Jun 2011 10:42:05 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6711E80B7 for ; Fri, 10 Jun 2011 10:42:05 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3286881vxg.31 for ; Fri, 10 Jun 2011 10:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wqIPdL5Wolyg8z+YtxJLrXi2oRqNZWuFxxqs5J3OmzM=; b=OqiYmbsdNYsMEXLNTO6Uf2CnmvHdN8iLGLGyKZYZuY3osIRNurUvkj8wgiutmNJDZb ASZd4M+mLO9Jvb22BsSBW7dGQT2iEYV5imo1aI6Gh6tTDVVFs/YO1R/pvosNYKzgGHS9 tJcnIpWxuCB8CnZGL1PP2mDe1tcZqGgaZuKU0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MykiODMmy6oaPka4Dlh4gGqWTGW3WAila8/BbPbjMb32OQqTM6A43SSree5iLKy/ZP rEezjxgjiIcg/WhDrh8v96sFk2FlOq292DouTzWCIiF3K7FHgw5lhdO8w/J8B9ghLm8B B81iUOWUqFlhuwAg22Rh+dTWdSBinykgFex30=
MIME-Version: 1.0
Received: by 10.52.177.70 with SMTP id co6mr3208630vdc.92.1307727724615; Fri, 10 Jun 2011 10:42:04 -0700 (PDT)
Received: by 10.52.111.169 with HTTP; Fri, 10 Jun 2011 10:42:04 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 10 Jun 2011 10:42:04 -0700
Message-ID: 
From: Robert Sayre 
To: Adam Barth 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 17:42:06 -0000

On Thu, Jun 9, 2011 at 10:25 PM, Adam Barth  wrote:
>
> What happens when the client wants to send more than one request at a
> time to the server? =A0For example, when loading a web page, browsers
> often open multiple sockets to send multiple request in parallel to
> improve performance.

In my example, I changed it with each request just to show how it
might work if the server changed it with every request. FWIW, section
3.2.3 of RFC2617 covers exactly this tradeoff.

>
> The normal flow in the browser setting does not use 401 and is as follows=
:

OK, but there's still an initial challenge that fulfills the same
role. I wasn't clear on the coordination present between the first and
second requests below. Now I am.

>
> Client ----> Server (HTTPS)
> GET /login
>
> Server ----> Client (HTTPS)
> 200 OK
> Set-Cookie: SID=3D3048jhseofhoesdfdf; MAC-Key=3DOIneoiunf;
> MAC-Algorithm=3Dhmac-sha-1; Path=3D/
>
> Client ----> Server (HTTPS)
> POST /login
> Authorization: MAC id=3D"SID", nonce=3D"2:ion308r32"; mac=3D"ow8fnwnougvi=
ew4t0=3D"
> username=3Dsayrer&password=3Dtacotacotaco
>
> The session is now established. =A0Commonly, we'd expect the session to
> contain a mix of HTTP and HTTPS requests. =A0Each request comes with a
> new nonce and a mac, etc.
>

Perhaps some confusion has been caused by my use of the word "nonce".
I have been using it as Digest does, where the server nonce is only
sent with an authentication challenge, and then reused by the client
until the server decides it is stale. So, the client can use the same
server nonce many times. In the flow above, a server nonce would be
sent in the first response, and then reused by the client.

A client nonce is still worth including (just a random string), but I
still think giving the server a way to determine the age of the
credentials without relying on the client would be more reliable.
Let's call my proposed addition the "opaque" parameter. The client
sends it back unchanged, just like the id. In the example below, the

Client ----> Server (HTTPS)
GET /login

Server ----> Client (HTTPS)
200 OK
Set-Cookie: SID=3D3048jhseofhoesdfdf; MAC-Key=3DOIneoiunf;
MAC-Algorithm=3Dhmac-sha-1; Path=3D/;
Opaque=3D'MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=3D=3D'

Client ----> Server (HTTPS)
POST /login
Authorization: MAC id=3D"SID", nonce=3D"2:ion308r32"; mac=3D"ow8fnwnougview=
4t0=3D";
Opaque=3D'MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=3D=3D'
username=3Dsayrer&password=3Dtacotacotaco

Below, I included a little python session showing a simple example of
how this might work. It allows the server to check the age of the
credentials, check that it generated the age that was given, and
/then/ hit the authentication database.

This is just one use of an opaque field that servers might want to
try. I suppose this data could get stuffed into the SID too. Is that
the idea?

- Rob



>>> import hashlib
>>> import base64
>>> import time
>>> private_key =3D "foobar"
>>> timestamp =3D str(int(time.time()))
>>> timestamp
'1307726112'
>>> m =3D hashlib.sha1()
>>> m.update(timestamp + private_key)
>>> base64.b64encode(timestamp + ":" + m.digest())
'MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=3D=3D'
>>> # our outgoing opaque value	^^
...

>>> # incoming request
...
>>> incoming_opaque =3D base64.b64decode('MTMwNzcyNjExMjofeosXZh7sTFT1mBGkK=
Aw6AoOOQQ=3D=3D')
>>> incoming_opaque
'1307726112:\x1fz\x8b\x17f\x1e\xecLT\xf5\x98\x11\xa4(\x0c:\x02\x83\x8eA'
>>> timestamp =3D int(incoming_opaque[:incoming_opaque.find(':')])
>>> timestamp
1307726112
>>> # now check the hash
...
>>> incoming_hash =3D incoming_opaque[incoming_opaque.find(':') + 1:]
>>> m =3D hashlib.sha1()
>>> m.update(str(timestamp) + private_key)
>>> m.digest() =3D=3D incoming_hash
True
>>> # now look at the MAC
...

From ietf@adambarth.com  Fri Jun 10 10:51:45 2011
Return-Path: 
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 42C6F11E81DA for ; Fri, 10 Jun 2011 10:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.144
X-Spam-Level: 
X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noq6KyK2FXLv for ; Fri, 10 Jun 2011 10:51:44 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4711E8138 for ; Fri, 10 Jun 2011 10:51:44 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1439363ywp.31 for ; Fri, 10 Jun 2011 10:51:44 -0700 (PDT)
Received: by 10.151.24.10 with SMTP id b10mr3425676ybj.93.1307728304184; Fri, 10 Jun 2011 10:51:44 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id p23sm1706457ybc.14.2011.06.10.10.51.42 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 10:51:42 -0700 (PDT)
Received: by yxs7 with SMTP id 7so298775yxs.31 for ; Fri, 10 Jun 2011 10:51:42 -0700 (PDT)
Received: by 10.91.207.11 with SMTP id j11mr3443417agq.17.1307728302303; Fri, 10 Jun 2011 10:51:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Fri, 10 Jun 2011 10:51:12 -0700 (PDT)
In-Reply-To: 
References:    
From: Adam Barth 
Date: Fri, 10 Jun 2011 10:51:12 -0700
Message-ID: 
To: Robert Sayre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 17:51:45 -0000

On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre  wrote:
> Let's call my proposed addition the "opaque" parameter. The client
> sends it back unchanged, just like the id.

That already exists in the scheme.  It's just the value of the cookie.

> This is just one use of an opaque field that servers might want to
> try. I suppose this data could get stuffed into the SID too. Is that
> the idea?

Yep.

In talking with folks who run large web sites, they already have a
session identifier cookie that contains most of the information you'd
want to encode in this opaque value.  For example, most sites include
an "issue date" in their session identifiers so they can discard old
values.

One possibility is to include the value of the Cookie header in the
MAC.  Then sites could use Set-Cookie to change a server-side nonce,
if they wanted.  So far there's hasn't been much demand for that
feature from server operators I've talked with.

Adam

From sayrer@gmail.com  Fri Jun 10 11:36:41 2011
Return-Path: 
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 EA55411E8175 for ; Fri, 10 Jun 2011 11:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5feDzZztozL3 for ; Fri, 10 Jun 2011 11:36:41 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2FA411E8075 for ; Fri, 10 Jun 2011 11:36:40 -0700 (PDT)
Received: by vws12 with SMTP id 12so3366290vws.31 for ; Fri, 10 Jun 2011 11:36:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pxvf4sX/9rziPUWAkd9IB+X8ePc64D0Smti88NAiCi4=; b=uhO1h0vqJNiGW75wqtqI5WPxvKjIjxuiEaRQlx0oc3+LE5MFgxNcJykGW1clr/NE5j 6PbBzrSVZShFITKEYKttRywU5J1ZXC0hsW+nmbd/F8IEXQngGC+G6bfkRkO5jzuVYYpL PpHGRaHzI2Qo6uGTCLkSpmRPMv8JA1JV59Lck=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BZDmvkhtFzVtc5sRniMF3Yzd4c4z+3NDmJYzSa1lN6Z9r6y0TjoWpqBp46aK6nSWgw FFrIXDPuhCWdnBMgGo7+zXR+lL0DXmdzTpTq/tCKJe/6EvhllvDjKp5AeGTimEzEfaCC 12NrvgNnULUYY8RupbpVOF6ZvS9khzh5m2U9k=
MIME-Version: 1.0
Received: by 10.52.177.70 with SMTP id co6mr3285258vdc.92.1307730999455; Fri, 10 Jun 2011 11:36:39 -0700 (PDT)
Received: by 10.52.111.169 with HTTP; Fri, 10 Jun 2011 11:36:39 -0700 (PDT)
In-Reply-To: 
References:     
Date: Fri, 10 Jun 2011 11:36:39 -0700
Message-ID: 
From: Robert Sayre 
To: Adam Barth 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 18:36:42 -0000

On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth  wrote:
> On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre  wrote:
>> Let's call my proposed addition the "opaque" parameter. The client
>> sends it back unchanged, just like the id.
>
> That already exists in the scheme. =A0It's just the value of the cookie.
>
>> This is just one use of an opaque field that servers might want to
>> try. I suppose this data could get stuffed into the SID too. Is that
>> the idea?
>
> Yep.

OK, this is all much clearer. Could the draft include these
explanations and examples? It seems like the draft is obfuscated right
now. Why not just plainly state something similar to

"This mechanism really just adds a little more security to session cookies.=
"

in the introduction? I hope it isn't because of HTTP religion or
something like that.

- Rob

From ietf@adambarth.com  Fri Jun 10 12:05:30 2011
Return-Path: 
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 F2FE011E820B for ; Fri, 10 Jun 2011 12:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhztjROMeEad for ; Fri, 10 Jun 2011 12:05:29 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBC511E81AA for ; Fri, 10 Jun 2011 12:05:08 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1481362ywp.31 for ; Fri, 10 Jun 2011 12:05:07 -0700 (PDT)
Received: by 10.150.113.20 with SMTP id l20mr3457080ybc.36.1307732707603; Fri, 10 Jun 2011 12:05:07 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id v35sm11731yba.4.2011.06.10.12.05.06 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 12:05:06 -0700 (PDT)
Received: by yxs7 with SMTP id 7so340454yxs.31 for ; Fri, 10 Jun 2011 12:05:06 -0700 (PDT)
Received: by 10.91.198.17 with SMTP id a17mr3592495agq.44.1307732706087; Fri, 10 Jun 2011 12:05:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Fri, 10 Jun 2011 12:04:36 -0700 (PDT)
In-Reply-To: 
References:      
From: Adam Barth 
Date: Fri, 10 Jun 2011 12:04:36 -0700
Message-ID: 
To: Robert Sayre 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 19:05:30 -0000

On Fri, Jun 10, 2011 at 11:36 AM, Robert Sayre  wrote:
> On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth  wrote:
>> On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre  wrote:
>>> Let's call my proposed addition the "opaque" parameter. The client
>>> sends it back unchanged, just like the id.
>>
>> That already exists in the scheme. =A0It's just the value of the cookie.
>>
>>> This is just one use of an opaque field that servers might want to
>>> try. I suppose this data could get stuffed into the SID too. Is that
>>> the idea?
>>
>> Yep.
>
> OK, this is all much clearer. Could the draft include these
> explanations and examples? It seems like the draft is obfuscated right
> now. Why not just plainly state something similar to
>
> "This mechanism really just adds a little more security to session cookie=
s."
>
> in the introduction? I hope it isn't because of HTTP religion or
> something like that.

Sounds like a good idea.

Adam

From jbradley@mac.com  Fri Jun 10 12:08:52 2011
Return-Path: 
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 095F811E81AA for ; Fri, 10 Jun 2011 12:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17L44OPbWRtc for ; Fri, 10 Jun 2011 12:08:51 -0700 (PDT)
Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2C111E8122 for ; Fri, 10 Jun 2011 12:08:51 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from [192.168.1.4] ([190.22.44.195]) by asmtp021.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LML00J2995ZBI90@asmtp021.mac.com> for oauth@ietf.org; Fri, 10 Jun 2011 12:08:28 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-06-10_07:2011-06-10, 2011-06-10, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1106100159
From: John Bradley 
Content-transfer-encoding: quoted-printable
Date: Fri, 10 Jun 2011 15:08:23 -0400
Message-id: 
To: Shane B Weeden 
X-Mailer: Apple Mail (2.1084)
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 19:08:52 -0000

Shane,

We have been working on openID Connect (formerly known as openID AB) for =
some time.

If there are standard ways to do things in OAuth 2.0 that we can reuse =
then it saves us from inventing custom extensions for openID Connect.

We have identified the need to request multiple tokens as one issue that =
we would have to extend.

Certainly FaceBook is doing that now.

We have been working on a standard token/assertion format (JWT) that can =
be signed and encrypted.  That will be submitted as a separate spec.

Facebook has their own signature that they have been using for a while.  =
I don't know that we are going to get 100% convergence on token formats =
overnight.

=46rom PAPE it turns out that one of the things people found most useful =
was the max-auth-age request to force interactive authentications.  =20

For SSO use we also need to be able to request a PAPE policy/ =
AuthnContext.  That may however be specific to Connect and less useful =
in general OAuth.

We want to invent as little as possible outside of OAuth as possible.  =
However we are mindful of OAuth deadlines so the Connect working group =
has been trying to track the spec as much as possible without requesting =
changes.

I understand Paul's request for those features, and they would make life =
easier for those of us working on SSO. =20

The details probably need more discussion, on types of tokens names etc.

Regards
John Bradley

	=20
> 	=95 From: Shane B Weeden 
> 	=95 To: Paul Tarjan 
> 	=95 Cc: "oauth at ietf.org" 
> 	=95 Date: Tue, 7 Jun 2011 13:16:03 +1000
> 	=95 In-reply-to: 
> 	=95 References: 
> Just an observation - some of this function seems to have direct =
parallels
> in OpenID.
> E.g.
> display=3Dnone sounds very much like checkid_immediate
> prompt=3Dxxx seems like a direct correlation to the PAPE extension
>=20
>=20
> Could things like signed_request and nonce be considered part of a =
custom
> token format in a separate token spec rather than part of the core -
> provided the client can be token-type-aware?
>=20
>=20
>=20
>=20
> From:	Paul Tarjan 
> To:	"oauth at ietf.org" 
> Date:	07-06-11 11:57 AM
> Subject:	[OAUTH-WG] Proposed OAuth Extensions
> Sent by:	oauth-bounces at ietf.org
>=20
>=20
>=20
> Hi fellow OAuthers,
>=20
> As we discussed at the meeting there are a few extensions that we'd =
like
> to implement. To do this, we'd like the response_type to be =
extensible. We
> are proposing two new values. "none" and "signed_request token" (and
> "token signed_request" for symmetry). Or if you want to turn =
response_type
> into a space separated list, that would work too.
>=20
> I'm also including our other extension parameters so you can see what =
we
> are planning incase others need similar functionality.
>=20
>=20
> ---
> response_type=3Dnone
>=20
> If this is specified then no code nor token is passed to the =
redirect_uri.
> This is very useful when the authentication will be done via other =
means
> (like the display=3Dnone parameter, or Facebook's canvas iframe).
>=20
> Example:
>=20
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=3D150629244948164&
>   redirect_uri=3D
> http://apps.facebook.com/ptarjan/&
> ;
>   response_type=3Dnone
>=20
> (shows user the permission dialog then redirects to)
>=20
>=20
> http://apps.facebook.com/ptarjan/
>=20
>=20
> (or if they click cancel)
>=20
>=20
> http://apps.facebook.com/ptarjan/
> ?
>   error=3Daccess_denied&
>   error_description=3D...&
>   state=3D...
>=20
>=20
> ---
> response_type=3Dsigned_request
>=20
> This response type is used to tie the Javascript SDK to a server-side =
SDK.
> It is used in conjunction with response_type=3Dtoken and display=3Dnone.=
 It
> sends a "signed_request" along with the response, which is a signed =
blob
> that we expect the JS library to dump into a cookie for the server SDK =
to
> read and validate. The JS SDK will also look inside of it (without
> verifying the signature) to see the user's ID. That is safe because =
the JS
> SDK uses state and only handles responses it's expecting.
>=20
> The signed_request will contain:
>=20
>   user_id   (provider specific id string)
>   issued_at (UNIXTIME)
>   code      (optional. OAuth code issued with redirect_uri set to ""
>              since the server won't know which URL it was issued on)
>   client_id (optional. Needed by Google for 4th party auth)
>   audience  (optional. Google's public key crypto)
>   ...       (other provider specific data)
>=20
> Example:
>=20
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=3D150629244948164&
>   redirect_uri=3D
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#&
> ;
>   display=3Dnone&
>   response_type=3Dtoken signed_request
>=20
> 302s to
>=20
>=20
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#
>=20
>   access_token=3D...&
>   expires_in=3D...&
>   signed_request=3Dabcd...
>=20
> And the JS SDK then does
>=20
> setcookie("fbc_"+client_id, signed_request)
>=20
>=20
> ---
> display=3Dnone
>=20
> This means the user never will see a dialog and is meant to be opened =
in
> an iframe by javascript to asynchronously get an access_token or =
discover
> the user's state.
>=20
> Example:
>=20
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=3D150629244948164&
>   redirect_uri=3D
> https://example.com/&
> ;
>   display=3Dnone&
>   response_type=3Dtoken
>=20
> If the user is not logged into Facebook, this endpoint 302s to
>=20
>=20
> https://example.com/#
>=20
>   error=3Dunknown_user
>=20
> If the user is logged in but hasn't authorized this app, it 302s to
>=20
>=20
> https://example.com/#
>=20
>   error=3Dnot_authorized
>=20
>=20
> If the user has authorized the app then it 302s to the normal OAuth =
output
>=20
>=20
> https://example.com/#
>=20
>   access_token=3D...&
>   expires_in=3D...
>=20
>=20
> ---
> prompt=3D
>=20
> A parameter that changes some things with the OAuth prompt. These can =
be
> specified as a space/comma separated string.
>=20
> prompt=3Dlogin
>=20
> This forces the user to enter their password again.
>=20
> prompt=3Dconsent
>=20
> This always shows the "Do you allow this app" dialog, even if they
> consented before. Google will only issue long lived tokens when the =
user
> clicks something.
>=20
> prompt=3Dsecure
>=20
> The user must be verified by secure (https) cookies. This protects the =
app
> from firesheep attacks.
>=20
> prompt=3Dselect_account
>=20
> The user will be shown a dialog to select amongst their connected =
accounts
> (Google wants this for multiple connected accounts).
>=20
>=20
> ---
> nonce=3D
>=20
> If this parameter is specified, the nonce is encoded in the =
access_token,
> which is then accessible via a "Token Info Endpoint". This is paired =
with
> prompt=3Dlogin to guarantee the user put in their password before they =
buy
> something expensive with their paypal account.
>=20
> It is limited to a 20 character opaque string, but we recommend =
base64url
> encoding a set of random bits.
>=20
> Example:
>=20
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=3D150629244948164&
>   redirect_uri=3D...
>   nonce=3Dsome_string
>   response_type=3Dcode
>=20
> Does exactly the same OAuth flow, except when they hit
>=20
> https//graph.facebook.com/access_token?access_token=3D...
>=20
> They get back json with a key "nonce" being the nonce encoded inside =
the
> Token.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
>=20
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
>=20

From ietf@adambarth.com  Fri Jun 10 12:17:10 2011
Return-Path: 
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 A331011E812B for ; Fri, 10 Jun 2011 12:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.852
X-Spam-Level: 
X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k15vKN2vzCx for ; Fri, 10 Jun 2011 12:17:10 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D81C811E80AD for ; Fri, 10 Jun 2011 12:17:09 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2670894gxk.31 for ; Fri, 10 Jun 2011 12:16:53 -0700 (PDT)
Received: by 10.101.207.30 with SMTP id j30mr2228819anq.86.1307733413502; Fri, 10 Jun 2011 12:16:53 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id b25sm2818304anb.20.2011.06.10.12.16.51 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 12:16:51 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1488014ywp.31 for ; Fri, 10 Jun 2011 12:16:51 -0700 (PDT)
Received: by 10.90.248.5 with SMTP id v5mr3484495agh.98.1307733411135; Fri, 10 Jun 2011 12:16:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Fri, 10 Jun 2011 12:16:21 -0700 (PDT)
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com>  <02c401cc2662$9a21d220$ce657660$@packetizer.com> 
From: Adam Barth 
Date: Fri, 10 Jun 2011 12:16:21 -0700
Message-ID: 
To: Nico Williams 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Ben Adida , OAuth WG 
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 19:17:10 -0000

On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams  wro=
te:
> [Dropped a few lists.]
>
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones  wr=
ote:
>> What issues, specifically.=A0 (Messages are all over the place and I don=
=92t
>> know exactly what issues you=92re raising.=A0 Is it with the approach we=
=92re
>> proposing or something else?)
>
> The fundamental issue is that protecting the cookie alone is not
> enough. =A0On open wifi networks it's a fair assumption that the
> difficulty of active attacks is about the same as the difficulty of
> passive attacks. =A0Therefore you need to provide integrity protection
> for most of the request and most of the response, including the
> bodies.

You can repeat that statement as many times as you want, but that
doesn't make it true.

Adam

From nico@cryptonector.com  Fri Jun 10 12:27:53 2011
Return-Path: 
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 CB5DE11E8094 for ; Fri, 10 Jun 2011 12:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.066
X-Spam-Level: 
X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPhKP6apxpE0 for ; Fri, 10 Jun 2011 12:27:53 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7609D11E8083 for ; Fri, 10 Jun 2011 12:27:53 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 136A6B806B for ; Fri, 10 Jun 2011 12:27:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=vtKm5YQDykQvh/3DsIx9PiWXp8IWqx4k9pX+fhnluTxg XFWMoNSyCp+0mmZ8dUt2toJcBWFgEd8XDpM+8B9EHSRjxJH9/MjWClNW3e/d9Zkm iLWKHWnnfJTNNnfrZbhrOuXmf7ZHG8texYumrGP61LnhhGOsxE/LJpg0mMebobE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=98otF+Y4hSJC8I/hb23ykyQaVWw=; b=OmJUrknkOgc 0OD8OiSGU/Ka+eEmPOgYLw1F0H7/2wzRwXPRFpBNxV/DUP+kvznQg30U+V/dC6o1 6Kqx3bVvoGNG7Dw0lJrwVbJNy0i9rUp0q9lZd9kFI6YOJcleGBnAp5OcegI3UA/W cDo3/rwhQqccj5Ajo28DzLIPEkSHHPKc=
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id C5229B805C for ; Fri, 10 Jun 2011 12:27:52 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2198605pxi.27 for ; Fri, 10 Jun 2011 12:27:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.0.7 with SMTP id 7mr1282943pba.188.1307734072362; Fri, 10 Jun 2011 12:27:52 -0700 (PDT)
Received: by 10.68.50.39 with HTTP; Fri, 10 Jun 2011 12:27:52 -0700 (PDT)
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com>  <02c401cc2662$9a21d220$ce657660$@packetizer.com>  
Date: Fri, 10 Jun 2011 14:27:52 -0500
Message-ID: 
From: Nico Williams 
To: Adam Barth 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Ben Adida , OAuth WG 
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 19:27:53 -0000

On Fri, Jun 10, 2011 at 2:16 PM, Adam Barth  wrote:
> On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams  w=
rote:
>> The fundamental issue is that protecting the cookie alone is not
>> enough. =C2=A0On open wifi networks it's a fair assumption that the
>> difficulty of active attacks is about the same as the difficulty of
>> passive attacks. =C2=A0Therefore you need to provide integrity protectio=
n
>> for most of the request and most of the response, including the
>> bodies.
>
> You can repeat that statement as many times as you want, but that
> doesn't make it true.

No, I'm done repeating it.  Those who disagree can also continue to
ignore it.  If it needs trial by fire, so be it.

From paulej@packetizer.com  Fri Jun 10 13:04:03 2011
Return-Path: 
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 4A6D511E80FB; Fri, 10 Jun 2011 13:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.417
X-Spam-Level: 
X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAy2cIYevvjP; Fri, 10 Jun 2011 13:04:02 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 13DED11E8097; Fri, 10 Jun 2011 13:03:49 -0700 (PDT)
Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p5AK3VJs002670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2011 16:03:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307736217; bh=65DhJkxJweupl9J5VTi9bGIOu1I5puC8lk5CxwhLUo8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TiuOXknIBjKKfYuabwcRFFZ02Xa5AxBB9qKAa/eXRofYC/A5dsoESJIQiJ4+DVdZY 1l0NYQo/LpN7v2d4pQjpZFZ21WcFB2eK11wI9YqBrILJxd5Gqc/jeJRUWrhJnGy307 HZo4jNmOb/zhbqShegKSyhimv9hsqDx7oVNfGAis=
From: "Paul E. Jones" 
To: "'Nico Williams'" 
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<09c801cc24c2$a05bae00$e1130a00$@packetizer.com>		<00f101cc255e$2d426020$87c72060$@packetizer.com>		<015801cc25ab$063a2150$12ae63f0$@packetizer.com>		<02c401cc2662$9a21d220$ce657660$@packetizer.com> 
In-Reply-To: 
Date: Fri, 10 Jun 2011 16:03:20 -0400
Message-ID: <051201cc27a9$7603f970$620bec50$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QI7UtjxArFQ00YB68uctpTKGnTw
Content-Language: en-us
Cc: 'Ben Adida' , 'Adam Barth' , 'OAuth WG' , apps-discuss@ietf.org
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 20:04:03 -0000

Nico,

> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones 
> wrote:
> > What issues, specifically.  (Messages are all over the place and I
> > don=E2=80=99t know exactly what issues you=E2=80=99re raising.  Is =
it with the
> > approach we=E2=80=99re proposing or something else?)
>=20
> The fundamental issue is that protecting the cookie alone is not =
enough.
> On open wifi networks it's a fair assumption that the difficulty of
> active attacks is about the same as the difficulty of passive attacks.
> Therefore you need to provide integrity protection for most of the
> request and most of the response, including the bodies.

While I will not claim that our current draft is bullet proof, we did =
make an attempt to define a means of allowing the client and server to =
be able to detect if a request has been altered, including both message =
headers and message body.

Draft:
http://tools.ietf.org/html//draft-salgueiro-secure-state-management-04

Paul




From eran@hueniverse.com  Fri Jun 10 15:17:59 2011
Return-Path: 
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 AD5FB21F84AD for ; Fri, 10 Jun 2011 15:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level: 
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpXaeFHFRvff for ; Fri, 10 Jun 2011 15:17:59 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DC6AC21F845F for ; Fri, 10 Jun 2011 15:17:58 -0700 (PDT)
Received: (qmail 21710 invoked from network); 10 Jun 2011 22:17:57 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2011 22:17:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 10 Jun 2011 15:17:54 -0700
From: Eran Hammer-Lahav 
To: Marius Scurtescu , John Kemp 
Date: Fri, 10 Jun 2011 15:17:42 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: Acwnld4eTm2ersK3Tw+jUr/11sZllAAJjx2A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E7742CA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   <4DF206E7.3040401@aol.com>	<90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com>	<133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 22:17:59 -0000

Extensibility in authentication schemes is a bad thing, given how they are =
deployed and the difficulty of changing them. No existing authentication sc=
heme is extensible (explicitly).

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Friday, June 10, 2011 10:39 AM
> To: John Kemp
> Cc: paul Tarjan; OAuth WG
> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
> > George,
> >
> > On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
> >
> >> I definitely don't want to change the Authorization header naming
> scheme. I believe it should stay 'Bearer' because that's what the token i=
s. We
> could make it...
> >>
> >> Authorization: Bearer access_token=3DvF9dft4qmT
> >>
> >> If that helps with consistency.
> >
> > Well, it might seem more consistent, but I'm not sure it's worthwhile t=
o
> make the change just for that reason.
> >
> > Is it possible that the Bearer HTTP mechanism would ever take multiple
> parameters? In which case, having the ability to name the parameters of t=
he
> Bearer mechanism might become more interesting.
>=20
> Hard to say, but using a proper name/value pair has several advantages:
> - permits extensibility
> - no need to limit or define character set of access tokens (name is eith=
er
> "token" or "quoted string")
> - HTTP header parsers can properly deal with name/value pairs
>=20
> If we make changes to the GET/POST parameter name then I think we
> should also consider the header as well.
>=20
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Fri Jun 10 15:19:44 2011
Return-Path: 
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 10DA821F84BC for ; Fri, 10 Jun 2011 15:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level: 
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcLOisj4jDsx for ; Fri, 10 Jun 2011 15:19:43 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4513121F84BB for ; Fri, 10 Jun 2011 15:19:43 -0700 (PDT)
Received: (qmail 14181 invoked from network); 10 Jun 2011 22:19:42 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jun 2011 22:19:42 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 10 Jun 2011 15:19:37 -0700
From: Eran Hammer-Lahav 
To: Robert Sayre , Adam Barth 
Date: Fri, 10 Jun 2011 15:19:25 -0700
Thread-Topic: Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
Thread-Index: AcwnnViXTD/xeo0WQ7Ctg7UG8kzWygAHwhkw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E7742CB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 22:19:44 -0000

> -----Original Message-----
> From: Robert Sayre [mailto:sayrer@gmail.com]
> Sent: Friday, June 10, 2011 11:37 AM
> To: Adam Barth
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: Why not use a server-supplied nonce (was: HTTP MAC
> Authentication Scheme)
>=20
> On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth  wrote:
> > On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre  wrote=
:
> >> Let's call my proposed addition the "opaque" parameter. The client
> >> sends it back unchanged, just like the id.
> >
> > That already exists in the scheme. =A0It's just the value of the cookie=
.
> >
> >> This is just one use of an opaque field that servers might want to
> >> try. I suppose this data could get stuffed into the SID too. Is that
> >> the idea?
> >
> > Yep.
>=20
> OK, this is all much clearer. Could the draft include these explanations =
and
> examples? It seems like the draft is obfuscated right now. Why not just
> plainly state something similar to
>=20
> "This mechanism really just adds a little more security to session cookie=
s."
>=20
> in the introduction? I hope it isn't because of HTTP religion or somethin=
g like
> that.

We can make it clearer with regard to session cookies, but overall, the mec=
hanism is just a cleanup of the OAuth 1.0 MAC functionality.

EHL

From ietf@adambarth.com  Fri Jun 10 15:50:04 2011
Return-Path: 
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 41803228016 for ; Fri, 10 Jun 2011 15:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.755
X-Spam-Level: 
X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+JZ5EqoKbiE for ; Fri, 10 Jun 2011 15:50:03 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3C5228010 for ; Fri, 10 Jun 2011 15:50:03 -0700 (PDT)
Received: by yxs7 with SMTP id 7so450836yxs.31 for ; Fri, 10 Jun 2011 15:50:03 -0700 (PDT)
Received: by 10.150.252.5 with SMTP id z5mr3617407ybh.164.1307746202876; Fri, 10 Jun 2011 15:50:02 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id i26sm1467756yhn.28.2011.06.10.15.50.01 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 15:50:01 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2775901gxk.31 for ; Fri, 10 Jun 2011 15:50:01 -0700 (PDT)
Received: by 10.91.207.26 with SMTP id j26mr3618149agq.206.1307746201110; Fri, 10 Jun 2011 15:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Fri, 10 Jun 2011 15:49:30 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E7742CB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:       <90C41DD21FB7C64BB94121FBBC2E7234475E7742CB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Adam Barth 
Date: Fri, 10 Jun 2011 15:49:30 -0700
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Why not use a server-supplied nonce (was: HTTP MAC Authentication Scheme)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jun 2011 22:50:04 -0000

On Fri, Jun 10, 2011 at 3:19 PM, Eran Hammer-Lahav  wr=
ote:
>> -----Original Message-----
>> From: Robert Sayre [mailto:sayrer@gmail.com]
>> Sent: Friday, June 10, 2011 11:37 AM
>> To: Adam Barth
>> Cc: Eran Hammer-Lahav; OAuth WG
>> Subject: Re: Why not use a server-supplied nonce (was: HTTP MAC
>> Authentication Scheme)
>>
>> On Fri, Jun 10, 2011 at 10:51 AM, Adam Barth  wrote:
>> > On Fri, Jun 10, 2011 at 10:42 AM, Robert Sayre  wrot=
e:
>> >> Let's call my proposed addition the "opaque" parameter. The client
>> >> sends it back unchanged, just like the id.
>> >
>> > That already exists in the scheme. =A0It's just the value of the cooki=
e.
>> >
>> >> This is just one use of an opaque field that servers might want to
>> >> try. I suppose this data could get stuffed into the SID too. Is that
>> >> the idea?
>> >
>> > Yep.
>>
>> OK, this is all much clearer. Could the draft include these explanations=
 and
>> examples? It seems like the draft is obfuscated right now. Why not just
>> plainly state something similar to
>>
>> "This mechanism really just adds a little more security to session cooki=
es."
>>
>> in the introduction? I hope it isn't because of HTTP religion or somethi=
ng like
>> that.
>
> We can make it clearer with regard to session cookies, but overall, the m=
echanism is just a cleanup of the OAuth 1.0 MAC functionality.

I might be helpful to have a clear example flow of how to use this
mechanism in a normal session-cookie set up.  I think that would
address some of the questions we've been getting.

Adam

From torsten@lodderstedt.net  Sat Jun 11 00:30:20 2011
Return-Path: 
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 26E3411E8091 for ; Sat, 11 Jun 2011 00:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMs9B0nNxHnz for ; Sat, 11 Jun 2011 00:30:19 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by ietfa.amsl.com (Postfix) with ESMTP id 64DCD11E8085 for ; Sat, 11 Jun 2011 00:30:18 -0700 (PDT)
Received: from [80.187.106.247] (helo=[192.168.43.164]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QVIe8-0002Xa-Rd; Sat, 11 Jun 2011 09:30:16 +0200
Message-ID: <4DF3198C.8080901@lodderstedt.net>
Date: Sat, 11 Jun 2011 09:30:20 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John Bradley 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jun 2011 07:30:20 -0000

Hi,

I also see the need to request and issue multiple tokens in a single 
authorization process. There has already been some discussion about this 
topic roughly a year ago:
- http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
- http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html

We at Deutsche Telekom have implemented an OAuth 2.0 extension 
supporting that use case. It's called "bulk authorization".

Would that be an interessting topic we could discuss at IETF-81 for the 
re-chartering?  I could present our approach there.

regards,
Torsten.

Am 10.06.2011 21:08, schrieb John Bradley:
> We have identified the need to request multiple tokens as one issue that we would have to extend.

From stephen.farrell@cs.tcd.ie  Sat Jun 11 05:12:53 2011
Return-Path: 
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 194C411E80A9 for ; Sat, 11 Jun 2011 05:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGXSJPEMntsf for ; Sat, 11 Jun 2011 05:12:51 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1711E80A4 for ; Sat, 11 Jun 2011 05:12:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7D55615433C; Sat, 11 Jun 2011 13:12:26 +0100 (IST)
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=1307794340; bh=qAZA+Oa+l3gCYJ kkp5txuhVSs6T0qqVSlTtEUBvjS5A=; b=5BDpTaDtlEun/K0KStBHQwSYgV4AGF Qn3YHHEsxgZ/sKzh55p1Xq9W9RlHWg5VWNkiaziop3GmUYJot6UB7D2xUqPgCa/5 cRqKENImOoQwMUMXFk1Vv6RKJpp+AQRhifNobv3WSAExODu9Os3AkucdbjApD84o aHSXiWHewecLGPrC5PbotT+9jdhQE8JbaDWunzFGxJzqjLIxuyLTdjutVHi/LeJ5 cVxPuAJ+y6QvfeQhHF8sSTs+Qrn7/LbjIK7yq6GFCUOZVrkoBYFcRicZ/J283On+ mbl1XDMWK/Jxlr27nTg24iozRk8TV+bmdcfWLzXnRfDteuLbm76YJRLg==
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 Jlg1s3AVsaFE; Sat, 11 Jun 2011 13:12:20 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.46.16.188]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D1F4515433B; Sat, 11 Jun 2011 13:12:16 +0100 (IST)
Message-ID: <4DF35BA0.9070104@cs.tcd.ie>
Date: Sat, 11 Jun 2011 13:12:16 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Eran Hammer-Lahav 
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>			<4DF206E7.3040401@aol.com>	<90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>	<4DF21800.9090302@aol.com>	<133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>	 <90C41DD21FB7C64BB94121FBBC2E7234475E7742CA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E7742CA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jun 2011 12:12:53 -0000

On 10/06/11 23:17, Eran Hammer-Lahav wrote:
> Extensibility in authentication schemes is a bad thing, given how they are deployed and the difficulty of changing them. No existing authentication scheme is extensible (explicitly).

Maybe that statement is a tad too general? [1]

S.

[1] http://tools.ietf.org/html/rfc3748


> 
> EHL
> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Marius Scurtescu
>> Sent: Friday, June 10, 2011 10:39 AM
>> To: John Kemp
>> Cc: paul Tarjan; OAuth WG
>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
>> type
>>
>> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
>>> George,
>>>
>>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>>
>>>> I definitely don't want to change the Authorization header naming
>> scheme. I believe it should stay 'Bearer' because that's what the token is. We
>> could make it...
>>>>
>>>> Authorization: Bearer access_token=vF9dft4qmT
>>>>
>>>> If that helps with consistency.
>>>
>>> Well, it might seem more consistent, but I'm not sure it's worthwhile to
>> make the change just for that reason.
>>>
>>> Is it possible that the Bearer HTTP mechanism would ever take multiple
>> parameters? In which case, having the ability to name the parameters of the
>> Bearer mechanism might become more interesting.
>>
>> Hard to say, but using a proper name/value pair has several advantages:
>> - permits extensibility
>> - no need to limit or define character set of access tokens (name is either
>> "token" or "quoted string")
>> - HTTP header parsers can properly deal with name/value pairs
>>
>> If we make changes to the GET/POST parameter name then I think we
>> should also consider the header as well.
>>
>> Marius
>> _______________________________________________
>> 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
> 

From eran@hueniverse.com  Sat Jun 11 09:35:21 2011
Return-Path: 
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 BC17421F8707 for ; Sat, 11 Jun 2011 09:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level: 
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBR4zaiyp+XG for ; Sat, 11 Jun 2011 09:35:20 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D6BAA21F8706 for ; Sat, 11 Jun 2011 09:35:20 -0700 (PDT)
Received: (qmail 2135 invoked from network); 11 Jun 2011 16:35:20 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2011 16:35:19 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 11 Jun 2011 09:35:18 -0700
From: Eran Hammer-Lahav 
To: Stephen Farrell 
Date: Sat, 11 Jun 2011 09:35:05 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AcwoMNmuYCNxFM96Qk65mO0FjLxc/gAJI5iA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E77431E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   <4DF206E7.3040401@aol.com>	<90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com>	<133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>  <90C41DD21FB7C64BB94121FBBC2E7234475E7742CA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35BA0.9070104@cs.tcd.ie>
In-Reply-To: <4DF35BA0.9070104@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , OAuth WG 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jun 2011 16:35:21 -0000

I meant HTTP authentication scheme (given the topic, that was implied).

EHL

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Saturday, June 11, 2011 5:12 AM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; John Kemp; paul Tarjan; OAuth WG
> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
>=20
>=20
> On 10/06/11 23:17, Eran Hammer-Lahav wrote:
> > Extensibility in authentication schemes is a bad thing, given how they =
are
> deployed and the difficulty of changing them. No existing authentication
> scheme is extensible (explicitly).
>=20
> Maybe that statement is a tad too general? [1]
>=20
> S.
>=20
> [1] http://tools.ietf.org/html/rfc3748
>=20
>=20
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Marius Scurtescu
> >> Sent: Friday, June 10, 2011 10:39 AM
> >> To: John Kemp
> >> Cc: paul Tarjan; OAuth WG
> >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer
> >> token type
> >>
> >> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
> >>> George,
> >>>
> >>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
> >>>
> >>>> I definitely don't want to change the Authorization header naming
> >> scheme. I believe it should stay 'Bearer' because that's what the
> >> token is. We could make it...
> >>>>
> >>>> Authorization: Bearer access_token=3DvF9dft4qmT
> >>>>
> >>>> If that helps with consistency.
> >>>
> >>> Well, it might seem more consistent, but I'm not sure it's
> >>> worthwhile to
> >> make the change just for that reason.
> >>>
> >>> Is it possible that the Bearer HTTP mechanism would ever take
> >>> multiple
> >> parameters? In which case, having the ability to name the parameters
> >> of the Bearer mechanism might become more interesting.
> >>
> >> Hard to say, but using a proper name/value pair has several advantages=
:
> >> - permits extensibility
> >> - no need to limit or define character set of access tokens (name is
> >> either "token" or "quoted string")
> >> - HTTP header parsers can properly deal with name/value pairs
> >>
> >> If we make changes to the GET/POST parameter name then I think we
> >> should also consider the header as well.
> >>
> >> Marius
> >> _______________________________________________
> >> 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
> >

From ritou.06@gmail.com  Sun Jun 12 09:03:00 2011
Return-Path: 
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 07D8211E80E8 for ; Sun, 12 Jun 2011 09:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.983
X-Spam-Level: 
X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA2ZXaZJBljX for ; Sun, 12 Jun 2011 09:02:59 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 411E311E80A1 for ; Sun, 12 Jun 2011 09:02:59 -0700 (PDT)
Received: by wyb29 with SMTP id 29so3169902wyb.31 for ; Sun, 12 Jun 2011 09:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Dkxtiq32W5NhOCuupMoW7oaBbkDQzBEBOCww78nyxiQ=; b=sPSyQ8IFo6akm2W21eAATQe9sR1+O3W/dckAC2OLqXBVEpwdN1iQtr1cqcg1fWigj6 JvGIANXvZJLM6yfaXYTjS2uF2yu04b6QbHr6DzYlyZvZejNvN/ex+j9j2T8DuCJmG+l0 CxUJOkNnFQLlVVeKJ6KHNcMbMNlvzHxtdDhJU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oAdTUNfoojX/teEpfBqGVcCLCXUMkeirlq3TkHULHQmxO6wUAlxUVmceZ9ZB8KA6zl YMMVvN9/r6723J4nLGigfOA3gA9BWFXu4xkN764dnnGDptJyGrmNaNwDdLtj3DeaeKTk 5gfJrzv1IIdJRVlZsY9X9735F2f/1C4q5Qfqc=
MIME-Version: 1.0
Received: by 10.216.174.129 with SMTP id x1mr4452785wel.45.1307894555829; Sun, 12 Jun 2011 09:02:35 -0700 (PDT)
Received: by 10.216.29.144 with HTTP; Sun, 12 Jun 2011 09:02:35 -0700 (PDT)
Date: Mon, 13 Jun 2011 01:02:35 +0900
Message-ID: 
From: Ryo Ito 
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [OAUTH-WG] Accessing to Client Resource as an External Protected Resource
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Jun 2011 16:03:00 -0000

Hi,

OAuth 1.0a has OAuth Echo which is Identity Verification Delegation Extenison.
On OAuth 2.0 specs, MAC token may enable the same delegation flow, but
Client must not pass Delegator bearer token.
The separation of Access Token will solve this problem.

Moreover, I think that client must obtain the permission to access the
3rd party's data by the user.

So, I propose the enhanced OAuth Echo.
=========================================================================

Abstruct of Proposal:

This extension allows the client to access the resources of other client.

Added Terminology
- External Resource Server(ERS)

Obtaining Authorization
- The client adds scope of accessing to ERS
- AuthZ Server must verify the scope (by Registory or discovery ERS(TBD))

Issuing an Access Token
- AuthZ Server adds ERS access_token to response

Accessing Protected Resources
- Client use ERS access_token to access ERS data
- ERS sends the token to AuthZ Server's delegation endpoint
- AuthZ Server returns the user identifier and client data(name,URL etc...)
- ERS processes the request

=======================================================================

In Twitter OAuth, it has a lot of Client that uses only the user identifier.
When the Client behaves as ERS, they can provide the own resources
easily without implementing the AuthZ Server.

Actually, is there Client that needs such the use case?

Ryo.

-- 
====================
Ryo Ito
Email : ritou.06@gmail.com
====================

From eran@hueniverse.com  Mon Jun 13 00:26:59 2011
Return-Path: 
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 F1BAB21F84BA for ; Mon, 13 Jun 2011 00:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEqSyFFHElrV for ; Mon, 13 Jun 2011 00:26:58 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7310C21F84BB for ; Mon, 13 Jun 2011 00:26:58 -0700 (PDT)
Received: (qmail 13399 invoked from network); 13 Jun 2011 07:26:54 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jun 2011 07:26:53 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 13 Jun 2011 00:26:53 -0700
From: Eran Hammer-Lahav 
To: Tim , Robert Sayre 
Date: Mon, 13 Jun 2011 00:26:37 -0700
Thread-Topic: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
Thread-Index: Acwms3fxX3rJ7OFlSrWL/fhQrFzuuQC5jjtg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <20110609144224.GR1565@sentinelchicken.org>
In-Reply-To: <20110609144224.GR1565@sentinelchicken.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG , "apps-discuss@ietf.org" 
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 07:26:59 -0000

> -----Original Message-----
> From: Tim [mailto:tim-projects@sentinelchicken.org]
> Sent: Thursday, June 09, 2011 7:42 AM
> To: Robert Sayre
> Cc: Eran Hammer-Lahav; OAuth WG; apps-discuss@ietf.org
> Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC
> Authentication Scheme
>=20
> > Digest has a bunch of problems. See this document
> >
> > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#s
> > ection-2.2.2
> >
> > for a short tour of them.
>=20
> Thanks for the link.  I totally agree with all of this, and in fact there=
 are more
> MitM attacks possible than are alluded to in that document. This is one o=
f the
> two reasons I brought up Digest initially.  The MAC proposal does not app=
ear
> to provide any additional security over Digest, and yet Digest is still
> susceptible to MitM attacks.
>=20
> We can pick and prod at the MAC proposal all we want from a security
> perspective, but we'll probably end up at the same place that Digest is a=
t,
> security-wise.  We'll still have a protocol that can't defend against Mit=
M
> attacks.  So what is the point in providing integrity again?
>=20
> We need to use TLS.  Everywhere.

Sure.
=20
> The more you look at advanced web attacks (MitM downgrade attacks, DNS
> rebinding attacks, etc), the more you realize that most of these are
> addressed by TLS if only it were used everywhere.
>=20
> It's fine to bring out special-purpose authentication protocols.
> Authentication can happen in a variety of ways either within TLS or tunne=
led
> over it (hopefully with channel binding), but don't pretend you'll be doi=
ng
> anyone favors by trying to provide partial integrity protection that is
> ultimately ineffective.  Just focus on better authentication and
> key/certificate management and let TLS do the rest.

Modern web applications require a lot of third-party hosted services: analy=
tics, advertising, plug-ins, etc. Until everyone deploys TLS, including suc=
h non-TLS bits in a TLS page cause the browser to show a broken TLS state i=
n the address bar. For most web users, that's more of a red flag (valid TLS=
 but with some resources loaded without TLS) than no TLS at all. The realit=
y is that it is really hard to deploy TLS applications today without having=
 issues with at least one vendor (especially when that vendor is an ad netw=
ork you rely on for your profits).

So while we wait for the web to catch up and deploy TLS (and this effort do=
es not delay that), we should try and do something about trivial attacks li=
ke Firesheep. Yes, adding MAC to cookies without TLS does not provide anywh=
ere near the protection of TLS, but it is better than nothing, when TLS is =
not available.

Note that the MAC authentication scheme is not exclusively about cookies, a=
nd has value beside just making session cookies better.

EHL






From tim-projects@sentinelchicken.org  Mon Jun 13 08:28:39 2011
Return-Path: 
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 1BC6621F84DE for ; Mon, 13 Jun 2011 08:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.307
X-Spam-Level: 
X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5HgZuu2fQ0v for ; Mon, 13 Jun 2011 08:28:38 -0700 (PDT)
Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2025721F84E5 for ; Mon, 13 Jun 2011 08:28:37 -0700 (PDT)
Received: (qmail 24164 invoked from network); 13 Jun 2011 15:28:33 -0000
Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Jun 2011 15:28:33 -0000
Received: (qmail 14338 invoked from network); 13 Jun 2011 15:29:28 -0000
Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 13 Jun 2011 15:29:28 -0000
Received: (nullmailer pid 337 invoked by uid 1000); Mon, 13 Jun 2011 15:28:32 -0000
Date: Mon, 13 Jun 2011 08:28:32 -0700
From: Tim 
To: Eran Hammer-Lahav 
Message-ID: <20110613152832.GU1565@sentinelchicken.org>
References: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <20110609144224.GR1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: OAuth WG , "apps-discuss@ietf.org" 
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 15:28:39 -0000

Hi Eran,

> ... Until everyone deploys TLS, including such non-TLS bits in a TLS
> page cause the browser to show a broken TLS state in the address bar.
> For most web users, that's more of a red flag (valid TLS but with some
> resources loaded without TLS) than no TLS at all. 

And in fact, in any modern browser, this situation is rightfully
called out as an insecure deployment.  Many one of those non-TLS
resources you refer to could be modified by an attacker to inject
malicious script and therefore hijack sessions.


> The reality is that
> it is really hard to deploy TLS applications today without having
> issues with at least one vendor (especially when that vendor is an ad
> network you rely on for your profits).

Agreed.  It is a typical "no one can do it because no one else is
doing it" situation.


> Yes, adding MAC to cookies without TLS
> does not provide anywhere near the protection of TLS, but it is better
> than nothing, when TLS is not available.

To Nico's point, I'm not entirely sure about that.  If something like
MAC caught on, where would people deploy it?  They deploy it to
protect credentials over non-TLS connections, right?  So it might be
used as yet another excuse not to use TLS, even though it doesn't
provide the kind of protection that most users would expect.

In modern browsers, MAC would do nothing to stop someone from
injecting script into a response which initiates arbitrary requests on
behalf of a user.  A browser would have no idea that the script was
malicious, so it would happily sign requests as if they were
user-initiated.  To the point: session hijacking isn't just about
stealing and reusing a session token.

I see no problem trying to provide something to help protect user
credentials through hard-to-crack hashes and the like, since those are
often used in more than one place, but I see no point in trying to
provide one-way integrity protection.


thanks,
tim

From igor.faynberg@alcatel-lucent.com  Mon Jun 13 10:42:13 2011
Return-Path: 
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 225BA11E80AC for ; Mon, 13 Jun 2011 10:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndDIOiQ5bZqP for ; Mon, 13 Jun 2011 10:42:12 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 86DBB11E80A9 for ; Mon, 13 Jun 2011 10:42:12 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5DHgBj7018006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 12:42:11 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5DHgA4n015098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Jun 2011 12:42:10 -0500
Received: from [135.244.25.71] (faynberg.lra.lucent.com [135.244.25.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5DHg9rt012323; Mon, 13 Jun 2011 12:42:09 -0500 (CDT)
Message-ID: <4DF64BF3.7010602@alcatel-lucent.com>
Date: Mon, 13 Jun 2011 13:42:11 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Torsten Lodderstedt 
References:  <4DF3198C.8080901@lodderstedt.net>
In-Reply-To: <4DF3198C.8080901@lodderstedt.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: John Bradley , OAuth WG 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 17:42:13 -0000

+1

Igor

Torsten Lodderstedt wrote:
> Hi,
>
> I also see the need to request and issue multiple tokens in a single 
> authorization process. There has already been some discussion about 
> this topic roughly a year ago:
> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>
> We at Deutsche Telekom have implemented an OAuth 2.0 extension 
> supporting that use case. It's called "bulk authorization".
>
> Would that be an interessting topic we could discuss at IETF-81 for 
> the re-chartering?  I could present our approach there.
>
> regards,
> Torsten.
>
> Am 10.06.2011 21:08, schrieb John Bradley:
>> We have identified the need to request multiple tokens as one issue 
>> that we would have to extend.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From svartman95@gmail.com  Mon Jun 13 08:45:02 2011
Return-Path: 
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 74F2E11E8072; Mon, 13 Jun 2011 08:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+mjzCwzzNVK; Mon, 13 Jun 2011 08:45:01 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD511E80D9; Mon, 13 Jun 2011 08:45:00 -0700 (PDT)
Received: by gxk19 with SMTP id 19so4116763gxk.31 for ; Mon, 13 Jun 2011 08:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1tjUbpJ2L4XoEaTJI1CgNC/2eMAtanVrxdlaOqFwNVw=; b=xsjbuawlyqVvM8dNaIt+hZvoi7cjBkoNCalXeD8hnGQviLy0c2e6yKugXDxCI16sMq VciyuOX5bvPzGuVOmFlqFpJCjG1mWtSAqdtDAuMv4eLmt/TDdVH+ju9Lus+/pHiSuJiZ Z64KaWB4u+czRSzX3RMck4S2Ciiv9Q7TKH1Ko=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dyg1l3I0wQ0UcFt8XKzWezLZblQZkzEOBs4/lquzCCAAK1puN+jBquNSt1drlCQNmW +gTr9Q4PpixNRGEkm+Agj+6V/fiGzeYWKDfvh4DE/S1gnCRwUu7i+JqgqBE9a6WwdpwO ou9VStN2dGp2W452zgfNPzI80AO6bqY4XpiXc=
MIME-Version: 1.0
Received: by 10.236.66.49 with SMTP id g37mr3527411yhd.237.1307979880381; Mon, 13 Jun 2011 08:44:40 -0700 (PDT)
Received: by 10.236.70.35 with HTTP; Mon, 13 Jun 2011 08:44:39 -0700 (PDT)
In-Reply-To: <20110613152832.GU1565@sentinelchicken.org>
References: <09c801cc24c2$a05bae00$e1130a00$@packetizer.com>  <00f101cc255e$2d426020$87c72060$@packetizer.com>  <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <20110609144224.GR1565@sentinelchicken.org> <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110613152832.GU1565@sentinelchicken.org>
Date: Mon, 13 Jun 2011 15:44:39 +0000
Message-ID: 
From: Bjartur Thorlacius 
To: Tim 
Content-Type: text/plain; charset=UTF-8
X-Mailman-Approved-At: Mon, 13 Jun 2011 12:39:53 -0700
Cc: "apps-discuss@ietf.org" , OAuth WG 
Subject: Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Jun 2011 15:45:02 -0000

On 6/13/11, Tim  wrote:
> Agreed.  It is a typical "no one can do it because no one else is
> doing it" situation.
Not quite, as ad networks are free to support TLS. Embedders simply
link to ads using either the http or the https scheme (without
breaking anythings as user agents support both already). The problem
seems to be lack of pressure, as ad networks compete primarily on
price and amount of distraction. Users won't notice if they're
downloading both their content and ads over plain HTTP over TCP.

From James.H.Manger@team.telstra.com  Mon Jun 13 18:11:27 2011
Return-Path: 
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 CFA9B11E8075 for ; Mon, 13 Jun 2011 18:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPCH8uRrs53W for ; Mon, 13 Jun 2011 18:11:26 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA2228004 for ; Mon, 13 Jun 2011 18:11:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,361,1304258400"; d="scan'208,217";a="39982969"
Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 14 Jun 2011 11:11:24 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6376"; a="28870138"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdni.tcif.telstra.com.au with ESMTP; 14 Jun 2011 11:11:23 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 14 Jun 2011 11:11:23 +1000
From: "Manger, James H" 
To: oauth 
Date: Tue, 14 Jun 2011 11:11:21 +1000
Thread-Topic: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqL/kMOBs9DL99R+SHchOEYK5ihA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112867EEDE0WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [OAUTH-WG] MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 01:11:28 -0000

--_000_255B9BB34FB7D647A506DC292726F6E112867EEDE0WSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]:



When MAC credentials are issued with a Set-Cookie response header [section =
6] the spec says to use the cookie's name as the MAC key identifier (eg "id=
=3DSID"). It would make more sense to use the cookie's value (eg "id=3D31d4=
d96e407aad42").



I guess the intention is to include the cookie's value in the Cookie header=
 so it in unnecessary to repeat it in the Authorization header. Repeating t=
he cookie name should be less overhead as it will usually be quite short. T=
his is a bit hacky, too hacky. Wouldn't it be better for a client that reco=
gnizes a special MAC cookie to use it to construct Authorization headers an=
d omit it from Cookie headers? A client that doesn't understand the extra M=
AC-Key cookie attribute will treat the cookie as a normal cookie to return =
in a Cookie header.



A "normal" MAC library would use the id field in a "Authorization: MAC" hea=
der to lookup the secret key. A library for this spec will sometimes use th=
e id field to lookup the secret key, but also sometimes use the id field to=
 lookup a cookie then use that value to lookup the secret key. There is no =
explicit sign about which approach to follow in any given instance. It depe=
nds on how the MAC credentials were issued - which a protected resource sho=
uldn't have to care about, and might not know.



There have been suggestions that the MAC calculation could/should cover the=
 key id. In that situation it is even more crucial that the id field isn't =
just a name referring to the real value elsewhere - as then the security ch=
anges based on the syntax used to issue the credentials.





[Section 6, and 6.1.3]



     Set-Cookie: SID=3D31d4d96e407aad42; Path=3D/; Domain=3Dexample.com;

                 MAC-Key=3D8yfrufh348h; MAC-Algorithm=3Dhmac-sha-1



   ...The cookie name "SID" is used as the MAC key identifier


   ...
   MAC key identifier
      is equal to the operative-cookie's name,





--

James Manger




--_000_255B9BB34FB7D647A506DC292726F6E112867EEDE0WSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











A comment on the MAC draft [draft-ietf-oauth-v2-http=
-mac-00]:


 


When MAC credentials are issued with a Set-Cookie re=
sponse header [section 6] the spec says to use the cookie’s name as t=
he MAC key identifier (eg “id=3DSID”). It would make more sense=
 to use the cookie’s value (eg “id=3D31d4d96e407aad42”).<=
o:p>


 


I guess the intention is to include the cookie’=
;s value in the Cookie header so it in unnecessary to repeat it in the Auth=
orization header. Repeating the cookie name should be less overhead as it w=
ill usually be quite short. This is a bit
 hacky, too hacky. Wouldn’t it be better for a client that recognizes=
 a special MAC cookie to use it to construct Authorization headers and omit=
 it from Cookie headers? A client that doesn’t understand the extra M=
AC-Key cookie attribute will treat the cookie
 as a normal cookie to return in a Cookie header.


 


A “normal” MAC library would use the id =
field in a “Authorization: MAC” header to lookup the secret key=
. A library for this spec will sometimes use the id field to lookup the sec=
ret key, but also sometimes use the id field to lookup a cookie
 then use that value to lookup the secret key. There is no explicit sign ab=
out which approach to follow in any given instance. It depends on how the M=
AC credentials were issued – which a protected resource shouldn’=
;t have to care about, and might not know.


 


There have been suggestions that the MAC calculation=
 could/should cover the key id. In that situation it is even more crucial t=
hat the id field isn’t just a name referring to the real value elsewh=
ere – as then the security changes based
 on the syntax used to issue the credentials.


 


 


[Section 6, and 6.1.3]


 


     Set-Cookie: SID=3D31d4d96e407aad4=
2; Path=3D/; Domain=3Dexample.com;


         &nbs=
p;       MAC-Key=3D8yfrufh348h; MAC-Algorithm=
=3Dhmac-sha-1


 


   …The cookie name "SID" is use=
d as the MAC key identifier


 


   …


   MAC key identifier


      is equal to the operative-cookie's name=
,


 


 


--


James Manger


 






--_000_255B9BB34FB7D647A506DC292726F6E112867EEDE0WSMSG3153Vsrv_--

From ietf@adambarth.com  Mon Jun 13 18:41:32 2011
Return-Path: 
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 3461D11E80AE for ; Mon, 13 Jun 2011 18:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.414
X-Spam-Level: 
X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmhO+BR12KK6 for ; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7511E80A5 for ; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: by iwn39 with SMTP id 39so5866430iwn.31 for ; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: by 10.42.170.129 with SMTP id f1mr6881525icz.190.1308015690569; Mon, 13 Jun 2011 18:41:30 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id er6sm1784792ibb.40.2011.06.13.18.41.29 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
Received: by iwn39 with SMTP id 39so5866407iwn.31 for ; Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
Received: by 10.42.218.1 with SMTP id ho1mr6543972icb.474.1308015689033; Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.52.4 with HTTP; Mon, 13 Jun 2011 18:40:59 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
From: Adam Barth 
Date: Mon, 13 Jun 2011 18:40:59 -0700
Message-ID: 
To: "Manger, James H" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 01:41:32 -0000

On Mon, Jun 13, 2011 at 6:11 PM, Manger, James H
 wrote:
> A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]:
>
> When MAC credentials are issued with a Set-Cookie response header [sectio=
n
> 6] the spec says to use the cookie=92s name as the MAC key identifier (eg
> =93id=3DSID=94). It would make more sense to use the cookie=92s value (eg
> =93id=3D31d4d96e407aad42=94).

That was the original plan, but cookie values tend to be longer than
cookie names and it seemed silly to repeat the value twice in the
request.  (It's bad enough to repeat the name.)

> I guess the intention is to include the cookie=92s value in the Cookie he=
ader
> so it in unnecessary to repeat it in the Authorization header.

Yep.

> Repeating the
> cookie name should be less overhead as it will usually be quite short.

Correct.

> This is a bit hacky, too hacky. Wouldn=92t it be better for a client that
> recognizes a special MAC cookie to use it to construct Authorization head=
ers
> and omit it from Cookie headers?

Nope.  Sending the value in the Cookie header is important to help
servers implement this scheme without breaking themselves.

> A client that doesn=92t understand the extra
> MAC-Key cookie attribute will treat the cookie as a normal cookie to retu=
rn
> in a Cookie header.

Indeed.

> A =93normal=94 MAC library would use the id field in a =93Authorization: =
MAC=94
> header to lookup the secret key.

You're welcome to use the protocol that way.  Just encode that
information into the cookie name.

> A library for this spec will sometimes use
> the id field to lookup the secret key, but also sometimes use the id fiel=
d
> to lookup a cookie then use that value to lookup the secret key. There is=
 no
> explicit sign about which approach to follow in any given instance. It
> depends on how the MAC credentials were issued =96 which a protected reso=
urce
> shouldn=92t have to care about, and might not know.
>
> There have been suggestions that the MAC calculation could/should cover t=
he
> key id. In that situation it is even more crucial that the id field isn=
=92t
> just a name referring to the real value elsewhere =96 as then the securit=
y
> changes based on the syntax used to issue the credentials.

It's not a big deal either way in practice.  Folks will be
cross-checking the cookies with the Mac anyway.  It's better to send
things once rather than have duplication.

Adam


> [Section 6, and 6.1.3]
>
> =A0=A0=A0=A0 Set-Cookie: SID=3D31d4d96e407aad42; Path=3D/; Domain=3Dexamp=
le.com;
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MAC-Key=3D8yfrufh348h; M=
AC-Algorithm=3Dhmac-sha-1
>
> =A0=A0 =85The cookie name "SID" is used as the MAC key identifier
>
> =A0=A0 =85
>
> =A0=A0 MAC key identifier
>
> =A0=A0=A0=A0=A0 is equal to the operative-cookie's name,

From barryleiba.mailing.lists@gmail.com  Mon Jun 13 18:58:24 2011
Return-Path: 
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 D8FF421F8583 for ; Mon, 13 Jun 2011 18:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeRV6OL4XG2F for ; Mon, 13 Jun 2011 18:58:24 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD321F8580 for ; Mon, 13 Jun 2011 18:58:24 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1158795yxt.31 for ; Mon, 13 Jun 2011 18:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Axo8KfuL4pTovAG+G6uEvfhoXt+Mka2cPFE4dZ56frg=; b=KSWdGSvzkIwleMzDVKVWXc6uVM8VQn5CFGR31oE7YdQKW+LSzIipsDDZ7fqyNMO+kd Oswk4phAxmDAwCJgTxVwOWI2yHGCCvGWtau9XtE5/RryDJ6S10POIgrfzXqFXI73WRWc E8cxqcG3P0iCLPxyVtDjpSOefsQjie9/OFnpQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=stkRi6PRr8uACcVF/X7FYy9tlqNb5qW2xjV9ttUmrakb5Ws0ylbV/5uLB6aYlL6K9H 1qtIGzLBXXbVgwq+guTSS7UTfm8duKXvhH5lq1gyTEM7AU+BVYgZJ9JMGDRNJeWEPXsi PDl6wG4MYJB0qeidqh+iIawPhXWZExdJADFYo=
MIME-Version: 1.0
Received: by 10.146.28.25 with SMTP id b25mr5851845yab.0.1308016703442; Mon, 13 Jun 2011 18:58:23 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.113.3 with HTTP; Mon, 13 Jun 2011 18:58:23 -0700 (PDT)
In-Reply-To: <4DF3198C.8080901@lodderstedt.net>
References:  <4DF3198C.8080901@lodderstedt.net>
Date: Mon, 13 Jun 2011 21:58:23 -0400
X-Google-Sender-Auth: jvfcnIifAB-OIDnPVAupP9VkyEo
Message-ID: 
From: Barry Leiba 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 01:58:25 -0000

On Sat, Jun 11, 2011 at 3:30 AM, Torsten Lodderstedt
 wrote:
> We at Deutsche Telekom have implemented an OAuth 2.0 extension supporting
> that use case. It's called "bulk authorization".
>
> Would that be an interessting topic we could discuss at IETF-81 for the
> re-chartering? =A0I could present our approach there.

A reminder: We won't be discussing rechartering until we have the
currently chartered documents in to the IESG, which means successfully
through working-group last call.

So those who want to talk about extensions and additions -- and
rechartering -- should have a good bit of enthusiasm to ensure that we
get those documents done tout de suite.

Barry, as chair

From James.H.Manger@team.telstra.com  Mon Jun 13 19:17:25 2011
Return-Path: 
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 6BD2C21F866B for ; Mon, 13 Jun 2011 19:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlnqfjCJkPap for ; Mon, 13 Jun 2011 19:17:25 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D221F866A for ; Mon, 13 Jun 2011 19:17:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,361,1304258400"; d="scan'208";a="39993242"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 14 Jun 2011 12:17:23 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6376"; a="29384224"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 14 Jun 2011 12:17:23 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 14 Jun 2011 12:17:23 +1000
From: "Manger, James H" 
To: Adam Barth 
Date: Tue, 14 Jun 2011 12:17:21 +1000
Thread-Topic: [OAUTH-WG] MAC: Cookie name or value as MAC key id
Thread-Index: AcwqNDdszRTrQX2dSgSHOuu0iDfH0gAAFWUw
Message-ID: <255B9BB34FB7D647A506DC292726F6E112867EF000@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 02:17:25 -0000

>> This is a bit hacky, too hacky. Wouldn't it be better for a client that
>> recognizes a special MAC cookie to use it to construct Authorization hea=
ders
>> and omit it from Cookie headers?

> Nope.  Sending the value in the Cookie header is important to help
> servers implement this scheme without breaking themselves.

Why? How? Could you explain this a bit more?

Is this so the cookie can be reused as a session id that load balancers can=
 use to implement "sticky" sessions? A key id doesn't sound like a great se=
ssion id. Wouldn't a separate session cookie be better?

Is this so a server can issue MAC credentials, but still accept clients tha=
t are unaware of the MAC scheme? That seems possible either way.

Is this so a central security server can start issuing MAC credentials whil=
e some of its content servers don't understand MAC and just treat the key i=
d as a bearer token? That sounds bad -- client's think they are getting MAC=
 security when they are not.

--
James Manger





From igor.faynberg@alcatel-lucent.com  Mon Jun 13 22:06:05 2011
Return-Path: 
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 B172B1F0C82 for ; Mon, 13 Jun 2011 22:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lTz3NeMtJDA for ; Mon, 13 Jun 2011 22:06:02 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8FA1F0C35 for ; Mon, 13 Jun 2011 22:06:01 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5E55hgG011017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 00:05:46 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5E55hUh031436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 00:05:43 -0500
Received: from [135.244.25.71] (faynberg.lra.lucent.com [135.244.25.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5E55art010323; Tue, 14 Jun 2011 00:05:38 -0500 (CDT)
Message-ID: <4DF6EC1F.4020703@alcatel-lucent.com>
Date: Tue, 14 Jun 2011 01:05:35 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Barry Leiba 
References: 	<4DF3198C.8080901@lodderstedt.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 05:06:05 -0000

Barry,

I think there has been a confusion.  I also thought that the 
rechartering was to be discussed at the July meeting; the IETF call for 
rechartering was issued on May 31.

My question: has the rechartering discussion been closed in the WG?  (If 
so, I guess I missed the point when it happened.)

Igor

Barry Leiba wrote:
> On Sat, Jun 11, 2011 at 3:30 AM, Torsten Lodderstedt
>  wrote:
>   
>> We at Deutsche Telekom have implemented an OAuth 2.0 extension supporting
>> that use case. It's called "bulk authorization".
>>
>> Would that be an interessting topic we could discuss at IETF-81 for the
>> re-chartering?  I could present our approach there.
>>     
>
> A reminder: We won't be discussing rechartering until we have the
> currently chartered documents in to the IESG, which means successfully
> through working-group last call.
>
> So those who want to talk about extensions and additions -- and
> rechartering -- should have a good bit of enthusiasm to ensure that we
> get those documents done tout de suite.
>
> Barry, as chair
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>   

From barryleiba.mailing.lists@gmail.com  Mon Jun 13 22:20:50 2011
Return-Path: 
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 6CCC911E8294 for ; Mon, 13 Jun 2011 22:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xlh+H19F9jm for ; Mon, 13 Jun 2011 22:20:49 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B699711E8292 for ; Mon, 13 Jun 2011 22:20:49 -0700 (PDT)
Received: by gxk19 with SMTP id 19so4537832gxk.31 for ; Mon, 13 Jun 2011 22:20:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q10hSb66x6KAWdCPwDx9mj4tPPL7KJiWfybBHkz9ZAw=; b=RhSQdxGerOMwvQmSngr9o9soVjtO02HA3PxsWy1yar5mmkZWtGVl5rGZtKWK+Jm9Dt gdMgNkFMCCN3Io7+iZ47OAQu8gxqJ/fJgCeKZr52GP3VQWHx+9ZKsPQF68DT5USmRpBE uaC/xBUPtVSKUk/+D0AqKOS/0EcK1mZy8KdZo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fP9ZnfyYXFBbCTmrLZLnn1LF7Z5tzW6ckka/ZAf69G95MZ0yr1iFenhkQOAg6tJ2x6 ye+MMgC8izKJ5MIrLdOdKW9yfnv6/qOWpv9H2SK5lXYe5Av2reLlpg/5efpM14YnTFRn pS6abAhxBJUFmBABkQsbv3kQdztnMquJVca9Y=
MIME-Version: 1.0
Received: by 10.236.168.99 with SMTP id j63mr6065439yhl.117.1308028848918; Mon, 13 Jun 2011 22:20:48 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.113.3 with HTTP; Mon, 13 Jun 2011 22:20:48 -0700 (PDT)
In-Reply-To: <4DF6EC1F.4020703@alcatel-lucent.com>
References:  <4DF3198C.8080901@lodderstedt.net>  <4DF6EC1F.4020703@alcatel-lucent.com>
Date: Tue, 14 Jun 2011 01:20:48 -0400
X-Google-Sender-Auth: 9VvsTLLMmX6YRy6RLEnYb98lsYk
Message-ID: 
From: Barry Leiba 
To: igor.faynberg@alcatel-lucent.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 05:20:50 -0000

> I think there has been a confusion. =A0I also thought that the recharteri=
ng
> was to be discussed at the July meeting; the IETF call for rechartering w=
as
> issued on May 31.

Right, and that call was not for discussion of rechartering, but for a
review of the specific proposed charter.

The charter that we discussed here was sent out for internal review on
31 May, and was approved by the IESG last Thursday -- that should be
officially announced any time now.  That charter, if you recall, was
very focused and included milestones for submitting OAuth 2.0, bearer
tokens, and MAC auth to the IESG in July and August, and discussion of
rechartering again, for further work, in October.

We won't be discussing rechartering in Qu=E9bec, unless we've finished
those three documents already.  That seems unlikely.  But if we can do
it, tant mieux.

Barry

From eran@hueniverse.com  Mon Jun 13 22:47:55 2011
Return-Path: 
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 B209B11E8170 for ; Mon, 13 Jun 2011 22:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level: 
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+Rmq45TGwCV for ; Mon, 13 Jun 2011 22:47:55 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D84FA11E816F for ; Mon, 13 Jun 2011 22:47:54 -0700 (PDT)
Received: (qmail 5255 invoked from network); 14 Jun 2011 05:47:54 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2011 05:47:54 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 13 Jun 2011 22:47:53 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , oauth 
Date: Mon, 13 Jun 2011 22:47:36 -0700
Thread-Topic: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqL/kMOBs9DL99R+SHchOEYK5ihAAJnmqw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E77465A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 05:47:55 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, June 13, 2011 6:11 PM

> There have been suggestions that the MAC calculation could/should cover
> the key id. In that situation it is even more crucial that the id field i=
sn't just a
> name referring to the real value elsewhere - as then the security changes
> based on the syntax used to issue the credentials.

What suggestions? We could not come up with any reason to include the key i=
dentifier in the normalized string.

EHL


From ietf@adambarth.com  Tue Jun 14 00:59:09 2011
Return-Path: 
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 4202611E8092 for ; Tue, 14 Jun 2011 00:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.389
X-Spam-Level: 
X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMPPBxHT0gfC for ; Tue, 14 Jun 2011 00:59:08 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9DC11E8070 for ; Tue, 14 Jun 2011 00:59:08 -0700 (PDT)
Received: by iyn15 with SMTP id 15so6110509iyn.31 for ; Tue, 14 Jun 2011 00:59:08 -0700 (PDT)
Received: by 10.231.29.101 with SMTP id p37mr6776826ibc.3.1308038348055; Tue, 14 Jun 2011 00:59:08 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id gb8sm3202587ibb.9.2011.06.14.00.59.06 (version=SSLv3 cipher=OTHER); Tue, 14 Jun 2011 00:59:07 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6104287iwn.31 for ; Tue, 14 Jun 2011 00:59:06 -0700 (PDT)
Received: by 10.42.100.141 with SMTP id a13mr7205196ico.72.1308038346381; Tue, 14 Jun 2011 00:59:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.52.4 with HTTP; Tue, 14 Jun 2011 00:53:11 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112867EF000@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E112867EF000@WSMSG3153V.srv.dir.telstra.com>
From: Adam Barth 
Date: Tue, 14 Jun 2011 00:53:11 -0700
Message-ID: 
To: "Manger, James H" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 07:59:09 -0000

On Mon, Jun 13, 2011 at 7:17 PM, Manger, James H
 wrote:
>>> This is a bit hacky, too hacky. Wouldn't it be better for a client that
>>> recognizes a special MAC cookie to use it to construct Authorization he=
aders
>>> and omit it from Cookie headers?
>
>> Nope. =A0Sending the value in the Cookie header is important to help
>> servers implement this scheme without breaking themselves.
>
> Why? How? Could you explain this a bit more?
>
> Is this so the cookie can be reused as a session id that load balancers c=
an use to implement "sticky" sessions? A key id doesn't sound like a great =
session id. Wouldn't a separate session cookie be better?
>
> Is this so a server can issue MAC credentials, but still accept clients t=
hat are unaware of the MAC scheme? That seems possible either way.
>
> Is this so a central security server can start issuing MAC credentials wh=
ile some of its content servers don't understand MAC and just treat the key=
 id as a bearer token? That sounds bad -- client's think they are getting M=
AC security when they are not.

Most folks who run web sites use cookies to generate sessions.  These
folks will layer the MAC protections on top of their existing systems
by adding a couple cookie attributes and verifying an HMAC.  If we
removed the MAC cookie from the Cookie header, the Cookie header would
be different in supporting and legacy user agents, causing pain and
misery.

It might be instructive to try using MAC in a real deployment.  You'll
see immediately why this behavior is preferable.

Adam

From stephen.farrell@cs.tcd.ie  Tue Jun 14 02:11:32 2011
Return-Path: 
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 4E0699E800C for ; Tue, 14 Jun 2011 02:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.99
X-Spam-Level: 
X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6SWFths+-jK for ; Tue, 14 Jun 2011 02:11:31 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 315AD9E8005 for ; Tue, 14 Jun 2011 02:11:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EB55515356B; Tue, 14 Jun 2011 10:11:22 +0100 (IST)
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=1308042682; bh=1fc/JxVJU1nUb+ 0jKvjk36FNBJ07tPDzFHFCHNeS9Qk=; b=dfAXw37MSnb/+ZSBuUjiOg6D4Bt40r AjwMdTS4tsfP7WnSowOz59QiX+bQ0iUuNpyMHMuk/MpSkJ9h6Qb4GNcoW/Hx/20j DEmYkWwEAGgDVvIaz+JFrtOAk7ICxutBANnVBIw99v3NvVpC60Bg2fGOEijdNT1O zHVvbxPJxEX5dZP9MbsThguLeyT4U4xhnnkD5iE9007zSi8TnHhV6V7Qnlsx81Ok i+HCKZNsbFtuDlhzhNAK4arHIna192oPeW9lnd9qqTSDQw068KT7jrFt+hOC09gE g8sChaSme1EJO0Q6WLEmyNEvLbPjcohoeMpkMvXQjDSr33zzKHmPhe/g==
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 dFbWLi8Sly10; Tue, 14 Jun 2011 10:11:22 +0100 (IST)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2E51C15356A; Tue, 14 Jun 2011 10:11:18 +0100 (IST)
Message-ID: <4DF725B6.1030008@cs.tcd.ie>
Date: Tue, 14 Jun 2011 10:11:18 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: OAuth WG 
References: 	<4DF3198C.8080901@lodderstedt.net>		<4DF6EC1F.4020703@alcatel-lucent.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: Barry Leiba 
Subject: Re: [OAUTH-WG] Proposed OAuth Extensions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 09:11:32 -0000

On 14/06/11 06:20, Barry Leiba wrote:
> The charter that we discussed here was sent out for internal review on
> 31 May, and was approved by the IESG last Thursday -- that should be
> officially announced any time now.  That charter, if you recall, was
> very focused and included milestones for submitting OAuth 2.0, bearer
> tokens, and MAC auth to the IESG in July and August, and discussion of
> rechartering again, for further work, in October.
> 
> We won't be discussing rechartering in Québec, unless we've finished
> those three documents already.  That seems unlikely.  But if we can do
> it, tant mieux.

Right. I really hope to see documents for AD review or at least
being done or almost done WGLC before Quebec. Time is already very
tight for that to happen: if a 2 week WGLC started say in one week,
(June 21) then that would only leave 4 days from the end of WGLC
(July 5) until the I-D submission deadline (July 11) for Quebec.

In terms of extensions/rechartering, there are two ways to look at
this:

1 - the AD is being a PITA about this
2 - the WG has existed since late 2008 and really needs to produce
    results before moving on, as was agreed between the WG, AD and
    the IESG very very recently (last Thursday), the relevant part of
    the new charter being "Milestones will be added for the later
    items *after* the near-term work has been completed."

I'm ok with folks believing either:-)

To be concrete, there's no point in discussing rechartering at
this stage, because, as AD, I'm just not going to push any new
charter to the IESG until the current milestones are sufficiently
advanced. (At present, I interpret that to mean entering IETF
LC, which is after WGLC and AD review.)

So: what Barry said - please concentrate on getting the current
work finished. (Not perfect, but with rough consensus in the WG.)

S.

From James.H.Manger@team.telstra.com  Tue Jun 14 07:26:54 2011
Return-Path: 
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 2D44E9E801E for ; Tue, 14 Jun 2011 07:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWmUWzBXBPu8 for ; Tue, 14 Jun 2011 07:26:53 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 26E389E800A for ; Tue, 14 Jun 2011 07:26:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,364,1304258400"; d="scan'208";a="38036690"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 00:26:50 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6376"; a="28831906"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 00:26:50 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 15 Jun 2011 00:26:50 +1000
From: "Manger, James H" 
To: oauth 
Date: Wed, 15 Jun 2011 00:25:12 +1000
Thread-Topic: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqL/kMOBs9DL99R+SHchOEYK5ihAAJnmqwAAJMj+AADybjsA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 14:26:54 -0000

>> There have been suggestions that the MAC calculation could/should cover
>> the key id. In that situation it is even more crucial that the id field =
isn't just a
>> name referring to the real value elsewhere - as then the security change=
s
>> based on the syntax used to issue the credentials.

>What suggestions? We could not come up with any reason to include the key =
identifier in the >normalized string.

Adam Barth said "one possibility is to include the value of the Cookie head=
er in the MAC". That was in response to Robert Sayre's suggestion of a serv=
er-provided nonce ("opaque" parameter) that would be covered by the MAC, wh=
ich Adam said could go into the key id. Adam did go on to say he hadn't see=
n much demand for this feature from site operators he has talked to. [http:=
//www.ietf.org/mail-archive/web/oauth/current/msg06631.html]

So not a complete suggestion with proposed text for the spec -- just a hint=
 that it was a possible design. HTTP Digest signs the username, for instanc=
e. I don't have a specific reason to sign the key id. I don't think it woul=
d be harmful. Perhaps it could help where the key id is actually a combinat=
ion of complicated assertions (eg SAML) by giving a bit more protection aga=
inst attacks that modify the Authorization header. Various PKI specs includ=
e a cert id in the data they sign, purportedly for security/legal reasons.

The point was that an id field that is sometimes the key id, but at other t=
imes just a pointer to the key id (with no indication of which mode is in u=
se), does not feel like a good design -- at least not until I understand th=
e compelling reason for keeping the Cookie header when using MAC with Cooki=
e-issued credentials.


Adam provides an ok argument for why tacking MAC-... attributes on to an ex=
isting cookie will be the simplest implementation choice. (Thanks)

>Most folks who run web sites use cookies to generate sessions.  These
>folks will layer the MAC protections on top of their existing systems
>by adding a couple cookie attributes and verifying an HMAC.  If we
>removed the MAC cookie from the Cookie header, the Cookie header would
>be different in supporting and legacy user agents, causing pain and
>misery.
>
>It might be instructive to try using MAC in a real deployment.  You'll
>see immediately why this behavior is preferable.


Perhaps omitting the id parameter from the Authorization header would be an=
 even better approach than using the cookie name. It avoids that minor repe=
tition, and is an unambiguous signal that the key id comes from elsewhere (=
ie from a cookie value).

--
James Manger

From bill@dehora.net  Tue Jun 14 08:12:25 2011
Return-Path: 
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 D084E11E80AD for ; Tue, 14 Jun 2011 08:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIIeV4375udA for ; Tue, 14 Jun 2011 08:12:24 -0700 (PDT)
Received: from chilco.textdrive.com (mail.indigozen.co.uk [207.7.108.242]) by ietfa.amsl.com (Postfix) with ESMTP id DEDCF11E80C7 for ; Tue, 14 Jun 2011 08:12:21 -0700 (PDT)
Received: from [192.168.3.18] (87-198-172-217.static.ptr.magnet.ie [87.198.172.217]) by chilco.textdrive.com (Postfix) with ESMTP id 8EE08DF8A4 for ; Tue, 14 Jun 2011 15:12:20 +0000 (UTC)
Message-ID: <4DF77A50.8080403@dehora.net>
Date: Tue, 14 Jun 2011 16:12:16 +0100
From: Bill 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>			<4DF206E7.3040401@aol.com>	<90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>	<4DF21800.9090302@aol.com>	<133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 15:12:25 -0000

On 10/06/11 17:45, David Recordon wrote:
> I think it's vital to have the GET and POST parameters make sense to
> every developer. I worry less about the authorization header since a
> developer implementing it will honestly be a stronger engineer.

I agree with David regardless of engineering strength, this is going to 
be confusing to developers. Also tho', devs are exposed to the access 
token response, not just the GET/POST bits. So ideally syntax would line 
up with how the token is obtained 
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.1 and not 
just across requests using the token.

A possible clarifying change is to use something like "bearer_token" end 
to end.

[[[
{
        "access_token":"vF9dft4qmT",
        "token_type":"bearer_token", /* ? */
...
}


GET /resource HTTP/1.1
Host: server.example.com
Authorization: bearer_token vF9dft4qmT


GET /resource?bearer_token=vF9dft4qmT&...
Host: server.example.com


POST /resource
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

&bearer_token=vF9dft4qmT&...


HTTP/1.1 401 Unauthorized
WWW-Authenticate: bearer_token realm="example"
]]]


Bill


> Here's what I said earlier in the thread about my motivation:
>> Did a full read through of draft 16 and the bear token spec with Paul
>> yesterday afternoon in order to do a manual diff from draft 10. The
>> point Doug raised was actually confusing. Throughout the core spec
>> it's referred to as access_token but then becomes bearer_token upon
>> use.
>>
>> Just thinking through this from a developer documentation perspective,
>> it's going to become confusing. Developer documentation focuses on
>> getting an access token and then using that access token to interact
>> with an API. Thus the code you're writing as a client developer will
>> use variables, cache keys, and database columns named `access_token`.
>> But then when you're going to use it, you'll need to put this access
>> token into a field named bearer_token.
>>
>> Feels quite a bit simpler to just name it access_token. Realize the
>> core spec never did this since we didn't want to trample on protected
>> resources which might already have a different type of access_token
>> parameter. oauth_token was a good compromise since developers would
>> already know that they were using OAuth and thus a new term wasn't
>> being introduced. That's no longer true with bearer_token since 99% of
>> developers will have never heard of a bearer token.
>>
>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>> Bearer Tokens are a Terrible Idea" and there isn't a single result on
>> the first page which explains what they are. Binging for "bearer
>> token" is equally scary.
>
> --David
>
>
> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp  wrote:
>> George,
>>
>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>
>>> I definitely don't want to change the Authorization header naming scheme. I believe it should stay 'Bearer' because that's what the token is. We could make it...
>>>
>>> Authorization: Bearer access_token=vF9dft4qmT
>>>
>>> If that helps with consistency.
>>
>> Well, it might seem more consistent, but I'm not sure it's worthwhile to make the change just for that reason.
>>
>> Is it possible that the Bearer HTTP mechanism would ever take multiple parameters? In which case, having the ability to name the parameters of the Bearer mechanism might become more interesting.
>>
>> - John
>>
>>> I don't think we should be associating the term 'access_token' with the bearer security mechanism.
>>>
>>> Thanks,
>>> George
>>>
>>> On 6/10/11 8:35 AM, John Kemp wrote:
>>>> What does this mean for the HTTP Authorization header naming scheme for bearer tokens?
>>>>
>>>> As I understand this decision, we are discussing whether to standardize on the name "access_token" when a bearer token is sent as either a URL query parameter, or in a form POSTed body?
>>>>
>>>> Currently the HTTP Authorization header looks like this (from
>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>>> ):
>>>>
>>>> GET /resource HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: Bearer vF9dft4qmT
>>>>
>>>> Is the proposal then that we have:
>>>>
>>>> 1. GET /resource?access_token=vF9dft4qmT
>>>> 2. POST /resource
>>>>
>>>> access_token=vF9dft4qmT&...
>>>>
>>>> 3.
>>>>
>>>> GET /resource HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: access_token vF9dft4qmT
>>>>
>>>> Can someone actually give the details of the proposal, or agree/disagree with the examples above?
>>>>
>>>> - John
>>>>
>>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>>
>>>>
>>>>> Yes, that's fine with me.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>>
>>>>>> George, Doug and Eran are you alright with the Bearer token spec using
>>>>>> the parameter name "access_token" as well?
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>>
>>>>>> 
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> If you can drive a consensus decision for the name "access_token", I'd be glad to change the name in the spec.  I agree that the current names are confusing for developers.
>>>>>>>>
>>>>>>>>
>>>>>>> At Google we are getting the same feedback, that it is confusing for
>>>>>>> developers. It would definitely help if we could change the name to
>>>>>>> "access_token".
>>>>>>>
>>>>>>> Marius
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> _______________________________________________
>>>>> 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
>


From ietf@adambarth.com  Tue Jun 14 10:06:07 2011
Return-Path: 
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 9CBF211E8078 for ; Tue, 14 Jun 2011 10:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.366
X-Spam-Level: 
X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62UpUXHdM9LQ for ; Tue, 14 Jun 2011 10:06:06 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9EC11E808A for ; Tue, 14 Jun 2011 10:06:03 -0700 (PDT)
Received: by ywp31 with SMTP id 31so3803944ywp.31 for ; Tue, 14 Jun 2011 10:06:03 -0700 (PDT)
Received: by 10.150.255.36 with SMTP id c36mr8471496ybi.56.1308071161915; Tue, 14 Jun 2011 10:06:01 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id u21sm952396ybm.17.2011.06.14.10.06.00 (version=SSLv3 cipher=OTHER); Tue, 14 Jun 2011 10:06:00 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1745068yxt.31 for ; Tue, 14 Jun 2011 10:05:59 -0700 (PDT)
Received: by 10.91.207.11 with SMTP id j11mr8014337agq.17.1308071159646; Tue, 14 Jun 2011 10:05:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 14 Jun 2011 10:05:25 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>
From: Adam Barth 
Date: Tue, 14 Jun 2011 10:05:25 -0700
Message-ID: 
To: "Manger, James H" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 17:06:07 -0000

On Tue, Jun 14, 2011 at 7:25 AM, Manger, James H
 wrote:
>>> There have been suggestions that the MAC calculation could/should cover
>>> the key id. In that situation it is even more crucial that the id field=
 isn't just a
>>> name referring to the real value elsewhere - as then the security chang=
es
>>> based on the syntax used to issue the credentials.
>
>>What suggestions? We could not come up with any reason to include the key=
 identifier in the >normalized string.
>
> Adam Barth said "one possibility is to include the value of the Cookie he=
ader in the MAC". That was in response to Robert Sayre's suggestion of a se=
rver-provided nonce ("opaque" parameter) that would be covered by the MAC, =
which Adam said could go into the key id. Adam did go on to say he hadn't s=
een much demand for this feature from site operators he has talked to. [htt=
p://www.ietf.org/mail-archive/web/oauth/current/msg06631.html]
>
> So not a complete suggestion with proposed text for the spec -- just a hi=
nt that it was a possible design. HTTP Digest signs the username, for insta=
nce. I don't have a specific reason to sign the key id. I don't think it wo=
uld be harmful. Perhaps it could help where the key id is actually a combin=
ation of complicated assertions (eg SAML) by giving a bit more protection a=
gainst attacks that modify the Authorization header. Various PKI specs incl=
ude a cert id in the data they sign, purportedly for security/legal reasons=
.
>
> The point was that an id field that is sometimes the key id, but at other=
 times just a pointer to the key id (with no indication of which mode is in=
 use), does not feel like a good design -- at least not until I understand =
the compelling reason for keeping the Cookie header when using MAC with Coo=
kie-issued credentials.

Oh, we'd put that in the ext field because it's specific to the Cookie
instantiating of the protocol.  If you're using a SAML or whatever
other instantiation of the protocol, you'll want to put that stuff in
the ext field rather than cluttering up the base protocol.

> Adam provides an ok argument for why tacking MAC-... attributes on to an =
existing cookie will be the simplest implementation choice. (Thanks)
>
>>Most folks who run web sites use cookies to generate sessions. =A0These
>>folks will layer the MAC protections on top of their existing systems
>>by adding a couple cookie attributes and verifying an HMAC. =A0If we
>>removed the MAC cookie from the Cookie header, the Cookie header would
>>be different in supporting and legacy user agents, causing pain and
>>misery.
>>
>>It might be instructive to try using MAC in a real deployment. =A0You'll
>>see immediately why this behavior is preferable.
>
> Perhaps omitting the id parameter from the Authorization header would be =
an even better approach than using the cookie name. It avoids that minor re=
petition, and is an unambiguous signal that the key id comes from elsewhere=
 (ie from a cookie value).

Yeah, I've often wondered whether we should remove the id parameter
from the Authorization header.  My understanding is that it plays some
important role in the OAuth instantiation of the protocol.  There's
also the question about what to do when you have multiple cookies with
MAC attributes.  In that case, having the id to disambiguate seems
useful.

Adam

From wwwrun@ietfa.amsl.com  Tue Jun 14 10:14:09 2011
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 30) id 9C9AE11E8078; Tue, 14 Jun 2011 10:14:09 -0700 (PDT)
From: IESG Secretary 
To: IETF Announcement list 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20110614171409.9C9AE11E8078@ietfa.amsl.com>
Date: Tue, 14 Jun 2011 10:14:09 -0700 (PDT)
Cc: barryleiba@computer.org, oauth@ietf.org
Subject: [OAUTH-WG] WG Action: RECHARTER: Web Authorization Protocol Working Group (oauth)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 17:14:09 -0000

The Web Authorization Protocol Working Group (oauth) in the Security 
Area of the IETF has been rechartered.  For additional information, 
please contact the Area Directors or the working group Chairs.

Web Authorization Protocol Working Group (oauth)
-----------------------
Current Status: Active Working Group

Chairs: 
  Barry Leiba 
  Hannes Tschofenig 
  Blaine Cook 

Security Area Directors: 
  Stephen Farrell   
  Sean Turner 

Security Area Advisor: 
  Stephen Farrell   

Technical Advisor: Peter Saint-Andre 

Mailing List:
  Address: oauth@ietf.org  
  To Subscribe: https://www.ietf.org/mailman/listinfo/oauth 
  Archive: http://www.ietf.org/mail-archive/web/oauth/

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account.

OAuth encompasses
* a mechanism for a user to authorize issuance of credentials that
 a third party can use to access resources on the user's behalf and
* a mechanism for using the issued credentials to authenticate
 HTTP requests.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). The working
group has since been developing OAuth 2.0, a standards-track version
that will reflect IETF consensus.  Version 2.0 will consider the
implementation experience with version 1.0, a discovered security
vulnerability (session fixation attack), the use cases and
functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
* improve the terminology used,
* consider broader use cases,
* embody good security practices,
* improve interoperability, and
* provide guidelines for extensibility.

The working group will develop authentication schemes for
peers/servers taking part in OAuth (accessing protected resources).
This includes

* an HMAC-based authentication mechanism

This document aims to provide a general purpose MAC authentication
scheme that can be used both with OAuth 2.0 but also with other use cases.
The WG will work with the security and applications area directors to
ensure that this work gets appropriate review, e.g. via additional last
calls in other relevant working groups such as HTTPBIS,

* a specification for access protected by Transport Layer Security
(bearer tokens),

* an extension to OAuth 2.0 to allow access tokens to be requested
when a client is in possession of a SAML assertion.

A separate informational description will be produced to provide
additional security analysis for audiences beyond the community
of protocol implementers.

Milestones will be added for the later items after the near-term work
has been completed.

Goals and Milestones

May 2011    Submit 'HTTP Authentication: MAC Authentication' as a
            working group item

May 2011    Submit 'OAuth 2.0 Threat Model and Security Considerations'
            as a working group item

Jul 2011    Submit 'The OAuth 2.0 Authorization Protocol' to the
            IESG for consideration as a Proposed Standard

Jul 2011    Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the
            IESG for consideration as a Proposed Standard

Aug 2011    Submit 'HTTP Authentication: MAC Authentication' to the
            IESG for consideration as a Proposed Standard

Oct 2011    Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for
            OAuth 2.0' to the IESG for consideration as a Proposed 
            Standard

Oct 2011    Re-chartering working group


From eran@hueniverse.com  Tue Jun 14 11:07:19 2011
Return-Path: 
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 328DC21F84FF for ; Tue, 14 Jun 2011 11:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFpXSfFZ1QKD for ; Tue, 14 Jun 2011 11:07:18 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7F1D721F8495 for ; Tue, 14 Jun 2011 11:07:18 -0700 (PDT)
Received: (qmail 7961 invoked from network); 14 Jun 2011 18:07:18 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2011 18:07:17 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 14 Jun 2011 11:07:13 -0700
From: Eran Hammer-Lahav 
To: Adam Barth , "Manger, James H" 
Date: Tue, 14 Jun 2011 11:06:54 -0700
Thread-Topic: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqtV8PsbK7w93mR6a7bIH6yaYxlwACGJ1w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jun 2011 18:07:19 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Adam Barth
> Sent: Tuesday, June 14, 2011 10:05 AM
> To: Manger, James H
> Cc: oauth
> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>=20
> On Tue, Jun 14, 2011 at 7:25 AM, Manger, James H
>  wrote:
> >>> There have been suggestions that the MAC calculation could/should
> >>> cover the key id. In that situation it is even more crucial that the
> >>> id field isn't just a name referring to the real value elsewhere -
> >>> as then the security changes based on the syntax used to issue the
> credentials.
> >
> >>What suggestions? We could not come up with any reason to include the
> key identifier in the >normalized string.
> >
> > Adam Barth said "one possibility is to include the value of the Cookie
> > header in the MAC". That was in response to Robert Sayre's suggestion
> > of a server-provided nonce ("opaque" parameter) that would be covered
> > by the MAC, which Adam said could go into the key id. Adam did go on
> > to say he hadn't seen much demand for this feature from site operators
> > he has talked to.
> > [http://www.ietf.org/mail-archive/web/oauth/current/msg06631.html]
> >
> > So not a complete suggestion with proposed text for the spec -- just a =
hint
> that it was a possible design. HTTP Digest signs the username, for instan=
ce. I
> don't have a specific reason to sign the key id. I don't think it would b=
e
> harmful. Perhaps it could help where the key id is actually a combination=
 of
> complicated assertions (eg SAML) by giving a bit more protection against
> attacks that modify the Authorization header. Various PKI specs include a
> cert id in the data they sign, purportedly for security/legal reasons.
> >
> > The point was that an id field that is sometimes the key id, but at oth=
er
> times just a pointer to the key id (with no indication of which mode is i=
n use),
> does not feel like a good design -- at least not until I understand the
> compelling reason for keeping the Cookie header when using MAC with
> Cookie-issued credentials.
>=20
> Oh, we'd put that in the ext field because it's specific to the Cookie
> instantiating of the protocol.  If you're using a SAML or whatever other
> instantiation of the protocol, you'll want to put that stuff in the ext f=
ield
> rather than cluttering up the base protocol.
>=20
> > Adam provides an ok argument for why tacking MAC-... attributes on to
> > an existing cookie will be the simplest implementation choice.
> > (Thanks)
> >
> >>Most folks who run web sites use cookies to generate sessions. =A0These
> >>folks will layer the MAC protections on top of their existing systems
> >>by adding a couple cookie attributes and verifying an HMAC. =A0If we
> >>removed the MAC cookie from the Cookie header, the Cookie header
> would
> >>be different in supporting and legacy user agents, causing pain and
> >>misery.
> >>
> >>It might be instructive to try using MAC in a real deployment. =A0You'l=
l
> >>see immediately why this behavior is preferable.
> >
> > Perhaps omitting the id parameter from the Authorization header would
> be an even better approach than using the cookie name. It avoids that min=
or
> repetition, and is an unambiguous signal that the key id comes from
> elsewhere (ie from a cookie value).
>=20
> Yeah, I've often wondered whether we should remove the id parameter
> from the Authorization header.  My understanding is that it plays some
> important role in the OAuth instantiation of the protocol.  There's also =
the
> question about what to do when you have multiple cookies with MAC
> attributes.  In that case, having the id to disambiguate seems useful.

With OAuth 2.0, the id is the access token. With cookies, it makes it clear=
 which MAC cookie is being used. It's required.

EHL

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

From recordond@gmail.com  Tue Jun 14 18:30:18 2011
Return-Path: 
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 BE68A1F0C55 for ; Tue, 14 Jun 2011 18:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LAWAtlhH7q7 for ; Tue, 14 Jun 2011 18:30:17 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3911F0C52 for ; Tue, 14 Jun 2011 18:30:17 -0700 (PDT)
Received: by vws12 with SMTP id 12so7118352vws.31 for ; Tue, 14 Jun 2011 18:30:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VFSHc25xSxLi2wfOAokOvt8CFoEFa37BElS20xieur8=; b=Eo59xz5Q1pb37BViD+jvVhk8KJQZynxig/jSMETsxmMe80N3QnYPYQEt/o2yU9ZoU7 drUh1IBAvx3R0EZj+s2Zwm3Y2r64OW59yrMxEIjim57OgGCI6dJXt9Z0hHuwK5wJfoHy rtlHiX9QUDQOOshxgjd9J6lSYkcEaMVkc/eAI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fTX/hWSA/tqeTDSop6QUG4Dl7z6kQ6h9YA6Uf2uK8/2WP7+vxGDfmYoNMg4IWDODIX S8nW3yiC3bHth+EB5Vf3xduSn88+4ysNkbOze9XmituCR2LDMrQPScHH8jDC7e4OOPXt yTrz6lcBkvt4ghuDwjb169lr/ne/5xpYOh0zE=
MIME-Version: 1.0
Received: by 10.52.101.195 with SMTP id fi3mr741906vdb.156.1308101415276; Tue, 14 Jun 2011 18:30:15 -0700 (PDT)
Received: by 10.52.162.195 with HTTP; Tue, 14 Jun 2011 18:30:15 -0700 (PDT)
In-Reply-To: <4DF77A50.8080403@dehora.net>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>   <4DF206E7.3040401@aol.com> <90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net> <4DF21800.9090302@aol.com> <133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>  <4DF77A50.8080403@dehora.net>
Date: Tue, 14 Jun 2011 18:30:15 -0700
Message-ID: 
From: David Recordon 
To: Bill 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 01:30:18 -0000

Bearer token doesn't exist within the core spec around getting an
access token. The term that is used is "access token".


On Tue, Jun 14, 2011 at 8:12 AM, Bill  wrote:
> On 10/06/11 17:45, David Recordon wrote:
>>
>> I think it's vital to have the GET and POST parameters make sense to
>> every developer. I worry less about the authorization header since a
>> developer implementing it will honestly be a stronger engineer.
>
> I agree with David regardless of engineering strength, this is going to b=
e
> confusing to developers. Also tho', devs are exposed to the access token
> response, not just the GET/POST bits. So ideally syntax would line up wit=
h
> how the token is obtained
> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.1 and not jus=
t
> across requests using the token.
>
> A possible clarifying change is to use something like "bearer_token" end =
to
> end.
>
> [[[
> {
> =A0 =A0 =A0 "access_token":"vF9dft4qmT",
> =A0 =A0 =A0 "token_type":"bearer_token", /* ? */
> ...
> }
>
>
> GET /resource HTTP/1.1
> Host: server.example.com
> Authorization: bearer_token vF9dft4qmT
>
>
> GET /resource?bearer_token=3DvF9dft4qmT&...
> Host: server.example.com
>
>
> POST /resource
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
>
> &bearer_token=3DvF9dft4qmT&...
>
>
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: bearer_token realm=3D"example"
> ]]]
>
>
> Bill
>
>
>> Here's what I said earlier in the thread about my motivation:
>>>
>>> Did a full read through of draft 16 and the bear token spec with Paul
>>> yesterday afternoon in order to do a manual diff from draft 10. The
>>> point Doug raised was actually confusing. Throughout the core spec
>>> it's referred to as access_token but then becomes bearer_token upon
>>> use.
>>>
>>> Just thinking through this from a developer documentation perspective,
>>> it's going to become confusing. Developer documentation focuses on
>>> getting an access token and then using that access token to interact
>>> with an API. Thus the code you're writing as a client developer will
>>> use variables, cache keys, and database columns named `access_token`.
>>> But then when you're going to use it, you'll need to put this access
>>> token into a field named bearer_token.
>>>
>>> Feels quite a bit simpler to just name it access_token. Realize the
>>> core spec never did this since we didn't want to trample on protected
>>> resources which might already have a different type of access_token
>>> parameter. oauth_token was a good compromise since developers would
>>> already know that they were using OAuth and thus a new term wasn't
>>> being introduced. That's no longer true with bearer_token since 99% of
>>> developers will have never heard of a bearer token.
>>>
>>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>>> Bearer Tokens are a Terrible Idea" and there isn't a single result on
>>> the first page which explains what they are. Binging for "bearer
>>> token" is equally scary.
>>
>> --David
>>
>>
>> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp =A0wrote:
>>>
>>> George,
>>>
>>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>>
>>>> I definitely don't want to change the Authorization header naming
>>>> scheme. I believe it should stay 'Bearer' because that's what the toke=
n is.
>>>> We could make it...
>>>>
>>>> Authorization: Bearer access_token=3DvF9dft4qmT
>>>>
>>>> If that helps with consistency.
>>>
>>> Well, it might seem more consistent, but I'm not sure it's worthwhile t=
o
>>> make the change just for that reason.
>>>
>>> Is it possible that the Bearer HTTP mechanism would ever take multiple
>>> parameters? In which case, having the ability to name the parameters of=
 the
>>> Bearer mechanism might become more interesting.
>>>
>>> - John
>>>
>>>> I don't think we should be associating the term 'access_token' with th=
e
>>>> bearer security mechanism.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 6/10/11 8:35 AM, John Kemp wrote:
>>>>>
>>>>> What does this mean for the HTTP Authorization header naming scheme f=
or
>>>>> bearer tokens?
>>>>>
>>>>> As I understand this decision, we are discussing whether to standardi=
ze
>>>>> on the name "access_token" when a bearer token is sent as either a UR=
L query
>>>>> parameter, or in a form POSTed body?
>>>>>
>>>>> Currently the HTTP Authorization header looks like this (from
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>>>> ):
>>>>>
>>>>> GET /resource HTTP/1.1
>>>>> Host: server.example.com
>>>>> Authorization: Bearer vF9dft4qmT
>>>>>
>>>>> Is the proposal then that we have:
>>>>>
>>>>> 1. GET /resource?access_token=3DvF9dft4qmT
>>>>> 2. POST /resource
>>>>>
>>>>> access_token=3DvF9dft4qmT&...
>>>>>
>>>>> 3.
>>>>>
>>>>> GET /resource HTTP/1.1
>>>>> Host: server.example.com
>>>>> Authorization: access_token vF9dft4qmT
>>>>>
>>>>> Can someone actually give the details of the proposal, or
>>>>> agree/disagree with the examples above?
>>>>>
>>>>> - John
>>>>>
>>>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>>>
>>>>>
>>>>>> Yes, that's fine with me.
>>>>>>
>>>>>> Thanks,
>>>>>> George
>>>>>>
>>>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>>>
>>>>>>> George, Doug and Eran are you alright with the Bearer token spec
>>>>>>> using
>>>>>>> the parameter name "access_token" as well?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike
>>>>>>>> Jones
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> If you can drive a consensus decision for the name "access_token"=
,
>>>>>>>>> I'd be glad to change the name in the spec. =A0I agree that the c=
urrent names
>>>>>>>>> are confusing for developers.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> At Google we are getting the same feedback, that it is confusing f=
or
>>>>>>>> developers. It would definitely help if we could change the name t=
o
>>>>>>>> "access_token".
>>>>>>>>
>>>>>>>> Marius
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>

From James.H.Manger@team.telstra.com  Tue Jun 14 19:06:20 2011
Return-Path: 
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 322551F0C52 for ; Tue, 14 Jun 2011 19:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH5iB1l5drvA for ; Tue, 14 Jun 2011 19:06:19 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2E91F0C4F for ; Tue, 14 Jun 2011 19:06:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,368,1304258400"; d="scan'208";a="36433123"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 12:06:17 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6377"; a="28963255"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 12:06:17 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 15 Jun 2011 12:06:16 +1000
From: "Manger, James H" 
To: oauth 
Date: Wed, 15 Jun 2011 12:06:15 +1000
Thread-Topic: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqtV8PsbK7w93mR6a7bIH6yaYxlwACGJ1wAA++2SA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 02:06:20 -0000

>>> Perhaps omitting the id parameter from the Authorization header
>>> would be an even better approach [when a cookie provides the key id]

>> Yeah, I've often wondered whether we should remove the id parameter
>> from the Authorization header.  My understanding is that it plays some
>> important role in the OAuth instantiation of the protocol.  There's also=
 the
>> question about what to do when you have multiple cookies with MAC
>> attributes.  In that case, having the id to disambiguate seems useful.

> With OAuth 2.0, the id is the access token. With cookies, it makes it cle=
ar which MAC cookie is > > being used. It's required.

How does the server know if a particular request with a "Authorization: MAC=
 ..." header is using credentials from OAuth 2.0 or from Set-Cookie?

P.S. id=3D is not ideal for indicating which MAC cookie is bei=
ng used as there can be multiple cookies with the same cookie-name (eg set =
from sibling domains).

--
James Manger

From eran@hueniverse.com  Tue Jun 14 22:00:52 2011
Return-Path: 
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 8A0D321F8447 for ; Tue, 14 Jun 2011 22:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR-+QDJBHWiN for ; Tue, 14 Jun 2011 22:00:52 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E35D621F8443 for ; Tue, 14 Jun 2011 22:00:51 -0700 (PDT)
Received: (qmail 21082 invoked from network); 15 Jun 2011 05:00:50 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 05:00:50 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 14 Jun 2011 22:00:50 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , oauth 
Date: Tue, 14 Jun 2011 22:00:30 -0700
Thread-Topic: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqtV8PsbK7w93mR6a7bIH6yaYxlwACGJ1wAA++2SAABxUs4A==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 05:00:52 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Tuesday, June 14, 2011 7:06 PM
> To: oauth
> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>=20
> >>> Perhaps omitting the id parameter from the Authorization header
> >>> would be an even better approach [when a cookie provides the key id]
>=20
> >> Yeah, I've often wondered whether we should remove the id parameter
> >> from the Authorization header.  My understanding is that it plays
> >> some important role in the OAuth instantiation of the protocol.
> >> There's also the question about what to do when you have multiple
> >> cookies with MAC attributes.  In that case, having the id to disambigu=
ate
> seems useful.
>=20
> > With OAuth 2.0, the id is the access token. With cookies, it makes it c=
lear
> which MAC cookie is > > being used. It's required.
>=20
> How does the server know if a particular request with a "Authorization: M=
AC
> ..." header is using credentials from OAuth 2.0 or from Set-Cookie?

This should be pretty easy to resolve with a common-sense deployment and ke=
y identifiers.

> P.S. id=3D is not ideal for indicating which MAC cookie is b=
eing
> used as there can be multiple cookies with the same cookie-name (eg set
> from sibling domains).

I'll let Adam answer that.

EHL

> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From James.H.Manger@team.telstra.com  Tue Jun 14 22:39:44 2011
Return-Path: 
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 AF15C11E80AB for ; Tue, 14 Jun 2011 22:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opWrv1HiXBcE for ; Tue, 14 Jun 2011 22:39:43 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 45B4122800F for ; Tue, 14 Jun 2011 22:39:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,369,1304258400"; d="scan'208";a="35958336"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 15:39:38 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6377"; a="28938004"
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 15:39:33 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 15 Jun 2011 15:39:25 +1000
From: "Manger, James H" 
To: Eran Hammer-Lahav , oauth 
Date: Wed, 15 Jun 2011 15:39:24 +1000
Thread-Topic: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqtV8PsbK7w93mR6a7bIH6yaYxlwACGJ1wAA++2SAABxUs4AAAxFIg
Message-ID: <255B9BB34FB7D647A506DC292726F6E112869611EF@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 05:39:44 -0000

>> How does the server know if a particular request with a "Authorization: =
MAC
>> ..." header is using credentials from OAuth 2.0 or from Set-Cookie?

> This should be pretty easy to resolve with a common-sense deployment and =
key identifiers.

You are right, Eran. Though putting a cookie-name in a key id field is a bi=
t hacky, in practice a server can work this out with a little bit of code, =
perhaps a little config, and a little bit of sense choosing names.

I withdraw my suggestion for using the cookie-value as the key id.

--
James Manger


From eran@hueniverse.com  Tue Jun 14 22:48:27 2011
Return-Path: 
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 6D49E21F8454 for ; Tue, 14 Jun 2011 22:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6onR6cTZ+Yrg for ; Tue, 14 Jun 2011 22:48:27 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E2E9F21F8453 for ; Tue, 14 Jun 2011 22:48:26 -0700 (PDT)
Received: (qmail 17858 invoked from network); 15 Jun 2011 05:48:25 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 05:48:25 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 14 Jun 2011 22:48:25 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , oauth 
Date: Tue, 14 Jun 2011 22:48:07 -0700
Thread-Topic: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqtV8PsbK7w93mR6a7bIH6yaYxlwACGJ1wAA++2SAABxUs4AAAxFIgAADiExA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E9869EB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112869611EF@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112869611EF@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 05:48:27 -0000

This whole cookie thing is a 'a bit hacky'... that's part of what we're wor=
king with... :-)

EHL

> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Tuesday, June 14, 2011 10:39 PM
> To: Eran Hammer-Lahav; oauth
> Subject: RE: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>=20
> >> How does the server know if a particular request with a
> >> "Authorization: MAC ..." header is using credentials from OAuth 2.0 or
> from Set-Cookie?
>=20
> > This should be pretty easy to resolve with a common-sense deployment
> and key identifiers.
>=20
> You are right, Eran. Though putting a cookie-name in a key id field is a =
bit
> hacky, in practice a server can work this out with a little bit of code, =
perhaps a
> little config, and a little bit of sense choosing names.
>=20
> I withdraw my suggestion for using the cookie-value as the key id.
>=20
> --
> James Manger


From ietf@adambarth.com  Tue Jun 14 23:31:18 2011
Return-Path: 
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 9188F11E80A1 for ; Tue, 14 Jun 2011 23:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Level: 
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNCBouteKEbl for ; Tue, 14 Jun 2011 23:31:17 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5511E8096 for ; Tue, 14 Jun 2011 23:31:17 -0700 (PDT)
Received: by yie30 with SMTP id 30so82412yie.31 for ; Tue, 14 Jun 2011 23:31:17 -0700 (PDT)
Received: by 10.101.28.33 with SMTP id f33mr145048anj.36.1308119477085; Tue, 14 Jun 2011 23:31:17 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id r10sm136229anh.28.2011.06.14.23.31.15 (version=SSLv3 cipher=OTHER); Tue, 14 Jun 2011 23:31:15 -0700 (PDT)
Received: by ywp31 with SMTP id 31so81514ywp.31 for ; Tue, 14 Jun 2011 23:31:15 -0700 (PDT)
Received: by 10.91.156.10 with SMTP id i10mr378904ago.67.1308119475235; Tue, 14 Jun 2011 23:31:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Tue, 14 Jun 2011 23:30:45 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E112868E56E3@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E7747B3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112868E5D71@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E9869E9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Adam Barth 
Date: Tue, 14 Jun 2011 23:30:45 -0700
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
Cc: oauth 
Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 06:31:18 -0000

On Tue, Jun 14, 2011 at 10:00 PM, Eran Hammer-Lahav  wrote:
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Manger, James H
>> Sent: Tuesday, June 14, 2011 7:06 PM
>> To: oauth
>> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
>>
>> P.S. id= is not ideal for indicating which MAC cookie is being
>> used as there can be multiple cookies with the same cookie-name (eg set
>> from sibling domains).
>
> I'll let Adam answer that.

Yeah, that's a corner case that sucks.  Turns out cookie suck in a lot
of ways like that.  :)

Adam

From James.H.Manger@team.telstra.com  Wed Jun 15 00:07:56 2011
Return-Path: 
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 7C62B11E8096 for ; Wed, 15 Jun 2011 00:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDQIvrG3NtbF for ; Wed, 15 Jun 2011 00:07:55 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A995611E8074 for ; Wed, 15 Jun 2011 00:07:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,369,1304258400"; d="scan'208,217";a="38131404"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 17:07:49 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6377"; a="28906912"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 17:07:49 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 15 Jun 2011 17:07:48 +1000
From: "Manger, James H" 
To: oauth 
Date: Wed, 15 Jun 2011 17:07:46 +1000
Thread-Topic: MAC: creation-time when a cookie is renewed
Thread-Index: AcwrKu36mUVVJEeMR/OCcKdO42HGTQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E11286961435@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11286961435WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [OAUTH-WG] MAC: creation-time when a cookie is renewed
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 07:07:56 -0000

--_000_255B9BB34FB7D647A506DC292726F6E11286961435WSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The MAC scheme's cookie mode [draft-ietf-oauth-v2-http-mac-00, section 6] s=
ays the cookie's creation-time is used to determine the age that goes in th=
e nonce in a request. The creation-time is the time the client receives the=
 Set-Cookie response - unless the client already has a cookie with the same=
 name, domain, and path, in which case the creation-time of the existing co=
okie is kept [rfc6265 HTTP state management mechanism, section 5.3, step 11=
.3].



Is this going to cause complications in practice?

A server will need to know if a client has an existing cookie before issuin=
g a new one. That should be possible as the old cookie will be included in =
the request whose response contains the Set-Cookie header for the new cooki=
e.



There are some corner cases, such as an old cookie that expires after being=
 sent to the server, but before the new cookie is returned. Perhaps they ar=
e rare enough to ignore.



If a server crashes then reboots (loosing in-memory details about old cooki=
es) it cannot just issue new cookies. First it needs to issue an expired co=
okie to clear the client's cookie store (deleting the old cookie that has a=
 creation-time that the server no longer knows), then issue a new cookie wi=
th a known creation-time. That sounds painful (ie will not be implemented i=
nitially, but will eventually cause a nasty outage).



It might encourage people to tack the creation-time into the cookie-value. =
Do that without integrity protection, however, and you are open to replay a=
ttacks.



--

James Manger




--_000_255B9BB34FB7D647A506DC292726F6E11286961435WSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The MAC scheme’s cookie mode [draft-ietf-oauth=
-v2-http-mac-00, section 6] says the cookie’s creation-time is used t=
o determine the age that goes in the nonce in a request. The creation-time =
is the time the client receives the Set-Cookie
 response – unless the client already has a cookie with the same name=
, domain, and path, in which case the creation-time of the existing cookie =
is kept [rfc6265 HTTP state management mechanism, section 5.3, step 11.3].<=
o:p>


 


Is this going to cause complications in practice?


A server will need to know if a client has an existi=
ng cookie before issuing a new one. That should be possible as the old cook=
ie will be included in the request whose response contains the Set-Cookie h=
eader for the new cookie.


 


There are some corner cases, such as an old cookie t=
hat expires after being sent to the server, but before the new cookie is re=
turned. Perhaps they are rare enough to ignore.


 


If a server crashes then reboots (loosing in-memory =
details about old cookies) it cannot just issue new cookies. First it needs=
 to issue an expired cookie to clear the client’s cookie store (delet=
ing the old cookie that has a creation-time
 that the server no longer knows), then issue a new cookie with a known cre=
ation-time. That sounds painful (ie will not be implemented initially, but =
will eventually cause a nasty outage).


 


It might encourage people to tack the creation-time =
into the cookie-value. Do that without integrity protection, however, and y=
ou are open to replay attacks.


 


--


James Manger


 






--_000_255B9BB34FB7D647A506DC292726F6E11286961435WSMSG3153Vsrv_--

From ietf@adambarth.com  Wed Jun 15 00:16:08 2011
Return-Path: 
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 553CD21F84B2 for ; Wed, 15 Jun 2011 00:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsMub3M1bsTJ for ; Wed, 15 Jun 2011 00:16:07 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5B21F84AE for ; Wed, 15 Jun 2011 00:16:06 -0700 (PDT)
Received: by yxt33 with SMTP id 33so123790yxt.31 for ; Wed, 15 Jun 2011 00:16:05 -0700 (PDT)
Received: by 10.236.66.17 with SMTP id g17mr272912yhd.106.1308122165589; Wed, 15 Jun 2011 00:16:05 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id 1sm84033yhs.81.2011.06.15.00.16.04 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 00:16:04 -0700 (PDT)
Received: by gxk19 with SMTP id 19so102551gxk.31 for ; Wed, 15 Jun 2011 00:16:04 -0700 (PDT)
Received: by 10.90.197.15 with SMTP id u15mr405595agf.148.1308122164090; Wed, 15 Jun 2011 00:16:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Wed, 15 Jun 2011 00:15:34 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11286961435@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E11286961435@WSMSG3153V.srv.dir.telstra.com>
From: Adam Barth 
Date: Wed, 15 Jun 2011 00:15:34 -0700
Message-ID: 
To: "Manger, James H" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] MAC: creation-time when a cookie is renewed
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 07:16:08 -0000

These problems all seem sovled with the new definition of age to not
be necessarily related to time.

Adam


On Wed, Jun 15, 2011 at 12:07 AM, Manger, James H
 wrote:
> The MAC scheme=92s cookie mode [draft-ietf-oauth-v2-http-mac-00, section =
6]
> says the cookie=92s creation-time is used to determine the age that goes =
in
> the nonce in a request. The creation-time is the time the client receives
> the Set-Cookie response =96 unless the client already has a cookie with t=
he
> same name, domain, and path, in which case the creation-time of the exist=
ing
> cookie is kept [rfc6265 HTTP state management mechanism, section 5.3, ste=
p
> 11.3].
>
> Is this going to cause complications in practice?
>
> A server will need to know if a client has an existing cookie before issu=
ing
> a new one. That should be possible as the old cookie will be included in =
the
> request whose response contains the Set-Cookie header for the new cookie.
>
> There are some corner cases, such as an old cookie that expires after bei=
ng
> sent to the server, but before the new cookie is returned. Perhaps they a=
re
> rare enough to ignore.
>
> If a server crashes then reboots (loosing in-memory details about old
> cookies) it cannot just issue new cookies. First it needs to issue an
> expired cookie to clear the client=92s cookie store (deleting the old coo=
kie
> that has a creation-time that the server no longer knows), then issue a n=
ew
> cookie with a known creation-time. That sounds painful (ie will not be
> implemented initially, but will eventually cause a nasty outage).
>
>
>
> It might encourage people to tack the creation-time into the cookie-value=
.
> Do that without integrity protection, however, and you are open to replay
> attacks.
>
>
>
> --
>
> James Manger
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

From bill@dehora.net  Wed Jun 15 01:46:11 2011
Return-Path: 
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 D944611E807A for ; Wed, 15 Jun 2011 01:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgfP4OKfknk1 for ; Wed, 15 Jun 2011 01:46:11 -0700 (PDT)
Received: from chilco.textdrive.com (mail.indigozen.co.uk [207.7.108.242]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3C11E8074 for ; Wed, 15 Jun 2011 01:46:10 -0700 (PDT)
Received: from [192.168.3.18] (87-198-172-217.static.ptr.magnet.ie [87.198.172.217]) by chilco.textdrive.com (Postfix) with ESMTP id 4F20EE0329; Wed, 15 Jun 2011 08:46:09 +0000 (UTC)
Message-ID: <4DF8714D.7090601@dehora.net>
Date: Wed, 15 Jun 2011 09:46:05 +0100
From: Bill 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: David Recordon 
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>			<4DF206E7.3040401@aol.com>	<90662920-6576-4DA7-B6B6-80C83FDB1E15@jkemp.net>	<4DF21800.9090302@aol.com>	<133A769C-7B4F-4C36-BDCC-E1D4CAB8D256@jkemp.net>		<4DF77A50.8080403@dehora.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 08:46:12 -0000

On 15/06/11 02:30, David Recordon wrote:
> Bearer token doesn't exist within the core spec around getting an
> access token. The term that is used is "access token".

Right, I get that Bearer is defined in another draft document (which the 
core spec references and probably should not btw, that's confusing as well)

 >> "access_token":"vF9dft4qmT",
 >> "token_type":"Bearer"

I was referring to bearer token wrt token_type. The above is how I 
understand one will be supplied.

Bill

>
>
> On Tue, Jun 14, 2011 at 8:12 AM, Bill  wrote:
>> On 10/06/11 17:45, David Recordon wrote:
>>>
>>> I think it's vital to have the GET and POST parameters make sense to
>>> every developer. I worry less about the authorization header since a
>>> developer implementing it will honestly be a stronger engineer.
>>
>> I agree with David regardless of engineering strength, this is going to be
>> confusing to developers. Also tho', devs are exposed to the access token
>> response, not just the GET/POST bits. So ideally syntax would line up with
>> how the token is obtained
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.1 and not just
>> across requests using the token.
>>
>> A possible clarifying change is to use something like "bearer_token" end to
>> end.
>>
>> [[[
>> {
>>        "access_token":"vF9dft4qmT",
>>        "token_type":"bearer_token", /* ? */
>> ...
>> }
>>
>>
>> GET /resource HTTP/1.1
>> Host: server.example.com
>> Authorization: bearer_token vF9dft4qmT
>>
>>
>> GET /resource?bearer_token=vF9dft4qmT&...
>> Host: server.example.com
>>
>>
>> POST /resource
>> Host: server.example.com
>> Content-Type: application/x-www-form-urlencoded
>>
>> &bearer_token=vF9dft4qmT&...
>>
>>
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: bearer_token realm="example"
>> ]]]
>>
>>
>> Bill
>>
>>
>>> Here's what I said earlier in the thread about my motivation:
>>>>
>>>> Did a full read through of draft 16 and the bear token spec with Paul
>>>> yesterday afternoon in order to do a manual diff from draft 10. The
>>>> point Doug raised was actually confusing. Throughout the core spec
>>>> it's referred to as access_token but then becomes bearer_token upon
>>>> use.
>>>>
>>>> Just thinking through this from a developer documentation perspective,
>>>> it's going to become confusing. Developer documentation focuses on
>>>> getting an access token and then using that access token to interact
>>>> with an API. Thus the code you're writing as a client developer will
>>>> use variables, cache keys, and database columns named `access_token`.
>>>> But then when you're going to use it, you'll need to put this access
>>>> token into a field named bearer_token.
>>>>
>>>> Feels quite a bit simpler to just name it access_token. Realize the
>>>> core spec never did this since we didn't want to trample on protected
>>>> resources which might already have a different type of access_token
>>>> parameter. oauth_token was a good compromise since developers would
>>>> already know that they were using OAuth and thus a new term wasn't
>>>> being introduced. That's no longer true with bearer_token since 99% of
>>>> developers will have never heard of a bearer token.
>>>>
>>>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>>>> Bearer Tokens are a Terrible Idea" and there isn't a single result on
>>>> the first page which explains what they are. Binging for "bearer
>>>> token" is equally scary.
>>>
>>> --David
>>>
>>>
>>> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp    wrote:
>>>>
>>>> George,
>>>>
>>>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>>>
>>>>> I definitely don't want to change the Authorization header naming
>>>>> scheme. I believe it should stay 'Bearer' because that's what the token is.
>>>>> We could make it...
>>>>>
>>>>> Authorization: Bearer access_token=vF9dft4qmT
>>>>>
>>>>> If that helps with consistency.
>>>>
>>>> Well, it might seem more consistent, but I'm not sure it's worthwhile to
>>>> make the change just for that reason.
>>>>
>>>> Is it possible that the Bearer HTTP mechanism would ever take multiple
>>>> parameters? In which case, having the ability to name the parameters of the
>>>> Bearer mechanism might become more interesting.
>>>>
>>>> - John
>>>>
>>>>> I don't think we should be associating the term 'access_token' with the
>>>>> bearer security mechanism.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 6/10/11 8:35 AM, John Kemp wrote:
>>>>>>
>>>>>> What does this mean for the HTTP Authorization header naming scheme for
>>>>>> bearer tokens?
>>>>>>
>>>>>> As I understand this decision, we are discussing whether to standardize
>>>>>> on the name "access_token" when a bearer token is sent as either a URL query
>>>>>> parameter, or in a form POSTed body?
>>>>>>
>>>>>> Currently the HTTP Authorization header looks like this (from
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>>>>> ):
>>>>>>
>>>>>> GET /resource HTTP/1.1
>>>>>> Host: server.example.com
>>>>>> Authorization: Bearer vF9dft4qmT
>>>>>>
>>>>>> Is the proposal then that we have:
>>>>>>
>>>>>> 1. GET /resource?access_token=vF9dft4qmT
>>>>>> 2. POST /resource
>>>>>>
>>>>>> access_token=vF9dft4qmT&...
>>>>>>
>>>>>> 3.
>>>>>>
>>>>>> GET /resource HTTP/1.1
>>>>>> Host: server.example.com
>>>>>> Authorization: access_token vF9dft4qmT
>>>>>>
>>>>>> Can someone actually give the details of the proposal, or
>>>>>> agree/disagree with the examples above?
>>>>>>
>>>>>> - John
>>>>>>
>>>>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>>>>
>>>>>>
>>>>>>> Yes, that's fine with me.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> George
>>>>>>>
>>>>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>>>>
>>>>>>>> George, Doug and Eran are you alright with the Bearer token spec
>>>>>>>> using
>>>>>>>> the parameter name "access_token" as well?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike
>>>>>>>>> Jones
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If you can drive a consensus decision for the name "access_token",
>>>>>>>>>> I'd be glad to change the name in the spec.  I agree that the current names
>>>>>>>>>> are confusing for developers.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> At Google we are getting the same feedback, that it is confusing for
>>>>>>>>> developers. It would definitely help if we could change the name to
>>>>>>>>> "access_token".
>>>>>>>>>
>>>>>>>>> Marius
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>


From tdb2@ecs.soton.ac.uk  Wed Jun 15 05:41:52 2011
Return-Path: 
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 85A6621F84FE for ; Wed, 15 Jun 2011 05:41:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXNSOaZPWGW2 for ; Wed, 15 Jun 2011 05:41:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A221F84FC for ; Wed, 15 Jun 2011 05:41:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5FCfn8v023933 for ; Wed, 15 Jun 2011 13:41:49 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5FCfn8v023933
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308141709; bh=Mx+6m7bRWjJQAU+Lh2oYOkeRxc8=; h=Subject:From:To:Date:Mime-Version:References; b=RYGLIpJ+G3UsIUcghFC7eAMQF0uhIvhp9rnmsbONuSmq3t9D4OVQMytUMSwQ9OOMB AMUNFQlBEEZO6ygLf1T6HA8ioxMOgmmVMBW0nuWS+r4F90DYKHh+TPoJzdZIJ56SS0 ClDJthzcng/Et9c/1AZkQN9oSZoNGBtv0uJNSlHQ=
Received: from imap.ecs.soton.ac.uk (imap.ecs.soton.ac.uk [2001:630:d0:f102:21e:c9ff:fee7:83c0]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP id n5EDfn0521312074Z6 ret-id none; Wed, 15 Jun 2011 13:41:49 +0100
Received: from [IPv6:2001:630:d0:f111:230:48ff:fed6:4e94] ([IPv6:2001:630:d0:f111:230:48ff:fed6:4e94]) (authenticated bits=0) by imap.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5FCfh3I030073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2011 13:41:44 +0100
From: Tim Brody 
To: oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 15 Jun 2011 13:41:43 +0100
Message-ID: 
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n5EDfn052131207400; tid=n5EDfn0521312074Z6; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p5FCfn8v023933
X-ECS-MailScanner-From: tdb2@ecs.soton.ac.uk
Subject: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 12:41:52 -0000

Hi All,

I'm the author of this Perl library for signing OAuth 1.0 requests:
http://search.cpan.org/~timbrody/LWP-Authen-OAuth-1.01/

I've been asked about OAuth 2.0 so have scanned through the spec and
joined this list :-)


The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP
library that can talk 1.0 or 1.1. I make an HTTP request with URI + form
parameters + extra headers - I don't know if the "Host:" header will
exist. So, can you just refer to the "hostname" and "port"? (Whether
they are in the URI or a Host: header seems orthogonal to OAuth anyway?)


Why do you POST application/x-www-form-urlencoded but get
application/json?

I couldn't find a conclusion to the May 2010 discussions about using
x-www-form-urlencoded vs. json nor a rationale in the spec for using
JSON. Why do I need to add a JSON lexer/parser to my library just to get
key-value pairs that can be represented by form-urlencoded?


All the best,
Tim.


From eran@hueniverse.com  Wed Jun 15 08:32:10 2011
Return-Path: 
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 6D64511E8158 for ; Wed, 15 Jun 2011 08:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRDSY2Pi4gXa for ; Wed, 15 Jun 2011 08:32:09 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 83A8511E8137 for ; Wed, 15 Jun 2011 08:32:09 -0700 (PDT)
Received: (qmail 27868 invoked from network); 15 Jun 2011 15:32:07 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 15:32:02 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 08:31:59 -0700
From: Eran Hammer-Lahav 
To: Tim Brody , "oauth@ietf.org" 
Date: Wed, 15 Jun 2011 08:31:39 -0700
Thread-Topic: [OAUTH-WG] HTTP/1.0 and JSON
Thread-Index: AcwrWaKurOtWm9RvT36fBNvWevstOwAFzpoQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986A8B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 15:32:10 -0000

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tim Brody
> Sent: Wednesday, June 15, 2011 5:42 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] HTTP/1.0 and JSON
>=20
> Hi All,
>=20
> I'm the author of this Perl library for signing OAuth 1.0 requests:
> http://search.cpan.org/~timbrody/LWP-Authen-OAuth-1.01/
>=20
> I've been asked about OAuth 2.0 so have scanned through the spec and
> joined this list :-)
>=20
>=20
> The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP li=
brary
> that can talk 1.0 or 1.1. I make an HTTP request with URI + form paramete=
rs +
> extra headers - I don't know if the "Host:" header will exist. So, can yo=
u just
> refer to the "hostname" and "port"? (Whether they are in the URI or a Hos=
t:
> header seems orthogonal to OAuth anyway?)

The MAC draft works on HTTP/1.1 requests. Using it with 1.0 is undefined.

>=20
> Why do you POST application/x-www-form-urlencoded but get
> application/json?

There is a long thread somewhere... But it's the compromise we reached.

> I couldn't find a conclusion to the May 2010 discussions about using x-ww=
w-
> form-urlencoded vs. json nor a rationale in the spec for using JSON. Why =
do I
> need to add a JSON lexer/parser to my library just to get key-value pairs=
 that
> can be represented by form-urlencoded?

Every modern platform has a JSON parser.

EHL
=20
>=20
> All the best,
> Tim.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Wed Jun 15 08:47:22 2011
Return-Path: 
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 A4B0F11E80C7 for ; Wed, 15 Jun 2011 08:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9bJDP-6Hg-V for ; Wed, 15 Jun 2011 08:47:22 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3011E8081 for ; Wed, 15 Jun 2011 08:47:21 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 635EE21B043E; Wed, 15 Jun 2011 11:47:17 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5D86321B0433; Wed, 15 Jun 2011 11:47:17 -0400 (EDT)
Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.159.2; Wed, 15 Jun 2011 11:47:17 -0400
From: Justin Richer 
To: Eran Hammer-Lahav 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986A8B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>  <90C41DD21FB7C64BB94121FBBC2E7234475E986A8B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 15 Jun 2011 11:45:28 -0400
Message-ID: <1308152728.29889.108.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 15:47:22 -0000

> > I couldn't find a conclusion to the May 2010 discussions about using x-www-
> > form-urlencoded vs. json nor a rationale in the spec for using JSON. Why do I
> > need to add a JSON lexer/parser to my library just to get key-value pairs that
> > can be represented by form-urlencoded?
> 
> Every modern platform has a JSON parser.

While JSON is widespread, it is an additional requirement. I've done
some work to define and XML encoding for OAuth tokens here:

  http://tools.ietf.org/html/draft-richer-oauth-xml-00

The draft still needs to be updated to point to the right sections of
the OAuth2 spec, but the mechanics are still valid. 

The point of this is similar to your contention: if I'm already speaking
one wire format (XML), why would I want to deal with JSON just to do my
auth step? 

If you'd like to try defining a key-value encoding, we can publish an
extension draft for that as well.

 -- Justin


From eran@hueniverse.com  Wed Jun 15 09:33:45 2011
Return-Path: 
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 D24C211E812B for ; Wed, 15 Jun 2011 09:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBtzv6oyVAZB for ; Wed, 15 Jun 2011 09:33:45 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A71A811E808D for ; Wed, 15 Jun 2011 09:33:44 -0700 (PDT)
Received: (qmail 16388 invoked from network); 15 Jun 2011 16:33:44 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 16:33:44 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 09:33:38 -0700
From: Eran Hammer-Lahav 
To: Chuck Mortimore , "oauth@ietf.org" 
Date: Wed, 15 Jun 2011 09:33:18 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986ACEP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 16:33:45 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986ACEP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token



--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986ACEP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated text for Native Apps<=
style>
Is there =
an updated text based on the long thread?
 
EHL=

 <=
/p>
From: oauth-bounces@ietf.org [ma=
ilto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent=
: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Sub=
ject: [OAUTH-WG] Updated text for Native Apps
 
Minor updates for section 9 based upon feedback from t=
he list

-cmort

----------------


9.  Native Ap=
plications

A native application is a client which is installed and e=
xecutes on the end-user's device (i.e. desktop application, native mobile a=
pplication).  Native applications require special consideration relate=
d to security, platform capabilities, and overall end-user experience. &nbs=
p;The following are examples of how native applications may utilize OAuth:<=
br>
   o  Initiate an Authorization Request using an=
 external user-agent: The native application can capture the response from =
the authorization server using a variety of techniques such as the use of a=
 redirection URI identifying a custom URI scheme (registered with the opera=
ting system to invoke the native application as handler), manual copy-and-p=
aste, running a local webserver, browser plug-ins, or by providing a redire=
ction URI identifying a server-hosted resource under the native application=
's control, which in turn makes the response available to the native applic=
ation.
   o  Initiate an Authorization Request using=
 an embedded user-agent:  The native application obtains the response =
by directly communicating with the embedded user-agent.  Techniques in=
clude monitoring state changes emitted during URL loading, monitoring http =
headers, accessing the user-agent's cookie jar, etc.

When choosing b=
etween launching an external user-agent and an embedding a user-agent, nati=
ve application developers should consider the following:

  =
; o  External user-agents may improve completion rate as the end-=
user may already have an active session with the authorization server remov=
ing the need to re-authenticate, and provide a familiar user-agent user exp=
erience.  The end-user may also rely on extensions or add-ons to assis=
t with authentication (e.g. password managers or 2-factor device reader).   o  Embedded user-agents may offer an improved end-=
user flow, as they remove the need to switch context and open new windows.&=
nbsp;
   o  Embedded user-agents pose a security cha=
llenge because end-users are authenticating in an unidentified window witho=
ut access to the visual protections offered by many user-agents.  Embe=
dded user-agents educate end-user to trust unidentified requests for authen=
tication (making phishing attacks easier to execute).

When choosing =
between implicit and authorization code grant types, the following should b=
e considered:

   o  Native applications that use=
 the authorization code grant type flow SHOULD do so without client passwor=
d credentials, due to their inability to keep those credentials confidentia=
l.
   o  Native applications that use the implicit g=
rant type may offer optimized performance in some scenarios due to reduced =
network requests
   o  The implicit grant type does =
not return a refresh token  


=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986ACEP3PW5EX1MB01E_--

From tonynad@microsoft.com  Wed Jun 15 10:10:24 2011
Return-Path: 
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 AED0E21F8526 for ; Wed, 15 Jun 2011 10:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level: 
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A40FnMYEikaZ for ; Wed, 15 Jun 2011 10:10:23 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4DECD21F8524 for ; Wed, 15 Jun 2011 10:10:23 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 15 Jun 2011 10:10:11 -0700
Received: from AM1EHSOBE003.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 15 Jun 2011 10:10:10 -0700
Received: from mail117-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 15 Jun 2011 17:10:02 +0000
Received: from mail117-am1 (localhost.localdomain [127.0.0.1])	by mail117-am1-R.bigfish.com (Postfix) with ESMTP id 9EC1111182CE	for ; Wed, 15 Jun 2011 17:10:02 +0000 (UTC)
X-SpamScore: -22
X-BigFish: PS-22(zz9371Mzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail117-am1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail117-am1 (localhost.localdomain [127.0.0.1]) by mail117-am1 (MessageSwitch) id 1308157802120022_1335; Wed, 15 Jun 2011 17:10:02 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.249])	by mail117-am1.bigfish.com (Postfix) with ESMTP id 1738666804B; Wed, 15 Jun 2011 17:10:02 +0000 (UTC)
Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 15 Jun 2011 17:10:01 +0000
Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.97]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.052; Wed, 15 Jun 2011 17:10:00 +0000
From: Anthony Nadalin 
To: Eran Hammer-Lahav , Chuck Mortimore , "oauth@ietf.org" 
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmA=
Date: Wed, 15 Jun 2011 17:09:59 +0000
Message-ID: 
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.28.29.112]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DEC3CH1PRD0302MB115_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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%SALESFORCE.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: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:10:24 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DEC3CH1PRD0302MB115_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token


--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DEC3CH1PRD0302MB115_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





Updated text for Native Apps






Since Torsten and I had t=
he action item to propose text we will update the text based upon the list =
and give you back an update


 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav

Sent: Wednesday, June 15, 2011 9:33 AM

To: Chuck Mortimore; oauth@ietf.org

Subject: Re: [OAUTH-WG] Updated text for Native Apps






 


Is there an updated text =
based on the long thread?


 <=
/p>

EHL


 <=
/p>







From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore

Sent: Tuesday, May 31, 2011 10:37 AM

To: oauth@ietf.org

Subject: [OAUTH-WG] Updated text for Native Apps





 


Minor updates for section=
 9 based upon feedback from the list



-cmort



----------------





9.  Native Applications



A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  =
;Native applications require special consideration related to security, pla=
tform capabilities, and overall end-user
 experience.  The following are examples of how native applications ma=
y utilize OAuth:



   o  Initiate an Authorization Request using an extern=
al user-agent: The native application can capture the response from the aut=
horization server using a variety of techniques such as the use of a redire=
ction URI identifying a custom URI scheme (registered
 with the operating system to invoke the native application as handler), ma=
nual copy-and-paste, running a local webserver, browser plug-ins, or by pro=
viding a redirection URI identifying a server-hosted resource under the nat=
ive application's control, which
 in turn makes the response available to the native application.

   o  Initiate an Authorization Request using an embedd=
ed user-agent:  The native application obtains the response by directl=
y communicating with the embedded user-agent.  Techniques include moni=
toring state changes emitted during URL loading, monitoring http
 headers, accessing the user-agent's cookie jar, etc.



When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:



   o  External user-agents may improve completion rate =
as the end-user may already have an active session with the authorization s=
erver removing the need to re-authenticate, and provide a familiar user-age=
nt user experience.  The end-user may also rely on extensions
 or add-ons to assist with authentication (e.g. password managers or 2-fact=
or device reader).

   o  Embedded user-agents may offer an improved end-us=
er flow, as they remove the need to switch context and open new windows.&nb=
sp;

   o  Embedded user-agents pose a security challenge be=
cause end-users are authenticating in an unidentified window without access=
 to the visual protections offered by many user-agents.  Embedded user=
-agents educate end-user to trust unidentified requests for
 authentication (making phishing attacks easier to execute).



When choosing between implicit and authorization code grant types, the foll=
owing should be considered:



   o  Native applications that use the authorization co=
de grant type flow SHOULD do so without client password credentials, due to=
 their inability to keep those credentials confidential.

   o  Native applications that use the implicit grant t=
ype may offer optimized performance in some scenarios due to reduced networ=
k requests

   o  The implicit grant type does not return a refresh=
 token  












--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DEC3CH1PRD0302MB115_--

From eran@hueniverse.com  Wed Jun 15 10:20:23 2011
Return-Path: 
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 D5B4111E80A4 for ; Wed, 15 Jun 2011 10:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtnYgLdrE08X for ; Wed, 15 Jun 2011 10:20:19 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id C55F69E8006 for ; Wed, 15 Jun 2011 10:19:53 -0700 (PDT)
Received: (qmail 16829 invoked from network); 15 Jun 2011 17:19:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:19:51 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 10:19:39 -0700
From: Eran Hammer-Lahav 
To: Anthony Nadalin , Chuck Mortimore , "oauth@ietf.org" 
Date: Wed, 15 Jun 2011 10:19:19 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986AEFP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:20:24 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AEFP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'=
ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AEFP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated text for Native Apps<=
style>
This work=
ing group has failed, for well over a year, to reach any sort of consensus =
regarding which grant types are suitable for a given client type. There was=
 no draft between 00 and 16 in which we had agreement on the definition of =
client types, or the exclusivity of any flow to any given type. Trying to r=
each such a conclusion is a waste of time.
 
Th=
e main reason for this is lack of deployment experience. We have pretty goo=
d experience with some cases like a server-based client capable of keeping =
secrets, and browser-based clients executing fully visible source code. We =
clearly do not even have a clear definition of what is a native application=
 and the recent attempt to define a native application client type seems to=
 cause more confusion than help.
=
 
While there =
is clearly an expectation that the specification will offer guidance to nat=
ive application developers, I have yet to see any such text gaining consens=
us.
 
My suggestion is to drop this attempt, bu=
t if a new text gain consensus, I’ll incorporate it.
 
EHL
&nb=
sp;
 
From: Anthony Nadalin [mailto:tony=
nad@microsoft.com] 
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject:<=
/b> RE: Updated text for Native Apps
 
Since Tors=
ten and I had the action item to propose text we will update the text based=
 upon the list and give you back an update
 
=
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal=
f Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM=

To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUT=
H-WG] Updated text for Native Apps
 
Is there an =
updated text based on the long thread?
 
EHL<=
o:p>
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To:=
 oauth@ietf.org
Subject: [O=
AUTH-WG] Updated text for Native Apps
 
Minor updates for section 9 based upon feedback from the list
<=
br>-cmort

----------------


9.  Native Applications
A native application is a client which is installed and executes on t=
he end-user's device (i.e. desktop application, native mobile application).=
  Native applications require special consideration related to securit=
y, platform capabilities, and overall end-user experience.  The follow=
ing are examples of how native applications may utilize OAuth:

 =
;  o  Initiate an Authorization Request using an external us=
er-agent: The native application can capture the response from the authoriz=
ation server using a variety of techniques such as the use of a redirection=
 URI identifying a custom URI scheme (registered with the operating system =
to invoke the native application as handler), manual copy-and-paste, runnin=
g a local webserver, browser plug-ins, or by providing a redirection URI id=
entifying a server-hosted resource under the native application's control, =
which in turn makes the response available to the native application.
&n=
bsp;  o  Initiate an Authorization Request using an embedded=
 user-agent:  The native application obtains the response by directly =
communicating with the embedded user-agent.  Techniques include monito=
ring state changes emitted during URL loading, monitoring http headers, acc=
essing the user-agent's cookie jar, etc.

When choosing between launc=
hing an external user-agent and an embedding a user-agent, native applicati=
on developers should consider the following:

   o &nb=
sp;External user-agents may improve completion rate as the end-user may alr=
eady have an active session with the authorization server removing the need=
 to re-authenticate, and provide a familiar user-agent user experience. &nb=
sp;The end-user may also rely on extensions or add-ons to assist with authe=
ntication (e.g. password managers or 2-factor device reader).
 &nbs=
p; o  Embedded user-agents may offer an improved end-user flow, a=
s they remove the need to switch context and open new windows. 
&nb=
sp;  o  Embedded user-agents pose a security challenge becau=
se end-users are authenticating in an unidentified window without access to=
 the visual protections offered by many user-agents.  Embedded user-ag=
ents educate end-user to trust unidentified requests for authentication (ma=
king phishing attacks easier to execute).

When choosing between impl=
icit and authorization code grant types, the following should be considered=
:

   o  Native applications that use the authori=
zation code grant type flow SHOULD do so without client password credential=
s, due to their inability to keep those credentials confidential.
 =
  o  Native applications that use the implicit grant type ma=
y offer optimized performance in some scenarios due to reduced network requ=
ests
   o  The implicit grant type does not return a=
 refresh token  
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AEFP3PW5EX1MB01E_--

From tonynad@microsoft.com  Wed Jun 15 10:26:24 2011
Return-Path: 
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 6220121F8526 for ; Wed, 15 Jun 2011 10:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level: 
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD18I8Q83hnb for ; Wed, 15 Jun 2011 10:26:21 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id EE4BC21F84F2 for ; Wed, 15 Jun 2011 10:26:20 -0700 (PDT)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 15 Jun 2011 10:26:20 -0700
Received: from CH1EHSOBE003.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 15 Jun 2011 10:26:20 -0700
Received: from mail161-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Wed, 15 Jun 2011 17:25:55 +0000
Received: from mail161-ch1 (localhost.localdomain [127.0.0.1])	by mail161-ch1-R.bigfish.com (Postfix) with ESMTP id EFF499B02AD	for ; Wed, 15 Jun 2011 17:25:54 +0000 (UTC)
X-SpamScore: -27
X-BigFish: PS-27(zz9371M1418Mzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT007.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail161-ch1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT007.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail161-ch1 (localhost.localdomain [127.0.0.1]) by mail161-ch1 (MessageSwitch) id 1308158733122967_25231; Wed, 15 Jun 2011 17:25:33 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254])	by mail161-ch1.bigfish.com (Postfix) with ESMTP id 8ECC9BF0001;	Wed, 15 Jun 2011 17:24:13 +0000 (UTC)
Received: from CH1PRD0302HT007.namprd03.prod.outlook.com (157.55.61.146) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 15 Jun 2011 17:24:11 +0000
Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.97]) by CH1PRD0302HT007.namprd03.prod.outlook.com ([10.28.29.126]) with mapi id 14.01.0225.052; Wed, 15 Jun 2011 17:24:11 +0000
From: Anthony Nadalin 
To: Eran Hammer-Lahav , Chuck Mortimore , "oauth@ietf.org" 
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYAAAGH/w
Date: Wed, 15 Jun 2011 17:24:10 +0000
Message-ID: 
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.28.29.112]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DF72CH1PRD0302MB115_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT007.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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%SALESFORCE.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: TK5EX14MLTC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:26:24 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DF72CH1PRD0302MB115_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not seeing what you write about below, I think that the basic text that was=
 discussed at the F2F has consensus around the guidance (with some changes =
that were discussed and Chuck provided), I think that some of the other tho=
ughts people have thrown out don't. I disagree with dropping the text as th=
ere is not consensus to do that, since there was an action item to put text=
 back in.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'=
ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DF72CH1PRD0302MB115_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





Updated text for Native Apps






Not seeing what you write=
 about below, I think that the basic text that was discussed at the F2F has=
 consensus around the guidance (with some changes that were
 discussed and Chuck provided), I think that some of the other thoughts peo=
ple have thrown out don’t. I disagree with dropping the text as there=
 is not consensus to do that, since there was an action item to put text ba=
ck in.


 <=
/p>





From: Eran Ham=
mer-Lahav [mailto:eran@hueniverse.com]


Sent: Wednesday, June 15, 2011 10:19 AM

To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org

Subject: RE: Updated text for Native Apps






 


This working group has fa=
iled, for well over a year, to reach any sort of consensus regarding which =
grant types are suitable for a given client type. There
 was no draft between 00 and 16 in which we had agreement on the definition=
 of client types, or the exclusivity of any flow to any given type. Trying =
to reach such a conclusion is a waste of time.


 <=
/p>

The main reason for this =
is lack of deployment experience. We have pretty good experience with some =
cases like a server-based client capable of keeping secrets,
 and browser-based clients executing fully visible source code. We clearly =
do not even have a clear definition of what is a native application and the=
 recent attempt to define a native application client type seems to cause m=
ore confusion than help.


 <=
/p>

While there is clearly an=
 expectation that the specification will offer guidance to native applicati=
on developers, I have yet to see any such text gaining consensus.


 <=
/p>

My suggestion is to drop =
this attempt, but if a new text gain consensus, I’ll incorporate it.<=
o:p>


 <=
/p>

EHL


 <=
/p>

 <=
/p>







From: Anthony =
Nadalin
[mailto:tonynad@microsoft=
.com]


Sent: Wednesday, June 15, 2011 10:10 AM

To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org

Subject: RE: Updated text for Native Apps






 


Since Torsten and I had t=
he action item to propose text we will update the text based upon the list =
and give you back an update


 <=
/p>





From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM

To: Chuck Mortimore; oauth@ietf.or=
g

Subject: Re: [OAUTH-WG] Updated text for Native Apps






 


Is there an updated text =
based on the long thread?


 <=
/p>

EHL


 <=
/p>







From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore

Sent: Tuesday, May 31, 2011 10:37 AM

To: oauth@ietf.org

Subject: [OAUTH-WG] Updated text for Native Apps





 


Minor updates for section=
 9 based upon feedback from the list



-cmort



----------------





9.  Native Applications



A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  =
;Native applications require special consideration related to security, pla=
tform capabilities, and overall end-user
 experience.  The following are examples of how native applications ma=
y utilize OAuth:



   o  Initiate an Authorization Request using an extern=
al user-agent: The native application can capture the response from the aut=
horization server using a variety of techniques such as the use of a redire=
ction URI identifying a custom URI scheme (registered
 with the operating system to invoke the native application as handler), ma=
nual copy-and-paste, running a local webserver, browser plug-ins, or by pro=
viding a redirection URI identifying a server-hosted resource under the nat=
ive application's control, which
 in turn makes the response available to the native application.

   o  Initiate an Authorization Request using an embedd=
ed user-agent:  The native application obtains the response by directl=
y communicating with the embedded user-agent.  Techniques include moni=
toring state changes emitted during URL loading, monitoring http
 headers, accessing the user-agent's cookie jar, etc.



When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:



   o  External user-agents may improve completion rate =
as the end-user may already have an active session with the authorization s=
erver removing the need to re-authenticate, and provide a familiar user-age=
nt user experience.  The end-user may also rely on extensions
 or add-ons to assist with authentication (e.g. password managers or 2-fact=
or device reader).

   o  Embedded user-agents may offer an improved end-us=
er flow, as they remove the need to switch context and open new windows.&nb=
sp;

   o  Embedded user-agents pose a security challenge be=
cause end-users are authenticating in an unidentified window without access=
 to the visual protections offered by many user-agents.  Embedded user=
-agents educate end-user to trust unidentified requests for
 authentication (making phishing attacks easier to execute).



When choosing between implicit and authorization code grant types, the foll=
owing should be considered:



   o  Native applications that use the authorization co=
de grant type flow SHOULD do so without client password credentials, due to=
 their inability to keep those credentials confidential.

   o  Native applications that use the implicit grant t=
ype may offer optimized performance in some scenarios due to reduced networ=
k requests

   o  The implicit grant type does not return a refresh=
 token  










--_000_B26C1EF377CB694EAB6BDDC8E624B6E72311DF72CH1PRD0302MB115_--

From eran@hueniverse.com  Wed Jun 15 10:27:24 2011
Return-Path: 
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 3785221F857F for ; Wed, 15 Jun 2011 10:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8wxSDs3iT66 for ; Wed, 15 Jun 2011 10:27:23 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E864221F857D for ; Wed, 15 Jun 2011 10:27:22 -0700 (PDT)
Received: (qmail 26895 invoked from network); 15 Jun 2011 17:27:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:27:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 10:27:19 -0700
From: Eran Hammer-Lahav 
To: OAuth WG 
Date: Wed, 15 Jun 2011 10:26:59 -0700
Thread-Topic: Client authentication requirement
Thread-Index: AcwrgIwZK4VJQHN3TIuODI9Bl2Ieew==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986AF7P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:27:24 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF7P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Client authentication has been one of the main problem areas in OAuth 1.0 a=
nd 2.0 does nothing to resolve it (arguably, it makes it more confusing).

Because of the desire to allow any client type in any deployment environmen=
t, we ended up with a barely defined client authentication model. We offer =
password-based client authentication using HTTP Basic (and an alternative p=
arameter), but leave it optional.

It has been suggested that by doing so, we have made the protocol security =
hard to define and harder to implement properly. The document was written l=
argely with the requirement to use client authentication with any request t=
o the access token endpoint. However, it does allow unauthenticated request=
s in section 3.

Are there any other client properties than the client's ability to authenti=
cate with regards to security?

We have one grant type without client authentication (implicit), two with o=
ptional authentication (authorization code and username/password), and one =
with required authentication (client credentials).

I would like to go back to requiring client authentication for the access t=
oken endpoint, using HTTP Basic or other schemes. To leave the door open fo=
r clients incapable of authenticating to use the endpoint, we will add a se=
curity consideration section discussing the ramifications of using the acce=
ss token endpoint without client authentication.

This suggestions is linked to the topic of refresh tokens which I'll post s=
eparately.

EHL


--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF7P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Client authentic=
ation has been one of the main problem areas in OAuth 1.0 and 2.0 does noth=
ing to resolve it (arguably, it makes it more confusing).
 
Because of the =
desire to allow any client type in any deployment environment, we ended up =
with a barely defined client authentication model. We offer password-based =
client authentication using HTTP Basic (and an alternative parameter), but =
leave it optional.
 
=

It has been suggested that by doing so, we have made t=
he protocol security hard to define and harder to implement properly. The d=
ocument was written largely with the requirement to use client authenticati=
on with any request to the access token endpoint. However, it does allow un=
authenticated requests in section 3.
 
Are there any other client propertie=
s than the client’s ability to authenticate with regards to security?=

 
We have one grant type without client authentication (implicit), two wit=
h optional authentication (authorization code and username/password), and o=
ne with required authentication (client credentials). 
 
I would like to go=
 back to requiring client authentication for the access token endpoint, usi=
ng HTTP Basic or other schemes. To leave the door open for clients incapabl=
e of authenticating to use the endpoint, we will add a security considerati=
on section discussing the ramifications of using the access token endpoint =
without client authentication.
&nbs=
p;
This suggestions is linked to the topic of=
 refresh tokens which I’ll post separately.
 
EHL
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF7P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 10:30:59 2011
Return-Path: 
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 2ECB221F85CF for ; Wed, 15 Jun 2011 10:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPdFfZCXyy2x for ; Wed, 15 Jun 2011 10:30:53 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C045321F85CE for ; Wed, 15 Jun 2011 10:30:53 -0700 (PDT)
Received: (qmail 26792 invoked from network); 15 Jun 2011 17:30:52 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:30:52 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 10:30:47 -0700
From: Eran Hammer-Lahav 
To: OAuth WG 
Date: Wed, 15 Jun 2011 10:30:27 -0700
Thread-Topic: Refresh tokens
Thread-Index: AcwrgXObqVi9qhn3QCOgElgVMivvNw==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986AF9P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:30:59 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF9P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The main source of confusion about refresh token is caused by the protocol =
lack of clear definition of access token lifetime, even in relative terms, =
and the objectives of refresh tokens. For example, the authorization server=
 can issue:

- an access token good for an hour, with a refresh token good for a year or=
 good-till-revoked
- an access token good-till-revoked without a refresh token
- an access token good-till-revoked with a refresh token, used to obtain ad=
ditional access tokens for a distributed environment

In large scale systems access tokens are often self-describing, including a=
ll the information needed by the resource server to validate them. In such =
a setup, access tokens cannot be revoked until expired. Refresh tokens on t=
he other hand, require a database lookup for the resource owner grant, and =
can be revoked.

The only real difference between the implicit and authorization code grant =
types is the inclusion of a refresh token. The point is not to issue long t=
erm credentials without client authentication, relying on the presence of t=
he resource owner for authenticating the client. However, we don't say that=
 anywhere, or define the goals of the two token types design with enough de=
tail to offer sound security.

I would like to add a quick discussion of access token and refresh token re=
commended deployment setup, providing clear guidelines when a refresh token=
 SHOULD and SHOULD NOT be issued, and when issues, how it is difference fro=
m the access token.

It's time we stop trying to accommodate every possible combination and make=
 some hard choices.

EHL




--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF9P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The main source =
of confusion about refresh token is caused by the protocol lack of clear de=
finition of access token lifetime, even in relative terms, and the objectiv=
es of refresh tokens. For example, the authorization server can issue:=

 
- =
an access token good for an hour, with a refresh token good for a year or g=
ood-till-revoked
- an access token good-=
till-revoked without a refresh token
- a=
n access token good-till-revoked with a refresh token, used to obtain addit=
ional access tokens for a distributed environment
 
In large scale systems =
access tokens are often self-describing, including all the information need=
ed by the resource server to validate them. In such a setup, access tokens =
cannot be revoked until expired. Refresh tokens on the other hand, require =
a database lookup for the resource owner grant, and can be revoked.
 
The o=
nly real difference between the implicit and authorization code grant types=
 is the inclusion of a refresh token. The point is not to issue long term c=
redentials without client authentication, relying on the presence of the re=
source owner for authenticating the client. However, we don’t say tha=
t anywhere, or define the goals of the two token types design with enough d=
etail to offer sound security.
&nbs=
p;
I would like to add a quick discussion of =
access token and refresh token recommended deployment setup, providing clea=
r guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when=
 issues, how it is difference from the access token.
 
It’s time we s=
top trying to accommodate every possible combination and make some hard cho=
ices.
 
EHL
 
 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF9P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 10:36:01 2011
Return-Path: 
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 EF42221F85E0 for ; Wed, 15 Jun 2011 10:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHN7EYIvha-y for ; Wed, 15 Jun 2011 10:35:58 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id F0BA621F85E2 for ; Wed, 15 Jun 2011 10:35:57 -0700 (PDT)
Received: (qmail 1839 invoked from network); 15 Jun 2011 17:35:57 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:35:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 10:35:45 -0700
From: Eran Hammer-Lahav 
To: Anthony Nadalin , Chuck Mortimore , "oauth@ietf.org" 
Date: Wed, 15 Jun 2011 10:35:25 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYAAAGH/wAABbt7A=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AFD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986AFDP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:36:02 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AFDP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That's an odd way of looking at it. I'm looking at over 30 responses to the=
 text with clear disagreement on how native applications should be deployed=
 using different grant types. To say that there is consensus to the text, b=
ut not to the other comments objecting to it is ignoring the lack of consen=
sus...

If you think you can propose a new text that will be endorsed by the group,=
 please go ahead. But the F2F action item carries no weight if the list doe=
sn't like what is suggested.

What is clear from the discussion is that we have some unresolved issues ar=
ound refresh tokens and client authentication which are at the heart of adv=
ising about native applications. It would be impossible to make recommendat=
ions without resolving these issues first (and once we do, I would argue no=
 additional text would be needed).

EHL



From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:24 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Not seeing what you write about below, I think that the basic text that was=
 discussed at the F2F has consensus around the guidance (with some changes =
that were discussed and Chuck provided), I think that some of the other tho=
ughts people have thrown out don't. I disagree with dropping the text as th=
ere is not consensus to do that, since there was an action item to put text=
 back in.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'=
ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AFDP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated text for Native Apps<=
style>
That̵=
7;s an odd way of looking at it. I’m looking at over 30 responses to =
the text with clear disagreement on how native applications should be deplo=
yed using different grant types. To say that there is consensus to the text=
, but not to the other comments objecting to it is ignoring the lack of con=
sensus…
 <=
/o:p>
If you think you can propose a =
new text that will be endorsed by the group, please go ahead. But the F2F a=
ction item carries no weight if the list doesn’t like what is suggest=
ed.
 
What is clear from the discussion is that=
 we have some unresolved issues around refresh tokens and client authentica=
tion which are at the heart of advising about native applications. It would=
 be impossible to make recommendations without resolving these issues first=
 (and once we do, I would argue no additional text would be needed).
 
EHL
 
 =

 
<=
div>
From: Anthony Nadalin [mailto:tonynad@micro=
soft.com] 
Sent: Wednesday, June 15, 2011 10:24 AM
To: =
Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: U=
pdated text for Native Apps
 
Not seeing what you=
 write about below, I think that the basic text that was discussed at the F=
2F has consensus around the guidance (with some changes that were discussed=
 and Chuck provided), I think that some of the other thoughts people have t=
hrown out don’t. I disagree with dropping the text as there is not co=
nsensus to do that, since there was an action item to put text back in.
 
<=
div>
From: Eran Hammer-Lahav [mailto:eran@hueniv=
erse.com] 
Sent: Wednesday, June 15, 2011 10:19 AM
To: =
Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Upd=
ated text for Native Apps
 
This working group ha=
s failed, for well over a year, to reach any sort of consensus regarding wh=
ich grant types are suitable for a given client type. There was no draft be=
tween 00 and 16 in which we had agreement on the definition of client types=
, or the exclusivity of any flow to any given type. Trying to reach such a =
conclusion is a waste of time.
 
The main reaso=
n for this is lack of deployment experience. We have pretty good experience=
 with some cases like a server-based client capable of keeping secrets, and=
 browser-based clients executing fully visible source code. We clearly do n=
ot even have a clear definition of what is a native application and the rec=
ent attempt to define a native application client type seems to cause more =
confusion than help.
 
While there is clearly =
an expectation that the specification will offer guidance to native applica=
tion developers, I have yet to see any such text gaining consensus.
 
My suggestion is to drop this attempt, but if a new =
text gain consensus, I’ll incorporate it.
 
EHL
 
 
From: Anthony Nadalin [mailto:tonynad@microsoft.com] 
Sent:<=
/b> Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuc=
k Mortimore; oauth@ietf.org
Sub=
ject: RE: Updated text for Native Apps
 
Sinc=
e Torsten and I had the action item to propose text we will update the text=
 based upon the list and give you back an update
 
From: oauth-bounces@ie=
tf.org [mailto:oauth=
-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH=
-WG] Updated text for Native Apps
 
Is there an u=
pdated text based on the long thread?
 
EHL
 
<=
div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4=
.0pt'>
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuc=
k Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUT=
H-WG] Updated text for Native Apps
 
Minor updates for section 9 based upon feedback from the list

=
-cmort

----------------


9.  Native Applications
<=
br>A native application is a client which is installed and executes on the =
end-user's device (i.e. desktop application, native mobile application). &n=
bsp;Native applications require special consideration related to security, =
platform capabilities, and overall end-user experience.  The following=
 are examples of how native applications may utilize OAuth:

 &n=
bsp; o  Initiate an Authorization Request using an external user-=
agent: The native application can capture the response from the authorizati=
on server using a variety of techniques such as the use of a redirection UR=
I identifying a custom URI scheme (registered with the operating system to =
invoke the native application as handler), manual copy-and-paste, running a=
 local webserver, browser plug-ins, or by providing a redirection URI ident=
ifying a server-hosted resource under the native application's control, whi=
ch in turn makes the response available to the native application.
 =
;  o  Initiate an Authorization Request using an embedded us=
er-agent:  The native application obtains the response by directly com=
municating with the embedded user-agent.  Techniques include monitorin=
g state changes emitted during URL loading, monitoring http headers, access=
ing the user-agent's cookie jar, etc.

When choosing between launchin=
g an external user-agent and an embedding a user-agent, native application =
developers should consider the following:

   o  =
External user-agents may improve completion rate as the end-user may alread=
y have an active session with the authorization server removing the need to=
 re-authenticate, and provide a familiar user-agent user experience.  =
The end-user may also rely on extensions or add-ons to assist with authenti=
cation (e.g. password managers or 2-factor device reader).
  &=
nbsp;o  Embedded user-agents may offer an improved end-user flow, as t=
hey remove the need to switch context and open new windows. 
 =
  o  Embedded user-agents pose a security challenge because =
end-users are authenticating in an unidentified window without access to th=
e visual protections offered by many user-agents.  Embedded user-agent=
s educate end-user to trust unidentified requests for authentication (makin=
g phishing attacks easier to execute).

When choosing between implici=
t and authorization code grant types, the following should be considered:
   o  Native applications that use the authorizat=
ion code grant type flow SHOULD do so without client password credentials, =
due to their inability to keep those credentials confidential.
 &nb=
sp; o  Native applications that use the implicit grant type may o=
ffer optimized performance in some scenarios due to reduced network request=
s
   o  The implicit grant type does not return a re=
fresh token  
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AFDP3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 10:39:00 2011
Return-Path: 
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 83CDE21F85F2 for ; Wed, 15 Jun 2011 10:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e71hIRSdhmYj for ; Wed, 15 Jun 2011 10:38:59 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 448AC21F85F8 for ; Wed, 15 Jun 2011 10:38:59 -0700 (PDT)
Received: (qmail 7548 invoked from network); 15 Jun 2011 17:38:57 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:38:56 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 10:38:46 -0700
From: Eran Hammer-Lahav 
To: Mike Jones , David Recordon , George Fletcher 
Date: Wed, 15 Jun 2011 10:38:26 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AQHMEGLvUtk/Y41LJU+xw7NH/M+2opSa0CjQgAgtbYCABOk9gIAAwn+AgABmmeCAFdUR4A==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 17:39:00 -0000

It should be pretty easy :-)

Anyone objects to changing the parameter name from 'bearer_token' to 'acces=
s_token'? Let Mike know by 6/20 or he will make the change.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Mike Jones
> Sent: Wednesday, June 01, 2011 1:15 PM
> To: David Recordon; George Fletcher
> Cc: paul Tarjan; oauth@ietf.org
> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
> If you can drive a consensus decision for the name "access_token", I'd be
> glad to change the name in the spec.  I agree that the current names are
> confusing for developers.
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: David Recordon [mailto:recordond@gmail.com]
> Sent: Wednesday, June 01, 2011 12:06 AM
> To: George Fletcher
> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
> Yeah, can understand how we got here. Just found it quite confusing when
> reading these two specifications together with an implementor's hat on.
>=20
> On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
> wrote:
> > Brief pointer to the "history" of this change. This change was adopted
> > in draft 4 of the bearer spec as there were concerns with the previous
> > parameter name of 'oauth_token'. The suggestion was made to use
> > 'bearer_token' so that it matches the scheme used in the Authorization
> > header. The thinking being that reading the bearer token spec would
> > seem weird if the Authorization header used one name and the GET/POST
> > methods used a different name.
> >
> > The 'bearer_token' name got a few +1 and no dissents.
> >
> > Full thread starts here [1]. Mike accepting the 'bearer_token'
> > recommendation is here [2].
> >
> > Thanks,
> > George
> >
> > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
> >
> > On 5/28/11 12:30 PM, David Recordon wrote:
> >
> > Did a full read through of draft 16 and the bear token spec with Paul
> > yesterday afternoon in order to do a manual diff from draft 10. The
> > point Doug raised was actually confusing. Throughout the core spec
> > it's referred to as access_token but then becomes bearer_token upon
> > use.
> >
> > Just thinking through this from a developer documentation perspective,
> > it's going to become confusing. Developer documentation focuses on
> > getting an access token and then using that access token to interact
> > with an API. Thus the code you're writing as a client developer will
> > use variables, cache keys, and database columns named `access_token`.
> > But then when you're going to use it, you'll need to put this access
> > token into a field named bearer_token.
> >
> > Feels quite a bit simpler to just name it access_token. Realize the
> > core spec never did this since we didn't want to trample on protected
> > resources which might already have a different type of access_token
> > parameter. oauth_token was a good compromise since developers would
> > already know that they were using OAuth and thus a new term wasn't
> > being introduced. That's no longer true with bearer_token since 99% of
> > developers will have never heard of a bearer token.
> >
> > Googling for "bearer token" turns up Eran's blog post titled "OAuth
> > Bearer Tokens are a Terrible Idea" and there isn't a single result on
> > the first page which explains what they are. Binging for "bearer
> > token" is equally scary.
> >
> > --David
> >
> >
> > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> >  wrote:
> >
> > The working group explicitly decided that a different name should be
> > used, to make it clear that other token types other than bearer tokens
> > could also be used with OAuth 2.
> >
> >
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
> >
> >
> >
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Doug Tangren
> > Sent: Wednesday, May 11, 2011 10:09 PM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] consistency of token param name in bearer token
> > type
> >
> >
> >
> > This may have come up before so I'm sorry if I'm repeating. Why does
> > bearer token spec introduce a new name for oauth2 access tokens [1],
> > "bearer_token", and before that [2], "oauth_token"?
> >
> >
> >
> > I=A0apologize=A0if this may sound shallow but, why introduce a new
> > parameter name verses sticking with what the general oauth2 spec
> > already defines, "access_token". It seems arbitrary for an auth server
> > to hand a client an apple then have the client hand it off to the
> > resource server and call it an orange.
> >
> >
> >
> > Was this just for the sake of differentiating the parameter name
> > enough so that the bearer tokens may be used in other protocols
> > without being confused with oauth2 access_tokens?
> >
> >
> >
> > [1]:
> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
> >
> > [2]:
> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
> >
> >
> >
> > -Doug Tangren
> > http://lessis.me
> >
> > _______________________________________________
> > 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
> >
> >
> > --
> > Chief Architect                   AIM:  gffletch
> > Identity Services Engineering     Work: george.fletcher@teamaol.com
> > AOL Inc.                          Home: gffletch@aol.com
> > Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
> > Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch
> >
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Wed Jun 15 11:04:27 2011
Return-Path: 
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 60E2A11E80C7 for ; Wed, 15 Jun 2011 11:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLQgkXIoFiD0 for ; Wed, 15 Jun 2011 11:04:26 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11411E808D for ; Wed, 15 Jun 2011 11:04:25 -0700 (PDT)
Received: by fxm15 with SMTP id 15so686191fxm.31 for ; Wed, 15 Jun 2011 11:04:25 -0700 (PDT)
Received: by 10.223.61.82 with SMTP id s18mr37101fah.44.1308161064860; Wed, 15 Jun 2011 11:04:24 -0700 (PDT)
Received: from [192.168.1.210] ([190.22.14.136]) by mx.google.com with ESMTPS id 11sm369449fax.12.2011.06.15.11.04.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 11:04:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: John Bradley 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 14:04:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav 
X-Mailer: Apple Mail (2.1084)
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 18:04:27 -0000

I agree access_token is better.

John B.
On 2011-06-15, at 1:38 PM, Eran Hammer-Lahav wrote:

> It should be pretty easy :-)
>=20
> Anyone objects to changing the parameter name from 'bearer_token' to =
'access_token'? Let Mike know by 6/20 or he will make the change.
>=20
> EHL
>=20
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Mike Jones
>> Sent: Wednesday, June 01, 2011 1:15 PM
>> To: David Recordon; George Fletcher
>> Cc: paul Tarjan; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer =
token
>> type
>>=20
>> If you can drive a consensus decision for the name "access_token", =
I'd be
>> glad to change the name in the spec.  I agree that the current names =
are
>> confusing for developers.
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: David Recordon [mailto:recordond@gmail.com]
>> Sent: Wednesday, June 01, 2011 12:06 AM
>> To: George Fletcher
>> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer =
token
>> type
>>=20
>> Yeah, can understand how we got here. Just found it quite confusing =
when
>> reading these two specifications together with an implementor's hat =
on.
>>=20
>> On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
>> wrote:
>>> Brief pointer to the "history" of this change. This change was =
adopted
>>> in draft 4 of the bearer spec as there were concerns with the =
previous
>>> parameter name of 'oauth_token'. The suggestion was made to use
>>> 'bearer_token' so that it matches the scheme used in the =
Authorization
>>> header. The thinking being that reading the bearer token spec would
>>> seem weird if the Authorization header used one name and the =
GET/POST
>>> methods used a different name.
>>>=20
>>> The 'bearer_token' name got a few +1 and no dissents.
>>>=20
>>> Full thread starts here [1]. Mike accepting the 'bearer_token'
>>> recommendation is here [2].
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
>>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
>>>=20
>>> On 5/28/11 12:30 PM, David Recordon wrote:
>>>=20
>>> Did a full read through of draft 16 and the bear token spec with =
Paul
>>> yesterday afternoon in order to do a manual diff from draft 10. The
>>> point Doug raised was actually confusing. Throughout the core spec
>>> it's referred to as access_token but then becomes bearer_token upon
>>> use.
>>>=20
>>> Just thinking through this from a developer documentation =
perspective,
>>> it's going to become confusing. Developer documentation focuses on
>>> getting an access token and then using that access token to interact
>>> with an API. Thus the code you're writing as a client developer will
>>> use variables, cache keys, and database columns named =
`access_token`.
>>> But then when you're going to use it, you'll need to put this access
>>> token into a field named bearer_token.
>>>=20
>>> Feels quite a bit simpler to just name it access_token. Realize the
>>> core spec never did this since we didn't want to trample on =
protected
>>> resources which might already have a different type of access_token
>>> parameter. oauth_token was a good compromise since developers would
>>> already know that they were using OAuth and thus a new term wasn't
>>> being introduced. That's no longer true with bearer_token since 99% =
of
>>> developers will have never heard of a bearer token.
>>>=20
>>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>>> Bearer Tokens are a Terrible Idea" and there isn't a single result =
on
>>> the first page which explains what they are. Binging for "bearer
>>> token" is equally scary.
>>>=20
>>> --David
>>>=20
>>>=20
>>> On Mon, May 23, 2011 at 11:38 AM, Mike Jones
>>>  wrote:
>>>=20
>>> The working group explicitly decided that a different name should be
>>> used, to make it clear that other token types other than bearer =
tokens
>>> could also be used with OAuth 2.
>>>=20
>>>=20
>>>=20
>>>                                                             -- Mike
>>>=20
>>>=20
>>>=20
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> Of Doug Tangren
>>> Sent: Wednesday, May 11, 2011 10:09 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] consistency of token param name in bearer token
>>> type
>>>=20
>>>=20
>>>=20
>>> This may have come up before so I'm sorry if I'm repeating. Why does
>>> bearer token spec introduce a new name for oauth2 access tokens [1],
>>> "bearer_token", and before that [2], "oauth_token"?
>>>=20
>>>=20
>>>=20
>>> I apologize if this may sound shallow but, why introduce a new
>>> parameter name verses sticking with what the general oauth2 spec
>>> already defines, "access_token". It seems arbitrary for an auth =
server
>>> to hand a client an apple then have the client hand it off to the
>>> resource server and call it an orange.
>>>=20
>>>=20
>>>=20
>>> Was this just for the sake of differentiating the parameter name
>>> enough so that the bearer tokens may be used in other protocols
>>> without being confused with oauth2 access_tokens?
>>>=20
>>>=20
>>>=20
>>> [1]:
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
>>>=20
>>> [2]:
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
>>>=20
>>>=20
>>>=20
>>> -Doug Tangren
>>> http://lessis.me
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>> --
>>> Chief Architect                   AIM:  gffletch
>>> Identity Services Engineering     Work: george.fletcher@teamaol.com
>>> AOL Inc.                          Home: gffletch@aol.com
>>> Mobile: +1-703-462-3494           Blog: =
http://practicalid.blogspot.com
>>> Office: +1-703-265-2544           Twitter: =
http://twitter.com/gffletch
>>>=20
>>=20
>> _______________________________________________
>> 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


From beaton@google.com  Wed Jun 15 11:32:59 2011
Return-Path: 
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 93A2511E8153 for ; Wed, 15 Jun 2011 11:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StqSf7mbbK8F for ; Wed, 15 Jun 2011 11:32:59 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D13911E8141 for ; Wed, 15 Jun 2011 11:32:58 -0700 (PDT)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p5FIWvwg007475 for ; Wed, 15 Jun 2011 11:32:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308162777; bh=3PN1dwKMZf+KI1R1ZODueUDx6C4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bJCNZBs3E3u0tn+hVjg+gw3hxSbr0VpKmJI6N7xOMBztxRyiO98oMgzlRdCWX8NNv K/sKLr5eBmci8ObI8QReA==
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by wpaz29.hot.corp.google.com with ESMTP id p5FIWWP1004168 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 11:32:55 -0700
Received: by pzk10 with SMTP id 10so507093pzk.7 for ; Wed, 15 Jun 2011 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UvG1fkF+BxgQT74vZ45U4NP2qie9YNX+Ex94Ia2oWy8=; b=eVGIEcCQJwDKa5EazoVBqK5nv/zm0skn2AHMdOyTakfRwHoLQ16naeHhvNa7SHkFBS ALdk9/Xlgzk1cFeQ7k5Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VhNIMXX/Pxcb1h2vdZs7plo8Jec6kMaVnDRgg5FgE4zo3aAPfXql8zbiObDzzB+djA SoHGJ9/OebNFlhYb9YEA==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr17246wfa.323.1308162774179; Wed, 15 Jun 2011 11:32:54 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Wed, 15 Jun 2011 11:32:54 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 11:32:54 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e906f176a15304a5c4613c
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 18:32:59 -0000

--001636e906f176a15304a5c4613c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav wr=
ote:

> I would like to add a quick discussion of access token and refresh token
> recommended deployment setup, providing clear guidelines when a refresh
> token SHOULD and SHOULD NOT be issued, and when issues, how it is differe=
nce
> from the access token.
>

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html


> **
>
> It=92s time we stop trying to accommodate every possible combination and =
make
> some hard choices.****
>
> **
>

+1.  Yes please.

--001636e906f176a15304a5c4613c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <<=
a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com> wr=
ote:


I would like to add a quick discussion of access token and refresh toke=
n recommended deployment setup, providing clear guidelines when a refresh t=
oken SHOULD and SHOULD NOT be issued, and when issues, how it is difference=
 from the access token.



Is this a start?


=A0=A0
It=92s time we stop trying to accommodate every possible com=
bination and make some hard choices.



+=
1. =A0Yes please.


--001636e906f176a15304a5c4613c--

From bcampbell@pingidentity.com  Wed Jun 15 11:47:53 2011
Return-Path: 
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 A33BF11E8166 for ; Wed, 15 Jun 2011 11:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.676
X-Spam-Level: 
X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyyNRwh4QAqB for ; Wed, 15 Jun 2011 11:47:53 -0700 (PDT)
Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id AC04B11E8165 for ; Wed, 15 Jun 2011 11:47:51 -0700 (PDT)
Received: from mail-qy0-f178.google.com ([209.85.216.178]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTfj+VtxSMnUE+X7/CTTqi24k402lr20m@postini.com; Wed, 15 Jun 2011 11:47:52 PDT
Received: by qyk2 with SMTP id 2so417263qyk.9 for ; Wed, 15 Jun 2011 11:47:50 -0700 (PDT)
Received: by 10.224.27.10 with SMTP id g10mr65390qac.204.1308163670165; Wed, 15 Jun 2011 11:47:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.54.133 with HTTP; Wed, 15 Jun 2011 11:47:20 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Brian Campbell 
Date: Wed, 15 Jun 2011 12:47:20 -0600
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=bcaec51ba3d5de48d904a5c49651
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 18:47:53 -0000

--bcaec51ba3d5de48d904a5c49651
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Also seems this is related to the topic of native/mobile clients.  As I
understand it, native apps using the authorization code grant/flow have bee=
n
the primary motivator for keeping client authentication optional.  Anonymou=
s
client have come up too.



On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav wr=
ote:

> Client authentication has been one of the main problem areas in OAuth 1.0
> and 2.0 does nothing to resolve it (arguably, it makes it more confusing)=
.
>
>
>
> Because of the desire to allow any client type in any deployment
> environment, we ended up with a barely defined client authentication mode=
l.
> We offer password-based client authentication using HTTP Basic (and an
> alternative parameter), but leave it optional.
>
>
>
> It has been suggested that by doing so, we have made the protocol securit=
y
> hard to define and harder to implement properly. The document was written
> largely with the requirement to use client authentication with any reques=
t
> to the access token endpoint. However, it does allow unauthenticated
> requests in section 3.
>
>
>
> Are there any other client properties than the client=92s ability to
> authenticate with regards to security?
>
>
>
> We have one grant type without client authentication (implicit), two with
> optional authentication (authorization code and username/password), and o=
ne
> with required authentication (client credentials).
>
>
>
> I would like to go back to requiring client authentication for the access
> token endpoint, using HTTP Basic or other schemes. To leave the door open
> for clients incapable of authenticating to use the endpoint, we will add =
a
> security consideration section discussing the ramifications of using the
> access token endpoint without client authentication.
>
>
>
> This suggestions is linked to the topic of refresh tokens which I=92ll po=
st
> separately.
>
>
>
> EHL
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--bcaec51ba3d5de48d904a5c49651
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Also seems this is related to the topic of native/mobile clients.=A0 As I u=
nderstand it, native apps using the authorization code grant/flow have been=
 the primary motivator for keeping client authentication optional.=A0 Anony=
mous client have come up too.=A0 





On Wed, Jun 15, 2011 at 11:26 AM, Er=
an Hammer-Lahav <eran@hueniverse.com> wrote:



Client authentication has been one of the main problem areas in OAuth 1=
.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing=
).



=A0
Because of the desire =
to allow any client type in any deployment environment, we ended up with a =
barely defined client authentication model. We offer password-based client =
authentication using HTTP Basic (and an alternative parameter), but leave i=
t optional.



=A0
It has been suggested =
that by doing so, we have made the protocol security hard to define and har=
der to implement properly. The document was written largely with the requir=
ement to use client authentication with any request to the access token end=
point. However, it does allow unauthenticated requests in section 3.



=A0
Are there any other cl=
ient properties than the client=92s ability to authenticate with regards to=
 security?
=A0
We have =
one grant type without client authentication (implicit), two with optional =
authentication (authorization code and username/password), and one with req=
uired authentication (client credentials). 



=A0
I would like to go bac=
k to requiring client authentication for the access token endpoint, using H=
TTP Basic or other schemes. To leave the door open for clients incapable of=
 authenticating to use the endpoint, we will add a security consideration s=
ection discussing the ramifications of using the access token endpoint with=
out client authentication.



=A0
This suggestions is li=
nked to the topic of refresh tokens which I=92ll post separately.
=A0
EHL<=
/p>


=A0

_____________________________________________=
__

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--bcaec51ba3d5de48d904a5c49651--

From eran@hueniverse.com  Wed Jun 15 11:56:53 2011
Return-Path: 
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 D610021F85A0 for ; Wed, 15 Jun 2011 11:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level: 
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I9ctWS3+kqz for ; Wed, 15 Jun 2011 11:56:52 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C9F7921F859F for ; Wed, 15 Jun 2011 11:56:52 -0700 (PDT)
Received: (qmail 26135 invoked from network); 15 Jun 2011 18:56:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 18:56:50 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 15 Jun 2011 11:56:44 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 11:56:25 -0700
Thread-Topic: [OAUTH-WG] Refresh tokens
Thread-Index: AcwriqZG+rtuEexTQKqoSJO19hK/0wAAyZ5g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986B4FP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 18:56:53 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B4FP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a=
 refresh token is for. Right now, we have a very vague definition for it, a=
nd it is not clear how developers should use it alongside access tokens.

EHL

From: Brian Eaton [mailto:beaton@google.com]
Sent: Wednesday, June 15, 2011 11:33 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav > wrote:
I would like to add a quick discussion of access token and refresh token re=
commended deployment setup, providing clear guidelines when a refresh token=
 SHOULD and SHOULD NOT be issued, and when issues, how it is difference fro=
m the access token.

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html

It's time we stop trying to accommodate every possible combination and make=
 some hard choices.

+1.  Yes please.

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B4FP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Yes, this=
 is useful and on my list of changes to apply.
 
But I would like to start with a more basic, normative definition of what=
 a refresh token is for. Right now, we have a very vague definition for it,=
 and it is not clear how developers should use it alongside access tokens.<=
o:p>
 
EHL
 
Fr=
om: Brian Eaton [mailto:beaton@google.com] 
Sent: Wednesday, J=
une 15, 2011 11:33 AM
To: Eran Hammer-Lahav
Cc: OAuth W=
G
Subject: Re: [OAUTH-WG] Refresh tokens
 
On =
Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I would li=
ke to add a quick discussion of access token and refresh token recommended =
deployment setup, providing clear guidelines when a refresh token SHOULD an=
d SHOULD NOT be issued, and when issues, how it is difference from the acce=
ss token.
=
 
Is this a start?<=
/o:p>
 
  
It’s time we stop trying to accommodate every possible c=
ombination and make some hard choices.
 
+1.  Yes please.
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B4FP3PW5EX1MB01E_--

From kris.selden@gmail.com  Wed Jun 15 12:21:53 2011
Return-Path: 
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 A97A821F85D3 for ; Wed, 15 Jun 2011 12:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOYEAiQ9phBO for ; Wed, 15 Jun 2011 12:21:52 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id C23E821F85CB for ; Wed, 15 Jun 2011 12:21:52 -0700 (PDT)
Received: by pvh18 with SMTP id 18so641708pvh.31 for ; Wed, 15 Jun 2011 12:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=sxQiINu6DmZWOUx+Xqv7dOA5lBbBGP565pl/xwT67IU=; b=bOfuM3XTYaDwm6nPyKgW8/CxaQZXUiSyXX0fYscV4N6XKdR5eU45I6Rf8ZKBtSB7yL uiQjvLJhXq/LitYl9ldy8QPooKQ/AMfvNMFZK4WlYIntSp1rjUW0Qn56HP6fLYVJV3Hn I7InB15nQdoFGzni62isEHfwj4A9imwq4Uo0U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=PwGMXf0Yy6ozjO165TeFFXraZwEjEctN8zzPPbLJ2jZw8IdLuvxrE+gQXTJdluT+hC v59YtE/7G4pG7Xf4D2pAFRRqAViUxrwJtoAzX4yuGT6PmzllXqTy45hnCdCP7l5VHJ75 ViUrtLJaoEuXus4yLwtsmAWUsX9Ahn6UzcXLM=
Received: by 10.68.9.5 with SMTP id v5mr36135pba.140.1308165625455; Wed, 15 Jun 2011 12:20:25 -0700 (PDT)
Received: from [172.16.176.24] (65-122-179-162.dia.static.qwest.net [65.122.179.162]) by mx.google.com with ESMTPS id x1sm400069pbb.82.2011.06.15.12.20.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 12:20:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-11--854034262
From: Kris Selden 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 12:20:47 -0700
Message-Id: <23E83C1C-3874-43D1-A941-F86D79B86B41@gmail.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav 
X-Mailer: Apple Mail (2.1082)
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 19:21:53 -0000

--Apple-Mail-11--854034262
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

There is a scalability reason, in that the access_token could be =
verifiable on the resource server without DB lookup or a call out to a =
central server, then the refresh token serves as the means for revoking =
in the "an access token good for an hour, with a refresh token good for =
a year or good-till-revoked."

There is a security reason, the refresh_token is only ever exchanged =
with authorization server whereas the access_token is exchanged with =
resource servers.  This mitigates the risk of a long-lived access_token =
leaking (query param in a log file on an insecure resource server, beta =
or poorly coded resource server app, JS SDK client on a non https site =
that puts the access_token in a cookie, etc) in the "an access token =
good for an hour, with a refresh token good for a year or =
good-till-revoked" vs "an access token good-till-revoked without a =
refresh token."

On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:

> Yes, this is useful and on my list of changes to apply.
> =20
> But I would like to start with a more basic, normative definition of =
what a refresh token is for. Right now, we have a very vague definition =
for it, and it is not clear how developers should use it alongside =
access tokens.
> =20
> EHL
> =20


--Apple-Mail-11--854034262
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


There is a scalability reason, in that the =
access_token could be verifiable on the resource server without DB =
lookup or a call out to a central server, then the refresh token serves =
as the means for revoking in the "an access token good for an hour, with =
a refresh token good for a year or =
good-till-revoked."

There is a security reason, =
the refresh_token is only ever exchanged with authorization server =
whereas the access_token is exchanged with resource servers. =
 This mitigates the risk of a long-lived access_token leaking =
(query param in a log file on an insecure resource server, beta or =
poorly coded resource server app, JS SDK client on a non https site that =
puts the access_token in a cookie, etc) in the "an access token =
good for an hour, with a refresh token good for a year or =
good-till-revoked" vs "an access token good-till-revoked without a =
refresh token."

On Jun 15, 2011, at 11:56 =
AM, Eran Hammer-Lahav wrote:

Yes, =
this is useful and on my list of changes to =
apply.
But I =
would like to start with a more basic, normative definition of what a =
refresh token is for. Right now, we have a very vague definition for it, =
and it is not clear how developers should use it alongside access =
tokens.

Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 19:27:48 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B62P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B62P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
I agree to the extent that the user can be trusted to know how they =
got to the authorization endpoint.
 
If the cli=
ent cannot be authenticated, the authorization server is limited in the inf=
ormation it can offer the user to make the decision. It is extremely hard t=
o come up with language that will tell the user to only approve the applica=
tion, claiming to be X, if they got here from X directly. There might be wa=
ys to improve security a bit using Origin header etc. but overall, if the c=
lient is not authenticated, the authorization server can’t really des=
cribe it to the user.
 
EHL
 
 
From: oauth-bounces@ietf.org [mailto:=
oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent:=
 Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-=
16
 <=
/p>
I fully agree with Brian and would like to add some=
 thoughts: 

Not authenticating the client does not directly create a=
 security problem at all. If we would follow this line, every e-Mail client=
 out there would be considered insecure because the client itself is never =
authenticated. Not even Kerbereos has a concept of client authentication. <=
br>
In my opinion, OAuth client authentication (in delegated authorizati=
on scenarios) is an improvement over classical approaches. But I do not see=
 a degration in security if it is not applicable. As long as the _user_ aut=
horizes the client's access (and the duration of the token) and is able to =
revoke the tokens at any time, the situation is much better than with class=
ical approaches. 

regards,
Torsten.

Am 01.06.2011 21:06, s=
chrieb Brian Eaton: 
Hey Peter -&nb=
sp;
 
I haven't read all of your comments yet, but I =
wanted to clarify one point about client impersonation and installed apps. =
 The cuirrent text is unrealistic, but your request would push it the =
wrong way.  CC'ing Torsten as well.
 
---------=
------------
OLD:
  The authorization =
server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticati=
ng.

NEW:
  If the authorization server issues access tokens=
 to clients
  that are incapa=
ble of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authoriza=
tion servers are to
issue such tok=
ens, are we?
---------------------
 
We are most d=
efinitely recommending that clients that have no way of authenticating are =
issued long-lived credentials to access user data.
 
Most installed applications work as f=
ollows:
- they ask the user for their password
- they save the password to disk
 
That's a horrible security pro=
blem, because it means you cannot upgrade user authentication to anything s=
tronger than a password.  Client certificates, one time passwords, ris=
k based authentication, throw it all out the window.  If you're going =
to let installed apps authenticate with just a password, nothing else you d=
o to improve authentication is going to help.
 
This is a blocking issue for rolling out st=
ronger forms of user authentication, and it's one of the main reasons I car=
e about OAuth2.  
 
Think IMAP and XMPP client=
s running on Windows desktops.  They are important, and we need a way =
to migrate them off of saving passwords.
 
So the current text ba=
sically says that you should issue temporary credentials to native apps. &n=
bsp;That's not practical.  Native apps end up needing permanent or nea=
r-permanent credentials.  Expirations need to be measured in months. &=
nbsp;And the credentials are going to be issued to stock IMAP and XMPP clie=
nts that don't have any way of authenticating themselves.=

 
The advantage with OAuth2 over =
passwords is that
a) the refresh tokens are ungu=
essable.
b) the refresh tokens aren't sent dir=
ectly to the IMAP and XMPP servers, they are restricted to authorization se=
rvers.
c) if you've got a managed machine (think=
 Kerberos logins), you can create flows that bridge from those managed cred=
entials to temporary access credentials.
&n=
bsp;
Cheers,
Brian
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B62P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 12:38:23 2011
Return-Path: 
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 3F89421F8673 for ; Wed, 15 Jun 2011 12:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level: 
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o8Ske9e2j4w for ; Wed, 15 Jun 2011 12:38:21 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 30AA721F866B for ; Wed, 15 Jun 2011 12:38:21 -0700 (PDT)
Received: (qmail 7635 invoked from network); 15 Jun 2011 19:38:16 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 19:38:16 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 12:38:15 -0700
From: Eran Hammer-Lahav 
To: OAuth WG 
Date: Wed, 15 Jun 2011 12:37:54 -0700
Thread-Topic: Redirection URI and Implicit grant
Thread-Index: AcwrkXd5SBig2F1wTQuL6ojuGIKt8w==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986B71P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 19:38:23 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B71P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is coming from recent experience building a full web service and multi=
ple clients using OAuth 2.0. I am going to make these changes to my own imp=
lementation and would like to raise the questions here and discuss possible=
 changes.

A few questions:

1. Why not require the registration of a redirection URI for implicit grant=
 requests, removing the redirect_uri parameter completely from the request =
(the client can still use the state parameter)?

2. What is the value of the client_id when a redirection URI is not pre-reg=
istered? The client identity cannot be verified without other means for the=
 purpose of informing the user who is asking for access, no refresh token i=
s issued, and the redirect_uri parameter contains the only useful informati=
on for both the flow and identifying the client (to the extent it can be tr=
usted not to be an open redirector).

3. Are there real use cases for performing redirection URI matching against=
 a pre-registered value, where partial (i.e. not string) comparison is need=
ed? Why can't this be solved by simply using any URI variations into the st=
ate parameter?

Changes I would like to see:

The implicit grant should be split into 2 flavors (can be given different g=
rant type name or just using normative language to define the restrictions)=
, one with client_id and state, and one with redirect_uri only.

Registered client: the client request token response type by including its =
client identifier and optional state parameter. No redirect_uri is allowed.=
 The authorization server will be able to inform the user about the client =
identity, where the token will be sent (the domain of the registered URI, i=
f the server can verify if the endpoint is not an open redirector), and pre=
vent others from hijacking the client identifier for their own application.=
 The exception is when using custom URI schemes which other applications ca=
n hijack on the local operating system (but that's the least of our concern=
 if a native application is doing bad things).

Unregistered client: the client request token response type by including a =
redirection URI (no client_id or state). The authorization server may requi=
re registration of the redirection URI for the purpose of accepting terms o=
f service, but not issue an client identifier which is useless without a re=
gistered redirection URI. This way, the operator of example.com can go to t=
he authorization server and ask to enable issuing tokens to requests with c=
allbacks at example.com, in case the authorization server requires some leg=
al contracts before sharing data.

EHL



--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B71P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This is coming f=
rom recent experience building a full web service and multiple clients usin=
g OAuth 2.0. I am going to make these changes to my own implementation and =
would like to raise the questions here and discuss possible changes.
 
A fe=
w questions:
 
1. Why not require the registration of a redirection URI for=
 implicit grant requests, removing the redirect_uri parameter completely fr=
om the request (the client can still use the state parameter)?
 
2. What is=
 the value of the client_id when a redirection URI is not pre-registered? T=
he client identity cannot be verified without other means for the purpose o=
f informing the user who is asking for access, no refresh token is issued, =
and the redirect_uri parameter contains the only useful information for bot=
h the flow and identifying the client (to the extent it can be trusted not =
to be an open redirector).
 
3. Are there real use cases for performing red=
irection URI matching against a pre-registered value, where partial (i.e. n=
ot string) comparison is needed? Why can’t this be solved by simply u=
sing any URI variations into the state parameter?
 
Changes I would like to=
 see:
 
The implicit grant should be split into 2 flavors (can be given dif=
ferent grant type name or just using normative language to define the restr=
ictions), one with client_id and state, and one with redirect_uri only.
 
R=
egistered client: the client request token response type by including its c=
lient identifier and optional state parameter. No redirect_uri is allowed. =
The authorization server will be able to inform the user about the client i=
dentity, where the token will be sent (the domain of the registered URI, if=
 the server can verify if the endpoint is not an open redirector), and prev=
ent others from hijacking the client identifier for their own application. =
The exception is when using custom URI schemes which other applications can=
 hijack on the local operating system (but that’s the least of our co=
ncern if a native application is doing bad things).
 
Unregistered client:=
 the client request token response type by including a redirection URI (no =
client_id or state). The authorization server may require registration of t=
he redirection URI for the purpose of accepting terms of service, but not i=
ssue an client identifier which is useless without a registered redirection=
 URI. This way, the operator of example.com can go to the authorization ser=
ver and ask to enable issuing tokens to requests with callbacks at example.=
com, in case the authorization server requires some legal contracts before =
sharing data.
 
EHL
 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B71P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 12:50:19 2011
Return-Path: 
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 9952B11E8146 for ; Wed, 15 Jun 2011 12:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNqp-L7FeJdZ for ; Wed, 15 Jun 2011 12:50:17 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 530A211E810D for ; Wed, 15 Jun 2011 12:50:17 -0700 (PDT)
Received: (qmail 32540 invoked from network); 15 Jun 2011 19:50:14 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 19:50:14 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 12:50:02 -0700
From: Eran Hammer-Lahav 
To: Kris Selden 
Date: Wed, 15 Jun 2011 12:49:42 -0700
Thread-Topic: [OAUTH-WG] Refresh tokens
Thread-Index: AcwrkU2z5htX4wEWT+OhVyydm1Yl8QAAoMNA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B80@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <23E83C1C-3874-43D1-A941-F86D79B86B41@gmail.com>
In-Reply-To: <23E83C1C-3874-43D1-A941-F86D79B86B41@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_90C41DD21FB7C64BB94121FBBC2E7234475E986B80P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 19:50:19 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B80P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And we need to say that explicitly.

Even if we allow servers to use the two tokens differently, we should clear=
ly state their design considerations and apply any needed restrictions to m=
ake that clear. We are leaving way too much to the whims of the individual =
developer.

Are the access tokens issued using the implicit grant short lived or long l=
ived?
Is it valid to issue valid-till-revoked access tokens alongside refresh tok=
ens?
What are the requirements for allowing resource owners to revoke access, wh=
en it comes to issued access tokens and refresh tokens?
Why even issue a refresh token, if the client can authenticate with the aut=
horization server. Why not just include the client identifier and user iden=
tifier and let the authorization server lookup what the user already author=
ized? Yes, this requires different client identifiers for different access =
rights, but that's easy to do.

There are many more open questions. I have been convinced from reading the =
last 80 or so messages on the list, that we have given developers too much =
flexibility. We're at a point where I am no longer sure what's the right wa=
y of deploying this. I would like to see use enforce a common-sense approac=
h to deploying these tokens, based on the collective wisdom and deployment =
experience of this group. We have enough hands-on knowledge to agree on how=
 to narrow this down.

I am not looking for dramatic changes. I'm looking for restrictions. I want=
 the protocol to be more helpful to developers who are not security experts=
 to make the right decisions, and that includes me.

Yes, some use cases will suffer, but that's just what standards are about.

EHL



From: Kris Selden [mailto:kris.selden@gmail.com]
Sent: Wednesday, June 15, 2011 12:21 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

There is a scalability reason, in that the access_token could be verifiable=
 on the resource server without DB lookup or a call out to a central server=
, then the refresh token serves as the means for revoking in the "an access=
 token good for an hour, with a refresh token good for a year or good-till-=
revoked."

There is a security reason, the refresh_token is only ever exchanged with a=
uthorization server whereas the access_token is exchanged with resource ser=
vers.  This mitigates the risk of a long-lived access_token leaking (query =
param in a log file on an insecure resource server, beta or poorly coded re=
source server app, JS SDK client on a non https site that puts the access_t=
oken in a cookie, etc) in the "an access token good for an hour, with a ref=
resh token good for a year or good-till-revoked" vs "an access token good-t=
ill-revoked without a refresh token."

On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:


Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a=
 refresh token is for. Right now, we have a very vague definition for it, a=
nd it is not clear how developers should use it alongside access tokens.

EHL



--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B80P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


And we ne=
ed to say that explicitly.
 
Even if we allow s=
ervers to use the two tokens differently, we should clearly state their des=
ign considerations and apply any needed restrictions to make that clear. We=
 are leaving way too much to the whims of the individual developer.
 
Are the access tokens issued using the implicit gran=
t short lived or long lived?
Is it valid to issue valid-till-revoked access tokens alongside refresh =
tokens?
What are the requi=
rements for allowing resource owners to revoke access, when it comes to iss=
ued access tokens and refresh tokens?
Why even issue a refresh token, if the client can authenticate =
with the authorization server. Why not just include the client identifier a=
nd user identifier and let the authorization server lookup what the user al=
ready authorized? Yes, this requires different client identifiers for diffe=
rent access rights, but that’s easy to do.
 
There are many more open questions. I have been convinced from reading =
the last 80 or so messages on the list, that we have given developers too m=
uch flexibility. We’re at a point where I am no longer sure what̵=
7;s the right way of deploying this. I would like to see use enforce a comm=
on-sense approach to deploying these tokens, based on the collective wisdom=
 and deployment experience of this group. We have enough hands-on knowledge=
 to agree on how to narrow this down.
 
I am no=
t looking for dramatic changes. I’m looking for restrictions. I want =
the protocol to be more helpful to developers who are not security experts =
to make the right decisions, and that includes me.
 
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>Yes, some use cases will suffer, but that’s just what standards=
 are about.
 
EHL
 
 
 <=
/span>
From: Kris Selden [mailt=
o:kris.selden@gmail.com] 
Sent: Wednesday, June 15, 2011 12:21 PM=

To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG
=
Subject: Re: [OAUTH-WG] Refresh tokens
 
There =
is a scalability reason, in that the access_token could be verifiable on th=
e resource server without DB lookup or a call out to a central server, then=
 the refresh token serves as the means for revoking in the "an access =
token good for an hour, with a refresh token good for a year or good-till-r=
evoked."
 
There is a security reason, the refre=
sh_token is only ever exchanged with authorization server whereas the&=
nbsp;access_token is exchanged with resource servers.  This mitig=
ates the risk of a long-lived access_token leaking (query param in a log fi=
le on an insecure resource server, beta or poorly coded resource server app=
, JS SDK client on a non https site that puts the access_token in a cookie,=
 etc) in the "an access token good for an hour, with a refresh to=
ken good for a year or good-till-revoked" vs "an access token goo=
d-till-revoked without a refresh token."
 
=
On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:
=



=
Yes, this is useful and on my list of changes to apply.<=
/o:p>
 
But I would like to start with a mo=
re basic, normative definition of what a refresh token is for. Right now, w=
e have a very vague definition for it, and it is not clear how developers s=
hould use it alongside access tokens.
 
EHL
 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B80P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 12:58:42 2011
Return-Path: 
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 1C70211E812B for ; Wed, 15 Jun 2011 12:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.375
X-Spam-Level: 
X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18aVQc-bkh2C for ; Wed, 15 Jun 2011 12:58:40 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E521D11E810D for ; Wed, 15 Jun 2011 12:58:39 -0700 (PDT)
Received: (qmail 12191 invoked from network); 15 Jun 2011 19:58:39 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 19:58:39 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 12:58:32 -0700
From: Eran Hammer-Lahav 
To: Brian Campbell 
Date: Wed, 15 Jun 2011 12:58:12 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwrjLxzhu8fFwX2TWaTKnjGz12sjAACLsOw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986B88P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 19:58:42 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B88P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Well, that's where this is coming from...

Client registration needs to be defined, and it should be specific about th=
e requirements for clients capable of authentication vs. not, as well as th=
e redirection URI registration requirements for using the implicit grant ty=
pe (see other message).

We need to be clear about the value of client authentication, and what does=
 it enables us to do.

The only value I know of for client authentication is when using an authori=
zation code, it prevents others from stealing the code and using it. This e=
nables the authorization server to present information about the client to =
the user with more confidence which helps the user make better decisions.

But I have no idea why we need client authentication for using a refresh to=
ken?

I can see the value of using client authentication with the username/passwo=
rd grant type, to restrict most clients from being allowed to use this flow=
, but at the same time, the most likely clients to use this grant type are =
those who cannot authentication (native applications).

This is goo.

EHL



From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Wednesday, June 15, 2011 11:47 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

Also seems this is related to the topic of native/mobile clients.  As I und=
erstand it, native apps using the authorization code grant/flow have been t=
he primary motivator for keeping client authentication optional.  Anonymous=
 client have come up too.


On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav > wrote:
Client authentication has been one of the main problem areas in OAuth 1.0 a=
nd 2.0 does nothing to resolve it (arguably, it makes it more confusing).

Because of the desire to allow any client type in any deployment environmen=
t, we ended up with a barely defined client authentication model. We offer =
password-based client authentication using HTTP Basic (and an alternative p=
arameter), but leave it optional.

It has been suggested that by doing so, we have made the protocol security =
hard to define and harder to implement properly. The document was written l=
argely with the requirement to use client authentication with any request t=
o the access token endpoint. However, it does allow unauthenticated request=
s in section 3.

Are there any other client properties than the client's ability to authenti=
cate with regards to security?

We have one grant type without client authentication (implicit), two with o=
ptional authentication (authorization code and username/password), and one =
with required authentication (client credentials).

I would like to go back to requiring client authentication for the access t=
oken endpoint, using HTTP Basic or other schemes. To leave the door open fo=
r clients incapable of authenticating to use the endpoint, we will add a se=
curity consideration section discussing the ramifications of using the acce=
ss token endpoint without client authentication.

This suggestions is linked to the topic of refresh tokens which I'll post s=
eparately.

EHL


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


--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B88P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Well, tha=
t’s where this is coming from…
 
Cl=
ient registration needs to be defined, and it should be specific about the =
requirements for clients capable of authentication vs. not, as well as the =
redirection URI registration requirements for using the implicit grant type=
 (see other message).
 
We need to be clear abo=
ut the value of client authentication, and what does it enables us to do.
 
The only value I know of for client authentica=
tion is when using an authorization code, it prevents others from stealing =
the code and using it. This enables the authorization server to present inf=
ormation about the client to the user with more confidence which helps the =
user make better decisions.
 
But I have no ide=
a why we need client authentication for using a refresh token?
 
I can see the value of using client authentication with=
 the username/password grant type, to restrict most clients from being allo=
wed to use this flow, but at the same time, the most likely clients to use =
this grant type are those who cannot authentication (native applications).<=
o:p>
 
This is goo.
 
EH=
L
 =

 
 
From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent:=
 Wednesday, June 15, 2011 11:47 AM
To: Eran Hammer-Lahav
<=
b>Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication =
requirement
&nbs=
p;
Also seems =
this is related to the topic of native/mobile clients.  As I understan=
d it, native apps using the authorization code grant/flow have been the pri=
mary motivator for keeping client authentication optional.  Anonymous =
client have come up too.  


On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<=
/p>
Client authentication has been one of the main problem =
areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes i=
t more confusing).
 
Because=
 of the desire to allow any client type in any deployment environment, we e=
nded up with a barely defined client authentication model. We offer passwor=
d-based client authentication using HTTP Basic (and an alternative paramete=
r), but leave it optional.
 
It has been suggested that by doing so, we have made the protocol security=
 hard to define and harder to implement properly. The document was written =
largely with the requirement to use client authentication with any request =
to the access token endpoint. However, it does allow unauthenticated reques=
ts in section 3.
 
Are there=
 any other client properties than the client’s ability to authenticat=
e with regards to security?
 
We have one grant type without client authentication (implicit), two with=
 optional authentication (authorization code and username/password), and on=
e with required authentication (client credentials). 
=
 
I would like to go back to requiring client aut=
hentication for the access token endpoint, using HTTP Basic or other scheme=
s. To leave the door open for clients incapable of authenticating to use th=
e endpoint, we will add a security consideration section discussing the ram=
ifications of using the access token endpoint without client authentication=
.
 
This suggestions is link=
ed to the topic of refresh tokens which I’ll post separately.
 
EHL=

 

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

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B88P3PW5EX1MB01E_--

From wmills@yahoo-inc.com  Wed Jun 15 13:24:23 2011
Return-Path: 
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 E50C421F8566 for ; Wed, 15 Jun 2011 13:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7ddSWxMRxP9 for ; Wed, 15 Jun 2011 13:24:23 -0700 (PDT)
Received: from nm9-vm0.bullet.mail.ac4.yahoo.com (nm9-vm0.bullet.mail.ac4.yahoo.com [98.139.53.192]) by ietfa.amsl.com (Postfix) with SMTP id C365621F856F for ; Wed, 15 Jun 2011 13:24:22 -0700 (PDT)
Received: from [98.139.52.196] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:17 -0000
Received: from [98.139.52.134] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:17 -0000
Received: from [127.0.0.1] by omp1017.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 295246.35010.bm@omp1017.mail.ac4.yahoo.com
Received: (qmail 15720 invoked by uid 60001); 15 Jun 2011 20:24:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1308169456; bh=FOuNDWti9FtoDaqt/Yo30/TlWOChiyKx45P9qJ/aooE=; 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=JJR90zTF78pjKONzks8O7GRCE/1eFnzOQQq1Pvo6YAfDvL7S01z3Olm8sYQ3OYGfKcSKpAEJgbO0QkmXPgQVd6gpXz7bLBoydmOp83d7pen8fx0j9bLChcaExqoPn6f2hR+P6XfqzxTj5P6vSfwWizjOfkI2VLgfx2b+Yr1ECZw=
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=GpvUBiRPDNN/5QlSsDKLNkBpaZc5yxlN/oJhTovbLItgbeU2rTKVeIWrHkLFk97mmMSrDGsTxz2Udx6ZxxqJQ8fjIDAeeS0ChE/IOKQVowKD3YLypi7oYb+KF8RtqXmQcQ+szjBlcsj+oQgQ6Ifn7vXwzTpcUzA9yR4EOnJ4Fug=;
X-YMail-OSG: l_b99o4VM1nVVXH74RZBle68wdaS6lsoiUYL3W1KS3WzNZv 414MkFbPj7S3OJRZyyc4xJxF1MIUebYQzMTJ3inRxnkSKiMdnZJ.P6lEN6y2 kgNjT5m.P3oIs5HsDrzFlrMRiFxjCIOaH6NL0MjmWvmRL9yrLtEdKny_BPPH MlvhdvGNzOMPxJ7pu_3i.uyeVUptHUjqILkEHm90R9fT8WOopCoUEd3Vx5ul VVqhwEIY_wPtIhv3rCCwCoQekoF.H1m9.YgZj4zoFk9QV42VNqEgEV6pkWpJ 1.wqf1gIaGu9wq_2stjHSrY0XUOd2DQK_OGlYdNN_NQTivARwgq6tIm3Wh7e QOfEFlU7fMJwgOWICfaOUIPwMKG8Zl6PIz4cx1kgwRaI-
Received: from [216.145.52.206] by web31810.mail.mud.yahoo.com via HTTP; Wed, 15 Jun 2011 13:24:16 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Message-ID: <1308169456.72680.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Wed, 15 Jun 2011 13:24:16 -0700 (PDT)
From: "William J. Mills" 
To: Brian Eaton , Eran Hammer-Lahav 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1585333484-1308169456=:72680"
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 20:24:24 -0000

--0-1585333484-1308169456=:72680
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I like your draft in general, but =0A=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0 10.1.3.=
 Access Tokens=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0 Access tokens are shorter-live=
d versions of refresh tokens.=0A=0ADoesn't work for me.  Access tokens are =
credentials used to access protected resources.  Refresh =0Atokens are cred=
entials used to obtain access tokens.=0A=0A-bill=0A=0A=0A=0A_______________=
_________________=0AFrom: Brian Eaton =0ATo: Eran Hammer=
-Lahav =0ACc: OAuth WG =0ASent: Wednes=
day, June 15, 2011 11:32 AM=0ASubject: Re: [OAUTH-WG] Refresh tokens=0A=0A=
=0AOn Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav  wrote:=0A=0AI would like to add a quick discussion of access token and re=
fresh token recommended deployment setup, providing clear guidelines when a=
 refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is =
difference from the access token.=0A=0AIs this a start?=0A=0Ahttp://www.iet=
f.org/mail-archive/web/oauth/current/msg06362.html=0A=C2=A0=C2=A0=0AIt=E2=
=80=99s time we stop trying to accommodate every possible combination and m=
ake some hard choices.=0A=0A+1. =C2=A0Yes please.=0A_______________________=
________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://ww=
w.ietf.org/mailman/listinfo/oauth
--0-1585333484-1308169456=:72680
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


I like your draft in general, but 

 &=
nbsp;   10.1.3. Access Tokens

  &nb=
sp;  Access tokens are shorter-lived versions of refresh tokens=
.

Doesn't work for me.  Access tokens are credentials used to access=
 protected resources.  Refresh 
tokens are credentials used to obtain ac=
cess tokens.

-bill

From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav
 <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Wednesday, June 15, 2011 11:32 AM
Subject: Re: [OAUTH-WG] Refresh tokens<=
br>
=0A
On Wed, Jun 15, 2011 at 10:30 AM=
, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
=0A
I would like to add a quick discussion of access token and refresh token =
recommended deployment setup, providing clear guidelines when a refresh tok=
en SHOULD and SHOULD NOT be issued, and when issues, how it is difference f=
rom the access token.
=0A

=
Is this a start?

http://www.ietf.org/mail-archive/=
web/oauth/current/msg06362.html
=0A
  
It=E2=80=99s time we stop trying to accommodate ever=
y possible combination and make some hard choices.
=0A
<=
/div>
+1.  Yes please.
=0A

_____________________=
__________________________
OAuth mailing list
OAuth@ietf.org
https://=
www.ietf.org/mailman/listinfo/oauth



--0-1585333484-1308169456=:72680--

From wmills@yahoo-inc.com  Wed Jun 15 13:24:58 2011
Return-Path: 
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 882E221F859F for ; Wed, 15 Jun 2011 13:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7oW7Lf9ytrb for ; Wed, 15 Jun 2011 13:24:57 -0700 (PDT)
Received: from nm28-vm0.bullet.mail.ac4.yahoo.com (nm28-vm0.bullet.mail.ac4.yahoo.com [98.139.52.246]) by ietfa.amsl.com (Postfix) with SMTP id DCD1721F859E for ; Wed, 15 Jun 2011 13:24:56 -0700 (PDT)
Received: from [98.139.52.197] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:56 -0000
Received: from [98.139.52.145] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:56 -0000
Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 15 Jun 2011 20:24:56 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 398585.63915.bm@omp1028.mail.ac4.yahoo.com
Received: (qmail 27681 invoked by uid 60001); 15 Jun 2011 20:24:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1308169495; bh=eUlrs5rxlUsPhDuIIrJ+0FRBlu7CbCJUI7dxkkdgRuk=; 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=krTi7+q5+M1MXDbXtxOlDoYDfQishvLO+TRLUJfMVWOGJToUJWE5l5TtEHZwWigVbuqqcRunL5LXpZBJc222deJ1vjjJosjUHXD2624CfrvF8O4kz4TwrScwHfiCm2fbDwU1hH6Px0i/CaT+fqFo4osa8i5vL6HWtKW6PM0WSeU=
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=g1r6FNLYUTE2m5ATkgOeW0NklpqHO0rcGX+0ghsodp7PyOgCEYvY/mgilP19NaA3PVU829X3uwccIfd79BZLxjtaj7jX6FCuFOOJHV5qUwPintgDQylBmrwuM5BpDpQ+u9gDtvXdavPsJOxMfztiBFqm/TYxdI61VeFZ/GfNJYg=;
X-YMail-OSG: 31ggCvYVM1kKLddZ2GZQ8kzpIDJfvDkp13SLgyK2TQ.S4_Z YUqxygpzoY66.PjF8V9N0Z3oeF8Jmkvjd1Mocru92YWSW3xZ3PIeaAtnFcVo cUKy49wefcuUgwl4k5CX8O_JskxJv1OwMLzUVoYJGpEygplOY2AuLBVET7SQ XbtEIfFbMAgmTRAzSA9Qu0USE_o02GORC6nTV0UCPBY9dMajlGtTKN3uhqjR y2ugflp7Uyfa.hzRi4_dGHP3K3Qn.mb_29DjDgC7o6W4X8Okv5Beaaxs_bHL zEvzl9rzAddHSZnJc6fWCPeW_.5.1YJM6__3.PnA.Sm3EkX3BQQppRYU18w_ DEXxoiB.J40tEVWnIfLeLio6SFtfuqyxVTPUKt7hqiI2LHHV4ERPYgkkxhn6 ZjYSlCz7BZUfoBg2ApTYeRbfqrstNZcEQTcE5CqzSi0vFqYSd1MxScZNJ4jw iyIEtE.DK84RZsautk6Ok3Lwf5iT6DKDU0HqhjAcDTd5FrfkxLF3LTwxet7l R0339PGP4MTl8mkd9wQhmOnjL1OdzfYZPQYwEXmM-
Received: from [216.145.52.206] by web31809.mail.mud.yahoo.com via HTTP; Wed, 15 Jun 2011 13:24:55 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Message-ID: <1308169495.19206.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Wed, 15 Jun 2011 13:24:55 -0700 (PDT)
From: "William J. Mills" 
To: John Bradley , Eran Hammer-Lahav 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-633154733-1308169495=:19206"
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 20:24:58 -0000

--0-633154733-1308169495=:19206
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Makes sense to me.=0A=0A=0A=0A________________________________=0AFrom: John=
 Bradley =0ATo: Eran Hammer-Lahav =
=0ACc: paul Tarjan ; "oauth@ietf.org" =
=0ASent: Wednesday, June 15, 2011 11:04 AM=0ASubject: Re: [OAUTH-WG] consis=
tency of token param name in bearer token type=0A=0AI agree access_token is=
 better.=0A=0AJohn B.=0AOn 2011-06-15, at 1:38 PM, Eran Hammer-Lahav wrote:=
=0A=0A> It should be pretty easy :-)=0A> =0A> Anyone objects to changing th=
e parameter name from 'bearer_token' to 'access_token'? Let Mike know by 6/=
20 or he will make the change.=0A> =0A> EHL=0A> =0A> =0A>> -----Original Me=
ssage-----=0A>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org=
] On Behalf=0A>> Of Mike Jones=0A>> Sent: Wednesday, June 01, 2011 1:15 PM=
=0A>> To: David Recordon; George Fletcher=0A>> Cc: paul Tarjan; oauth@ietf.=
org=0A>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer =
token=0A>> type=0A>> =0A>> If you can drive a consensus decision for the na=
me "access_token", I'd be=0A>> glad to change the name in the spec.=A0 I ag=
ree that the current names are=0A>> confusing for developers.=0A>> =0A>> =
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A>> =0A>> -----Original Me=
ssage-----=0A>> From: David Recordon [mailto:recordond@gmail.com]=0A>> Sent=
: Wednesday, June 01, 2011 12:06 AM=0A>> To: George Fletcher=0A>> Cc: Mike =
Jones; Doug Tangren; oauth@ietf.org; paul Tarjan=0A>> Subject: Re: [OAUTH-W=
G] consistency of token param name in bearer token=0A>> type=0A>> =0A>> Yea=
h, can understand how we got here. Just found it quite confusing when=0A>> =
reading these two specifications together with an implementor's hat on.=0A>=
> =0A>> On Tue, May 31, 2011 at 12:29 PM, George Fletcher =0A>> wrote:=0A>>> Brief pointer to the "history" of this change. This cha=
nge was adopted=0A>>> in draft 4 of the bearer spec as there were concerns =
with the previous=0A>>> parameter name of 'oauth_token'. The suggestion was=
 made to use=0A>>> 'bearer_token' so that it matches the scheme used in the=
 Authorization=0A>>> header. The thinking being that reading the bearer tok=
en spec would=0A>>> seem weird if the Authorization header used one name an=
d the GET/POST=0A>>> methods used a different name.=0A>>> =0A>>> The 'beare=
r_token' name got a few +1 and no dissents.=0A>>> =0A>>> Full thread starts=
 here [1]. Mike accepting the 'bearer_token'=0A>>> recommendation is here [=
2].=0A>>> =0A>>> Thanks,=0A>>> George=0A>>> =0A>>> [1] http://www.ietf.org/=
mail-archive/web/oauth/current/msg05497.html=0A>>> [2] http://www.ietf.org/=
mail-archive/web/oauth/current/msg05881.html=0A>>> =0A>>> On 5/28/11 12:30 =
PM, David Recordon wrote:=0A>>> =0A>>> Did a full read through of draft 16 =
and the bear token spec with Paul=0A>>> yesterday afternoon in order to do =
a manual diff from draft 10. The=0A>>> point Doug raised was actually confu=
sing. Throughout the core spec=0A>>> it's referred to as access_token but t=
hen becomes bearer_token upon=0A>>> use.=0A>>> =0A>>> Just thinking through=
 this from a developer documentation perspective,=0A>>> it's going to becom=
e confusing. Developer documentation focuses on=0A>>> getting an access tok=
en and then using that access token to interact=0A>>> with an API. Thus the=
 code you're writing as a client developer will=0A>>> use variables, cache =
keys, and database columns named `access_token`.=0A>>> But then when you're=
 going to use it, you'll need to put this access=0A>>> token into a field n=
amed bearer_token.=0A>>> =0A>>> Feels quite a bit simpler to just name it a=
ccess_token. Realize the=0A>>> core spec never did this since we didn't wan=
t to trample on protected=0A>>> resources which might already have a differ=
ent type of access_token=0A>>> parameter. oauth_token was a good compromise=
 since developers would=0A>>> already know that they were using OAuth and t=
hus a new term wasn't=0A>>> being introduced. That's no longer true with be=
arer_token since 99% of=0A>>> developers will have never heard of a bearer =
token.=0A>>> =0A>>> Googling for "bearer token" turns up Eran's blog post t=
itled "OAuth=0A>>> Bearer Tokens are a Terrible Idea" and there isn't a sin=
gle result on=0A>>> the first page which explains what they are. Binging fo=
r "bearer=0A>>> token" is equally scary.=0A>>> =0A>>> --David=0A>>> =0A>>> =
=0A>>> On Mon, May 23, 2011 at 11:38 AM, Mike Jones=0A>>>  wrote:=0A>>> =0A>>> The working group explicitly decided that =
a different name should be=0A>>> used, to make it clear that other token ty=
pes other than bearer tokens=0A>>> could also be used with OAuth 2.=0A>>> =
=0A>>> =0A>>> =0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  -- Mike=
=0A>>> =0A>>> =0A>>> =0A>>> From: oauth-bounces@ietf.org [mailto:oauth-boun=
ces@ietf.org] On Behalf=0A>>> Of Doug Tangren=0A>>> Sent: Wednesday, May 11=
, 2011 10:09 PM=0A>>> To: oauth@ietf.org=0A>>> Subject: [OAUTH-WG] consiste=
ncy of token param name in bearer token=0A>>> type=0A>>> =0A>>> =0A>>> =0A>=
>> This may have come up before so I'm sorry if I'm repeating. Why does=0A>=
>> bearer token spec introduce a new name for oauth2 access tokens [1],=0A>=
>> "bearer_token", and before that [2], "oauth_token"?=0A>>> =0A>>> =0A>>> =
=0A>>> I apologize if this may sound shallow but, why introduce a new=0A>>>=
 parameter name verses sticking with what the general oauth2 spec=0A>>> alr=
eady defines, "access_token". It seems arbitrary for an auth server=0A>>> t=
o hand a client an apple then have the client hand it off to the=0A>>> reso=
urce server and call it an orange.=0A>>> =0A>>> =0A>>> =0A>>> Was this just=
 for the sake of differentiating the parameter name=0A>>> enough so that th=
e bearer tokens may be used in other protocols=0A>>> without being confused=
 with oauth2 access_tokens?=0A>>> =0A>>> =0A>>> =0A>>> [1]:=0A>>> http://to=
ols.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2=0A>>> =0A>>> [2=
]:=0A>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2=
.2=0A>>> =0A>>> =0A>>> =0A>>> -Doug Tangren=0A>>> http://lessis.me=0A>>> =
=0A>>> _______________________________________________=0A>>> OAuth mailing =
list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth=
=0A>>> =0A>>> =0A>>> _______________________________________________=0A>>> =
OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/=
listinfo/oauth=0A>>> =0A>>> =0A>>> --=0A>>> Chief Architect=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0  AIM:=A0 gffletch=0A>>> Identity Services Engineering=
=A0 =A0  Work: george.fletcher@teamaol.com=0A>>> AOL Inc.=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Home: gffletch@aol.com=0A>>> Mobile: +1=
-703-462-3494=A0 =A0 =A0 =A0 =A0  Blog: http://practicalid.blogspot.com=0A>=
>> Office: +1-703-265-2544=A0 =A0 =A0 =A0 =A0  Twitter: http://twitter.com/=
gffletch=0A>>> =0A>> =0A>> _______________________________________________=
=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mail=
man/listinfo/oauth=0A> _______________________________________________=0A> =
OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/list=
info/oauth=0A=0A_______________________________________________=0AOAuth mai=
ling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--0-633154733-1308169495=:19206
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Makes sense to me.

=

From: John Bradley <ve7jtb@ve7jtb.com>
To: Eran Hammer-Lahav <eran@h=
ueniverse.com>
Cc: p=
aul Tarjan <paul.tarjan@fb.com>; "oauth@ietf.org" <oauth@ietf.org&=
gt;
Sent: Wednesday, Ju=
ne 15, 2011 11:04 AM
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type<=
br>
=0AI agree access_token is better.

John B.
On 2011-=
06-15, at 1:38 PM, Eran Hammer-Lahav wrote:

> It should be pretty=
 easy :-)
> 
> Anyone objects to changing the parameter name fr=
om 'bearer_token' to 'access_token'? Let Mike know by 6/20 or he will make =
the change.
> 
> EHL
> 
> 
>> -----Origina=
l Message-----
>> From: oauth-bounces@ietf.org [mailt=
o:oauth-bounces@ietf.org] On Behalf
>> Of Mike Jones<=
br>>> Sent: Wednesday, June 01, 2011 1:15 PM
>> To: David Re=
cordon; George Fletcher
>> Cc: paul Tarjan; oauth@ietf.org
>>=
; Subject: Re: [OAUTH-WG] consistency of token param name in bearer token>>
 type
>> 
>> If you can drive a consensus decision for th=
e name "access_token", I'd be
>> glad to change the name in the sp=
ec.  I agree that the current names are
>> confusing for deve=
lopers.
>> 
>>         &nbs=
p;       -- Mike
>> 
>> -----Ori=
ginal Message-----
>> From: David Recordon [mailto:recordond@gm=
ail.com]
>> Sent: Wednesday, June 01, 2011 12:06 AM
>>=
; To: George Fletcher
>> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
>> Subject: Re: [OAUTH-WG] consistency of token par=
am name in bearer token
>> type
>> 
>> Yeah, can=
 understand how we got here. Just found it quite confusing when
>>
 reading these two specifications together with an implementor's hat on.>> 
>> On Tue, May 31, 2011 at 12:29 PM, George Fletcher &l=
t;g=
ffletch@aol.com>
>> wrote:
>>> Brief pointer to=
 the "history" of this change. This change was adopted
>>> in d=
raft 4 of the bearer spec as there were concerns with the previous
>&=
gt;> parameter name of 'oauth_token'. The suggestion was made to use
=
>>> 'bearer_token' so that it matches the scheme used in the Autho=
rization
>>> header. The thinking being that reading the bearer=
 token spec would
>>> seem weird if the Authorization header us=
ed one name and the GET/POST
>>> methods used a different name.=

>>> 
>>> The 'bearer_token' name got a few +1 and =
no dissents.
>>> 
>>> Full thread starts here
 [1]. Mike accepting the 'bearer_token'
>>> recommendation is h=
ere [2].
>>> 
>>> Thanks,
>>> George>>> 
>>> [1] http://www.ietf.org/mail-archive/web/oau=
th/current/msg05497.html
>>> [2] http://www.ietf.org/mail-archi=
ve/web/oauth/current/msg05881.html
>>> 
>>> On 5/28=
/11 12:30 PM, David Recordon wrote:
>>> 
>>> Did a =
full read through of draft 16 and the bear token spec with Paul
>>=
> yesterday afternoon in order to do a manual diff from draft 10. The>>> point Doug raised was actually confusing. Throughout the core=
 spec
>>> it's referred to as access_token but then becomes bea=
rer_token upon
>>> use.
>>> 
>>> Just t=
hinking through this from a developer documentation perspective,
>>=
;> it's going to become confusing. Developer documentation
 focuses on
>>> getting an access token and then using that acc=
ess token to interact
>>> with an API. Thus the code you're wri=
ting as a client developer will
>>> use variables, cache keys, =
and database columns named `access_token`.
>>> But then when yo=
u're going to use it, you'll need to put this access
>>> token =
into a field named bearer_token.
>>> 
>>> Feels qui=
te a bit simpler to just name it access_token. Realize the
>>> =
core spec never did this since we didn't want to trample on protected
&g=
t;>> resources which might already have a different type of access_to=
ken
>>> parameter. oauth_token was a good compromise since deve=
lopers would
>>> already know that they were using OAuth and th=
us a new term wasn't
>>> being introduced. That's no longer tru=
e with bearer_token since 99% of
>>> developers will
 have never heard of a bearer token.
>>> 
>>> Googl=
ing for "bearer token" turns up Eran's blog post titled "OAuth
>>&=
gt; Bearer Tokens are a Terrible Idea" and there isn't a single result on>>> the first page which explains what they are. Binging for "be=
arer
>>> token" is equally scary.
>>> 
>>&=
gt; --David
>>> 
>>> 
>>> On Mon, May 2=
3, 2011 at 11:38 AM, Mike Jones
>>> <Mich=
ael.Jones@microsoft.com> wrote:
>>> 
>>> The=
 working group explicitly decided that a different name should be
>&g=
t;> used, to make it clear that other token types other than bearer toke=
ns
>>> could also be used with OAuth 2.
>>> 
>=
;>> 
>>> 
>>>       
                     &nbs=
p;                     &n=
bsp;          -- Mike
>>> 
>>> =

>>> 
>>> From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of =
Doug Tangren
>>> Sent: Wednesday, May 11, 2011 10:09 PM
>=
>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] consistency of=
 token param name in bearer token
>>> type
>>> 
=
>>> 
>>> 
>>> This may have come up before=
 so I'm sorry if I'm repeating. Why does
>>> bearer token spec
 introduce a new name for oauth2 access tokens [1],
>>> "bearer=
_token", and before that [2], "oauth_token"?
>>> 
>>&g=
t; 
>>> 
>>> I apologize if this may sound shallow =
but, why introduce a new
>>> parameter name verses sticking wit=
h what the general oauth2 spec
>>> already defines, "access_tok=
en". It seems arbitrary for an auth server
>>> to hand a client=
 an apple then have the client hand it off to the
>>> resource =
server and call it an orange.
>>> 
>>> 
>>=
> 
>>> Was this just for the sake of differentiating the par=
ameter name
>>> enough so that the bearer tokens may be used in=
 other protocols
>>> without being confused with oauth2 access_=
tokens?
>>> 
>>> 
>>> 
>>> =
[1]:
>>>
 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
&g=
t;>> 
>>> [2]:
>>> http://tools.ietf.org/html=
/draft-ietf-oauth-v2-bearer-03#section-2.2
>>> 
>>>=
 
>>> 
>>> -Doug Tangren
>>> http://les=
sis.me
>>> 
>>> ___________________________________=
____________
>>> 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
>&=
gt;> 
>>> 
>>> --
>>> Chief Architec=
t                   AIM: =
 gffletch
>>> Identity Services Engineering     Work:=
 george.fletcher@teamaol.com
>>> AOL Inc=
.                    &nbs=
p;     Home: gffletch@aol.com
>>> Mobile: +1-703-462=
-3494           Blog: http://practicalid.blogspot.=
com
>>> Office: +1-703-265-2544        &nbs=
p;  Twitter: http://twitter.com/gffletch
>>> 
>> 
&=
gt;> _______________________________________________
>> OAuth
 mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailm=
an/listinfo/oauth
> _____________________________________________=
__
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.o=
rg/mailman/listinfo/oauth

______________________________________=
_________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm=
an/listinfo/oauth



--0-633154733-1308169495=:19206--

From beaton@google.com  Wed Jun 15 13:39:30 2011
Return-Path: 
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 72ADC11E812B for ; Wed, 15 Jun 2011 13:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkt6FmOgF3BO for ; Wed, 15 Jun 2011 13:39:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6111E809A for ; Wed, 15 Jun 2011 13:39:29 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p5FKdSe3013332 for ; Wed, 15 Jun 2011 13:39:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308170368; bh=FAV1BoNjbYTgi+d41a0FU0YDyY0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JjoLqJkmgPTLKbmUVriOq1+gnTo26pQnXeCnNHtyDsQ6jaXMpCqR0QSv9Kmg5Mem2 X093CiFMUzay19ieUimkQ==
Received: from yib19 (yib19.prod.google.com [10.243.65.83]) by wpaz37.hot.corp.google.com with ESMTP id p5FKcRBx008262 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 13:39:27 -0700
Received: by yib19 with SMTP id 19so606007yib.37 for ; Wed, 15 Jun 2011 13:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o0rtiCm3c4U6iMK4X9VhXLzqPsFPr0CW8YH8kJqqju0=; b=kCyhDNKhKDEcY6+dYpbhRlnBChqI1koRaOaKjpOaDwMW+74kgZNoXlYOUYEQAeU+rX v07Aa5MblQsnGDW7KaPw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ucdBXh+jRX5VcpXshSW4ugAfYxzcfiGfKjVlW1jZ2/PmZNuw+ZMi0/GF2I04j0TRkU ksKKmILWLY2MwQXuVY6A==
MIME-Version: 1.0
Received: by 10.91.197.10 with SMTP id z10mr118677agp.143.1308170365905; Wed, 15 Jun 2011 13:39:25 -0700 (PDT)
Received: by 10.91.219.18 with HTTP; Wed, 15 Jun 2011 13:39:25 -0700 (PDT)
In-Reply-To: <1308169456.72680.YahooMailNeo@web31810.mail.mud.yahoo.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <1308169456.72680.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Wed, 15 Jun 2011 13:39:25 -0700
Message-ID: 
From: Brian Eaton 
To: "William J. Mills" 
Content-Type: multipart/alternative; boundary=00163676589bf72d1704a5c62564
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 20:39:30 -0000

--00163676589bf72d1704a5c62564
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yeah, I agree with that change.

On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills wro=
te:

> I like your draft in general, but
>
>
>      10.1.3. Access Tokens
>
>      Access tokens are shorter-lived versions of refresh tokens.
>
> Doesn't work for me.  Access tokens are credentials used to access protec=
ted resources.  Refresh
> tokens are credentials used to obtain access tokens.
>
> -bill
>
>
> ------------------------------
> *From:* Brian Eaton 
> *To:* Eran Hammer-Lahav 
> *Cc:* OAuth WG 
> *Sent:* Wednesday, June 15, 2011 11:32 AM
>
> *Subject:* Re: [OAUTH-WG] Refresh tokens
>
> On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav =
wrote:
>
> I would like to add a quick discussion of access token and refresh token
> recommended deployment setup, providing clear guidelines when a refresh
> token SHOULD and SHOULD NOT be issued, and when issues, how it is differe=
nce
> from the access token.
>
>
> Is this a start?
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html
>
>
> **
> It=92s time we stop trying to accommodate every possible combination and =
make
> some hard choices.****
> **
>
>
> +1.  Yes please.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--00163676589bf72d1704a5c62564
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yeah, I agree with that change.

On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills <=
wmills@yahoo-inc.com>=
 wrote:




I like your draft in general, but 

=A0=A0=A0=A0 10.1.3. Access Tokens

=A0=A0=A0=A0 Access tokens are shorter-lived versions of refresh tokens.

Doesn&=
#39;t work for me.  Access tokens are credentials used to access protected =
resources.  Refresh 

tokens are credentials used to obtain access tokens.

-bill
=




From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav
 <eran@hueniver=
se.com>
Cc: OAuth =
WG <oauth@ietf.org>

Sent: Wednesday, June 15, 20=
11 11:32 AM

Subjec=
t: Re: [OAUTH-WG] Refresh tokens




On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav =
<eran@hueniverse.com> wrote:



I would like to add a quick discussion of acc=
ess token and refresh token recommended deployment setup, providing clear g=
uidelines when a refresh token SHOULD and SHOULD NOT be issued, and when is=
sues, how it is difference from the access token.




Is this a start?



=A0=A0
It=92s time we stop trying to accommodate every possibl=
e combination and make some hard choices.




+1. =A0Yes please=
.



_______________________________________________
OA=
uth mailing list
OAu=
th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--00163676589bf72d1704a5c62564--

From beaton@google.com  Wed Jun 15 13:52:53 2011
Return-Path: 
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 5F87F11E817A for ; Wed, 15 Jun 2011 13:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.826
X-Spam-Level: 
X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B55H7rOZmBfN for ; Wed, 15 Jun 2011 13:52:52 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3A11E8159 for ; Wed, 15 Jun 2011 13:52:51 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5FKqo0k009512 for ; Wed, 15 Jun 2011 13:52:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308171171; bh=V+itQ9ELf6ab0gYZ9E75jzfnHq8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dCZlCP1sQPCD1C97FCN+sn1Kei+Um9ZUpqLJs8RQE4gEKwjcecHI6631UpXTjwwUI 6wykAmM3HNvazKTi31mTg==
Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by wpaz33.hot.corp.google.com with ESMTP id p5FKqEWB007666 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 13:52:49 -0700
Received: by gxk28 with SMTP id 28so664676gxk.13 for ; Wed, 15 Jun 2011 13:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iIr2xhOfYJT4A0thFPgNr4y15ukOAr3mk/YJt7koQeU=; b=B2FFXZrRhEUjkKadO8fZKgNM8i/XPSjizuZnM4HkbqF70D7euaoQnUummIvtBSgFNn RA4Gg16vqg5NN2HVM99g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FRoxm6emN3XtXvktL/EQe30NsA3ch9yGNLALPirRjBcWDkPfXrucMY2ykxgWEIXSrv 78VkqQWQeH3KGRPBo4oA==
MIME-Version: 1.0
Received: by 10.90.66.12 with SMTP id o12mr147529aga.116.1308171168909; Wed, 15 Jun 2011 13:52:48 -0700 (PDT)
Received: by 10.91.219.18 with HTTP; Wed, 15 Jun 2011 13:52:48 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 13:52:48 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=0016361e892cd40a1004a5c655c6
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 20:52:53 -0000

--0016361e892cd40a1004a5c655c6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

> We have one grant type without client authentication (implicit)

I suspect another choice of words would be useful there.  Implicit grants
rely on the browser's authentication of the receiving web site.  When https
is used, that authentication is fairly strong.

> I would like to go back to requiring client authentication for the access
token endpoint

Sure.  Why not?

1) It makes the spec simpler.
2) It has no impact on the security of clients that can't keep secrets.
3) It has no impact on the security of clients that can keep secrets.

> But I have no idea why we need client authentication for using a refresh
token?

****

This is covered here:
http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html.

Cheers,
Brian

On Wed, Jun 15, 2011 at 12:58 PM, Eran Hammer-Lahav wr=
ote:

> Well, that=92s where this is coming from=85****
>
> ** **
>
> Client registration needs to be defined, and it should be specific about
> the requirements for clients capable of authentication vs. not, as well a=
s
> the redirection URI registration requirements for using the implicit gran=
t
> type (see other message).****
>
> ** **
>
> We need to be clear about the value of client authentication, and what do=
es
> it enables us to do.****
>
> ** **
>
> The only value I know of for client authentication is when using an
> authorization code, it prevents others from stealing the code and using i=
t.
> This enables the authorization server to present information about the
> client to the user with more confidence which helps the user make better
> decisions.****
>
> ** **
>
> But I have no idea why we need client authentication for using a refresh
> token?****
>
> ** **
>
> I can see the value of using client authentication with the
> username/password grant type, to restrict most clients from being allowed=
 to
> use this flow, but at the same time, the most likely clients to use this
> grant type are those who cannot authentication (native applications).****
>
> ** **
>
> This is goo.****
>
> ** **
>
> EHL****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
> *Sent:* Wednesday, June 15, 2011 11:47 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Client authentication requirement****
>
> ** **
>
> Also seems this is related to the topic of native/mobile clients.  As I
> understand it, native apps using the authorization code grant/flow have b=
een
> the primary motivator for keeping client authentication optional.  Anonym=
ous
> client have come up too.
>
>
> ****
>
> On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav 
> wrote:****
>
> Client authentication has been one of the main problem areas in OAuth 1.0
> and 2.0 does nothing to resolve it (arguably, it makes it more confusing)=
.
> ****
>
>  ****
>
> Because of the desire to allow any client type in any deployment
> environment, we ended up with a barely defined client authentication mode=
l.
> We offer password-based client authentication using HTTP Basic (and an
> alternative parameter), but leave it optional.****
>
>  ****
>
> It has been suggested that by doing so, we have made the protocol securit=
y
> hard to define and harder to implement properly. The document was written
> largely with the requirement to use client authentication with any reques=
t
> to the access token endpoint. However, it does allow unauthenticated
> requests in section 3.****
>
>  ****
>
> Are there any other client properties than the client=92s ability to
> authenticate with regards to security?****
>
>  ****
>
> We have one grant type without client authentication (implicit), two with
> optional authentication (authorization code and username/password), and o=
ne
> with required authentication (client credentials). ****
>
>  ****
>
> I would like to go back to requiring client authentication for the access
> token endpoint, using HTTP Basic or other schemes. To leave the door open
> for clients incapable of authenticating to use the endpoint, we will add =
a
> security consideration section discussing the ramifications of using the
> access token endpoint without client authentication.****
>
>  ****
>
> This suggestions is linked to the topic of refresh tokens which I=92ll po=
st
> separately.****
>
>  ****
>
> EHL****
>
>  ****
>
>
> _______________________________________________
> 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
>
>

--0016361e892cd40a1004a5c655c6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

> We have one grant type with=
out client authentication (implicit)


I suspect a=
nother choice of words would be useful there. =A0Implicit grants rely on th=
e browser's authentication of the receiving web site. =A0When https is =
used, that authentication is fairly strong.



>=A0I would like to go back to requiring client authentication for the a=
ccess token endpoint



Sure. =A0Why not?



<=
span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">1) It =
makes the spec simpler.


2) It has no im=
pact on the security of clients that can't keep secrets.<=
/div>

3) It has no im=
pact on the security of clients that can keep secrets.
<=
meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">

>=A0But I have no idea why we need client authentication for using a=
 refresh token?








Cheers,
Brian



On Wed, Jun 15, 2011 at 12:58 PM, =
Eran Hammer-Lahav <eran@hueniverse.com> wrote:


Well, that=92s where thi=
s is coming from=85
=A0


Clien=
t registration needs to be defined, and it should be specific about the req=
uirements for clients capable of authentication vs. not, as well as the red=
irection URI registration requirements for using the implicit grant type (s=
ee other message).


=A0
We need to be clear about the value of client authenticat=
ion, and what does it enables us to do.


=A0
The only value I know of for client authentication is whe=
n using an authorization code, it prevents others from stealing the code an=
d using it. This enables the authorization server to present information ab=
out the client to the user with more confidence which helps the user make b=
etter decisions.


=A0
But I have no idea why we need client authentication for =
using a refresh token?


=A0
I can see the value of using client authentication with t=
he username/password grant type, to restrict most clients from being allowe=
d to use this flow, but at the same time, the most likely clients to use th=
is grant type are those who cannot authentication (native applications).=



=A0
This is goo.
=A0<=
/p>

EHL
=A0
=A0


=A0


=A0
Also seems this is related to the =
topic of native/mobile clients.=A0 As I understand it, native apps using th=
e authorization code grant/flow have been the primary motivator for keeping=
 client authentication optional.=A0 Anonymous client have come up too.=A0 <=
br>


On Wed, Jun 15, 2011 =
at 11:26 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
<=
div>

Client authentication has been one of the main probl=
em areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it make=
s it more confusing).
=A0=



Because of the desire to allow any client type in an=
y deployment environment, we ended up with a barely defined client authenti=
cation model. We offer password-based client authentication using HTTP Basi=
c (and an alternative parameter), but leave it optional.


=A0
It has b=
een suggested that by doing so, we have made the protocol security hard to =
define and harder to implement properly. The document was written largely w=
ith the requirement to use client authentication with any request to the ac=
cess token endpoint. However, it does allow unauthenticated requests in sec=
tion 3.


=A0
Are ther=
e any other client properties than the client=92s ability to authenticate w=
ith regards to security?
=A0=



We have one grant type without client authentication=
 (implicit), two with optional authentication (authorization code and usern=
ame/password), and one with required authentication (client credentials). <=
u>


=A0
I would =
like to go back to requiring client authentication for the access token end=
point, using HTTP Basic or other schemes. To leave the door open for client=
s incapable of authenticating to use the endpoint, we will add a security c=
onsideration section discussing the ramifications of using the access token=
 endpoint without client authentication.


=A0
This sug=
gestions is linked to the topic of refresh tokens which I=92ll post separat=
ely.
=A0

EHL
=A0

________________=
_______________________________

OAuth mailing list
O=
Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
u>


=A0
<=
/div>
_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--0016361e892cd40a1004a5c655c6--

From phil.hunt@oracle.com  Wed Jun 15 14:01:49 2011
Return-Path: 
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 DF16E21F851D for ; Wed, 15 Jun 2011 14:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level: 
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZZqGXA4BL2o for ; Wed, 15 Jun 2011 14:01:48 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4021F849C for ; Wed, 15 Jun 2011 14:01:48 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5FL1is6028224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jun 2011 21:01:46 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5FL1hRK021068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2011 21:01:44 GMT
Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5FL1cgZ004489; Wed, 15 Jun 2011 16:01:38 -0500
Received: from dhcp-2op4-5-west-130-35-46-25.usdhcp.oraclecorp.com (/130.35.46.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Jun 2011 14:01:37 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-20--847979276
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 15 Jun 2011 14:01:42 -0700
Message-Id: <84547248-0D7A-4F85-B501-2196B7DF4716@oracle.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <1308169456.72680.YahooMailNeo@web31810.mail.mud.yahoo.com> 
To: Brian Eaton 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090205.4DF91DBB.00CA:SCFSTAT5015188,ss=1,fgs=0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 21:01:50 -0000

--Apple-Mail-20--847979276
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

+ 1

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-15, at 1:39 PM, Brian Eaton wrote:

> Yeah, I agree with that change.
>=20
> On Wed, Jun 15, 2011 at 1:24 PM, William J. Mills =
 wrote:
> I like your draft in general, but=20
>=20
>      10.1.3. Access Tokens
>=20
>      Access tokens are shorter-lived versions of refresh tokens.
>=20
> Doesn't work for me.  Access tokens are credentials used to access =
protected resources.  Refresh=20
>=20
> tokens are credentials used to obtain access tokens.
>=20
> -bill
>=20
> From: Brian Eaton 
> To: Eran Hammer-Lahav 
> Cc: OAuth WG 
> Sent: Wednesday, June 15, 2011 11:32 AM
>=20
> Subject: Re: [OAUTH-WG] Refresh tokens
>=20
> On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav =
 wrote:
> I would like to add a quick discussion of access token and refresh =
token recommended deployment setup, providing clear guidelines when a =
refresh token SHOULD and SHOULD NOT be issued, and when issues, how it =
is difference from the access token.
>=20
> Is this a start?
>=20
> http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html
>  =20
> It=92s time we stop trying to accommodate every possible combination =
and make some hard choices.
>=20
> +1.  Yes please.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail-20--847979276
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

+ =
1



Phil

@independentid
www.independentid.com
phil.hunt@oracle.com








On 2011-06-15, at 1:39 PM, Brian Eaton wrote:

Yeah, I =
agree with that change.

On =
Wed, Jun 15, 2011 at 1:24 PM, William J. Mills <wmills@yahoo-inc.com> =
wrote:




I like your draft in general, but =


     10.1.3. =
Access Tokens

     Access tokens =
are shorter-lived versions of refresh tokens.

Doesn't work for =
me.  Access tokens are credentials used to access protected resources.  =
Refresh 

tokens are credentials used to obtain access =
tokens.

-bill



From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav
 <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>

Sent: Wednesday, June 15, =
2011 11:32 AM

Subject: Re: [OAUTH-WG] Refresh =
tokens




On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav <eran@hueniverse.com> =
wrote:



I would like to add a quick discussion of =
access token and refresh token recommended deployment setup, providing =
clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, =
and when issues, how it is difference from the access token.




Is this a =
start?




  
It=92s time we stop trying to =
accommodate every possible combination and make some hard =
choices.




+1.  Yes =
please.

=


_______________________________________________
O=
Auth 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

=

--Apple-Mail-20--847979276--

From phil.hunt@oracle.com  Wed Jun 15 14:15:47 2011
Return-Path: 
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 6588E11E80AF for ; Wed, 15 Jun 2011 14:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level: 
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+9jy5w9pKaJ for ; Wed, 15 Jun 2011 14:15:46 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2BB11E809A for ; Wed, 15 Jun 2011 14:15:46 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5FLFiR8014304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Jun 2011 21:15:45 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5FLFhZQ019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jun 2011 21:15:43 GMT
Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5FLFcjp028831 for ; Wed, 15 Jun 2011 16:15:38 -0500
Received: from dhcp-2op4-5-west-130-35-46-25.usdhcp.oraclecorp.com (/130.35.46.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Jun 2011 14:15:38 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary=Apple-Mail-21--847138806
Date: Wed, 15 Jun 2011 14:15:42 -0700
References: <4DF912C6.3090500@oracle.com>
To: OAuth WG 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4DF92102.0015:SCFMA922111,ss=1,fgs=0
Subject: [OAUTH-WG] What constitutes "Payload Body" in MAC spec
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 21:15:47 -0000

--Apple-Mail-21--847138806
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

We had a discussion today about the MAC token spec. There was confusion =
was to whether payload body included the headers or just the HTTP =
request message body. I think the confusion comes about because of =
subtle term differences in other RFCs, see the message from Ron below...

=46rom Ron:

> I took a look at rfc's 2626 (and 822) on the structure of http request =
messages, and I think at worst the
> terminology used in HTTP Authentication: MAC Access Authentication =
could be improved.
>=20
> the headers are indeed separated from the the message body, but the =
use of the term payload may be confusing
> since it apparently refers to the entire message
>=20
> so for example, the MAC document uses., "The HTTP request payload =
body", apparently to refer to the message body within the message =
payload.
>=20
> that may be fine, or it might be better to use "The HTTP request =
message body", as that more correlates to the terms used in
> 2626
>=20
>=20
> 
>        HTTP-message   =3D Request | Response     ; HTTP/1.1 messages
> Request (section 5) and Response (section 6) messages use the generic =
message format of RFC 822 [9] for transferring entities (the payload of =
the message). Both types of message consist of a start-line, zero or =
more header fields (also known as "headers"), an empty line (i.e., a =
line with nothing preceding the CRLF) indicating the end of the header =
fields, and possibly a message-body.
>=20
>         generic-message =3D start-line
>                           *(message-header CRLF)
>                           CRLF
>                           [ message-body ]
>         start-line      =3D Request-Line | Status-Line
> 
>=20
> It appears that MAC Access Authentication was not intended to protect =
header values (other than the HOST header); that probably makes things =
much simpler, as otherwise, as Phil suggested, there could be a cyclic =
dependency in the mac calculation.
>=20

I agree, the recommendation to use "HTTP request message body" is =
clearer than "HTTP request payload body".

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



--Apple-Mail-21--847138806
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

We =
had a discussion today about the MAC token spec. There was confusion was =
to whether payload body included the headers or just the HTTP request =
message body. I think the confusion comes about because of subtle term =
differences in other RFCs, see the message from Ron =
below...

=46rom =
Ron:

I took a look at rfc's 2626 (and =
822) on the structure of http request messages, and I think at worst =
the
terminology used in HTTP Authentication: MAC Access =
Authentication could be improved.

the headers are indeed =
separated from the the message body, but the use of the term payload may =
be confusing
since it apparently refers to the entire =
message

so for example, the MAC document uses., "The HTTP request =
payload body", apparently to refer to the message body within the =
message payload.

that may be fine, or it might be better to use =
"The HTTP request message body", as that more correlates to the terms =
used in
2626


<quote>
       HTTP-message   =3D=
 Request | Response     ; HTTP/1.1 messages

Request (section 5) and Response (section 6) messages use the =
generic message format of RFC 822 [9] for transferring entities (the =
payload of the message). Both types of message consist of a start-line, =
zero or more header fields (also known as "headers"), an empty line =
(i.e., a line with nothing preceding the CRLF) indicating the end of the =
header fields, and possibly a message-body.
        =
generic-message =3D start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      =3D Request-Line | Status-Line

</quote>

It appears that MAC Access Authentication =
was not intended to protect header values (other than the HOST header); =
that probably makes things much simpler, as otherwise, as Phil =
suggested, there could be a cyclic dependency in the mac =
calculation.


I agree, the =
recommendation to use "HTTP request message body" is clearer than "HTTP =
request payload body".



Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


=

--Apple-Mail-21--847138806--

From sweeden@au1.ibm.com  Wed Jun 15 15:51:13 2011
Return-Path: 
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 74EF011E81D5 for ; Wed, 15 Jun 2011 15:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjUNbblVsFcG for ; Wed, 15 Jun 2011 15:51:10 -0700 (PDT)
Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4542411E81D0 for ; Wed, 15 Jun 2011 15:51:09 -0700 (PDT)
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp03.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5FMjxOE030633 for ; Thu, 16 Jun 2011 08:45:59 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5FMo96X1171552 for ; Thu, 16 Jun 2011 08:50:09 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5FMp0xp000923 for ; Thu, 16 Jun 2011 08:51:01 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5FMp0Sm000918; Thu, 16 Jun 2011 08:51:00 +1000
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> 	<90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
X-KeepSent: 8F1316AF:C9515F06-4A2578B0:007767CC; type=4; name=$KeepSent
To: Brian Eaton 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Thu, 16 Jun 2011 08:50:50 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 16/06/2011 08:54:25
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 22:51:14 -0000

Eran: > >=A0I would like to go back to requiring client authentication =
for
the access token endpoint

Brian: > Sure. =A0Why not?
>
> 1) It makes the spec simpler.
> 2) It has no impact on the security of clients that can't keep secret=
s.
> 3) It has no impact on the security of clients that can keep secrets.=



Brain - can you elaborate on that a little? Are you suggesting that cli=
ents
that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
"requiring client authentication"?

I can't see any point in the spec saying client authentication is requi=
red
if it doesn't add value in a way that can be explained to everyone (eg.=

what you said in
http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html about
rolling over the client secret to deal with compromised refresh tokens)=
.

What seems to be missing in the discussion and the security considerati=
ons
of the spec is a decent list of general and grant-type-specific securit=
y
implications/pros/cons for the system if meaningful client authenticati=
on
at the token endpoint is available or not available.
=



From sweeden@au1.ibm.com  Wed Jun 15 15:51:13 2011
Return-Path: 
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 881C711E81D6 for ; Wed, 15 Jun 2011 15:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRFrCABsWduU for ; Wed, 15 Jun 2011 15:51:10 -0700 (PDT)
Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4548611E81D4 for ; Wed, 15 Jun 2011 15:51:09 -0700 (PDT)
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp02.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5FMj6mw017691 for ; Thu, 16 Jun 2011 08:45:06 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5FMo9io1298614 for ; Thu, 16 Jun 2011 08:50:09 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5FMp0qq006966 for ; Thu, 16 Jun 2011 08:51:01 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5FMp0lc006963; Thu, 16 Jun 2011 08:51:00 +1000
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-KeepSent: DD299468:C045FD9F-4A2578B0:00797AF7; type=4; name=$KeepSent
To: Eran Hammer-Lahav 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Thu, 16 Jun 2011 08:19:27 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 16/06/2011 08:54:24
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jun 2011 22:51:14 -0000

> From: Eran Hammer-Lahav 
> To: OAuth WG 
> Date: 16-06-11 05:43 AM
> Subject: [OAUTH-WG] Redirection URI and Implicit grant
> Sent by: oauth-bounces@ietf.org
>
> This is coming from recent experience building a full web service
> and multiple clients using OAuth 2.0. I am going to make these
> changes to my own implementation and would like to raise the
> questions here and discuss possible changes.
>
> A few questions:
>
> 1. Why not require the registration of a redirection URI for
> implicit grant requests, removing the redirect_uri parameter
> completely from the request (the client can still use the state
parameter)?

I can imagine situations where one-or-more redirect URI's may be required
rather than a single explicit URI. I think that either a
child-urlpath-of-the-registered URI, and/or the ability to register
multiple valid URI's for a particular client id allows this without being
overly restrictive.



From eran@hueniverse.com  Wed Jun 15 17:15:05 2011
Return-Path: 
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 A867411E8155 for ; Wed, 15 Jun 2011 17:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E1ex0kP-Oa6 for ; Wed, 15 Jun 2011 17:15:03 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E4D6F11E80DF for ; Wed, 15 Jun 2011 17:15:02 -0700 (PDT)
Received: (qmail 25041 invoked from network); 16 Jun 2011 00:15:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 00:15:00 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 17:14:54 -0700
From: Eran Hammer-Lahav 
To: Phil Hunt , OAuth WG 
Date: Wed, 15 Jun 2011 17:14:29 -0700
Thread-Topic: [OAUTH-WG] What constitutes "Payload Body" in MAC spec
Thread-Index: AcwroXAbbQPY9AuXTR2BmUCmhJY1sAAGLHmg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C04@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DF912C6.3090500@oracle.com> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986C04P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] What constitutes "Payload Body" in MAC spec
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:15:05 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C04P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

'Payload body' as defined by http://tools.ietf.org/html/draft-ietf-httpbis-=
p1-messaging-14#section-3.3

Message body is the wire bits which may include a range of content encoding=
, compression, fragmentation, etc. The point is that the client can't reall=
y know what the message body is going to look like on the other side, but o=
nce the body has been properly "decoded", the original payload body is what=
 we hash.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P=
hil Hunt
Sent: Wednesday, June 15, 2011 2:16 PM
To: OAuth WG
Subject: [OAUTH-WG] What constitutes "Payload Body" in MAC spec

We had a discussion today about the MAC token spec. There was confusion was=
 to whether payload body included the headers or just the HTTP request mess=
age body. I think the confusion comes about because of subtle term differen=
ces in other RFCs, see the message from Ron below...

>From Ron:

I took a look at rfc's 2626 (and 822) on the structure of http request mess=
ages, and I think at worst the
terminology used in HTTP Authentication: MAC Access Authentication could be=
 improved.

the headers are indeed separated from the the message body, but the use of =
the term payload may be confusing
since it apparently refers to the entire message

so for example, the MAC document uses., "The HTTP request payload body", ap=
parently to refer to the message body within the message payload.

that may be fine, or it might be better to use "The HTTP request message bo=
dy", as that more correlates to the terms used in
2626




       HTTP-message   =3D Request | Response     ; HTTP/1.1 messages

Request (section 5) and Response (section 6) messages use the generic messa=
ge format of RFC 822 [9] for transferring entities (the payload of the mess=
age). Both types of message consist of a start-line, zero or more header fi=
elds (also known as "headers"), an empty line (i.e., a line with nothing pr=
eceding the CRLF) indicating the end of the header fields, and possibly a m=
essage-body.

        generic-message =3D start-line

                          *(message-header CRLF)

                          CRLF

                          [ message-body ]

        start-line      =3D Request-Line | Status-Line


It appears that MAC Access Authentication was not intended to protect heade=
r values (other than the HOST header); that probably makes things much simp=
ler, as otherwise, as Phil suggested, there could be a cyclic dependency in=
 the mac calculation.

I agree, the recommendation to use "HTTP request message body" is clearer t=
han "HTTP request payload body".

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C04P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


‘Pa=
yload body’ as defined by http://tools.ietf.org/html/draft=
-ietf-httpbis-p1-messaging-14#section-3.3
 
Message body is the wire bits which may include a range of content encodin=
g, compression, fragmentation, etc. The point is that the client can’=
t really know what the message body is going to look like on the other side=
, but once the body has been properly “decoded”, the original p=
ayload body is what we hash.
 
EHL
 
From: oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, Ju=
ne 15, 2011 2:16 PM
To: OAuth WG
Subject: [OAUTH-WG] Wh=
at constitutes "Payload Body" in MAC spec
 
We=
 had a discussion today about the MAC token spec. There was confusion was t=
o whether payload body included the headers or just the HTTP request messag=
e body. I think the confusion comes about because of subtle term difference=
s in other RFCs, see the message from Ron below...
 
From R=
on:
 
I took a look at rfc's 2626 (and 822) on the structure of http=
 request messages, and I think at worst the
terminology used in HTTP Aut=
hentication: MAC Access Authentication could be improved.

the header=
s are indeed separated from the the message body, but the use of the term p=
ayload may be confusing
since it apparently refers to the entire message=


so for example, the MAC document uses., "The HTTP request payl=
oad body", apparently to refer to the message body within the message =
payload.

that may be fine, or it might be better to use "The HT=
TP request message body", as that more correlates to the terms used in=

2626


<quote>
   &nbs=
p;   HTTP-message   =3D Request | Response  &=
nbsp;  ; HTTP/1.1 messages
Request (section 5) and =
Response (section 6) messages use the generic message format of RFC 822 [9]=
 for transferring entities (the payload of the message). Both types of mess=
age consist of a start-line, zero or more header fields (also known as &quo=
t;headers"), an empty line (i.e., a line with nothing preceding the CR=
LF) indicating the end of the header fields, and possibly a message-body.
        generic-messag=
e =3D start-line
      &=
nbsp;           &nbs=
p;       *(message-header CRLF)
           &=
nbsp;           &nbs=
p;  CRLF
       &nb=
sp;            =
      [ message-body ]
&=
nbsp;       start-line    =
;  =3D Request-Line | Status-Line
</quote>

It appears that MAC A=
ccess Authentication was not intended to protect header values (other than =
the HOST header); that probably makes things much simpler, as otherwise, as=
 Phil suggested, there could be a cyclic dependency in the mac calculation.=

 
I agree, the recommendation to use &q=
uot;HTTP request message body" is clearer than "HTTP request payl=
oad body".
 
Phil
 =
;
@independentid=

<=
/div>
phil.hunt@oracle.com
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C04P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 17:21:31 2011
Return-Path: 
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 0442F11E8155 for ; Wed, 15 Jun 2011 17:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level: 
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RdqvOZu3mZh for ; Wed, 15 Jun 2011 17:21:30 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D167911E816A for ; Wed, 15 Jun 2011 17:21:29 -0700 (PDT)
Received: (qmail 32568 invoked from network); 16 Jun 2011 00:21:29 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 00:21:29 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 17:21:28 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 17:21:05 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwrnjeYxXh8580FTIaTWyXTPv3IIgAHG+yg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C07@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:21:31 -0000

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>=20
> > We have one grant type without client authentication (implicit)
>=20
> I suspect another choice of words would be useful there. =A0Implicit gran=
ts rely
> on the browser's authentication of the receiving web site. =A0When https =
is
> used, that authentication is fairly strong.

"authentication of the receiving web site"? Authentication how, and what is=
 a receiving web site?

The implicit grant relies on the presence of the user to "vouch" for the cl=
ient by making the connection of how it got to the authorization server and=
 what she is being asked to approve. In other words, the user does somethin=
g that lands her in front an authorization page. If that page makes sense t=
o her in that flow, she approves access to the party that got her there.

What does HTTPS has to do with this?

EHL

From eran@hueniverse.com  Wed Jun 15 17:27:44 2011
Return-Path: 
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 6AE2D21F85B9 for ; Wed, 15 Jun 2011 17:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw0K-QzXG0+x for ; Wed, 15 Jun 2011 17:27:43 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 93E8D21F85B6 for ; Wed, 15 Jun 2011 17:27:43 -0700 (PDT)
Received: (qmail 5667 invoked from network); 16 Jun 2011 00:27:43 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 00:27:43 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 15 Jun 2011 17:27:37 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 17:27:14 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwrnjeYxXh8580FTIaTWyXTPv3IIgAHT1iQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:27:44 -0000

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Wednesday, June 15, 2011 1:53 PM

> >=A0But I have no idea why we need client authentication for using a refr=
esh
> token?
>=20
> This is covered here:=A0http://www.ietf.org/mail-
> archive/web/oauth/current/msg06362.html.

So basically, it is authentication on top of bearer credentials to achieve =
another level of security. Are we just assuming that stealing the refresh t=
oken will be harder than stealing the client credentials? Seems a bit optim=
istic.

Both client secret and refresh token are sent in plain text over TLS during=
 the same client-server interaction. If there is a problem with TLS, both s=
ecrets are exposed. The client is more likely to store its client secret in=
 source code or local storage because it rarely changes, as opposed to stor=
ing the refresh token in some other cache or database. I can't figure out w=
hich one will be harder to steal.

What attack vector is requiring client authentication when using the refres=
h token protects against?

EHL



From beaton@google.com  Wed Jun 15 17:29:35 2011
Return-Path: 
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 D6AF521F85BD for ; Wed, 15 Jun 2011 17:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuiisQ8trOM6 for ; Wed, 15 Jun 2011 17:29:34 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7C521F85B9 for ; Wed, 15 Jun 2011 17:29:34 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p5G0TWiD002490 for ; Wed, 15 Jun 2011 17:29:32 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308184172; bh=ThPu+953zvKoHCwHO/U7A1YG9SA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=AxCdSRNQ/GPkA9Lu+dNpLV9YEu6grIUEqtD2PbUq9Go30H+foW5enPKtZGo/IEaRC BaQ0sw+Odv2pxXisTyzIQ==
Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by hpaq5.eem.corp.google.com with ESMTP id p5G0TTE3018936 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 17:29:30 -0700
Received: by pvc21 with SMTP id 21so739641pvc.25 for ; Wed, 15 Jun 2011 17:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ucPhjV7y+BwyrF4lZUi3/UlXwr3/VSKvTqmWvPt0owo=; b=t0/oieAWzsuZVXLkUTyTULWyNLlCz7WJoQvyODYEuc5gAsrVnmP4UMo0i5Zjjj1LZ6 3LGc91NSw6RM7GIawFDg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NYp1xA9Pyv7Uqxha68TW/AhOjFM7BHY4iKN9GC7aSXu7PNHEaooabV+73YGIMK+HHP L2Dz1VZnGBMa4GJLN2Aw==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr53531wfa.323.1308184168882; Wed, 15 Jun 2011 17:29:28 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Wed, 15 Jun 2011 17:29:28 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C07@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C07@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 17:29:28 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e906f1afe0d704a5c95c34
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:29:36 -0000

--001636e906f1afe0d704a5c95c34
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav wrote:

> > I suspect another choice of words would be useful there.  Implicit grants
> rely
> > on the browser's authentication of the receiving web site.  When https is
> > used, that authentication is fairly strong.
>
> "authentication of the receiving web site"? Authentication how, and what is
> a receiving web site?
>
> The implicit grant relies on the presence of the user to "vouch" for the
> client by making the connection of how it got to the authorization server
> and what she is being asked to approve. In other words, the user does
> something that lands her in front an authorization page. If that page makes
> sense to her in that flow, she approves access to the party that got her
> there.
>

Security for the implicit grant type comes from identifying the client based
on the redirect URI.  At client registration time, you bind client_id X to
redirect URIs Y and Z.

If the redirect URIs use HTTPs, that gives you reasonable security.

--001636e906f1afe0d704a5c95c34
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro=
te:


> I suspect another choice of words would be useful th=
ere. =A0Implicit grants rely

> on the browser's authentication of the receiving web site. =A0When=
 https is

> used, that authentication is fairly strong.




"authentication of the receiving web site"? Authentication =
how, and what is a receiving web site?



The implicit grant relies on the presence of the user to "vouch" =
for the client by making the connection of how it got to the authorization =
server and what she is being asked to approve. In other words, the user doe=
s something that lands her in front an authorization page. If that page mak=
es sense to her in that flow, she approves access to the party that got her=
 there.



Security for the implicit grant type comes=
 from identifying the client based on the redirect URI. =A0At client regist=
ration time, you bind client_id X to redirect URIs Y and Z.



If the redirect URIs use HTTPs, that gives you reasonable securi=
ty.


--001636e906f1afe0d704a5c95c34--

From eran@hueniverse.com  Wed Jun 15 17:32:57 2011
Return-Path: 
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 3922321F8621 for ; Wed, 15 Jun 2011 17:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTmGiY7DQcig for ; Wed, 15 Jun 2011 17:32:56 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7A92721F8620 for ; Wed, 15 Jun 2011 17:32:56 -0700 (PDT)
Received: (qmail 13390 invoked from network); 16 Jun 2011 00:32:56 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 00:32:56 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 17:32:56 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 17:32:33 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwrvHai1fD2fQmLQz+P2Puio9hkKQAADUBA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C0F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C07@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986C0FP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:32:57 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C0FP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ok. That makes sense and in line with my other thread about implicit grant =
and registration.

So if a callback is not registered, we are basically at the mercy of the us=
er not being an idiot.

Seems like a good reason to require redirection URI registration for implic=
it grant clients.

EHL

From: Brian Eaton [mailto:beaton@google.com]
Sent: Wednesday, June 15, 2011 5:29 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav > wrote:
> I suspect another choice of words would be useful there.  Implicit grants=
 rely
> on the browser's authentication of the receiving web site.  When https is
> used, that authentication is fairly strong.
"authentication of the receiving web site"? Authentication how, and what is=
 a receiving web site?

The implicit grant relies on the presence of the user to "vouch" for the cl=
ient by making the connection of how it got to the authorization server and=
 what she is being asked to approve. In other words, the user does somethin=
g that lands her in front an authorization page. If that page makes sense t=
o her in that flow, she approves access to the party that got her there.

Security for the implicit grant type comes from identifying the client base=
d on the redirect URI.  At client registration time, you bind client_id X t=
o redirect URIs Y and Z.

If the redirect URIs use HTTPs, that gives you reasonable security.

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C0FP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Ok. That =
makes sense and in line with my other thread about implicit grant and regis=
tration.
 =

So if a callback is not registered, =
we are basically at the mercy of the user not being an idiot.
 
Seems like a good reason to require redirection URI regist=
ration for implicit grant clients.
 
EHL
 
From: Brian Eaton [mailto:beaton@google=
.com] 
Sent: Wednesday, June 15, 2011 5:29 PM
To: Eran =
Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: =
[OAUTH-WG] Client authentication requirement
 
On Wed, J=
un 15, 2011 at 5:21 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I s=
uspect another choice of words would be useful there.  Implicit grants=
 rely
> on the browser's authentication of the receiving web site. &nb=
sp;When https is
> used, that authentication is fairly strong.
"authentication of the receiving we=
b site"? Authentication how, and what is a receiving web site?

=
The implicit grant relies on the presence of the user to "vouch" =
for the client by making the connection of how it got to the authorization =
server and what she is being asked to approve. In other words, the user doe=
s something that lands her in front an authorization page. If that page mak=
es sense to her in that flow, she approves access to the party that got her=
 there.
 
Security for the implicit grant type=
 comes from identifying the client based on the redirect URI.  At clie=
nt registration time, you bind client_id X to redirect URIs Y and Z.
 
If the redirect URIs use HTTPs, that gives you reasonable=
 security.
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C0FP3PW5EX1MB01E_--

From beaton@google.com  Wed Jun 15 17:33:07 2011
Return-Path: 
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 F375821F8628 for ; Wed, 15 Jun 2011 17:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.901
X-Spam-Level: 
X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9F0HObkZYTg for ; Wed, 15 Jun 2011 17:33:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC821F8627 for ; Wed, 15 Jun 2011 17:33:05 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5G0X3Bk008247 for ; Wed, 15 Jun 2011 17:33:03 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308184383; bh=c8h7Tu8QRHNIu+wwjV5D39f8Ebk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=V1XWKvS5nMuj27juonK5/meLBXPq2rZTK0GdSAtfZX9nQLmipRWm1+W3DD/Te1Bjv M8UgNFgx7xm5Rtz+XzaOA==
Received: from pvh18 (pvh18.prod.google.com [10.241.210.210]) by hpaq7.eem.corp.google.com with ESMTP id p5G0Wjr1001523 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 17:33:01 -0700
Received: by pvh18 with SMTP id 18so1200841pvh.17 for ; Wed, 15 Jun 2011 17:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yfTrW38VvkWxpUEZHi9nQp1m8Fhgs8hHVVX3iJS2h/U=; b=mObQ4NWo17o2w7jXsK3xG8qzoq1jjc1PPZpwuehoF4NG8vY9h+auytkg6b20AdMdnH 4Sjk4N9qKX1mmf6n8iXw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c3GR/Wm5KATsPmWE/imcGp6cLkuAbYTFd4AxQMEd4P5yb2TJ0g/Hk5wdc0rJzGhxWr c98PyOeZlr+7SOCHsNZg==
MIME-Version: 1.0
Received: by 10.143.5.19 with SMTP id h19mr76926wfi.38.1308184381451; Wed, 15 Jun 2011 17:33:01 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Wed, 15 Jun 2011 17:33:01 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 17:33:01 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e0a5b15b6db704a5c969eb
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:33:07 -0000

--001636e0a5b15b6db704a5c969eb
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav wrote:

> So basically, it is authentication on top of bearer credentials to achieve
> another level of security. Are we just assuming that stealing the refresh
> token will be harder than stealing the client credentials? Seems a bit
> optimistic.
>
> Both client secret and refresh token are sent in plain text over TLS during
> the same client-server interaction. If there is a problem with TLS, both
> secrets are exposed. The client is more likely to store its client secret in
> source code or local storage because it rarely changes, as opposed to
> storing the refresh token in some other cache or database. I can't figure
> out which one will be harder to steal.
>
> What attack vector is requiring client authentication when using the
> refresh token protects against?


Requiring client authentication doesn't defend against attacks directly; it
makes recovery after a successful attack easier.

If you use the assertion profiles for OAuth2, then it also binds the refresh
token to private keys that are much easier to store securely than client
secrets.

--001636e0a5b15b6db704a5c969eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro=
te:


So basically, it is authentication on top of bearer crede=
ntials to achieve another level of security. Are we just assuming that stea=
ling the refresh token will be harder than stealing the client credentials?=
 Seems a bit optimistic.




Both client secret and refresh token are sent in plain text over TLS during=
 the same client-server interaction. If there is a problem with TLS, both s=
ecrets are exposed. The client is more likely to store its client secret in=
 source code or local storage because it rarely changes, as opposed to stor=
ing the refresh token in some other cache or database. I can't figure o=
ut which one will be harder to steal.




What attack vector is requiring client authentication when using the refres=
h token protects against?

Requiring client =
authentication doesn't defend against attacks directly; it makes recove=
ry after a successful attack easier.



If you use the assertion profiles for OAuth2, then it a=
lso binds the refresh token to private keys that are much easier to store s=
ecurely than client secrets.


--001636e0a5b15b6db704a5c969eb--

From beaton@google.com  Wed Jun 15 17:36:22 2011
Return-Path: 
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 1F08B11E816A for ; Wed, 15 Jun 2011 17:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysYhmCfIDuKl for ; Wed, 15 Jun 2011 17:36:21 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6284111E8136 for ; Wed, 15 Jun 2011 17:36:21 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p5G0aK8l022828 for ; Wed, 15 Jun 2011 17:36:20 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308184581; bh=QLx+dRXsbE+ef8K/2eEnibft4Jg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GyEByr3RPiq1AaOFW5aM2fD640ZcQ7w8Dzp0D297lf+y7Kioq01I+3BAUQtlk88Ex YEqap9g/RgSsn4gNdrIEQ==
Received: from pvh18 (pvh18.prod.google.com [10.241.210.210]) by hpaq2.eem.corp.google.com with ESMTP id p5G0a0vp032264 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 17:36:18 -0700
Received: by pvh18 with SMTP id 18so860398pvh.31 for ; Wed, 15 Jun 2011 17:36:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b4mwnamRxXfonmVX1GPB5JR7ocJJ80PQVmy12qee2rQ=; b=PE3sSko0bs6cu9/U/dXwBbk+WiJkxr+NlkXByMDjCCXKTOhUJEjpE0No01Ah7Q09X8 XORnN8kRyL3ezfsWtpDg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U6JBlkjvBzhOM7Ji/x+ndp2LCvq/+AmFgKf/AJFpFs8yI8Ru68aqKA9YsfPkFfG6rN pkoaeLWhsDFcdnLeGgBQ==
MIME-Version: 1.0
Received: by 10.143.163.20 with SMTP id q20mr64008wfo.209.1308184578443; Wed, 15 Jun 2011 17:36:18 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Wed, 15 Jun 2011 17:36:18 -0700 (PDT)
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
Date: Wed, 15 Jun 2011 17:36:18 -0700
Message-ID: 
From: Brian Eaton 
To: Shane B Weeden 
Content-Type: multipart/alternative; boundary=001636e900211948da04a5c975f8
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 00:36:22 -0000

--001636e900211948da04a5c975f8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden  wrote:

> Brain - can you elaborate on that a little? Are you suggesting that clients
> that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
> "requiring client authentication"?
>

Or use random secrets.  Whatever floats your boat and keeps your product
managers happy.  It does not make a practical security difference for
installed applications.

What seems to be missing in the discussion and the security considerations
> of the spec is a decent list of general and grant-type-specific security
> implications/pros/cons for the system if meaningful client authentication
> at the token endpoint is available or not available.
>

Yep.

--001636e900211948da04a5c975f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden <sweeden@au1.ibm.com> wrote:=


Brain - can you elaborate on that a little? Are you suggesting that clients=


that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy<=
br>
"requiring client authentication"?

Or use random secrets. =A0Whatever floats your boat and keeps your pr=
oduct managers happy. =A0It does not make a practical security difference f=
or installed applications.




What seems to be missing in the discussion and the security considerations<=
br>
of the spec is a decent list of general and grant-type-specific security
implications/pros/cons for the system if meaningful client authentication
at the token endpoint is available or not available.
<=
br>
Yep.


--001636e900211948da04a5c975f8--

From eran@hueniverse.com  Wed Jun 15 18:03:05 2011
Return-Path: 
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 3E6E121F85AC for ; Wed, 15 Jun 2011 18:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level: 
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaX+3GQAdWqm for ; Wed, 15 Jun 2011 18:03:04 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 9AF7921F85AB for ; Wed, 15 Jun 2011 18:03:04 -0700 (PDT)
Received: (qmail 3152 invoked from network); 16 Jun 2011 01:03:03 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 01:03:03 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 18:03:03 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 18:02:40 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwrvPZeK3k0ZgEnSqmZrlYUvdUB1gAA9M+w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986C15P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 01:03:05 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C15P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

How does it make recovery easier? Why is revoking refresh token any harder =
than changing client secret?

As for the assertion grant type, where is the specified that the refresh to=
ken is bound to the private keys used to produce the assertion used to obta=
in the refresh token in the first place?

EHL

From: Brian Eaton [mailto:beaton@google.com]
Sent: Wednesday, June 15, 2011 5:33 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav > wrote:
So basically, it is authentication on top of bearer credentials to achieve =
another level of security. Are we just assuming that stealing the refresh t=
oken will be harder than stealing the client credentials? Seems a bit optim=
istic.

Both client secret and refresh token are sent in plain text over TLS during=
 the same client-server interaction. If there is a problem with TLS, both s=
ecrets are exposed. The client is more likely to store its client secret in=
 source code or local storage because it rarely changes, as opposed to stor=
ing the refresh token in some other cache or database. I can't figure out w=
hich one will be harder to steal.

What attack vector is requiring client authentication when using the refres=
h token protects against?

Requiring client authentication doesn't defend against attacks directly; it=
 makes recovery after a successful attack easier.

If you use the assertion profiles for OAuth2, then it also binds the refres=
h token to private keys that are much easier to store securely than client =
secrets.

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C15P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


How does =
it make recovery easier? Why is revoking refresh token any harder than chan=
ging client secret?
 
As for the assertion gr=
ant type, where is the specified that the refresh token is bound to the pri=
vate keys used to produce the assertion used to obtain the refresh token in=
 the first place?
&nb=
sp;
EHL
 
=

From: Brian Eaton [mailto:beaton@google.com] 
Sent=
: Wednesday, June 15, 2011 5:33 PM
To: Eran Hammer-Lahav
<=
b>Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client=
 authentication requirement
 
On Wed, Jun 15, 2011 at 5:=
27 PM, Eran Hammer-Lahav <eran@hu=
eniverse.com> wrote:
So basically, it is authe=
ntication on top of bearer credentials to achieve another level of security=
. Are we just assuming that stealing the refresh token will be harder than =
stealing the client credentials? Seems a bit optimistic.

Both client secret and refresh token are sent in=
 plain text over TLS during the same client-server interaction. If there is=
 a problem with TLS, both secrets are exposed. The client is more likely to=
 store its client secret in source code or local storage because it rarely =
changes, as opposed to storing the refresh token in some other cache or dat=
abase. I can't figure out which one will be harder to steal.

What at=
tack vector is requiring client authentication when using the refresh token=
 protects against?
 
Requiring client authenti=
cation doesn't defend against attacks directly; it makes recovery after a s=
uccessful attack easier.
 
If you use the assertion p=
rofiles for OAuth2, then it also binds the refresh token to private keys th=
at are much easier to store securely than client secrets.
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C15P3PW5EX1MB01E_--

From eran@hueniverse.com  Wed Jun 15 18:10:13 2011
Return-Path: 
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 494F421F8672 for ; Wed, 15 Jun 2011 18:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Level: 
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSCVV7WG-WYp for ; Wed, 15 Jun 2011 18:10:08 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7CBB321F8671 for ; Wed, 15 Jun 2011 18:10:08 -0700 (PDT)
Received: (qmail 9843 invoked from network); 16 Jun 2011 01:10:07 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 01:10:07 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 18:10:07 -0700
From: Eran Hammer-Lahav 
To: Shane B Weeden 
Date: Wed, 15 Jun 2011 18:09:44 -0700
Thread-Topic: [OAUTH-WG] Redirection URI and Implicit grant
Thread-Index: Acwrrrl1tRByqlp0QROd2PKorRIUCwAEssTQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C18@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 01:10:13 -0000

> -----Original Message-----
> From: Shane B Weeden [mailto:sweeden@au1.ibm.com]
> Sent: Wednesday, June 15, 2011 3:19 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
>=20
> > From: Eran Hammer-Lahav 
> > To: OAuth WG 
> > Date: 16-06-11 05:43 AM
> > Subject: [OAUTH-WG] Redirection URI and Implicit grant Sent by:
> > oauth-bounces@ietf.org
> >
> > This is coming from recent experience building a full web service and
> > multiple clients using OAuth 2.0. I am going to make these changes to
> > my own implementation and would like to raise the questions here and
> > discuss possible changes.
> >
> > A few questions:
> >
> > 1. Why not require the registration of a redirection URI for implicit
> > grant requests, removing the redirect_uri parameter completely from
> > the request (the client can still use the state
> parameter)?
>=20
> I can imagine situations where one-or-more redirect URI's may be required
> rather than a single explicit URI. I think that either a child-urlpath-of=
-the-
> registered URI, and/or the ability to register multiple valid URI's for a
> particular client id allows this without being overly restrictive.
>=20

Then just use multiple client identifiers if you need multiple redirection =
URIs, or better yet, use the state parameter and route the request on the c=
lient side based on the state value. Authorization server who want to be fa=
ncy can allow you to register more than one and let you indicate which one =
you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1).

I want to be restrictive because right now we offer too many insecure combi=
nations for the implicit grant.

EHL

From beaton@google.com  Wed Jun 15 18:15:00 2011
Return-Path: 
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 72C6D228008 for ; Wed, 15 Jun 2011 18:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.926
X-Spam-Level: 
X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcIvRxaPdAAG for ; Wed, 15 Jun 2011 18:14:58 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF421F8461 for ; Wed, 15 Jun 2011 18:14:57 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5G1Eu9b018632 for ; Wed, 15 Jun 2011 18:14:56 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308186896; bh=t8eIx+l2C7cpQfqXSYRIlYIuqwo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qbRqwWeUet7NtJOkwCM8svSzj0oJ24tjLuarpquPPjjwI9UzL2eLmaYW83nwFJa0N g1v0vO6eUxTjxzOrdtuvg==
Received: from pvg3 (pvg3.prod.google.com [10.241.210.131]) by wpaz33.hot.corp.google.com with ESMTP id p5G1EsvR001515 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jun 2011 18:14:55 -0700
Received: by pvg3 with SMTP id 3so836368pvg.4 for ; Wed, 15 Jun 2011 18:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gxNDbEBkH9fg+ZihtIvQkXo5sTnbDpC9JiYHfohAa6M=; b=DGUWii1lp4tHjEIgKErpwQUvI91GTh4CuccUjyuV30JXYAq8KCGumRsPn3Dc/k0ybW vcICPKyxk132gHOrxKbw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nefpxdn4YUcwyatpdxXna80h9U7TChVI/KATc/i9TnLo/IOWxpy6rXdf5j+Isl2b08 woCaxT1cDbunpGOVpkTA==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr57776wfa.323.1308186894143; Wed, 15 Jun 2011 18:14:54 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Wed, 15 Jun 2011 18:14:54 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 18:14:54 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e906f1200fa804a5c9ff62
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 01:15:00 -0000

--001636e906f1200fa804a5c9ff62
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav wrote:

> How does it make recovery easier? Why is revoking refresh token any harder
> than changing client secret?
>

Changing a client secret can be done without disrupting users.  You can even
schedule it, do it every 30 days as part of your general operational
procedures.  It's part of a healthy system.

Revoking refresh tokens every 30 days is not really feasible.


> As for the assertion grant type, where is the specified that the refresh
> token is bound to the private keys used to produce the assertion used to
> obtain the refresh token in the first place?
>

Well, the spec currently has refresh tokens bound to client ids.

And the assertion spec proposal authenticated client ids with public/private
key pairs.

You wouldn't bind the refresh token directly to a private key, for the same
reason that you don't bind the refresh token directly to the client secret.
 You bind refresh tokens to clients, and then you require client
authentication.

--001636e906f1200fa804a5c9ff62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro=
te:


How does it make recover=
y easier? Why is revoking refresh token any harder than changing client sec=
ret?



Changing a client secret can b=
e done without disrupting users. =A0You can even schedule it, do it every 3=
0 days as part of your general operational procedures. =A0It's part of =
a healthy system.



Revoking refresh tokens every 30 days is not really fea=
sible.
=A0=A0


As for the assertion gra=
nt type, where is the specified that the refresh token is bound to the priv=
ate keys used to produce the assertion used to obtain the refresh token in =
the first place?



Well, the spec currently has r=
efresh tokens bound to client ids.

And the asserti=
on spec proposal authenticated client ids with public/private key pairs.


You wouldn't bind the refresh token directly to a p=
rivate key, for the same reason that you don't bind the refresh token d=
irectly to the client secret. =A0You bind refresh tokens to clients, and th=
en you require client authentication.=A0




--001636e906f1200fa804a5c9ff62--

From eran@hueniverse.com  Wed Jun 15 18:19:53 2011
Return-Path: 
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 D73CB11E80C7 for ; Wed, 15 Jun 2011 18:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjAyFpPIsiCp for ; Wed, 15 Jun 2011 18:19:48 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 500A722800D for ; Wed, 15 Jun 2011 18:19:48 -0700 (PDT)
Received: (qmail 27569 invoked from network); 16 Jun 2011 01:19:47 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 01:19:47 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 15 Jun 2011 18:19:47 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Wed, 15 Jun 2011 18:19:25 -0700
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: Acwrws6bTqgt7hIpShOn0kFiPjY3FgAAGFNQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986C1AP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 01:19:54 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C1AP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Your comment was that having client authentication makes it easier to recov=
ery from an attack. I don't understand how the comments below about changin=
g client secrets every 30 days are relevant. Are you suggesting to wait unt=
il the next routine secret cycle to revoke compromised credentials? Or that=
 30 days is a reasonable time period for ignoring an attack?

EHL

From: Brian Eaton [mailto:beaton@google.com]
Sent: Wednesday, June 15, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav > wrote:
How does it make recovery easier? Why is revoking refresh token any harder =
than changing client secret?

Changing a client secret can be done without disrupting users.  You can eve=
n schedule it, do it every 30 days as part of your general operational proc=
edures.  It's part of a healthy system.

Revoking refresh tokens every 30 days is not really feasible.

As for the assertion grant type, where is the specified that the refresh to=
ken is bound to the private keys used to produce the assertion used to obta=
in the refresh token in the first place?

Well, the spec currently has refresh tokens bound to client ids.

And the assertion spec proposal authenticated client ids with public/privat=
e key pairs.

You wouldn't bind the refresh token directly to a private key, for the same=
 reason that you don't bind the refresh token directly to the client secret=
.  You bind refresh tokens to clients, and then you require client authenti=
cation.

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C1AP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Your comm=
ent was that having client authentication makes it easier to recovery from =
an attack. I don’t understand how the comments below about changing c=
lient secrets every 30 days are relevant. Are you suggesting to wait until =
the next routine secret cycle to revoke compromised credentials? Or that 30=
 days is a reasonable time period for ignoring an attack?=

 
EHL
&nbs=
p;
From: Brian Eato=
n [mailto:beaton@google.com] 
Sent: Wednesday, June 15, 2011 6:15=
 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG<=
br>Subject: Re: [OAUTH-WG] Client authentication requirement
 
On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
<=
p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:=
auto'>How does it make recov=
ery easier? Why is revoking refresh token any harder than changing client s=
ecret?
 
Changing a client =
secret can be done without disrupting users.  You can even schedule it=
, do it every 30 days as part of your general operational procedures.  =
;It's part of a healthy system.
 
Revoking refresh to=
kens every 30 days is not really feasible.
  
As for the assertion grant type, where is the=
 specified that the refresh token is bound to the private keys used to prod=
uce the assertion used to obtain the refresh token in the first place?
&n=
bsp;
Well, the spec currently has =
refresh tokens bound to client ids.
 
And the asserti=
on spec proposal authenticated client ids with public/private key pairs.
 
You wouldn't bind the refresh token directly to a pri=
vate key, for the same reason that you don't bind the refresh token directl=
y to the client secret.  You bind refresh tokens to clients, and then =
you require client authentication. 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C1AP3PW5EX1MB01E_--

From sweeden@au1.ibm.com  Wed Jun 15 18:28:54 2011
Return-Path: 
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 CF09111E8173 for ; Wed, 15 Jun 2011 18:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGA5nEZITTNs for ; Wed, 15 Jun 2011 18:28:54 -0700 (PDT)
Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F511E8080 for ; Wed, 15 Jun 2011 18:28:53 -0700 (PDT)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5G1OSlj026685 for ; Thu, 16 Jun 2011 11:24:28 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5G1Ribw1523738 for ; Thu, 16 Jun 2011 11:27:44 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5G1SjfU009841 for ; Thu, 16 Jun 2011 11:28:45 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5G1SjiL009834; Thu, 16 Jun 2011 11:28:45 +1000
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> 	<90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET> 	 
X-KeepSent: 46AAB970:0BDB52D7-4A2578B1:0007709C; type=4; name=$KeepSent
To: Brian Eaton 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Thu, 16 Jun 2011 11:28:35 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 16/06/2011 11:32:09
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 01:28:54 -0000

Brian Eaton  wrote on 16-06-2011 10:36:18 AM:

> From: Brian Eaton 
> To: Shane B Weeden/Australia/IBM@IBMAU
> Cc: OAuth WG 
> Date: 16-06-11 10:49 AM
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden =

wrote:
> Brain - can you elaborate on that a little? Are you suggesting that
clients
> that can't keep secrets use a dummy (notasecret) pwd anyway to satisf=
y
> "requiring client authentication"?
>
> Or use random secrets. =A0Whatever floats your boat and keeps your
> product managers happy. =A0It does not make a practical security
> difference for installed applications.

That is the same thing as not requiring client authentication at all (f=
or
installed applications). Having the spec say client authentication is
REQUIRED for the token endpoint is therefore misleading and nonsensical=
.

>
> What seems to be missing in the discussion and the security
considerations
> of the spec is a decent list of general and grant-type-specific secur=
ity
> implications/pros/cons for the system if meaningful client authentica=
tion
> at the token endpoint is available or not available.
>
> Yep.

I believe this piece of work would go a long way to settling the disput=
es
about when/why/if client authentication should be required at the token=

endpoint. For example I would like to see attempts to answer this quest=
ion:
If client authentication is not possible or required at the token endpo=
int
for native/installed apps, what advantages are gained from requiring it=
 for
clients that can authenticate?=



From James.H.Manger@team.telstra.com  Wed Jun 15 19:37:06 2011
Return-Path: 
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 76C7711E80DC for ; Wed, 15 Jun 2011 19:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u42DDbxkA-q5 for ; Wed, 15 Jun 2011 19:37:05 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3966111E810D for ; Wed, 15 Jun 2011 19:37:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,372,1304258400"; d="scan'208,217";a="40244813"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 16 Jun 2011 12:36:55 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6378"; a="29589580"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 16 Jun 2011 12:36:55 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 16 Jun 2011 12:36:54 +1000
From: "Manger, James H" 
To: Eran Hammer-Lahav , OAuth WG 
Date: Thu, 16 Jun 2011 12:36:52 +1000
Thread-Topic: Redirection URI and Implicit grant
Thread-Index: AcwrkXd5SBig2F1wTQuL6ojuGIKt8wAOpzcg
Message-ID: <255B9BB34FB7D647A506DC292726F6E11286961CF7@WSMSG3153V.srv.dir.telstra.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11286961CF7WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 02:37:06 -0000

--_000_255B9BB34FB7D647A506DC292726F6E11286961CF7WSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It seems like an authorization server receiving a request with an unregiste=
red redirect_uri of https://example.org/ can tell the user:



  "Permission will be passed to your browser then onto *example.org*"



An authorization server receiving a request with a registered redirect_uri =
of https://example.net/ can tell the user:



  "Permission will be passed to your browser then onto *WidgetXYZ by Exampl=
e Inc (example.net) [logo]*"



Where the label, company, and logo are extra details from the registration,=
 hopefully after some verification by the authorization server that all the=
se details are a consistent set. That verification could come from some dis=
covery on the redirect_uri, or from reputation stats - perhaps even without=
 a priori registration.



We might be better off ditching the client_id field and just keeping redire=
ct_uri in the implicit grant. If the value is registered (or the server has=
 done some discovery on it, or has some reputation stats for it) it can dis=
play a more user-friendly permission message.



The difference between registered and unregistered for clients without secr=
ets feels like a continuum, not black and white. So separate flavours (clie=
nt_id+state vs redirect_uri) makes less sense to me.



--

James Manger





From: Brian Eaton [mailto:beaton@google.com]



Security for the implicit grant type comes from identifying the client base=
d on the redirect URI.  At client registration time, you bind client_id X t=
o redirect URIs Y and Z.



If the redirect URIs use HTTPs, that gives you reasonable security.





From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer-Lahav



Changes I would like to see:



The implicit grant should be split into 2 flavors (can be given different g=
rant type name or just using normative language to define the restrictions)=
, one with client_id and state, and one with redirect_uri only.



Registered client: the client request token response type by including its =
client identifier and optional state parameter...



Unregistered client: the client request token response type by including a =
redirection URI (no client_id or state)...




--_000_255B9BB34FB7D647A506DC292726F6E11286961CF7WSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











It seems like an autho=
rization server receiving a request with an unregistered redirect_uri of
https://example.org/ can tell the user=
:


 


  “Permissi=
on will be passed to your browser then onto *example.org*”


 


An authorization serve=
r receiving a request with a registered redirect_uri of
https://example.net/ can tell the user=
:


 


  “Permissi=
on will be passed to your browser then onto *WidgetXYZ by
Example Inc (example.net) [logo]*”


 


Where the label, compa=
ny, and logo are extra details from the registration, hopefully after some =
verification by the authorization server that all these details are a consi=
stent set. That verification could come
 from some discovery on the redirect_uri, or from reputation stats – =
perhaps even without a priori registration.


 


We might be better off=
 ditching the client_id field and just keeping redirect_uri in the implicit=
 grant. If the value is registered (or the server has done some discovery o=
n it, or has some reputation stats for
 it) it can display a more user-friendly permission message.


 


The difference between=
 registered and unregistered for clients without secrets feels like a conti=
nuum, not black and white. So separate flavours (client_id+state vs red=
irect_uri) makes less sense to me.


 


--

James Manger


 


 


From: Brian Eaton [mailto=
:beaton@google.com]







Security for the implicit grant=
 type comes from identifying the client based on the redirect URI.  At=
 client registration time, you bind client_id X to redirect URIs Y and Z.


 


If the redirect URIs use HTTPs,=
 that gives you reasonable security.


 


 


From: oauth-bounces@ietf.=
org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav






Changes I would like to see:


 


The implicit grant should be sp=
lit into 2 flavors (can be given different grant type name or just using no=
rmative language to define the restrictions), one with client_id and state,=
 and one with redirect_uri only.


 


Registered client: the client r=
equest token response type by including its client identifier and optional =
state parameter…


&n=
bsp;


Unregistered client: the client=
 request token response type by including a redirection URI (no client_id o=
r state)…



 






--_000_255B9BB34FB7D647A506DC292726F6E11286961CF7WSMSG3153Vsrv_--

From eran@hueniverse.com  Wed Jun 15 19:51:20 2011
Return-Path: 
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 79C0411E808A for ; Wed, 15 Jun 2011 19:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level: 
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8UC26+owiVd for ; Wed, 15 Jun 2011 19:51:18 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 63D6311E8085 for ; Wed, 15 Jun 2011 19:51:18 -0700 (PDT)
Received: (qmail 15931 invoked from network); 16 Jun 2011 02:51:17 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 02:51:17 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 19:51:17 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , OAuth WG 
Date: Wed, 15 Jun 2011 19:50:54 -0700
Thread-Topic: Redirection URI and Implicit grant
Thread-Index: AcwrkXd5SBig2F1wTQuL6ojuGIKt8wAOpzcgAAD9yvA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C26@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11286961CF7@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11286961CF7@WSMSG3153V.srv.dir.telstra.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_90C41DD21FB7C64BB94121FBBC2E7234475E986C26P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 02:51:20 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C26P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would be interested in working out a solution where client identifier is =
just the redirection URI registered (or not), which would completely decoup=
le client authentication from the rest of the flow. But that's a much bigge=
r change.

EHL

From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, June 15, 2011 7:37 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Redirection URI and Implicit grant

It seems like an authorization server receiving a request with an unregiste=
red redirect_uri of https://example.org/ can tell the user:

  "Permission will be passed to your browser then onto *example.org*"

An authorization server receiving a request with a registered redirect_uri =
of https://example.net/ can tell the user:

  "Permission will be passed to your browser then onto *WidgetXYZ by Exampl=
e Inc (example.net) [logo]*"

Where the label, company, and logo are extra details from the registration,=
 hopefully after some verification by the authorization server that all the=
se details are a consistent set. That verification could come from some dis=
covery on the redirect_uri, or from reputation stats - perhaps even without=
 a priori registration.

We might be better off ditching the client_id field and just keeping redire=
ct_uri in the implicit grant. If the value is registered (or the server has=
 done some discovery on it, or has some reputation stats for it) it can dis=
play a more user-friendly permission message.

The difference between registered and unregistered for clients without secr=
ets feels like a continuum, not black and white. So separate flavours (clie=
nt_id+state vs redirect_uri) makes less sense to me.

--
James Manger


From: Brian Eaton [mailto:beaton@google.com]
Security for the implicit grant type comes from identifying the client base=
d on the redirect URI.  At client registration time, you bind client_id X t=
o redirect URIs Y and Z.

If the redirect URIs use HTTPs, that gives you reasonable security.


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E=
ran Hammer-Lahav
Changes I would like to see:

The implicit grant should be split into 2 flavors (can be given different g=
rant type name or just using normative language to define the restrictions)=
, one with client_id and state, and one with redirect_uri only.

Registered client: the client request token response type by including its =
client identifier and optional state parameter...

Unregistered client: the client request token response type by including a =
redirection URI (no client_id or state)...


--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C26P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I would be interested in working out a solution where client =
identifier is just the redirection URI registered (or not), which would com=
pletely decouple client authentication from the rest of the flow. But that&=
#8217;s a much bigger change.
 
EHL
 
From: Manger, James H [mailto:James.H.Manger@team.=
telstra.com] 
Sent: Wednesday, June 15, 2011 7:37 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Redirection URI and Im=
plicit grant
&nb=
sp;
It seems like an authorization server receiving a request with an unregis=
tered redirect_uri of https://example.org/=
 can tell the user:
 
  “Permission=
 will be passed to your browser then onto *example.org*”<=
/o:p>
 
An authorization server receiving a request with a re=
gistered redirect_uri of https://example.n=
et/ can tell the user:
 
  “Permi=
ssion will be passed to your browser then onto *WidgetXYZ by Exam=
ple Inc (example.net) [logo]*”
 =

Where t=
he label, company, and logo are extra details from the registration, hopefu=
lly after some verification by the authorization server that all these deta=
ils are a consistent set. That verification could come from some discovery =
on the redirect_uri, or from reputation stats – perhaps even without =
a priori registration.
 
We might be better off di=
tching the client_id field and just keeping redirect_uri in the implicit gr=
ant. If the value is registered (or the server has done some discovery on i=
t, or has some reputation stats for it) it can display a more user-friendly=
 permission message.
 
The difference between re=
gistered and unregistered for clients without secrets feels like a continuu=
m, not black and white. So separate flavours (client_id+state vs redirect_u=
ri) makes less sense to me.
 
--
James =
Manger
 
 
From: Brian Eaton [mailto:beaton@goo=
gle.com] 
Security for the implic=
it grant type comes from identifying the client based on the redirect URI. =
 At client registration time, you bind client_id X to redirect URIs Y =
and Z.
 
If the redirect URIs use HTTPs, that gives you reasonable security=
.
 
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces=
@ietf.org] On Behalf Of Eran Hammer-Lahav<=
o:p>
Changes I would like to see:=

 
Th=
e implicit grant should be split into 2 flavors (can be given different gra=
nt type name or just using normative language to define the restrictions), =
one with client_id and state, and one with redirect_uri only.
 
Registered =
client: the client request token response type by including its client iden=
tifier and optional state parameter…
=
 
Unregistered client: the client=
 request token response type by including a redirection URI (no client_id o=
r state)… 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986C26P3PW5EX1MB01E_--

From James.H.Manger@team.telstra.com  Wed Jun 15 22:01:43 2011
Return-Path: 
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 3718F11E814B for ; Wed, 15 Jun 2011 22:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzzovABDl2Kx for ; Wed, 15 Jun 2011 22:01:42 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3311E8147 for ; Wed, 15 Jun 2011 22:01:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,373,1304258400"; d="scan'208";a="36584982"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 16 Jun 2011 15:01:37 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6378"; a="28996104"
Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbvi.tcif.telstra.com.au with ESMTP; 16 Jun 2011 15:01:37 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 16 Jun 2011 15:01:36 +1000
From: "Manger, James H" 
To: OAuth WG 
Date: Thu, 16 Jun 2011 15:01:34 +1000
Thread-Topic: issuing multiple tokens
Thread-Index: Acwp8T/QhQv6PCwwRgeA9sbjnXT3sgB5E6lg
Message-ID: <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com>
In-Reply-To: <4DF64BF3.7010602@alcatel-lucent.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 05:01:43 -0000

Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 t=
o that; John Bradley identified that OpenID Connect needs to request multip=
le tokens; Eran Hammer-Lahav even mentioned a no-token flow as something th=
at could make sense; ...

Issuing 0, 1 or more tokens looks like an important enough feature to fix n=
ow, instead of trying to hack it in after the spec is finalised.


Changing the access token response [5.1] to be a JSON array of JSON objects=
 (one JSON object per issued token) seems like a simple way to get this imp=
ortant functionality -- with very limited overhead for services that will o=
nly ever issue a single token, and client written just for those services.

P.S. Does Facebook return a JSON object for its access token response (as i=
n draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded as =
the example at http://developers.facebook.com/docs/authentication/ implies =
[4th screen shot down]?

--
James Manger


Eran said (on a different thread):

...if the client can authenticate with the authorization server. Why not ju=
st include the client identifier and user identifier and let the authorizat=
ion server lookup what the user already authorized?


Igor Faynberg wrote:

+1

Torsten Lodderstedt wrote:
> Hi,
>
> I also see the need to request and issue multiple tokens in a single=20
> authorization process. There has already been some discussion about=20
> this topic roughly a year ago:
> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>
> We at Deutsche Telekom have implemented an OAuth 2.0 extension=20
> supporting that use case. It's called "bulk authorization".
>
> Would that be an interessting topic we could discuss at IETF-81 for=20
> the re-chartering?  I could present our approach there.
>
> regards,
> Torsten.

> Am 10.06.2011 21:08, schrieb John Bradley:
>> We have identified the need to request multiple tokens as one issue=20
>> that we would have to extend.

From eran@hueniverse.com  Wed Jun 15 22:32:19 2011
Return-Path: 
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 20ED111E80D4 for ; Wed, 15 Jun 2011 22:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKaXHPe4rns5 for ; Wed, 15 Jun 2011 22:32:18 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 09D6811E80B4 for ; Wed, 15 Jun 2011 22:32:17 -0700 (PDT)
Received: (qmail 10178 invoked from network); 16 Jun 2011 05:32:16 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 05:32:16 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 15 Jun 2011 22:32:15 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , OAuth WG 
Date: Wed, 15 Jun 2011 22:31:52 -0700
Thread-Topic: issuing multiple tokens
Thread-Index: Acwp8T/QhQv6PCwwRgeA9sbjnXT3sgB5E6lgAARD6AA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 05:32:19 -0000

My comment was not about not issuing an access token, but about the need fo=
r a refresh token *and* client authentication.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Wednesday, June 15, 2011 10:02 PM
> To: OAuth WG
> Subject: [OAUTH-WG] issuing multiple tokens
>=20
> Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1=
 to
> that; John Bradley identified that OpenID Connect needs to request multip=
le
> tokens; Eran Hammer-Lahav even mentioned a no-token flow as something
> that could make sense; ...
>=20
> Issuing 0, 1 or more tokens looks like an important enough feature to fix
> now, instead of trying to hack it in after the spec is finalised.
>=20
>=20
> Changing the access token response [5.1] to be a JSON array of JSON objec=
ts
> (one JSON object per issued token) seems like a simple way to get this
> important functionality -- with very limited overhead for services that w=
ill
> only ever issue a single token, and client written just for those service=
s.
>=20
> P.S. Does Facebook return a JSON object for its access token response (as=
 in
> draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded as
> the example at http://developers.facebook.com/docs/authentication/
> implies [4th screen shot down]?
>=20
> --
> James Manger
>=20
>=20
> Eran said (on a different thread):
>=20
> ...if the client can authenticate with the authorization server. Why not =
just
> include the client identifier and user identifier and let the authorizati=
on
> server lookup what the user already authorized?
>=20
>=20
> Igor Faynberg wrote:
>=20
> +1
>=20
> Torsten Lodderstedt wrote:
> > Hi,
> >
> > I also see the need to request and issue multiple tokens in a single
> > authorization process. There has already been some discussion about
> > this topic roughly a year ago:
> > - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> > - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> >
> > We at Deutsche Telekom have implemented an OAuth 2.0 extension
> > supporting that use case. It's called "bulk authorization".
> >
> > Would that be an interessting topic we could discuss at IETF-81 for
> > the re-chartering?  I could present our approach there.
> >
> > regards,
> > Torsten.
>=20
> > Am 10.06.2011 21:08, schrieb John Bradley:
> >> We have identified the need to request multiple tokens as one issue
> >> that we would have to extend.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From phil.hunt@oracle.com  Wed Jun 15 22:40:06 2011
Return-Path: 
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 6568E11E815C for ; Wed, 15 Jun 2011 22:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnZ44KkMFIyp for ; Wed, 15 Jun 2011 22:40:05 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 863B911E80D4 for ; Wed, 15 Jun 2011 22:40:05 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5G5e3BP007290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 05:40:04 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5G5e1Be026814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 05:40:02 GMT
Received: from abhmt018.oracle.com (abhmt018.oracle.com [141.146.116.27]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5G5duow000557; Thu, 16 Jun 2011 00:39:56 -0500
Received: from dhcp184-48-102-226.fisc.sjc.wayport.net (/184.48.102.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Jun 2011 22:39:56 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 15 Jun 2011 22:39:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090206.4DF99735.002D:SCFSTAT5015188,ss=1,fgs=0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 05:40:06 -0000

+1

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-15, at 10:01 PM, Manger, James H wrote:

> Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said =
+1 to that; John Bradley identified that OpenID Connect needs to request =
multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as =
something that could make sense; ...
>=20
> Issuing 0, 1 or more tokens looks like an important enough feature to =
fix now, instead of trying to hack it in after the spec is finalised.
>=20
>=20
> Changing the access token response [5.1] to be a JSON array of JSON =
objects (one JSON object per issued token) seems like a simple way to =
get this important functionality -- with very limited overhead for =
services that will only ever issue a single token, and client written =
just for those services.
>=20
> P.S. Does Facebook return a JSON object for its access token response =
(as in draft-ietf-oauth-v2-12 that they reference), or =
x-www-form-urlencoded as the example at =
http://developers.facebook.com/docs/authentication/ implies [4th screen =
shot down]?
>=20
> --
> James Manger
>=20
>=20
> Eran said (on a different thread):
>=20
> ...if the client can authenticate with the authorization server. Why =
not just include the client identifier and user identifier and let the =
authorization server lookup what the user already authorized?
>=20
>=20
> Igor Faynberg wrote:
>=20
> +1
>=20
> Torsten Lodderstedt wrote:
>> Hi,
>>=20
>> I also see the need to request and issue multiple tokens in a single=20=

>> authorization process. There has already been some discussion about=20=

>> this topic roughly a year ago:
>> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
>> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>>=20
>> We at Deutsche Telekom have implemented an OAuth 2.0 extension=20
>> supporting that use case. It's called "bulk authorization".
>>=20
>> Would that be an interessting topic we could discuss at IETF-81 for=20=

>> the re-chartering?  I could present our approach there.
>>=20
>> regards,
>> Torsten.
>=20
>> Am 10.06.2011 21:08, schrieb John Bradley:
>>> We have identified the need to request multiple tokens as one issue=20=

>>> that we would have to extend.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From eran@hueniverse.com  Wed Jun 15 22:46:26 2011
Return-Path: 
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 B9BB911E80D0 for ; Wed, 15 Jun 2011 22:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMdR-eb-V5mP for ; Wed, 15 Jun 2011 22:46:25 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id C515C11E80BC for ; Wed, 15 Jun 2011 22:46:25 -0700 (PDT)
Received: (qmail 19049 invoked from network); 16 Jun 2011 05:46:25 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 05:46:25 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 22:46:25 -0700
From: Eran Hammer-Lahav 
To: Phil Hunt , "Manger, James H" 
Date: Wed, 15 Jun 2011 22:46:01 -0700
Thread-Topic: [OAUTH-WG] issuing multiple tokens
Thread-Index: Acwr599HSlc3nszTS6K0drhdC2gP4QAAAyvg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 05:46:26 -0000

It is not an important enough feature. Parsing an array response when 99.99=
% will be a single object array is annoying. Also, what would you return in=
 case of error? A single object? What is the client supposed to do if it ge=
ts an empty array? Array with more than one token?

*This* would be the hack... If this is something people want to deploy, a f=
ull proposal end-to-end is required. And not now.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Wednesday, June 15, 2011 10:40 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>=20
> +1
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>=20
> > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said =
+1
> to that; John Bradley identified that OpenID Connect needs to request
> multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
> something that could make sense; ...
> >
> > Issuing 0, 1 or more tokens looks like an important enough feature to f=
ix
> now, instead of trying to hack it in after the spec is finalised.
> >
> >
> > Changing the access token response [5.1] to be a JSON array of JSON
> objects (one JSON object per issued token) seems like a simple way to get
> this important functionality -- with very limited overhead for services t=
hat will
> only ever issue a single token, and client written just for those service=
s.
> >
> > P.S. Does Facebook return a JSON object for its access token response (=
as
> in draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded
> as the example at http://developers.facebook.com/docs/authentication/
> implies [4th screen shot down]?
> >
> > --
> > James Manger
> >
> >
> > Eran said (on a different thread):
> >
> > ...if the client can authenticate with the authorization server. Why no=
t just
> include the client identifier and user identifier and let the authorizati=
on
> server lookup what the user already authorized?
> >
> >
> > Igor Faynberg wrote:
> >
> > +1
> >
> > Torsten Lodderstedt wrote:
> >> Hi,
> >>
> >> I also see the need to request and issue multiple tokens in a single
> >> authorization process. There has already been some discussion about
> >> this topic roughly a year ago:
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> >>
> >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
> >> supporting that use case. It's called "bulk authorization".
> >>
> >> Would that be an interessting topic we could discuss at IETF-81 for
> >> the re-chartering?  I could present our approach there.
> >>
> >> regards,
> >> Torsten.
> >
> >> Am 10.06.2011 21:08, schrieb John Bradley:
> >>> We have identified the need to request multiple tokens as one issue
> >>> that we would have to extend.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From phil.hunt@oracle.com  Wed Jun 15 23:08:18 2011
Return-Path: 
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 4EF9311E80C9 for ; Wed, 15 Jun 2011 23:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1Vhw+tU44cx for ; Wed, 15 Jun 2011 23:08:17 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 721C311E80AB for ; Wed, 15 Jun 2011 23:08:17 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5G68Er9006313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 06:08:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5G68DTs026922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 06:08:13 GMT
Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5G687Px003305; Thu, 16 Jun 2011 01:08:07 -0500
Received: from dhcp184-48-102-226.fisc.sjc.wayport.net (/184.48.102.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Jun 2011 23:08:07 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 23:08:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4DF99DD0.0026:SCFMA922111,ss=1,fgs=0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 06:08:18 -0000

Eran,
Agree, having an array all the time would be a pain.

Still, I maintain a +1 to explore this a wee bit further much as I hate =
to do so at this late stage.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-15, at 10:46 PM, Eran Hammer-Lahav wrote:

> It is not an important enough feature. Parsing an array response when =
99.99% will be a single object array is annoying. Also, what would you =
return in case of error? A single object? What is the client supposed to =
do if it gets an empty array? Array with more than one token?
>=20
> *This* would be the hack... If this is something people want to =
deploy, a full proposal end-to-end is required. And not now.
>=20
> EHL
>=20
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Phil Hunt
>> Sent: Wednesday, June 15, 2011 10:40 PM
>> To: Manger, James H
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] issuing multiple tokens
>>=20
>> +1
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>>=20
>>> Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg =
said +1
>> to that; John Bradley identified that OpenID Connect needs to request
>> multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
>> something that could make sense; ...
>>>=20
>>> Issuing 0, 1 or more tokens looks like an important enough feature =
to fix
>> now, instead of trying to hack it in after the spec is finalised.
>>>=20
>>>=20
>>> Changing the access token response [5.1] to be a JSON array of JSON
>> objects (one JSON object per issued token) seems like a simple way to =
get
>> this important functionality -- with very limited overhead for =
services that will
>> only ever issue a single token, and client written just for those =
services.
>>>=20
>>> P.S. Does Facebook return a JSON object for its access token =
response (as
>> in draft-ietf-oauth-v2-12 that they reference), or =
x-www-form-urlencoded
>> as the example at http://developers.facebook.com/docs/authentication/
>> implies [4th screen shot down]?
>>>=20
>>> --
>>> James Manger
>>>=20
>>>=20
>>> Eran said (on a different thread):
>>>=20
>>> ...if the client can authenticate with the authorization server. Why =
not just
>> include the client identifier and user identifier and let the =
authorization
>> server lookup what the user already authorized?
>>>=20
>>>=20
>>> Igor Faynberg wrote:
>>>=20
>>> +1
>>>=20
>>> Torsten Lodderstedt wrote:
>>>> Hi,
>>>>=20
>>>> I also see the need to request and issue multiple tokens in a =
single
>>>> authorization process. There has already been some discussion about
>>>> this topic roughly a year ago:
>>>> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
>>>> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>>>>=20
>>>> We at Deutsche Telekom have implemented an OAuth 2.0 extension
>>>> supporting that use case. It's called "bulk authorization".
>>>>=20
>>>> Would that be an interessting topic we could discuss at IETF-81 for
>>>> the re-chartering?  I could present our approach there.
>>>>=20
>>>> regards,
>>>> Torsten.
>>>=20
>>>> Am 10.06.2011 21:08, schrieb John Bradley:
>>>>> We have identified the need to request multiple tokens as one =
issue
>>>>> that we would have to extend.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From t.lodderstedt@telekom.de  Thu Jun 16 01:31:28 2011
Return-Path: 
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 2382211E80F0 for ; Thu, 16 Jun 2011 01:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tfWBn6PvmGN for ; Thu, 16 Jun 2011 01:31:27 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6130411E807B for ; Thu, 16 Jun 2011 01:31:26 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail71.telekom.de with ESMTP; 16 Jun 2011 10:27:36 +0200
Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 16 Jun 2011 10:27:36 +0200
Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Thu, 16 Jun 2011 10:27:35 +0200
From: "Lodderstedt, Torsten" 
To: Eran Hammer-Lahav , Mike Jones , David Recordon , George Fletcher 
Date: Thu, 16 Jun 2011 10:25:32 +0200
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AQHMEGLvUtk/Y41LJU+xw7NH/M+2opSa0CjQgAgtbYCABOk9gIAAwn+AgABmmeCAFdUR4IAA9jJA
Message-Id: <63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 08:31:28 -0000

The reason why I suggested the name "bearer_token" was to achieve a consist=
ent naming convention across different ways to uses those tokens (URI query=
, HTTP authn scheme). Now the discussion centers around achieving a consist=
ent naming between token acquisition and usage. I'm basically fine with rev=
erting to "access_token".

Just one question:=20
Is the assumption of the group that bearer tokens are the only type of toke=
ns to be used in conjunction with URI query parameters? Otherwise, a mechan=
ism is needed to distinguish bearer and other tokens, e.g. another paramete=
r (token_type?).

Regards,
Torsten.
> -----Urspr=FCngliche Nachricht-----
> Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Gesendet: Mittwoch, 15. Juni 2011 19:38
> An: Mike Jones; David Recordon; George Fletcher
> Cc: paul Tarjan; oauth@ietf.org
> Betreff: Re: [OAUTH-WG] consistency of token param name in bearer token
> type
>=20
> It should be pretty easy :-)
>=20
> Anyone objects to changing the parameter name from 'bearer_token' to
> 'access_token'? Let Mike know by 6/20 or he will make the change.
>=20
> EHL
>=20
>=20
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> > Of Mike Jones
> > Sent: Wednesday, June 01, 2011 1:15 PM
> > To: David Recordon; George Fletcher
> > Cc: paul Tarjan; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] consistency of token param name in bearer
> token
> > type
> >
> > If you can drive a consensus decision for the name "access_token",
> I'd be
> > glad to change the name in the spec.  I agree that the current names
> are
> > confusing for developers.
> >
> > 				-- Mike
> >
> > -----Original Message-----
> > From: David Recordon [mailto:recordond@gmail.com]
> > Sent: Wednesday, June 01, 2011 12:06 AM
> > To: George Fletcher
> > Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
> > Subject: Re: [OAUTH-WG] consistency of token param name in bearer
> token
> > type
> >
> > Yeah, can understand how we got here. Just found it quite confusing
> when
> > reading these two specifications together with an implementor's hat
> on.
> >
> > On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
> > wrote:
> > > Brief pointer to the "history" of this change. This change was
> adopted
> > > in draft 4 of the bearer spec as there were concerns with the
> previous
> > > parameter name of 'oauth_token'. The suggestion was made to use
> > > 'bearer_token' so that it matches the scheme used in the
> Authorization
> > > header. The thinking being that reading the bearer token spec would
> > > seem weird if the Authorization header used one name and the
> GET/POST
> > > methods used a different name.
> > >
> > > The 'bearer_token' name got a few +1 and no dissents.
> > >
> > > Full thread starts here [1]. Mike accepting the 'bearer_token'
> > > recommendation is here [2].
> > >
> > > Thanks,
> > > George
> > >
> > > [1] http://www.ietf.org/mail-
> archive/web/oauth/current/msg05497.html
> > > [2] http://www.ietf.org/mail-
> archive/web/oauth/current/msg05881.html
> > >
> > > On 5/28/11 12:30 PM, David Recordon wrote:
> > >
> > > Did a full read through of draft 16 and the bear token spec with
> Paul
> > > yesterday afternoon in order to do a manual diff from draft 10. The
> > > point Doug raised was actually confusing. Throughout the core spec
> > > it's referred to as access_token but then becomes bearer_token upon
> > > use.
> > >
> > > Just thinking through this from a developer documentation
> perspective,
> > > it's going to become confusing. Developer documentation focuses on
> > > getting an access token and then using that access token to
> interact
> > > with an API. Thus the code you're writing as a client developer
> will
> > > use variables, cache keys, and database columns named
> `access_token`.
> > > But then when you're going to use it, you'll need to put this
> access
> > > token into a field named bearer_token.
> > >
> > > Feels quite a bit simpler to just name it access_token. Realize the
> > > core spec never did this since we didn't want to trample on
> protected
> > > resources which might already have a different type of access_token
> > > parameter. oauth_token was a good compromise since developers would
> > > already know that they were using OAuth and thus a new term wasn't
> > > being introduced. That's no longer true with bearer_token since 99%
> of
> > > developers will have never heard of a bearer token.
> > >
> > > Googling for "bearer token" turns up Eran's blog post titled "OAuth
> > > Bearer Tokens are a Terrible Idea" and there isn't a single result
> on
> > > the first page which explains what they are. Binging for "bearer
> > > token" is equally scary.
> > >
> > > --David
> > >
> > >
> > > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> > >  wrote:
> > >
> > > The working group explicitly decided that a different name should
> be
> > > used, to make it clear that other token types other than bearer
> tokens
> > > could also be used with OAuth 2.
> > >
> > >
> > >
> > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
> > >
> > >
> > >
> > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> > > Of Doug Tangren
> > > Sent: Wednesday, May 11, 2011 10:09 PM
> > > To: oauth@ietf.org
> > > Subject: [OAUTH-WG] consistency of token param name in bearer token
> > > type
> > >
> > >
> > >
> > > This may have come up before so I'm sorry if I'm repeating. Why
> does
> > > bearer token spec introduce a new name for oauth2 access tokens
> [1],
> > > "bearer_token", and before that [2], "oauth_token"?
> > >
> > >
> > >
> > > I=A0apologize=A0if this may sound shallow but, why introduce a new
> > > parameter name verses sticking with what the general oauth2 spec
> > > already defines, "access_token". It seems arbitrary for an auth
> server
> > > to hand a client an apple then have the client hand it off to the
> > > resource server and call it an orange.
> > >
> > >
> > >
> > > Was this just for the sake of differentiating the parameter name
> > > enough so that the bearer tokens may be used in other protocols
> > > without being confused with oauth2 access_tokens?
> > >
> > >
> > >
> > > [1]:
> > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-
> 2.2
> > >
> > > [2]:
> > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-
> 2.2
> > >
> > >
> > >
> > > -Doug Tangren
> > > http://lessis.me
> > >
> > > _______________________________________________
> > > 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
> > >
> > >
> > > --
> > > Chief Architect                   AIM:  gffletch
> > > Identity Services Engineering     Work: george.fletcher@teamaol.com
> > > AOL Inc.                          Home: gffletch@aol.com
> > > Mobile: +1-703-462-3494           Blog:
> http://practicalid.blogspot.com
> > > Office: +1-703-265-2544           Twitter:
> http://twitter.com/gffletch
> > >
> >
> > _______________________________________________
> > 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

From t.lodderstedt@telekom.de  Thu Jun 16 01:36:31 2011
Return-Path: 
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 9470A11E80F0 for ; Thu, 16 Jun 2011 01:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GIIiCcXAd2P for ; Thu, 16 Jun 2011 01:36:30 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3A54311E807B for ; Thu, 16 Jun 2011 01:36:30 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail71.telekom.de with ESMTP; 16 Jun 2011 10:33:11 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 16 Jun 2011 10:33:11 +0200
Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Thu, 16 Jun 2011 10:32:58 +0200
From: "Lodderstedt, Torsten" 
To: Brian Eaton , Eran Hammer-Lahav 
Date: Thu, 16 Jun 2011 10:32:57 +0200
Thread-Topic: [OAUTH-WG] Refresh tokens
Thread-Index: Acwris2uGJwLEGMWQJik6w+PGMabFQAdS24w
Message-Id: <63366D5A116E514AA4A9872D3C53353956F676C5B8@QEO40072.de.t-online.corp>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956F676C5B8QEO40072deton_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 08:36:31 -0000

--_000_63366D5A116E514AA4A9872D3C53353956F676C5B8QEO40072deton_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

Von: Brian Eaton [mailto:beaton@google.com]
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Hammer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh tokens

On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav > wrote:
I would like to add a quick discussion of access token and refresh token re=
commended deployment setup, providing clear guidelines when a refresh token=
 SHOULD and SHOULD NOT be issued, and when issues, how it is difference fro=
m the access token.

Is this a start?

http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html

It's time we stop trying to accommodate every possible combination and make=
 some hard choices.

+1.  Yes please.

--_000_63366D5A116E514AA4A9872D3C53353956F676C5B8QEO40072deton_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


+1
 
Von: Brian Eaton [mailto:beaton@google.co=
m] 
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Ha=
mmer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh=
 tokens
 
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-=
Lahav <eran@hueniverse.com>=
; wrote:
I would like to add a quick discus=
sion of access token and refresh token recommended deployment setup, provid=
ing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, =
and when issues, how it is difference from the access token.
 =

Is this a start?
 
  
It’s time we stop trying to accommodate every possible=
 combination and make some hard choices.
<=
/blockquote>
 
+1.  Yes please.
<=
/html>=

--_000_63366D5A116E514AA4A9872D3C53353956F676C5B8QEO40072deton_--

From t.lodderstedt@telekom.de  Thu Jun 16 01:38:27 2011
Return-Path: 
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 B877111E807E for ; Thu, 16 Jun 2011 01:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.948
X-Spam-Level: 
X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xjcxBD5GAd8 for ; Thu, 16 Jun 2011 01:38:24 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id A329811E807B for ; Thu, 16 Jun 2011 01:38:23 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail31.telekom.de with ESMTP; 16 Jun 2011 10:38:21 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 16 Jun 2011 10:38:15 +0200
Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Thu, 16 Jun 2011 10:37:58 +0200
From: "Lodderstedt, Torsten" 
To: Eran Hammer-Lahav , Torsten Lodderstedt , Brian Eaton 
Date: Thu, 16 Jun 2011 10:37:48 +0200
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtA=
Message-Id: <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956F676C5BCQEO40072deton_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 08:38:27 -0000

--_000_63366D5A116E514AA4A9872D3C53353956F676C5BCQEO40072deton_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_63366D5A116E514AA4A9872D3C53353956F676C5BCQEO40072deton_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The ability to describe a client to the user does not depe=
nd on the authentication but on the identification of the client and the me=
ta data available to the authz server. The only difference between identifi=
ed and authenticated clients is the trust level the authz server has regard=
ing the client’s identity. It must clearly indicate this fact to the =
end-user.
 
regards,<=
o:p>
Torsten.=

 =

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Gesend=
et: Mittwoch, 15. Juni 2011 21:20
An=
: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff=
: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
=

 
I agree to the extent that th=
e user can be trusted to know how they got to the authorization endpoint.
 
If the client cannot=
 be authenticated, the authorization server is limited in the information i=
t can offer the user to make the decision. It is extremely hard to come up =
with language that will tell the user to only approve the application, clai=
ming to be X, if they got here from X directly. There might be ways to impr=
ove security a bit using Origin header etc. but overall, if the client is n=
ot authenticated, the authorization server can’t really describe it t=
o the user.
<=
o:p> 
EHL
 
 
Fr=
om: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Th=
ursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth=
 WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16=

&=
nbsp;
I fully agree=
 with Brian and would like to add some thoughts: 

Not authenticating=
 the client does not directly create a security problem at all. If we would=
 follow this line, every e-Mail client out there would be considered insecu=
re because the client itself is never authenticated. Not even Kerbereos has=
 a concept of client authentication. 

In my opinion, OAuth client au=
thentication (in delegated authorization scenarios) is an improvement over =
classical approaches. But I do not see a degration in security if it is not=
 applicable. As long as the _user_ authorizes the client's access (and the =
duration of the token) and is able to revoke the tokens at any time, the si=
tuation is much better than with classical approaches. 

regards,
=
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton: 
Hey Peter - 
 =
;
I have=
n't read all of your comments yet, but I wanted to clarify one point about =
client impersonation and installed apps.  The cuirrent text is unreali=
stic, but your request would push it the wrong way.  CC'ing Torsten as=
 well.
 
---------------------
OLD:
  The authorization server SHOULD issue acce=
ss tokens with limited
  scop=
e and duration to clients incapable of authenticating.

NEW:
&nbs=
p; If the authorization server issues access tokens to clients
  that are incapable of authenticating, t=
he scope and duration of
  su=
ch tokens SHOULD be limited.

R=
ATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
--------=
-------------
 
We are most definitely recommending that clients =
that have no way of authenticating are issued long-lived credentials to acc=
ess user data.
 
Most installed applications work as follows:
- they ask the user for their passwor=
d
- they save the password to disk<=
o:p>
 
<=
div>
That's a horrible security problem, because it means you cannot=
 upgrade user authentication to anything stronger than a password.  Cl=
ient certificates, one time passwords, risk based authentication, throw it =
all out the window.  If you're going to let installed apps authenticat=
e with just a password, nothing else you do to improve authentication is go=
ing to help.
 
This is a blocking issue for rolling out stronger =
forms of user authentication, and it's one of the main reasons I care about=
 OAuth2.  
 
Think IMAP and XMPP clients running on Windows desktops.  =
They are important, and we need a way to migrate them off of saving passwor=
ds.
 
So the current text basically says that =
you should issue temporary credentials to native apps.  That's not pra=
ctical.  Native apps end up needing permanent or near-permanent creden=
tials.  Expirations need to be measured in months.  And the crede=
ntials are going to be issued to stock IMAP and XMPP clients that don't hav=
e any way of authenticating themselves.
 
The advantage with OAut=
h2 over passwords is that
a) the re=
fresh tokens are unguessable.
b) th=
e refresh tokens aren't sent directly to the IMAP and XMPP servers, they ar=
e restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can cre=
ate flows that bridge from those managed credentials to temporary access cr=
edentials.
 
Cheers,
Bri=
an
=

--_000_63366D5A116E514AA4A9872D3C53353956F676C5BCQEO40072deton_--

From tdb2@ecs.soton.ac.uk  Thu Jun 16 01:43:39 2011
Return-Path: 
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 9519011E80EB for ; Thu, 16 Jun 2011 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level: 
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_URI_EQUALS=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fZg48F7aEe6 for ; Thu, 16 Jun 2011 01:43:35 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E011E807E for ; Thu, 16 Jun 2011 01:43:34 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5G8hSJC032251;  Thu, 16 Jun 2011 09:43:28 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5G8hSJC032251
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308213808; bh=6is92ezumfkle18bX9rKyfUjNPU=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References; b=MNjFH9yEj5T8WIbndjjPRMQ1xDhfucNih4VOM8tBnou39sZ9llkY036cV0eoPVpa6 gFD/rgijrn6Bkl0Ch7ViFuJ+VYqxZdxPrmjxT8bqV3PHOTFPi0L50S2YUtWF7DHifL p30PDLVc1ySHqQ8Nx2LXV4IqFPZ+frrg3f3aYD9c=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP id n5F9hS0521317757mo ret-id none; Thu, 16 Jun 2011 09:43:28 +0100
Received: from roundcube.ecs.soton.ac.uk (roundcube.ecs.soton.ac.uk [152.78.189.61]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5G8hNET019366;  Thu, 16 Jun 2011 09:43:25 +0100
MIME-Version: 1.0
Date: Thu, 16 Jun 2011 09:43:10 +0100
From: Tim Brody 
To: Justin Richer 
In-Reply-To: <1308152728.29889.108.camel@ground>
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>  <90C41DD21FB7C64BB94121FBBC2E7234475E986A8B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308152728.29889.108.camel@ground> <4cd3f85c786210282278c7052129391e@ecs.soton.ac.uk>
Message-ID: 
X-Sender: tdb2@ecs.soton.ac.uk
User-Agent: ECS RoundCube
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n5F9hS052131775700; tid=n5F9hS0521317757mo; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p5G8hSJC032251
X-ECS-MailScanner-From: tdb2@ecs.soton.ac.uk
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 08:43:39 -0000

On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer 
wrote:
>> > I couldn't find a conclusion to the May 2010 discussions about using
>> > x-www-
>> > form-urlencoded vs. json nor a rationale in the spec for using JSON.
>> > Why do I
>> > need to add a JSON lexer/parser to my library just to get key-value
>> > pairs that
>> > can be represented by form-urlencoded?
>> 
>> Every modern platform has a JSON parser.
> 
> While JSON is widespread, it is an additional requirement. I've done
> some work to define and XML encoding for OAuth tokens here:
> 
>   http://tools.ietf.org/html/draft-richer-oauth-xml-00
> 
> The draft still needs to be updated to point to the right sections of
> the OAuth2 spec, but the mechanics are still valid. 

Two queries on your spec:
 - Have you considered using HTTP Accept: (content negotiation) rather than
a 'format' parameter? Regardless I suggest using MIME types rather than
'json'/'xml'.

 - Use Schema rather than typing by bespoke attributes?

It's a useful short-cut (as a consumer) to be able to apply a schema to
validate the content including all of the values via basic schema
types/regexp.
Similarly with extensions, if you use namespacing then clients will
transparently ignore anything that isn't in their recognised namespace(s).

For simplicity I would require the default namespace (xmlns=) to be oauth.
Then values can easily be extracted using string-matching in lightweight
clients:
$xml =~ /([^<]+)<\/access_token>/;

(Schema would also address your 3.7 Information Loss because the Schema
would explicitly define values as numeric or text and singular or multiple)

Lastly a general RFC point - should you reference RFC 3023, especially the
content-type and security sections?

> The point of this is similar to your contention: if I'm already speaking
> one wire format (XML), why would I want to deal with JSON just to do my
> auth step? 
> 
> If you'd like to try defining a key-value encoding, we can publish an
> extension draft for that as well.

I think the simple case is simple:
Content-type: application/x-www-form-urlencoded

access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8

I would re-use the OpenID scheme for providing extension data:

openid.ns.ax=http://openid.net/srv/ax/1.0&
openid.ax.type.email=http://schema.openid.net/contact/email&
openid.ax.value.email=tdb2@ecs.soton.ac.uk&
oauth.ns.ext=http://example.com/api#limits&
oauth.ext.soft=10000&
oauth.ext.hard=15000&
oauth.ns.rr=http://example.com/api#roles&
oauth.rr.role=owner&
oauth.rr.role=editor&
oauth.rr.role=creator&
...

I suggest a constraint that the form/urlencoded is always utf-8 (c.f.
OpenURL KEV format NISO Z39.88-2004):
Ë => %C3%8B
And never:
Ë => %CB

I'm happy to write this up but all I'd do is drop replacement text into
your RFC.
Do you have a source doc I can work on? What do I do with it when finished?

-- 
All the best,
Tim.

From t.lodderstedt@telekom.de  Thu Jun 16 02:01:17 2011
Return-Path: 
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 1DE7711E807A for ; Thu, 16 Jun 2011 02:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJvwm1raRw5b for ; Thu, 16 Jun 2011 02:01:12 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3F11E8077 for ; Thu, 16 Jun 2011 02:00:26 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail31.telekom.de with ESMTP; 16 Jun 2011 11:00:24 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 16 Jun 2011 11:00:23 +0200
Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Thu, 16 Jun 2011 11:00:22 +0200
From: "Lodderstedt, Torsten" 
To: Eran Hammer-Lahav , Chuck Mortimore , "oauth@ietf.org" 
Date: Thu, 16 Jun 2011 11:00:19 +0200
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYAAAGH/wAABbt7AAH/TfEA==
Message-Id: <63366D5A116E514AA4A9872D3C53353956F676C5D3@QEO40072.de.t-online.corp>
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AFD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986AFD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956F676C5D3QEO40072deton_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 09:01:17 -0000

--_000_63366D5A116E514AA4A9872D3C53353956F676C5D3QEO40072deton_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In my perception, the main concern raised at the F2F was the absent of the =
implicit grant in the text. That's what Chuck added including a discussion =
of the pros and cons.

Most of the discussion in the thread you referred to was about refresh toke=
ns support in the implicit grant type, which was caused by an additional qu=
estion by Chuck. This would be a fundamental change to the protocol and we =
had a lively discussion about this idea. In the end, I have not seen a prop=
osal to add this feature to the spec.

This discussion is independent of the native apps text Chuck proposed (http=
://www.ietf.org/mail-archive/web/oauth/current/msg06444.html) and I have no=
t seen any objection on this text. I therefore consider this a consensous.

So please consider the proposed text for the next revision of the draft.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 19:35
An: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Updated text for Native Apps

That's an odd way of looking at it. I'm looking at over 30 responses to the=
 text with clear disagreement on how native applications should be deployed=
 using different grant types. To say that there is consensus to the text, b=
ut not to the other comments objecting to it is ignoring the lack of consen=
sus...

If you think you can propose a new text that will be endorsed by the group,=
 please go ahead. But the F2F action item carries no weight if the list doe=
sn't like what is suggested.

What is clear from the discussion is that we have some unresolved issues ar=
ound refresh tokens and client authentication which are at the heart of adv=
ising about native applications. It would be impossible to make recommendat=
ions without resolving these issues first (and once we do, I would argue no=
 additional text would be needed).

EHL



From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:24 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Not seeing what you write about below, I think that the basic text that was=
 discussed at the F2F has consensus around the guidance (with some changes =
that were discussed and Chuck provided), I think that some of the other tho=
ughts people have thrown out don't. I disagree with dropping the text as th=
ere is not consensus to do that, since there was an action item to put text=
 back in.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'=
ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

--_000_63366D5A116E514AA4A9872D3C53353956F676C5D3QEO40072deton_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated text for Native Apps<=
style>
In my perception, the main concern raised at the F2F was the absent of th=
e implicit grant in the text. That’s what Chuck added including a dis=
cussion of the pros and cons.
 
Most of the discussion in the thread you referred to was about r=
efresh tokens support in the implicit grant type, which was caused by an ad=
ditional question by Chuck. This would be a fundamental change to the proto=
col and we had a lively discussion about this idea. In the end, I have not =
seen a proposal to add this feature to the spec. 
 
This discussion is independent of the nati=
ve apps text Chuck proposed (http://www.ietf.org/mail-archive/web/oauth/c=
urrent/msg06444.html) and I have not seen any objection on this text. I=
 therefore consider this a consensous.
 
=
So please consider the proposed text for the next revis=
ion of the draft.
 
regards,<=
/o:p>
Torsten. 
=

 
Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 19:35
An: Anthony Nada=
lin; Chuck Mortimore; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Upda=
ted text for Native Apps
 
That̵=
7;s an odd way of looking at it. I’m looking at over 30 responses to =
the text with clear disagreement on how native applications should be deplo=
yed using different grant types. To say that there is consensus to the text=
, but not to the other comments objecting to it is ignoring the lack of con=
sensus…
 
If y=
ou think you can propose a new text that will be endorsed by the group, ple=
ase go ahead. But the F2F action item carries no weight if the list doesn&#=
8217;t like what is suggested.
 
What is clear from the discussion is that we have some unresolv=
ed issues around refresh tokens and client authentication which are at the =
heart of advising about native applications. It would be impossible to make=
 recommendations without resolving these issues first (and once we do, I wo=
uld argue no additional text would be needed).
 
EHL
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'> 
 
 
From: Anthony Nadalin [mailto:tonynad@microsoft.c=
om] 
Sent: Wednesday, June 15, 2011 10:24 AM
To: Eran H=
ammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated=
 text for Native Apps
 
Not seeing what you write about below, I think that the basic=
 text that was discussed at the F2F has consensus around the guidance (with=
 some changes that were discussed and Chuck provided), I think that some of=
 the other thoughts people have thrown out don’t. I disagree with dro=
pping the text as there is not consensus to do that, since there was an act=
ion item to put text back in.
 
From: Eran Hammer-Lahav [mailto:eran@huenivers=
e.com] 
Sent: Wednesday, June 15, 2011 10:19 AM
To: Ant=
hony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Update=
d text for Native Apps
 
This working group has failed, for well over a year, to reac=
h any sort of consensus regarding which grant types are suitable for a give=
n client type. There was no draft between 00 and 16 in which we had agreeme=
nt on the definition of client types, or the exclusivity of any flow to any=
 given type. Trying to reach such a conclusion is a waste of time.
 
The main reason for this is=
 lack of deployment experience. We have pretty good experience with some ca=
ses like a server-based client capable of keeping secrets, and browser-base=
d clients executing fully visible source code. We clearly do not even have =
a clear definition of what is a native application and the recent attempt t=
o define a native application client type seems to cause more confusion tha=
n help.
 
While ther=
e is clearly an expectation that the specification will offer guidance to n=
ative application developers, I have yet to see any such text gaining conse=
nsus.
&n=
bsp;
My suggestion=
 is to drop this attempt, but if a new text gain consensus, I’ll inco=
rporate it.
<=
o:p> 
EHL
 
 
From: Anthony Nadalin [mailt=
o:tonynad@microsoft.com] 
Sent: Wednesday, June 15, 2011 10:1=
0 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Na=
tive Apps
 
Since Torsten and I had the action item to propose text we will update t=
he text based upon the list and give you back an update
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be=
half Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33=
 AM
To: Chuck Mortimore; oauth@=
ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps=

<=
o:p> 
Is ther=
e an updated text based on the long thread?
 
EHL
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck =
Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-=
WG] Updated text for Native Apps
 
Minor updates for section 9 bas=
ed upon feedback from the list

-cmort

----------------

9.  Native Applications

A native application is a client w=
hich is installed and executes on the end-user's device (i.e. desktop appli=
cation, native mobile application).  Native applications require speci=
al consideration related to security, platform capabilities, and overall en=
d-user experience.  The following are examples of how native applicati=
ons may utilize OAuth:

   o  Initiate an Authori=
zation Request using an external user-agent: The native application can cap=
ture the response from the authorization server using a variety of techniqu=
es such as the use of a redirection URI identifying a custom URI scheme (re=
gistered with the operating system to invoke the native application as hand=
ler), manual copy-and-paste, running a local webserver, browser plug-ins, o=
r by providing a redirection URI identifying a server-hosted resource under=
 the native application's control, which in turn makes the response availab=
le to the native application.
   o  Initiate an Auth=
orization Request using an embedded user-agent:  The native applicatio=
n obtains the response by directly communicating with the embedded user-age=
nt.  Techniques include monitoring state changes emitted during URL lo=
ading, monitoring http headers, accessing the user-agent's cookie jar, etc.=


When choosing between launching an external user-agent and an embed=
ding a user-agent, native application developers should consider the follow=
ing:

   o  External user-agents may improve comp=
letion rate as the end-user may already have an active session with the aut=
horization server removing the need to re-authenticate, and provide a famil=
iar user-agent user experience.  The end-user may also rely on extensi=
ons or add-ons to assist with authentication (e.g. password managers or 2-f=
actor device reader).
   o  Embedded user-agents may=
 offer an improved end-user flow, as they remove the need to switch context=
 and open new windows. 
   o  Embedded user-age=
nts pose a security challenge because end-users are authenticating in an un=
identified window without access to the visual protections offered by many =
user-agents.  Embedded user-agents educate end-user to trust unidentif=
ied requests for authentication (making phishing attacks easier to execute)=
.

When choosing between implicit and authorization code grant types,=
 the following should be considered:

   o  Nativ=
e applications that use the authorization code grant type flow SHOULD do so=
 without client password credentials, due to their inability to keep those =
credentials confidential.
   o  Native applications =
that use the implicit grant type may offer optimized performance in some sc=
enarios due to reduced network requests
   o  The im=
plicit grant type does not return a refresh token  
=

--_000_63366D5A116E514AA4A9872D3C53353956F676C5D3QEO40072deton_--

From bkihara.l@gmail.com  Thu Jun 16 05:40:35 2011
Return-Path: 
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 F009B11E8071 for ; Thu, 16 Jun 2011 05:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.129
X-Spam-Level: 
X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.470,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNXHmWIAFBp8 for ; Thu, 16 Jun 2011 05:40:35 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2486711E8070 for ; Thu, 16 Jun 2011 05:40:35 -0700 (PDT)
Received: by pwi5 with SMTP id 5so688294pwi.31 for ; Thu, 16 Jun 2011 05:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=onLcEgh+dedfvir0+faupvEYd0JcXgHbK7mDE3tVyow=; b=Ns+f0wqCr/epYYWRuVK4YcoeXZP5rlowpg7/4zqx1vApoLhuKOwI/+y/LvdC6+12f9 IWnADgo8CiTCylQLuHxr2TQDeeJmRc3kBDRvcJer+Dw56U+gdwtFEzCXzxOpU/Gq7KrR cEW5mp/ZzrNUamC0OaD0aNcUBuxMSyeB5U6fc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l21Sj5zDpe0E0aAi2J7J5TGLrQphO5r0mUyKyYGD0ZzrAETvl2FwtCHQahVonRTy5n Ze3PyIfH7iW7LjW4+tM9Qa/aewzZm0DNWIirF9uzuMBsOEr/gIdsmVV2PO/9+zLL0Iiu ZjJLVQOC2pLTXkpCRPr/052paExPew5H1KHtA=
MIME-Version: 1.0
Received: by 10.142.226.15 with SMTP id y15mr132257wfg.232.1308228034725; Thu, 16 Jun 2011 05:40:34 -0700 (PDT)
Received: by 10.142.50.6 with HTTP; Thu, 16 Jun 2011 05:40:34 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 16 Jun 2011 21:40:34 +0900
Message-ID: 
From: "KIHARA, Boku" 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 12:40:36 -0000

+1 to access_token.

2011/6/16 Eran Hammer-Lahav :
> It should be pretty easy :-)
>
> Anyone objects to changing the parameter name from 'bearer_token' to 'acc=
ess_token'? Let Mike know by 6/20 or he will make the change.
>
> EHL
>
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mike Jones
>> Sent: Wednesday, June 01, 2011 1:15 PM
>> To: David Recordon; George Fletcher
>> Cc: paul Tarjan; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
>> type
>>
>> If you can drive a consensus decision for the name "access_token", I'd b=
e
>> glad to change the name in the spec. =A0I agree that the current names a=
re
>> confusing for developers.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> -----Original Message-----
>> From: David Recordon [mailto:recordond@gmail.com]
>> Sent: Wednesday, June 01, 2011 12:06 AM
>> To: George Fletcher
>> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
>> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
>> type
>>
>> Yeah, can understand how we got here. Just found it quite confusing when
>> reading these two specifications together with an implementor's hat on.
>>
>> On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
>> wrote:
>> > Brief pointer to the "history" of this change. This change was adopted
>> > in draft 4 of the bearer spec as there were concerns with the previous
>> > parameter name of 'oauth_token'. The suggestion was made to use
>> > 'bearer_token' so that it matches the scheme used in the Authorization
>> > header. The thinking being that reading the bearer token spec would
>> > seem weird if the Authorization header used one name and the GET/POST
>> > methods used a different name.
>> >
>> > The 'bearer_token' name got a few +1 and no dissents.
>> >
>> > Full thread starts here [1]. Mike accepting the 'bearer_token'
>> > recommendation is here [2].
>> >
>> > Thanks,
>> > George
>> >
>> > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
>> > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
>> >
>> > On 5/28/11 12:30 PM, David Recordon wrote:
>> >
>> > Did a full read through of draft 16 and the bear token spec with Paul
>> > yesterday afternoon in order to do a manual diff from draft 10. The
>> > point Doug raised was actually confusing. Throughout the core spec
>> > it's referred to as access_token but then becomes bearer_token upon
>> > use.
>> >
>> > Just thinking through this from a developer documentation perspective,
>> > it's going to become confusing. Developer documentation focuses on
>> > getting an access token and then using that access token to interact
>> > with an API. Thus the code you're writing as a client developer will
>> > use variables, cache keys, and database columns named `access_token`.
>> > But then when you're going to use it, you'll need to put this access
>> > token into a field named bearer_token.
>> >
>> > Feels quite a bit simpler to just name it access_token. Realize the
>> > core spec never did this since we didn't want to trample on protected
>> > resources which might already have a different type of access_token
>> > parameter. oauth_token was a good compromise since developers would
>> > already know that they were using OAuth and thus a new term wasn't
>> > being introduced. That's no longer true with bearer_token since 99% of
>> > developers will have never heard of a bearer token.
>> >
>> > Googling for "bearer token" turns up Eran's blog post titled "OAuth
>> > Bearer Tokens are a Terrible Idea" and there isn't a single result on
>> > the first page which explains what they are. Binging for "bearer
>> > token" is equally scary.
>> >
>> > --David
>> >
>> >
>> > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
>> >  wrote:
>> >
>> > The working group explicitly decided that a different name should be
>> > used, to make it clear that other token types other than bearer tokens
>> > could also be used with OAuth 2.
>> >
>> >
>> >
>> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
>> >
>> >
>> >
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Doug Tangren
>> > Sent: Wednesday, May 11, 2011 10:09 PM
>> > To: oauth@ietf.org
>> > Subject: [OAUTH-WG] consistency of token param name in bearer token
>> > type
>> >
>> >
>> >
>> > This may have come up before so I'm sorry if I'm repeating. Why does
>> > bearer token spec introduce a new name for oauth2 access tokens [1],
>> > "bearer_token", and before that [2], "oauth_token"?
>> >
>> >
>> >
>> > I=A0apologize=A0if this may sound shallow but, why introduce a new
>> > parameter name verses sticking with what the general oauth2 spec
>> > already defines, "access_token". It seems arbitrary for an auth server
>> > to hand a client an apple then have the client hand it off to the
>> > resource server and call it an orange.
>> >
>> >
>> >
>> > Was this just for the sake of differentiating the parameter name
>> > enough so that the bearer tokens may be used in other protocols
>> > without being confused with oauth2 access_tokens?
>> >
>> >
>> >
>> > [1]:
>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
>> >
>> > [2]:
>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
>> >
>> >
>> >
>> > -Doug Tangren
>> > http://lessis.me
>> >
>> > _______________________________________________
>> > 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
>> >
>> >
>> > --
>> > Chief Architect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AIM: =A0gffletch
>> > Identity Services Engineering =A0 =A0 Work: george.fletcher@teamaol.co=
m
>> > AOL Inc. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Home: gffl=
etch@aol.com
>> > Mobile: +1-703-462-3494 =A0 =A0 =A0 =A0 =A0 Blog: http://practicalid.b=
logspot.com
>> > Office: +1-703-265-2544 =A0 =A0 =A0 =A0 =A0 Twitter: http://twitter.co=
m/gffletch
>> >
>>
>> _______________________________________________
>> 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
>

From jricher@mitre.org  Thu Jun 16 05:52:31 2011
Return-Path: 
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 EC26521F848C for ; Thu, 16 Jun 2011 05:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.766
X-Spam-Level: 
X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbiX75D8yzYu for ; Thu, 16 Jun 2011 05:52:31 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E041121F848A for ; Thu, 16 Jun 2011 05:52:30 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D45F221B0F4E; Thu, 16 Jun 2011 08:52:26 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C4AE321B046F; Thu, 16 Jun 2011 08:52:26 -0400 (EDT)
Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.159.2; Thu, 16 Jun 2011 08:52:26 -0400
From: Justin Richer 
To: Tim Brody 
In-Reply-To: 
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>  <90C41DD21FB7C64BB94121FBBC2E7234475E986A8B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308152728.29889.108.camel@ground> <4cd3f85c786210282278c7052129391e@ecs.soton.ac.uk> 
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Jun 2011 08:50:37 -0400
Message-ID: <1308228637.29889.129.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 8bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 12:52:32 -0000

On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote:
> On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer 
> wrote:
> >> > I couldn't find a conclusion to the May 2010 discussions about using
> >> > x-www-
> >> > form-urlencoded vs. json nor a rationale in the spec for using JSON.
> >> > Why do I
> >> > need to add a JSON lexer/parser to my library just to get key-value
> >> > pairs that
> >> > can be represented by form-urlencoded?
> >> 
> >> Every modern platform has a JSON parser.
> > 
> > While JSON is widespread, it is an additional requirement. I've done
> > some work to define and XML encoding for OAuth tokens here:
> > 
> >   http://tools.ietf.org/html/draft-richer-oauth-xml-00
> > 
> > The draft still needs to be updated to point to the right sections of
> > the OAuth2 spec, but the mechanics are still valid. 
> 
> Two queries on your spec:
>  - Have you considered using HTTP Accept: (content negotiation) rather than
> a 'format' parameter? Regardless I suggest using MIME types rather than
> 'json'/'xml'.

Yes, and I'm planning on putting that into the updated revision. I
already had someone yell at me about its omission. :) This will be in
addition to the format parameter, though, not in lieu of it. I also
greatly prefer short names in the parameter, especially because it's a
limited set. The Accept header will use mimetypes though, obviously. 

>  - Use Schema rather than typing by bespoke attributes?
> 
> It's a useful short-cut (as a consumer) to be able to apply a schema to
> validate the content including all of the values via basic schema
> types/regexp.
> Similarly with extensions, if you use namespacing then clients will
> transparently ignore anything that isn't in their recognised namespace(s).

I'm personally a fan of schema-by-fiat, which is what JSON does. I've
also always hated writing XML schemas. If, however, someone wants to
write a schema for the core components, I'd be fine with that. However,
I do want it to remain general enough to be able to encode more complex
extensions, and apart from saying all extensions are in some namespace,
I'm not sure how to handle that with a Schema. Speaking of namespaces...

> For simplicity I would require the default namespace (xmlns=) to be oauth.
> Then values can easily be extracted using string-matching in lightweight
> clients:
> $xml =~ /([^<]+)<\/access_token>/;

I avoided using a namespace specifically to cut down on verbosity, since
even a default namespace requires attributes in the root tag. While I
think string-matching like that in XML is a Very Bad Thing, I do want to
keep the serialization simple. That said, if there's enough of a call I
can put in a default namespace. What would the URI of that be?
http://oauth.net/2/xml? urn:oauth2:xml?

> (Schema would also address your 3.7 Information Loss because the Schema
> would explicitly define values as numeric or text and singular or multiple)

For core attributes, but not for encoding extensions. I wanted this to
be a ruleset that one could apply to a blob of JSON to translate it to
parseable XML.

> Lastly a general RFC point - should you reference RFC 3023, especially the
> content-type and security sections?

Good catch, thanks.

> > The point of this is similar to your contention: if I'm already speaking
> > one wire format (XML), why would I want to deal with JSON just to do my
> > auth step? 
> > 
> > If you'd like to try defining a key-value encoding, we can publish an
> > extension draft for that as well.
> 
> I think the simple case is simple:
> Content-type: application/x-www-form-urlencoded
> 
> access_token=SlAV32hkKG&expires_in=3600&refresh_token=8xLOxBtZp8
> 
> I would re-use the OpenID scheme for providing extension data:
> 
> openid.ns.ax=http://openid.net/srv/ax/1.0&
> openid.ax.type.email=http://schema.openid.net/contact/email&
> openid.ax.value.email=tdb2@ecs.soton.ac.uk&
> oauth.ns.ext=http://example.com/api#limits&
> oauth.ext.soft=10000&
> oauth.ext.hard=15000&
> oauth.ns.rr=http://example.com/api#roles&
> oauth.rr.role=owner&
> oauth.rr.role=editor&
> oauth.rr.role=creator&
> ...
> 
> I suggest a constraint that the form/urlencoded is always utf-8 (c.f.
> OpenURL KEV format NISO Z39.88-2004):
> Ë => %C3%8B
> And never:
> Ë => %CB

Not all OAuth extensions that return more stuff have a namespace,
though, so it's not an exact map. However, the general method of
encoding objects and lists could work.


> I'm happy to write this up but all I'd do is drop replacement text into
> your RFC.
> Do you have a source doc I can work on? What do I do with it when finished?

I'd be happy to incorporate your encoding if you want to write them up.

 -- Justin



From d.tangren@gmail.com  Thu Jun 16 06:38:33 2011
Return-Path: 
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 8BF7E11E80B7 for ; Thu, 16 Jun 2011 06:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoGcABJ07sR0 for ; Thu, 16 Jun 2011 06:38:33 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE63411E807F for ; Thu, 16 Jun 2011 06:38:32 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1532746iwn.31 for ; Thu, 16 Jun 2011 06:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zhGOVXfXj2IBbH/6ZwWCHKcFxJDNlzOOSMTFNKXB8LA=; b=CaGGjL79VtsxBStSCY8JoN04hE9lmnZ0kVR3ECDA8qHeT9Dom/xMPirFAxW6R4LiwY fEfqfdoVe3XZlC1kEeXZL2zxR3u87sG/Avzl2F5/4u/n2odhIA8ztONFUwD9ADSRAk2H Qa+/pyAjLnZg892KErHCEdDKPbvQPVoq1Zy2c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BPfFkLAS9O9gToVPpuxfvOS0GH2txu5bgotAZFUAzKbCuJEU7KfjmAd3Rq9zDSvdb2 XQzMMj8YoOFuzq8ZPKwr6f6LwvsROm91up/DpilzXeXVwMzIKZ8P5DKwlIYwECdLwX8b LM8PFX7nVQon86lH1wXo7gG8q0z8SCuTXidb8=
Received: by 10.42.212.8 with SMTP id gq8mr766003icb.392.1308231512097; Thu, 16 Jun 2011 06:38:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Thu, 16 Jun 2011 06:38:12 -0700 (PDT)
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp>
From: Doug Tangren 
Date: Thu, 16 Jun 2011 09:38:12 -0400
Message-ID: 
To: "Lodderstedt, Torsten" 
Content-Type: multipart/alternative; boundary=20cf301d43b09002c504a5d4627e
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 13:38:33 -0000

--20cf301d43b09002c504a5d4627e
Content-Type: text/plain; charset=UTF-8

-Doug Tangren
http://lessis.me


Just one question:
> Is the assumption of the group that bearer tokens are the only type of
> tokens to be used in conjunction with URI query parameters? Otherwise, a
> mechanism is needed to distinguish bearer and other tokens, e.g. another
> parameter (token_type?).
>
>
I thought the idea was that token_type was a way to define general
extensions which define protocols to provide access_tokens to resources
servicers.

I think its up to the provider of access_tokens to document which of these
token_types they support and how to distinguish them if there are multiple
token_types what use access_tokens in query parameters. I think its up to
the extension authors to provide a consistent naming scheme with the base
oauth2's defined vocabulary.

Where it gets confusing, is when multiple token_type extensions all use
different vocabulary for roughly the same thing. I say that in regards to
the naming of query parameters.

--20cf301d43b09002c504a5d4627e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


-Doug Tangren
http://lessis.me




Just one question:

Is the assumption of the group that bearer tokens are the only type of toke=
ns to be used in conjunction with URI query parameters? Otherwise, a mechan=
ism is needed to distinguish bearer and other tokens, e.g. another paramete=
r (token_type?).




I thought the idea was that token_type=
 was a way to define general extensions which define protocols to provide a=
ccess_tokens to resources servicers.=C2=A0

I think=
 its up to the provider of access_tokens to document which of these token_t=
ypes they support and how to distinguish them if there are multiple token_t=
ypes what use access_tokens in query parameters. I think its up to the exte=
nsion authors to provide a consistent naming scheme with the base oauth2=
9;s defined vocabulary.=C2=A0




Where it gets confusing, is when multiple token_type ex=
tensions all use different vocabulary for roughly the same thing. I say tha=
t in regards to the naming of query parameters.


--20cf301d43b09002c504a5d4627e--

From jricher@mitre.org  Thu Jun 16 07:03:01 2011
Return-Path: 
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 143F011E80D7 for ; Thu, 16 Jun 2011 07:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.321
X-Spam-Level: 
X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYmWBkFUTksK for ; Thu, 16 Jun 2011 07:03:00 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF51311E8084 for ; Thu, 16 Jun 2011 07:02:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5912E21B1104; Thu, 16 Jun 2011 10:02:57 -0400 (EDT)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4977521B10AE; Thu, 16 Jun 2011 10:02:57 -0400 (EDT)
Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Thu, 16 Jun 2011 10:02:56 -0400
From: Justin Richer 
To: "KIHARA, Boku" 
In-Reply-To: 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Jun 2011 10:01:07 -0400
Message-ID: <1308232867.29889.131.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 14:03:01 -0000

If we're changing the bearer token's name, are we going to change the
parameter name inside of MAC as well? At the moment, it's "id", which
I've always found an odd naming choice.

I would argue for consistency across the three main documents.

 -- Justin


On Thu, 2011-06-16 at 08:40 -0400, KIHARA, Boku wrote:
> +1 to access_token.
> 
> 2011/6/16 Eran Hammer-Lahav :
> > It should be pretty easy :-)
> >
> > Anyone objects to changing the parameter name from 'bearer_token' to 'access_token'? Let Mike know by 6/20 or he will make the change.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> >> Of Mike Jones
> >> Sent: Wednesday, June 01, 2011 1:15 PM
> >> To: David Recordon; George Fletcher
> >> Cc: paul Tarjan; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> >> type
> >>
> >> If you can drive a consensus decision for the name "access_token", I'd be
> >> glad to change the name in the spec.  I agree that the current names are
> >> confusing for developers.
> >>
> >>                               -- Mike
> >>
> >> -----Original Message-----
> >> From: David Recordon [mailto:recordond@gmail.com]
> >> Sent: Wednesday, June 01, 2011 12:06 AM
> >> To: George Fletcher
> >> Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
> >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token
> >> type
> >>
> >> Yeah, can understand how we got here. Just found it quite confusing when
> >> reading these two specifications together with an implementor's hat on.
> >>
> >> On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
> >> wrote:
> >> > Brief pointer to the "history" of this change. This change was adopted
> >> > in draft 4 of the bearer spec as there were concerns with the previous
> >> > parameter name of 'oauth_token'. The suggestion was made to use
> >> > 'bearer_token' so that it matches the scheme used in the Authorization
> >> > header. The thinking being that reading the bearer token spec would
> >> > seem weird if the Authorization header used one name and the GET/POST
> >> > methods used a different name.
> >> >
> >> > The 'bearer_token' name got a few +1 and no dissents.
> >> >
> >> > Full thread starts here [1]. Mike accepting the 'bearer_token'
> >> > recommendation is here [2].
> >> >
> >> > Thanks,
> >> > George
> >> >
> >> > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> >> > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
> >> >
> >> > On 5/28/11 12:30 PM, David Recordon wrote:
> >> >
> >> > Did a full read through of draft 16 and the bear token spec with Paul
> >> > yesterday afternoon in order to do a manual diff from draft 10. The
> >> > point Doug raised was actually confusing. Throughout the core spec
> >> > it's referred to as access_token but then becomes bearer_token upon
> >> > use.
> >> >
> >> > Just thinking through this from a developer documentation perspective,
> >> > it's going to become confusing. Developer documentation focuses on
> >> > getting an access token and then using that access token to interact
> >> > with an API. Thus the code you're writing as a client developer will
> >> > use variables, cache keys, and database columns named `access_token`.
> >> > But then when you're going to use it, you'll need to put this access
> >> > token into a field named bearer_token.
> >> >
> >> > Feels quite a bit simpler to just name it access_token. Realize the
> >> > core spec never did this since we didn't want to trample on protected
> >> > resources which might already have a different type of access_token
> >> > parameter. oauth_token was a good compromise since developers would
> >> > already know that they were using OAuth and thus a new term wasn't
> >> > being introduced. That's no longer true with bearer_token since 99% of
> >> > developers will have never heard of a bearer token.
> >> >
> >> > Googling for "bearer token" turns up Eran's blog post titled "OAuth
> >> > Bearer Tokens are a Terrible Idea" and there isn't a single result on
> >> > the first page which explains what they are. Binging for "bearer
> >> > token" is equally scary.
> >> >
> >> > --David
> >> >
> >> >
> >> > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> >> >  wrote:
> >> >
> >> > The working group explicitly decided that a different name should be
> >> > used, to make it clear that other token types other than bearer tokens
> >> > could also be used with OAuth 2.
> >> >
> >> >
> >> >
> >> >                                                             -- Mike
> >> >
> >> >
> >> >
> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> >> > Of Doug Tangren
> >> > Sent: Wednesday, May 11, 2011 10:09 PM
> >> > To: oauth@ietf.org
> >> > Subject: [OAUTH-WG] consistency of token param name in bearer token
> >> > type
> >> >
> >> >
> >> >
> >> > This may have come up before so I'm sorry if I'm repeating. Why does
> >> > bearer token spec introduce a new name for oauth2 access tokens [1],
> >> > "bearer_token", and before that [2], "oauth_token"?
> >> >
> >> >
> >> >
> >> > I apologize if this may sound shallow but, why introduce a new
> >> > parameter name verses sticking with what the general oauth2 spec
> >> > already defines, "access_token". It seems arbitrary for an auth server
> >> > to hand a client an apple then have the client hand it off to the
> >> > resource server and call it an orange.
> >> >
> >> >
> >> >
> >> > Was this just for the sake of differentiating the parameter name
> >> > enough so that the bearer tokens may be used in other protocols
> >> > without being confused with oauth2 access_tokens?
> >> >
> >> >
> >> >
> >> > [1]:
> >> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
> >> >
> >> > [2]:
> >> > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
> >> >
> >> >
> >> >
> >> > -Doug Tangren
> >> > http://lessis.me
> >> >
> >> > _______________________________________________
> >> > 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
> >> >
> >> >
> >> > --
> >> > Chief Architect                   AIM:  gffletch
> >> > Identity Services Engineering     Work: george.fletcher@teamaol.com
> >> > AOL Inc.                          Home: gffletch@aol.com
> >> > Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
> >> > Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch
> >> >
> >>
> >> _______________________________________________
> >> 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



From hardjono@mit.edu  Thu Jun 16 08:08:52 2011
Return-Path: 
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 53FC99E8013 for ; Thu, 16 Jun 2011 08:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level: 
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fRAOW14nNDI for ; Thu, 16 Jun 2011 08:08:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id B39779E8004 for ; Thu, 16 Jun 2011 08:08:51 -0700 (PDT)
X-AuditID: 1209190e-b7c39ae000000a8c-62-4dfa1c6e2ad9
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FC.A1.02700.E6C1AFD4; Thu, 16 Jun 2011 11:08:30 -0400 (EDT)
Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p5GF8oka032586;  Thu, 16 Jun 2011 11:08:50 -0400
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p5GF8mSh015685; Thu, 16 Jun 2011 11:08:50 -0400
Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 16 Jun 2011 11:08:48 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Thu, 16 Jun 2011 11:08:48 -0400
From: Thomas Hardjono 
To: Eran Hammer-Lahav , OAuth WG 
Date: Thu, 16 Jun 2011 11:08:46 -0400
Thread-Topic: Client authentication requirement
Thread-Index: AcwrgIwZK4VJQHN3TIuODI9Bl2IeewAtG68Q
Message-ID: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsUixCmqrJsn88vX4MRpRYvTCxczWpx8+4rN gclj+lF/jyVLfjIFMEVx2aSk5mSWpRbp2yVwZUxYe4K9YDdfxZN5v9kaGG9wdzFyckgImEic mXiCFcIWk7hwbz1bFyMXh5DAPkaJZzc6mSCcA4wSW97dgMpcYZSYu/gUK4SzlVFi5qo37BDO BEaJ9du3sYMMYxPQkDj3ey+YLSLgJrHi31s2EJtFQFWi489xFhBbWEBPonlCF1SNvsT353dZ IWwjiVU3PoLFeQUCJN63nmAGsYUEoiQWTT0J1sspEC2xdtJMsBpGoMO/n1rDBGIzC4hL3Hoy nwniIUGJRbP3MMM892/XQzaIelGJO+3rGSHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1iAXpqF ZOwsJC2zkLTMQtKygJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRnAUSvLt YPx6UOkQowAHoxIP77qzP3yFWBPLiitzDzFKcjApifL2SP/yFeJLyk+pzEgszogvKs1JLT7E KMHBrCTCe+r3T18h3pTEyqrUonyYlDQHi5I470xJdV8hgfTEktTs1NSC1CKYrAwHh5IErzkw 2QgJFqWmp1akZeaUIKSZODhBhvMADTcFqeEtLkjMLc5Mh8ifYlSUEuf9CXKRAEgiozQPrheW JF8xigO9Isx7DKSKB5hg4bpfAQ1mAhp86+U3kMEliQgpqQbGDc5Jf1hk+r7kzDBZzPB7c/Q/ Y2fR+wZGi15NylvDISv+Oqx09p30j2+a3s7aL3msvKbhvIBQc1ikV5et41njnsfnP4se9Ldf r33J0E4oqXDlosCdJ37/953sELtfeFZdXNGh/y8dD/+/8kRX0aeY4UFtqOv6GVJS6vXPhSWY XJsuxwjOEIhXYinOSDTUYi4qTgQApFaDH20DAAA=
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:08:52 -0000

Apologies for the late response.


> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, June 15, 2011 1:27 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Client authentication requirement
>=20
> Client authentication has been one of the main problem areas in OAuth
> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
> confusing).
>=20
> Because of the desire to allow any client type in any deployment
> environment, we ended up with a barely defined client authentication
> model. We offer password-based client authentication using HTTP Basic
> (and an alternative parameter), but leave it optional.

I would to suggest that perhaps we need a better definition of the "client"=
 by way of identifying one or two (or three) types of clients and listing t=
heir respective security properties/capabilities. For example, if a client =
can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a =
client can do TLS but cannot do proper X509 processing, then list this, etc=
. etc.

In this way developers can at least map (in the minds) which client type ma=
tches their deployment scenario, based on the best-match capabilities list.


> I would like to go back to requiring client authentication for the
> access token endpoint, using HTTP Basic or other schemes. To leave the
> door open for clients incapable of authenticating to use the endpoint,
> we will add a security consideration section discussing the
> ramifications of using the access token endpoint without client
> authentication.
>=20
> This suggestions is linked to the topic of refresh tokens which I'll
> post separately.
>=20
> EHL

+1 agree that client authentication (to access token endpoint) should be ma=
de a requirement.=20

/thomas/




From eran@hueniverse.com  Thu Jun 16 08:30:36 2011
Return-Path: 
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 A8E8211E813B for ; Thu, 16 Jun 2011 08:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfuRAc61zVcO for ; Thu, 16 Jun 2011 08:30:35 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 60C2611E80CE for ; Thu, 16 Jun 2011 08:30:28 -0700 (PDT)
Received: (qmail 24300 invoked from network); 16 Jun 2011 15:30:27 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 15:30:27 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 16 Jun 2011 08:30:22 -0700
From: Eran Hammer-Lahav 
To: "Lodderstedt, Torsten" , Mike Jones , David Recordon , George Fletcher 
Date: Thu, 16 Jun 2011 08:29:59 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AQHMEGLvUtk/Y41LJU+xw7NH/M+2opSa0CjQgAgtbYCABOk9gIAAwn+AgABmmeCAFdUR4IAA9jJAgAB4YTA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986CC2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:30:36 -0000

> -----Original Message-----
> From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
> Sent: Thursday, June 16, 2011 1:26 AM
> To: Eran Hammer-Lahav; Mike Jones; David Recordon; George Fletcher
> Cc: paul Tarjan; oauth@ietf.org
> Subject: AW: [OAUTH-WG] consistency of token param name in bearer
> token type
>=20
> The reason why I suggested the name "bearer_token" was to achieve a
> consistent naming convention across different ways to uses those tokens
> (URI query, HTTP authn scheme). Now the discussion centers around
> achieving a consistent naming between token acquisition and usage. I'm
> basically fine with reverting to "access_token".
>=20
> Just one question:
> Is the assumption of the group that bearer tokens are the only type of
> tokens to be used in conjunction with URI query parameters? Otherwise, a
> mechanism is needed to distinguish bearer and other tokens, e.g. another
> parameter (token_type?).

YES (i.e. no more). It's bad enough we have this one.

EHL

> Regards,
> Torsten.
> > -----Urspr=FCngliche Nachricht-----
> > Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > Gesendet: Mittwoch, 15. Juni 2011 19:38
> > An: Mike Jones; David Recordon; George Fletcher
> > Cc: paul Tarjan; oauth@ietf.org
> > Betreff: Re: [OAUTH-WG] consistency of token param name in bearer
> > token type
> >
> > It should be pretty easy :-)
> >
> > Anyone objects to changing the parameter name from 'bearer_token' to
> > 'access_token'? Let Mike know by 6/20 or he will make the change.
> >
> > EHL
> >
> >
> > > -----Original Message-----
> > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > Behalf
> > > Of Mike Jones
> > > Sent: Wednesday, June 01, 2011 1:15 PM
> > > To: David Recordon; George Fletcher
> > > Cc: paul Tarjan; oauth@ietf.org
> > > Subject: Re: [OAUTH-WG] consistency of token param name in bearer
> > token
> > > type
> > >
> > > If you can drive a consensus decision for the name "access_token",
> > I'd be
> > > glad to change the name in the spec.  I agree that the current names
> > are
> > > confusing for developers.
> > >
> > > 				-- Mike
> > >
> > > -----Original Message-----
> > > From: David Recordon [mailto:recordond@gmail.com]
> > > Sent: Wednesday, June 01, 2011 12:06 AM
> > > To: George Fletcher
> > > Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
> > > Subject: Re: [OAUTH-WG] consistency of token param name in bearer
> > token
> > > type
> > >
> > > Yeah, can understand how we got here. Just found it quite confusing
> > when
> > > reading these two specifications together with an implementor's hat
> > on.
> > >
> > > On Tue, May 31, 2011 at 12:29 PM, George Fletcher 
> > > wrote:
> > > > Brief pointer to the "history" of this change. This change was
> > adopted
> > > > in draft 4 of the bearer spec as there were concerns with the
> > previous
> > > > parameter name of 'oauth_token'. The suggestion was made to use
> > > > 'bearer_token' so that it matches the scheme used in the
> > Authorization
> > > > header. The thinking being that reading the bearer token spec
> > > > would seem weird if the Authorization header used one name and the
> > GET/POST
> > > > methods used a different name.
> > > >
> > > > The 'bearer_token' name got a few +1 and no dissents.
> > > >
> > > > Full thread starts here [1]. Mike accepting the 'bearer_token'
> > > > recommendation is here [2].
> > > >
> > > > Thanks,
> > > > George
> > > >
> > > > [1] http://www.ietf.org/mail-
> > archive/web/oauth/current/msg05497.html
> > > > [2] http://www.ietf.org/mail-
> > archive/web/oauth/current/msg05881.html
> > > >
> > > > On 5/28/11 12:30 PM, David Recordon wrote:
> > > >
> > > > Did a full read through of draft 16 and the bear token spec with
> > Paul
> > > > yesterday afternoon in order to do a manual diff from draft 10.
> > > > The point Doug raised was actually confusing. Throughout the core
> > > > spec it's referred to as access_token but then becomes
> > > > bearer_token upon use.
> > > >
> > > > Just thinking through this from a developer documentation
> > perspective,
> > > > it's going to become confusing. Developer documentation focuses on
> > > > getting an access token and then using that access token to
> > interact
> > > > with an API. Thus the code you're writing as a client developer
> > will
> > > > use variables, cache keys, and database columns named
> > `access_token`.
> > > > But then when you're going to use it, you'll need to put this
> > access
> > > > token into a field named bearer_token.
> > > >
> > > > Feels quite a bit simpler to just name it access_token. Realize
> > > > the core spec never did this since we didn't want to trample on
> > protected
> > > > resources which might already have a different type of
> > > > access_token parameter. oauth_token was a good compromise since
> > > > developers would already know that they were using OAuth and thus
> > > > a new term wasn't being introduced. That's no longer true with
> > > > bearer_token since 99%
> > of
> > > > developers will have never heard of a bearer token.
> > > >
> > > > Googling for "bearer token" turns up Eran's blog post titled
> > > > "OAuth Bearer Tokens are a Terrible Idea" and there isn't a single
> > > > result
> > on
> > > > the first page which explains what they are. Binging for "bearer
> > > > token" is equally scary.
> > > >
> > > > --David
> > > >
> > > >
> > > > On Mon, May 23, 2011 at 11:38 AM, Mike Jones
> > > >  wrote:
> > > >
> > > > The working group explicitly decided that a different name should
> > be
> > > > used, to make it clear that other token types other than bearer
> > tokens
> > > > could also be used with OAuth 2.
> > > >
> > > >
> > > >
> > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --
> > > > Mike
> > > >
> > > >
> > > >
> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > Behalf
> > > > Of Doug Tangren
> > > > Sent: Wednesday, May 11, 2011 10:09 PM
> > > > To: oauth@ietf.org
> > > > Subject: [OAUTH-WG] consistency of token param name in bearer
> > > > token type
> > > >
> > > >
> > > >
> > > > This may have come up before so I'm sorry if I'm repeating. Why
> > does
> > > > bearer token spec introduce a new name for oauth2 access tokens
> > [1],
> > > > "bearer_token", and before that [2], "oauth_token"?
> > > >
> > > >
> > > >
> > > > I=A0apologize=A0if this may sound shallow but, why introduce a new
> > > > parameter name verses sticking with what the general oauth2 spec
> > > > already defines, "access_token". It seems arbitrary for an auth
> > server
> > > > to hand a client an apple then have the client hand it off to the
> > > > resource server and call it an orange.
> > > >
> > > >
> > > >
> > > > Was this just for the sake of differentiating the parameter name
> > > > enough so that the bearer tokens may be used in other protocols
> > > > without being confused with oauth2 access_tokens?
> > > >
> > > >
> > > >
> > > > [1]:
> > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-
> > 2.2
> > > >
> > > > [2]:
> > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-
> > 2.2
> > > >
> > > >
> > > >
> > > > -Doug Tangren
> > > > http://lessis.me
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > >
> > > > --
> > > > Chief Architect                   AIM:  gffletch
> > > > Identity Services Engineering     Work: george.fletcher@teamaol.com
> > > > AOL Inc.                          Home: gffletch@aol.com
> > > > Mobile: +1-703-462-3494           Blog:
> > http://practicalid.blogspot.com
> > > > Office: +1-703-265-2544           Twitter:
> > http://twitter.com/gffletch
> > > >
> > >
> > > _______________________________________________
> > > 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

From eran@hueniverse.com  Thu Jun 16 08:31:39 2011
Return-Path: 
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 6242D11E8117 for ; Thu, 16 Jun 2011 08:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oso9H3mH3e-H for ; Thu, 16 Jun 2011 08:31:38 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 184A911E80CE for ; Thu, 16 Jun 2011 08:31:38 -0700 (PDT)
Received: (qmail 22153 invoked from network); 16 Jun 2011 15:31:36 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 15:31:31 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 16 Jun 2011 08:31:30 -0700
From: Eran Hammer-Lahav 
To: Justin Richer , "KIHARA, Boku" 
Date: Thu, 16 Jun 2011 08:31:06 -0700
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AcwsLh1XQsZk/DG9QA+7LjMXBN96BAADC3cQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986CC3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <1308232867.29889.131.camel@ground>
In-Reply-To: <1308232867.29889.131.camel@ground>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:31:39 -0000

Tm9wZS4gT0F1dGggaXMgYSBzZWNvbmRhcnkgZ29hbCBvZiB0aGUgTUFDIHNjaGVtZSBhbmQgY2Fs
bGluZyBpdCBhY2Nlc3NfdG9rZW4gdGhlcmUgd291bGQgbWFrZSBubyBzZW5zZSBmb3IgYW55dGhp
bmcgYnV0IE9BdXRoLiANCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KPiBTZW50OiBU
aHVyc2RheSwgSnVuZSAxNiwgMjAxMSA3OjAxIEFNDQo+IFRvOiBLSUhBUkEsIEJva3UNCj4gQ2M6
IEVyYW4gSGFtbWVyLUxhaGF2OyBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBjb25zaXN0ZW5jeSBvZiB0b2tlbiBwYXJhbSBuYW1lIGluIGJlYXJlciB0b2tlbg0KPiB0
eXBlDQo+IA0KPiBJZiB3ZSdyZSBjaGFuZ2luZyB0aGUgYmVhcmVyIHRva2VuJ3MgbmFtZSwgYXJl
IHdlIGdvaW5nIHRvIGNoYW5nZSB0aGUNCj4gcGFyYW1ldGVyIG5hbWUgaW5zaWRlIG9mIE1BQyBh
cyB3ZWxsPyBBdCB0aGUgbW9tZW50LCBpdCdzICJpZCIsIHdoaWNoIEkndmUNCj4gYWx3YXlzIGZv
dW5kIGFuIG9kZCBuYW1pbmcgY2hvaWNlLg0KPiANCj4gSSB3b3VsZCBhcmd1ZSBmb3IgY29uc2lz
dGVuY3kgYWNyb3NzIHRoZSB0aHJlZSBtYWluIGRvY3VtZW50cy4NCj4gDQo+ICAtLSBKdXN0aW4N
Cj4gDQo+IA0KPiBPbiBUaHUsIDIwMTEtMDYtMTYgYXQgMDg6NDAgLTA0MDAsIEtJSEFSQSwgQm9r
dSB3cm90ZToNCj4gPiArMSB0byBhY2Nlc3NfdG9rZW4uDQo+ID4NCj4gPiAyMDExLzYvMTYgRXJh
biBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+Og0KPiA+ID4gSXQgc2hvdWxkIGJl
IHByZXR0eSBlYXN5IDotKQ0KPiA+ID4NCj4gPiA+IEFueW9uZSBvYmplY3RzIHRvIGNoYW5naW5n
IHRoZSBwYXJhbWV0ZXIgbmFtZSBmcm9tICdiZWFyZXJfdG9rZW4nIHRvDQo+ICdhY2Nlc3NfdG9r
ZW4nPyBMZXQgTWlrZSBrbm93IGJ5IDYvMjAgb3IgaGUgd2lsbCBtYWtlIHRoZSBjaGFuZ2UuDQo+
ID4gPg0KPiA+ID4gRUhMDQo+ID4gPg0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiA+ID4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0
aC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4+IEJlaGFsZiBPZiBNaWtlIEpvbmVzDQo+ID4g
Pj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDAxLCAyMDExIDE6MTUgUE0NCj4gPiA+PiBUbzogRGF2
aWQgUmVjb3Jkb247IEdlb3JnZSBGbGV0Y2hlcg0KPiA+ID4+IENjOiBwYXVsIFRhcmphbjsgb2F1
dGhAaWV0Zi5vcmcNCj4gPiA+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBjb25zaXN0ZW5jeSBv
ZiB0b2tlbiBwYXJhbSBuYW1lIGluIGJlYXJlcg0KPiA+ID4+IHRva2VuIHR5cGUNCj4gPiA+Pg0K
PiA+ID4+IElmIHlvdSBjYW4gZHJpdmUgYSBjb25zZW5zdXMgZGVjaXNpb24gZm9yIHRoZSBuYW1l
ICJhY2Nlc3NfdG9rZW4iLA0KPiA+ID4+IEknZCBiZSBnbGFkIHRvIGNoYW5nZSB0aGUgbmFtZSBp
biB0aGUgc3BlYy4gIEkgYWdyZWUgdGhhdCB0aGUNCj4gPiA+PiBjdXJyZW50IG5hbWVzIGFyZSBj
b25mdXNpbmcgZm9yIGRldmVsb3BlcnMuDQo+ID4gPj4NCj4gPiA+PiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAtLSBNaWtlDQo+ID4gPj4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiA+ID4+IEZyb206IERhdmlkIFJlY29yZG9uIFttYWlsdG86cmVjb3Jkb25kQGdt
YWlsLmNvbV0NCj4gPiA+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTEgMTI6MDYgQU0N
Cj4gPiA+PiBUbzogR2VvcmdlIEZsZXRjaGVyDQo+ID4gPj4gQ2M6IE1pa2UgSm9uZXM7IERvdWcg
VGFuZ3Jlbjsgb2F1dGhAaWV0Zi5vcmc7IHBhdWwgVGFyamFuDQo+ID4gPj4gU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gY29uc2lzdGVuY3kgb2YgdG9rZW4gcGFyYW0gbmFtZSBpbiBiZWFyZXINCj4g
PiA+PiB0b2tlbiB0eXBlDQo+ID4gPj4NCj4gPiA+PiBZZWFoLCBjYW4gdW5kZXJzdGFuZCBob3cg
d2UgZ290IGhlcmUuIEp1c3QgZm91bmQgaXQgcXVpdGUgY29uZnVzaW5nDQo+ID4gPj4gd2hlbiBy
ZWFkaW5nIHRoZXNlIHR3byBzcGVjaWZpY2F0aW9ucyB0b2dldGhlciB3aXRoIGFuIGltcGxlbWVu
dG9yJ3MNCj4gaGF0IG9uLg0KPiA+ID4+DQo+ID4gPj4gT24gVHVlLCBNYXkgMzEsIDIwMTEgYXQg
MTI6MjkgUE0sIEdlb3JnZSBGbGV0Y2hlcg0KPiA+ID4+IDxnZmZsZXRjaEBhb2wuY29tPg0KPiA+
ID4+IHdyb3RlOg0KPiA+ID4+ID4gQnJpZWYgcG9pbnRlciB0byB0aGUgImhpc3RvcnkiIG9mIHRo
aXMgY2hhbmdlLiBUaGlzIGNoYW5nZSB3YXMNCj4gPiA+PiA+IGFkb3B0ZWQgaW4gZHJhZnQgNCBv
ZiB0aGUgYmVhcmVyIHNwZWMgYXMgdGhlcmUgd2VyZSBjb25jZXJucyB3aXRoDQo+ID4gPj4gPiB0
aGUgcHJldmlvdXMgcGFyYW1ldGVyIG5hbWUgb2YgJ29hdXRoX3Rva2VuJy4gVGhlIHN1Z2dlc3Rp
b24gd2FzDQo+ID4gPj4gPiBtYWRlIHRvIHVzZSAnYmVhcmVyX3Rva2VuJyBzbyB0aGF0IGl0IG1h
dGNoZXMgdGhlIHNjaGVtZSB1c2VkIGluDQo+ID4gPj4gPiB0aGUgQXV0aG9yaXphdGlvbiBoZWFk
ZXIuIFRoZSB0aGlua2luZyBiZWluZyB0aGF0IHJlYWRpbmcgdGhlDQo+ID4gPj4gPiBiZWFyZXIg
dG9rZW4gc3BlYyB3b3VsZCBzZWVtIHdlaXJkIGlmIHRoZSBBdXRob3JpemF0aW9uIGhlYWRlcg0K
PiA+ID4+ID4gdXNlZCBvbmUgbmFtZSBhbmQgdGhlIEdFVC9QT1NUIG1ldGhvZHMgdXNlZCBhIGRp
ZmZlcmVudCBuYW1lLg0KPiA+ID4+ID4NCj4gPiA+PiA+IFRoZSAnYmVhcmVyX3Rva2VuJyBuYW1l
IGdvdCBhIGZldyArMSBhbmQgbm8gZGlzc2VudHMuDQo+ID4gPj4gPg0KPiA+ID4+ID4gRnVsbCB0
aHJlYWQgc3RhcnRzIGhlcmUgWzFdLiBNaWtlIGFjY2VwdGluZyB0aGUgJ2JlYXJlcl90b2tlbicN
Cj4gPiA+PiA+IHJlY29tbWVuZGF0aW9uIGlzIGhlcmUgWzJdLg0KPiA+ID4+ID4NCj4gPiA+PiA+
IFRoYW5rcywNCj4gPiA+PiA+IEdlb3JnZQ0KPiA+ID4+ID4NCj4gPiA+PiA+IFsxXQ0KPiA+ID4+
ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn
MDU0OTcuaHRtbA0KPiA+ID4+ID4gWzJdDQo+ID4gPj4gPiBodHRwOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwNTg4MS5odG1sDQo+ID4gPj4gPg0KPiA+
ID4+ID4gT24gNS8yOC8xMSAxMjozMCBQTSwgRGF2aWQgUmVjb3Jkb24gd3JvdGU6DQo+ID4gPj4g
Pg0KPiA+ID4+ID4gRGlkIGEgZnVsbCByZWFkIHRocm91Z2ggb2YgZHJhZnQgMTYgYW5kIHRoZSBi
ZWFyIHRva2VuIHNwZWMgd2l0aA0KPiA+ID4+ID4gUGF1bCB5ZXN0ZXJkYXkgYWZ0ZXJub29uIGlu
IG9yZGVyIHRvIGRvIGEgbWFudWFsIGRpZmYgZnJvbSBkcmFmdA0KPiA+ID4+ID4gMTAuIFRoZSBw
b2ludCBEb3VnIHJhaXNlZCB3YXMgYWN0dWFsbHkgY29uZnVzaW5nLiBUaHJvdWdob3V0IHRoZQ0K
PiA+ID4+ID4gY29yZSBzcGVjIGl0J3MgcmVmZXJyZWQgdG8gYXMgYWNjZXNzX3Rva2VuIGJ1dCB0
aGVuIGJlY29tZXMNCj4gPiA+PiA+IGJlYXJlcl90b2tlbiB1cG9uIHVzZS4NCj4gPiA+PiA+DQo+
ID4gPj4gPiBKdXN0IHRoaW5raW5nIHRocm91Z2ggdGhpcyBmcm9tIGEgZGV2ZWxvcGVyIGRvY3Vt
ZW50YXRpb24NCj4gPiA+PiA+IHBlcnNwZWN0aXZlLCBpdCdzIGdvaW5nIHRvIGJlY29tZSBjb25m
dXNpbmcuIERldmVsb3Blcg0KPiA+ID4+ID4gZG9jdW1lbnRhdGlvbiBmb2N1c2VzIG9uIGdldHRp
bmcgYW4gYWNjZXNzIHRva2VuIGFuZCB0aGVuIHVzaW5nDQo+ID4gPj4gPiB0aGF0IGFjY2VzcyB0
b2tlbiB0byBpbnRlcmFjdCB3aXRoIGFuIEFQSS4gVGh1cyB0aGUgY29kZSB5b3UncmUNCj4gPiA+
PiA+IHdyaXRpbmcgYXMgYSBjbGllbnQgZGV2ZWxvcGVyIHdpbGwgdXNlIHZhcmlhYmxlcywgY2Fj
aGUga2V5cywgYW5kDQo+IGRhdGFiYXNlIGNvbHVtbnMgbmFtZWQgYGFjY2Vzc190b2tlbmAuDQo+
ID4gPj4gPiBCdXQgdGhlbiB3aGVuIHlvdSdyZSBnb2luZyB0byB1c2UgaXQsIHlvdSdsbCBuZWVk
IHRvIHB1dCB0aGlzDQo+ID4gPj4gPiBhY2Nlc3MgdG9rZW4gaW50byBhIGZpZWxkIG5hbWVkIGJl
YXJlcl90b2tlbi4NCj4gPiA+PiA+DQo+ID4gPj4gPiBGZWVscyBxdWl0ZSBhIGJpdCBzaW1wbGVy
IHRvIGp1c3QgbmFtZSBpdCBhY2Nlc3NfdG9rZW4uIFJlYWxpemUNCj4gPiA+PiA+IHRoZSBjb3Jl
IHNwZWMgbmV2ZXIgZGlkIHRoaXMgc2luY2Ugd2UgZGlkbid0IHdhbnQgdG8gdHJhbXBsZSBvbg0K
PiA+ID4+ID4gcHJvdGVjdGVkIHJlc291cmNlcyB3aGljaCBtaWdodCBhbHJlYWR5IGhhdmUgYSBk
aWZmZXJlbnQgdHlwZSBvZg0KPiA+ID4+ID4gYWNjZXNzX3Rva2VuIHBhcmFtZXRlci4gb2F1dGhf
dG9rZW4gd2FzIGEgZ29vZCBjb21wcm9taXNlIHNpbmNlDQo+ID4gPj4gPiBkZXZlbG9wZXJzIHdv
dWxkIGFscmVhZHkga25vdyB0aGF0IHRoZXkgd2VyZSB1c2luZyBPQXV0aCBhbmQgdGh1cw0KPiA+
ID4+ID4gYSBuZXcgdGVybSB3YXNuJ3QgYmVpbmcgaW50cm9kdWNlZC4gVGhhdCdzIG5vIGxvbmdl
ciB0cnVlIHdpdGgNCj4gPiA+PiA+IGJlYXJlcl90b2tlbiBzaW5jZSA5OSUgb2YgZGV2ZWxvcGVy
cyB3aWxsIGhhdmUgbmV2ZXIgaGVhcmQgb2YgYQ0KPiBiZWFyZXIgdG9rZW4uDQo+ID4gPj4gPg0K
PiA+ID4+ID4gR29vZ2xpbmcgZm9yICJiZWFyZXIgdG9rZW4iIHR1cm5zIHVwIEVyYW4ncyBibG9n
IHBvc3QgdGl0bGVkDQo+ID4gPj4gPiAiT0F1dGggQmVhcmVyIFRva2VucyBhcmUgYSBUZXJyaWJs
ZSBJZGVhIiBhbmQgdGhlcmUgaXNuJ3QgYQ0KPiA+ID4+ID4gc2luZ2xlIHJlc3VsdCBvbiB0aGUg
Zmlyc3QgcGFnZSB3aGljaCBleHBsYWlucyB3aGF0IHRoZXkgYXJlLg0KPiA+ID4+ID4gQmluZ2lu
ZyBmb3IgImJlYXJlciB0b2tlbiIgaXMgZXF1YWxseSBzY2FyeS4NCj4gPiA+PiA+DQo+ID4gPj4g
PiAtLURhdmlkDQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+IE9uIE1vbiwgTWF5IDIzLCAy
MDExIGF0IDExOjM4IEFNLCBNaWtlIEpvbmVzDQo+ID4gPj4gPiA8TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPiB3cm90ZToNCj4gPiA+PiA+DQo+ID4gPj4gPiBUaGUgd29ya2luZyBncm91cCBl
eHBsaWNpdGx5IGRlY2lkZWQgdGhhdCBhIGRpZmZlcmVudCBuYW1lIHNob3VsZA0KPiA+ID4+ID4g
YmUgdXNlZCwgdG8gbWFrZSBpdCBjbGVhciB0aGF0IG90aGVyIHRva2VuIHR5cGVzIG90aGVyIHRo
YW4NCj4gPiA+PiA+IGJlYXJlciB0b2tlbnMgY291bGQgYWxzbyBiZSB1c2VkIHdpdGggT0F1dGgg
Mi4NCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tDQo+ID4gPj4g
PiBNaWtlDQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiBGcm9tOiBvYXV0
aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g
PiA+PiA+IEJlaGFsZiBPZiBEb3VnIFRhbmdyZW4NCj4gPiA+PiA+IFNlbnQ6IFdlZG5lc2RheSwg
TWF5IDExLCAyMDExIDEwOjA5IFBNDQo+ID4gPj4gPiBUbzogb2F1dGhAaWV0Zi5vcmcNCj4gPiA+
PiA+IFN1YmplY3Q6IFtPQVVUSC1XR10gY29uc2lzdGVuY3kgb2YgdG9rZW4gcGFyYW0gbmFtZSBp
biBiZWFyZXINCj4gPiA+PiA+IHRva2VuIHR5cGUNCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+
ID4NCj4gPiA+PiA+IFRoaXMgbWF5IGhhdmUgY29tZSB1cCBiZWZvcmUgc28gSSdtIHNvcnJ5IGlm
IEknbSByZXBlYXRpbmcuIFdoeQ0KPiA+ID4+ID4gZG9lcyBiZWFyZXIgdG9rZW4gc3BlYyBpbnRy
b2R1Y2UgYSBuZXcgbmFtZSBmb3Igb2F1dGgyIGFjY2Vzcw0KPiA+ID4+ID4gdG9rZW5zIFsxXSwg
ImJlYXJlcl90b2tlbiIsIGFuZCBiZWZvcmUgdGhhdCBbMl0sICJvYXV0aF90b2tlbiI/DQo+ID4g
Pj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiBJIGFwb2xvZ2l6ZSBpZiB0aGlzIG1h
eSBzb3VuZCBzaGFsbG93IGJ1dCwgd2h5IGludHJvZHVjZSBhIG5ldw0KPiA+ID4+ID4gcGFyYW1l
dGVyIG5hbWUgdmVyc2VzIHN0aWNraW5nIHdpdGggd2hhdCB0aGUgZ2VuZXJhbCBvYXV0aDIgc3Bl
Yw0KPiA+ID4+ID4gYWxyZWFkeSBkZWZpbmVzLCAiYWNjZXNzX3Rva2VuIi4gSXQgc2VlbXMgYXJi
aXRyYXJ5IGZvciBhbiBhdXRoDQo+ID4gPj4gPiBzZXJ2ZXIgdG8gaGFuZCBhIGNsaWVudCBhbiBh
cHBsZSB0aGVuIGhhdmUgdGhlIGNsaWVudCBoYW5kIGl0IG9mZg0KPiA+ID4+ID4gdG8gdGhlIHJl
c291cmNlIHNlcnZlciBhbmQgY2FsbCBpdCBhbiBvcmFuZ2UuDQo+ID4gPj4gPg0KPiA+ID4+ID4N
Cj4gPiA+PiA+DQo+ID4gPj4gPiBXYXMgdGhpcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBkaWZmZXJl
bnRpYXRpbmcgdGhlIHBhcmFtZXRlciBuYW1lDQo+ID4gPj4gPiBlbm91Z2ggc28gdGhhdCB0aGUg
YmVhcmVyIHRva2VucyBtYXkgYmUgdXNlZCBpbiBvdGhlciBwcm90b2NvbHMNCj4gPiA+PiA+IHdp
dGhvdXQgYmVpbmcgY29uZnVzZWQgd2l0aCBvYXV0aDIgYWNjZXNzX3Rva2Vucz8NCj4gPiA+PiA+
DQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+IFsxXToNCj4gPiA+PiA+IGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA0I3NlY3Rpb24tDQo+
ID4gPj4gPiAyLjINCj4gPiA+PiA+DQo+ID4gPj4gPiBbMl06DQo+ID4gPj4gPiBodHRwOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMyNzZWN0aW9uLQ0K
PiA+ID4+ID4gMi4yDQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiAtRG91
ZyBUYW5ncmVuDQo+ID4gPj4gPiBodHRwOi8vbGVzc2lzLm1lDQo+ID4gPj4gPg0KPiA+ID4+ID4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiA+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+PiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+PiA+DQo+ID4g
Pj4gPg0KPiA+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiA+PiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gT0F1dGhAaWV0Zi5v
cmcNCj4gPiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4gLS0NCj4gPiA+PiA+IENoaWVmIEFyY2hpdGVj
dCAgICAgICAgICAgICAgICAgICBBSU06ICBnZmZsZXRjaA0KPiA+ID4+ID4gSWRlbnRpdHkgU2Vy
dmljZXMgRW5naW5lZXJpbmcgICAgIFdvcms6IGdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbQ0K
PiA+ID4+ID4gQU9MIEluYy4gICAgICAgICAgICAgICAgICAgICAgICAgIEhvbWU6IGdmZmxldGNo
QGFvbC5jb20NCj4gPiA+PiA+IE1vYmlsZTogKzEtNzAzLTQ2Mi0zNDk0ICAgICAgICAgICBCbG9n
OiBodHRwOi8vcHJhY3RpY2FsaWQuYmxvZ3Nwb3QuY29tDQo+ID4gPj4gPiBPZmZpY2U6ICsxLTcw
My0yNjUtMjU0NCAgICAgICAgICAgVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL2dmZmxldGNo
DQo+ID4gPj4gPg0KPiA+ID4+DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gPiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+PiBPQXV0
aEBpZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPg0KPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1
dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KDQo=

From eran@hueniverse.com  Thu Jun 16 08:33:30 2011
Return-Path: 
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 3228411E8117 for ; Thu, 16 Jun 2011 08:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.243
X-Spam-Level: 
X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bunJ1aXWIgZm for ; Thu, 16 Jun 2011 08:33:24 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 01DCB11E80CE for ; Thu, 16 Jun 2011 08:33:23 -0700 (PDT)
Received: (qmail 25597 invoked from network); 16 Jun 2011 15:33:23 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 15:33:23 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 16 Jun 2011 08:33:20 -0700
From: Eran Hammer-Lahav 
To: "Lodderstedt, Torsten" , Torsten Lodderstedt , Brian Eaton 
Date: Thu, 16 Jun 2011 08:32:55 -0700
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtAADpo/YA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986CC4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986CC4P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:33:30 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC4P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Easier said than done. If you don't have strong trust, giving the user hint=
s will cause more harm than good.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC4P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Easier said than done. If you don’t have strong trust, giving =
the user hints will cause more harm than good.
 
EHL
 
From:<=
/b> Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] 
=
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; =
Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: =
AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16
=

 
The ability to describe a client to the user does not depend on the authen=
tication but on the identification of the client and the meta data availabl=
e to the authz server. The only difference between identified and authentic=
ated clients is the trust level the authz server has regarding the client&#=
8217;s identity. It must clearly indicate this fact to the end-user.
 
regards,
=
Torsten.
 =
;
Von: Eran Hammer-Lahav [mailto:eran@=
hueniverse.com] 
Gesendet: Mittwoch, 15. Juni 201=
1 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth =
WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16<=
/o:p>
 
I agree to the extent that the user can be trusted t=
o know how they got to the authorization endpoint.
 
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>If the client cannot be authenticated, the authorization server is li=
mited in the information it can offer the user to make the decision. It is =
extremely hard to come up with language that will tell the user to only app=
rove the application, claiming to be X, if they got here from X directly. T=
here might be ways to improve security a bit using Origin header etc. but o=
verall, if the client is not authenticated, the authorization server can=
217;t really describe it to the user.
 
EHL
 
<=
p class=3DMsoNormal> 
From: oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodders=
tedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Ea=
ton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draf=
t-ietf-oauth-v2-16
 
I fully agree with Brian and would =
like to add some thoughts: 

Not authenticating the client does not d=
irectly create a security problem at all. If we would follow this line, eve=
ry e-Mail client out there would be considered insecure because the client =
itself is never authenticated. Not even Kerbereos has a concept of client a=
uthentication. 

In my opinion, OAuth client authentication (in deleg=
ated authorization scenarios) is an improvement over classical approaches. =
But I do not see a degration in security if it is not applicable. As long a=
s the _user_ authorizes the client's access (and the duration of the token)=
 and is able to revoke the tokens at any time, the situation is much better=
 than with classical approaches. 

regards,
Torsten.

Am 01.=
06.2011 21:06, schrieb Brian Eaton: 
Hey Peter - 
&nbs=
p;
I haven't read all of your comm=
ents yet, but I wanted to clarify one point about client impersonation and =
installed apps.  The cuirrent text is unrealistic, but your request wo=
uld push it the wrong way.  CC'ing Torsten as well.
 
---------------------
<=
span class=3Dapple-style-span>OLD:
  The=
 authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable =
of authenticating.

NEW:=

  If the authorization server issue=
s access tokens to clients
  =
that are incapable of authenticating, the scope and duration of
<=
span class=3Dapple-style-span>  such tokens SHOULD be limited.<=
br>
RATIONALE: We're not actively RECOMME=
NDING authorization servers are to
issue such tokens, are we?
--------=
-------------
 
=

=
We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.<=
/span>
 
Most installed applicatio=
ns work as follows:
- they ask the user for thei=
r password
- they save the password to disk=

 
That's a horrible =
security problem, because it means you cannot upgrade user authentication t=
o anything stronger than a password.  Client certificates, one time pa=
sswords, risk based authentication, throw it all out the window.  If y=
ou're going to let installed apps authenticate with just a password, nothin=
g else you do to improve authentication is going to help.=

 
This is a blocking issue for ro=
lling out stronger forms of user authentication, and it's one of the main r=
easons I care about OAuth2.  
 
Think IMAP and=
 XMPP clients running on Windows desktops.  They are important, and we=
 need a way to migrate them off of saving passwords.
 
<=
div>
S=
o the current text basically says that you should issue temporary credentia=
ls to native apps.  That's not practical.  Native apps end up nee=
ding permanent or near-permanent credentials.  Expirations need to be =
measured in months.  And the credentials are going to be issued to sto=
ck IMAP and XMPP clients that don't have any way of authenticating themselv=
es.
 
The advant=
age with OAuth2 over passwords is that
a) the re=
fresh tokens are unguessable.
b) the refresh tok=
ens aren't sent directly to the IMAP and XMPP servers, they are restricted =
to authorization servers.
c) if you've got a man=
aged machine (think Kerberos logins), you can create flows that bridge from=
 those managed credentials to temporary access credentials.
 
Cheers,
=

Brian
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC4P3PW5EX1MB01E_--

From eran@hueniverse.com  Thu Jun 16 08:35:12 2011
Return-Path: 
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 323A811E80C5 for ; Thu, 16 Jun 2011 08:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D92a5s4ZbDqw for ; Thu, 16 Jun 2011 08:35:07 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 64B8111E8071 for ; Thu, 16 Jun 2011 08:35:07 -0700 (PDT)
Received: (qmail 32617 invoked from network); 16 Jun 2011 15:35:07 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 15:35:07 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 16 Jun 2011 08:35:03 -0700
From: Eran Hammer-Lahav 
To: "Lodderstedt, Torsten" , Chuck Mortimore , "oauth@ietf.org" 
Date: Thu, 16 Jun 2011 08:34:40 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYAAAGH/wAABbt7AAH/TfEAAOPvrg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986CC6@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AFD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5D3@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676C5D3@QEO40072.de.t-online.corp>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986CC6P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:35:12 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC6P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tony said a new text is coming. Once that is posted, I'll ask the list for =
a hum.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 16, 2011 2:00 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: AW: Updated text for Native Apps

In my perception, the main concern raised at the F2F was the absent of the =
implicit grant in the text. That's what Chuck added including a discussion =
of the pros and cons.

Most of the discussion in the thread you referred to was about refresh toke=
ns support in the implicit grant type, which was caused by an additional qu=
estion by Chuck. This would be a fundamental change to the protocol and we =
had a lively discussion about this idea. In the end, I have not seen a prop=
osal to add this feature to the spec.

This discussion is independent of the native apps text Chuck proposed (http=
://www.ietf.org/mail-archive/web/oauth/current/msg06444.html) and I have no=
t seen any objection on this text. I therefore consider this a consensous.

So please consider the proposed text for the next revision of the draft.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 19:35
An: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Updated text for Native Apps

That's an odd way of looking at it. I'm looking at over 30 responses to the=
 text with clear disagreement on how native applications should be deployed=
 using different grant types. To say that there is consensus to the text, b=
ut not to the other comments objecting to it is ignoring the lack of consen=
sus...

If you think you can propose a new text that will be endorsed by the group,=
 please go ahead. But the F2F action item carries no weight if the list doe=
sn't like what is suggested.

What is clear from the discussion is that we have some unresolved issues ar=
ound refresh tokens and client authentication which are at the heart of adv=
ising about native applications. It would be impossible to make recommendat=
ions without resolving these issues first (and once we do, I would argue no=
 additional text would be needed).

EHL



From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:24 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Not seeing what you write about below, I think that the basic text that was=
 discussed at the F2F has consensus around the guidance (with some changes =
that were discussed and Chuck provided), I think that some of the other tho=
ughts people have thrown out don't. I disagree with dropping the text as th=
ere is not consensus to do that, since there was an action item to put text=
 back in.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I'=
ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC6P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated text for Native Apps<=
style>
Tony said=
 a new text is coming. Once that is posted, I’ll ask the list for a h=
um.
 
EHL
 
From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] 
Se=
nt: Thursday, June 16, 2011 2:00 AM
To: Eran Hammer-Lahav; Ch=
uck Mortimore; oauth@ietf.org
Subject: AW: Updated text for Nativ=
e Apps
 
In my perception, the main concern raise=
d at the F2F was the absent of the implicit grant in the text. That’s=
 what Chuck added including a discussion of the pros and cons.
 
Most of the discussion in the thread you referred to wa=
s about refresh tokens support in the implicit grant type, which was caused=
 by an additional question by Chuck. This would be a fundamental change to =
the protocol and we had a lively discussion about this idea. In the end, I =
have not seen a proposal to add this feature to the spec. 
 
This discussion is independent of the native apps text Chuck =
proposed (http://www.ietf.org/mail-archive/web/oauth/current/msg06444.htm=
l) and I have not seen any objection on this text. I therefore consider=
 this a consensous.
 
So please consider the =
proposed text for the next revision of the draft.
 
regards,
Torsten. 
 
=
Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
G=
esendet: Mittwoch, 15. Juni 2011 19:35
An: Anthony Nadalin; C=
huck Mortimore; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Updated te=
xt for Native Apps
 
That=
’s an odd way of looking at it. I’m looking at over 30 response=
s to the text with clear disagreement on how native applications should be =
deployed using different grant types. To say that there is consensus to the=
 text, but not to the other comments objecting to it is ignoring the lack o=
f consensus…
&n=
bsp;
If you think you can propo=
se a new text that will be endorsed by the group, please go ahead. But the =
F2F action item carries no weight if the list doesn’t like what is su=
ggested.
 =

What is clear from the discussion is=
 that we have some unresolved issues around refresh tokens and client authe=
ntication which are at the heart of advising about native applications. It =
would be impossible to make recommendations without resolving these issues =
first (and once we do, I would argue no additional text would be needed).
 
EHL
=
 
 <=
/o:p>
 
From: Anthony Nadalin [mailto:tonynad@=
microsoft.com] 
Sent: Wednesday, June 15, 2011 10:24 AM
To:=
 Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: =
RE: Updated text for Native Apps
 
Not seeing wh=
at you write about below, I think that the basic text that was discussed at=
 the F2F has consensus around the guidance (with some changes that were dis=
cussed and Chuck provided), I think that some of the other thoughts people =
have thrown out don’t. I disagree with dropping the text as there is =
not consensus to do that, since there was an action item to put text back i=
n.
 
From: Eran Hammer-Lahav [mailto:eran@=
hueniverse.com] 
Sent: Wednesday, June 15, 2011 10:19 AM
To=
: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: R=
E: Updated text for Native Apps
 
This working =
group has failed, for well over a year, to reach any sort of consensus rega=
rding which grant types are suitable for a given client type. There was no =
draft between 00 and 16 in which we had agreement on the definition of clie=
nt types, or the exclusivity of any flow to any given type. Trying to reach=
 such a conclusion is a waste of time.
 
The =
main reason for this is lack of deployment experience. We have pretty good =
experience with some cases like a server-based client capable of keeping se=
crets, and browser-based clients executing fully visible source code. We cl=
early do not even have a clear definition of what is a native application a=
nd the recent attempt to define a native application client type seems to c=
ause more confusion than help.
 
While there is=
 clearly an expectation that the specification will offer guidance to nativ=
e application developers, I have yet to see any such text gaining consensus=
.
 =

My suggestion is to drop this attempt, but =
if a new text gain consensus, I’ll incorporate it.<=
/p>
 
EHL
 =
;
 
<=
div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4=
.0pt'>
From: Anthony Nadalin [mailto:tonynad@microsoft.com] 
=
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-La=
hav; Chuck Mortimore; oauth@ietf.org<=
br>Subject: RE: Updated text for Native Apps
 
Since Torsten and I had the action item to propose text we will update=
 the text based upon the list and give you back an update=

 
<=
p class=3DMsoNormal>From: oauth-bou=
nces@ietf.org [mailt=
o:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
S=
ent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [=
OAUTH-WG] Updated text for Native Apps
 
Is there=
 an updated text based on the long thread?
 
EH=
L
 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: =
[OAUTH-WG] Updated text for Native Apps
 
Minor updates for section 9 based upon feedback from the list
-cmort

----------------


9.  Native Applications=


A native application is a client which is installed and executes on=
 the end-user's device (i.e. desktop application, native mobile application=
).  Native applications require special consideration related to secur=
ity, platform capabilities, and overall end-user experience.  The foll=
owing are examples of how native applications may utilize OAuth:

&nb=
sp;  o  Initiate an Authorization Request using an external =
user-agent: The native application can capture the response from the author=
ization server using a variety of techniques such as the use of a redirecti=
on URI identifying a custom URI scheme (registered with the operating syste=
m to invoke the native application as handler), manual copy-and-paste, runn=
ing a local webserver, browser plug-ins, or by providing a redirection URI =
identifying a server-hosted resource under the native application's control=
, which in turn makes the response available to the native application.
=
   o  Initiate an Authorization Request using an embedd=
ed user-agent:  The native application obtains the response by directl=
y communicating with the embedded user-agent.  Techniques include moni=
toring state changes emitted during URL loading, monitoring http headers, a=
ccessing the user-agent's cookie jar, etc.

When choosing between lau=
nching an external user-agent and an embedding a user-agent, native applica=
tion developers should consider the following:

   o &=
nbsp;External user-agents may improve completion rate as the end-user may a=
lready have an active session with the authorization server removing the ne=
ed to re-authenticate, and provide a familiar user-agent user experience. &=
nbsp;The end-user may also rely on extensions or add-ons to assist with aut=
hentication (e.g. password managers or 2-factor device reader).
 &n=
bsp; o  Embedded user-agents may offer an improved end-user flow,=
 as they remove the need to switch context and open new windows. 
&=
nbsp;  o  Embedded user-agents pose a security challenge bec=
ause end-users are authenticating in an unidentified window without access =
to the visual protections offered by many user-agents.  Embedded user-=
agents educate end-user to trust unidentified requests for authentication (=
making phishing attacks easier to execute).

When choosing between im=
plicit and authorization code grant types, the following should be consider=
ed:

   o  Native applications that use the autho=
rization code grant type flow SHOULD do so without client password credenti=
als, due to their inability to keep those credentials confidential.
&nbs=
p;  o  Native applications that use the implicit grant type =
may offer optimized performance in some scenarios due to reduced network re=
quests
   o  The implicit grant type does not return=
 a refresh token  
=

=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986CC6P3PW5EX1MB01E_--

From beaton@google.com  Thu Jun 16 08:37:57 2011
Return-Path: 
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 612B411E80DF for ; Thu, 16 Jun 2011 08:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r8FEIIz+9WQ for ; Thu, 16 Jun 2011 08:37:56 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F311E80C5 for ; Thu, 16 Jun 2011 08:37:56 -0700 (PDT)
Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p5GFbtu6015699 for ; Thu, 16 Jun 2011 08:37:55 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308238676; bh=cY9qHgjP2mb36yBIHOUReSPboZw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=agsmxubgY3iItphhcgXa3NWf3x9BKDAZ/jB6a69ZY5Qf0HWotfXTdZHby99AAYDzb 5+yMy4Z7FBsV28M2WIn2g==
Received: from pvh10 (pvh10.prod.google.com [10.241.210.202]) by kpbe13.cbf.corp.google.com with ESMTP id p5GFbsQo005518 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 08:37:54 -0700
Received: by pvh10 with SMTP id 10so2525881pvh.1 for ; Thu, 16 Jun 2011 08:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wpOzvEGBgDXbLcsKWS8F35ygJeRGCxl1oJ/C2mjjWuk=; b=hXGtXvY4tX09TrTdVFsfPJ5Bt1148GxVBZmno8joJp0mMmMX9yxiNiKYsK+ba8WMkv jszm47YvVlQTcePZIHVg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T6GEll3jXhHcoYcboSEZ9zs0EJ6JDT+oFIfPGKRLE3Dgx68V2FJyImRYN2WZ2wTyEz pXCxfs/hUFhdcbXc/Ohw==
MIME-Version: 1.0
Received: by 10.142.136.6 with SMTP id j6mr189540wfd.437.1308238673773; Thu, 16 Jun 2011 08:37:53 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 08:37:53 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 16 Jun 2011 08:37:53 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=000e0cd32d326e857604a5d60daf
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:37:57 -0000

--000e0cd32d326e857604a5d60daf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav wro=
te:

> Your comment was that having client authentication makes it easier to
> recovery from an attack. I don=92t understand how the comments below abou=
t
> changing client secrets every 30 days are relevant. Are you suggesting to
> wait until the next routine secret cycle to revoke compromised credential=
s?
> Or that 30 days is a reasonable time period for ignoring an attack?
>

Sorry, there are multiple good reasons to require client authentication for
the access token endpoint.

- if you need to recover from a compromise, changing the client credentials
will prevent the attacker from abusing refresh tokens they have stolen.
 Changing a single client credential is much faster than revoking lots of
refresh tokens.

- if you want to follow best practices for management of authentication
credentials, you should do periodic key rotation.  Rotation of lots of
refresh tokens is quite challenging.  Rotation of client credentials is muc=
h
easier.

- if you want to bind refresh tokens to stronger authentication credentials=
,
such as private keys stored in an HSM, you need to require client
authentication when using the refresh token.

Is that helpful?

Cheers,
Brian

--000e0cd32d326e857604a5d60daf
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro=
te:


Your comment was that ha=
ving client authentication makes it easier to recovery from an attack. I do=
n=92t understand how the comments below about changing client secrets every=
 30 days are relevant. Are you suggesting to wait until the next routine se=
cret cycle to revoke compromised credentials? Or that 30 days is a reasonab=
le time period for ignoring an attack?



Sorry, there are multiple good=
 reasons to require client authentication for the access token endpoint.

- if you need to recover from a compromise, changing=
 the client credentials will prevent the attacker from abusing refresh toke=
ns they have stolen. =A0Changing a single client credential is much faster =
than revoking lots of refresh tokens.



- if you want to follow best practices for management o=
f authentication credentials, you should do periodic key rotation. =A0Rotat=
ion of lots of refresh tokens is quite challenging. =A0Rotation of client c=
redentials is much easier.



- if you want to bind refresh tokens to stronger authen=
tication credentials, such as private keys stored in an HSM, you need to re=
quire client authentication when using the refresh token.



Is that helpful?

Cheers,
Bria=
n


--000e0cd32d326e857604a5d60daf--

From hardjono@mit.edu  Thu Jun 16 08:48:38 2011
Return-Path: 
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 0788321F84FF for ; Thu, 16 Jun 2011 08:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.549
X-Spam-Level: 
X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSly0Vp8wOm6 for ; Thu, 16 Jun 2011 08:48:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4CC21F84A8 for ; Thu, 16 Jun 2011 08:48:36 -0700 (PDT)
X-AuditID: 12074424-b7bc6ae000005a77-4e-4dfa25d36d92
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id C5.12.23159.3D52AFD4; Thu, 16 Jun 2011 11:48:35 -0400 (EDT)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p5GFmZHo001195;  Thu, 16 Jun 2011 11:48:35 -0400
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p5GFmX1f027801; Thu, 16 Jun 2011 11:48:34 -0400
Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 16 Jun 2011 11:48:31 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Thu, 16 Jun 2011 11:48:27 -0400
From: Thomas Hardjono 
To: Eran Hammer-Lahav , Brian Eaton 
Date: Thu, 16 Jun 2011 11:48:26 -0400
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: Acwrws6bTqgt7hIpShOn0kFiPjY3FgAAGFNQAB3TOCA=
Message-ID: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPKsWRmVeSWpSXmKPExsUixCmqrXtZ9Zevwa4DxhbHnmxlsTi9cDGj xcm3r9gcmD0WbCr1mH7U32PJkp9MAcxRXDYpqTmZZalF+nYJXBmn15xjK5gkUTHx0VTGBsaj wl2MnBwSAiYSzbdXsELYYhIX7q1n62Lk4hAS2Mcose/RTnYI5wCjxLm9p6EyxxklVh3/xATh bGWU2Nn5lg2kX0hgAqNE81VeEJtNQEPi3O+97CC2iICPxKyNN8FsZgFZiTXnLjGD2CwCqhJT uv8wgtjCApYSf4/D1FtJvOnshLOnzj7HBGLzCgRI9E64DrV4FavEz2cXwA7nFIiWWPjhE5jN CPTE91NrmCCWiUvcejKfCeI5QYlFs/cwwzz6b9dDNoh6UYk77esZIep1JBbs/sQGYWtLLFv4 mhlisaDEyZlPWCYwSs5CMnYWkpZZSFpmIWlZwMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdc LzezRC81pXQTIyhe2V1UdjA2H1I6xCjAwajEw7vw7A9fIdbEsuLK3EOMkhxMSqK8DCq/fIX4 kvJTKjMSizPii0pzUosPMUpwMCuJ8J76/dNXiDclsbIqtSgfJiXNwaIkzjtPUt1XSCA9sSQ1 OzW1ILUIJivDwaEkwasGTEtCgkWp6akVaZk5JQhpJg5OkOE8QMOXgyzmLS5IzC3OTIfIn2JU lBLnZQNpFgBJZJTmwfXC0ukrRnGgV4R5P4O08wBTMVz3K6DBTECDb738BjK4JBEhJdXAWOWw 2d226KsU90wRdmOZyu/P5p5XKA+8k3v/yZtmyaa5gSF3nr33kmi65Te95qJN5Me45d4e8jeW zSk4IqJz+2tb6okfh3zVNPPT5YOunO/X1jwX+KPz96sbBll8LyNF3rpm32BN0Dui8Sp6yaxa UT6R9ASzdN3ogrMZH60a5QNFJW9wiX9TYinOSDTUYi4qTgQAcXvhd4IDAAA=
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:48:38 -0000

Eran:
I think the issue of refreshing tokens should be a configurable parameter (=
security policy) that the authorization server  (ie. admin managing it) set=
s. Perhaps the parameter value should be advertised in the "service documen=
tation" of the authorization end-point.  So the client can choose to accept=
 or walkaway when it sees this parameter (depending on its own security pol=
icies). Changing keying material is necessary to prevent crypto-attacks on =
stale keys.

Just to give an idea about timing: many large scale Kerberos infra require =
the user to get a new TGT every 24-hours, and some even sooner.


Brian:
I don't fully understand your earlier email:

>>> Requiring client authentication doesn't defend against=20
>>> attacks directly; it makes recovery after a successful=20
>>> attack easier.

I presume you mean direct attacks on the authorization server.=20
But wouldn't requiring OAuth clients to authenticate (in=20
some manner to the authorization server) at least reduce
the opportunity for DOS attacks to the authorization server.

Thanks.

/thomas/

_____________


> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, June 15, 2011 9:19 PM
> To: Brian Eaton
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>=20
> Your comment was that having client authentication makes it easier to
> recovery from an attack. I don't understand how the comments below
> about changing client secrets every 30 days are relevant. Are you
> suggesting to wait until the next routine secret cycle to revoke
> compromised credentials? Or that 30 days is a reasonable time period
> for ignoring an attack?
>=20
> EHL
>=20
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Wednesday, June 15, 2011 6:15 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> Subject: Re: [OAUTH-WG] Client authentication requirement
>=20
> On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav
>  wrote:
> How does it make recovery easier? Why is revoking refresh token any
> harder than changing client secret?
>=20
> Changing a client secret can be done without disrupting users.  You can
> even schedule it, do it every 30 days as part of your general
> operational procedures.  It's part of a healthy system.
>=20
> Revoking refresh tokens every 30 days is not really feasible.
>=20
> As for the assertion grant type, where is the specified that the
> refresh token is bound to the private keys used to produce the
> assertion used to obtain the refresh token in the first place?
>=20
> Well, the spec currently has refresh tokens bound to client ids.
>=20
> And the assertion spec proposal authenticated client ids with
> public/private key pairs.
>=20
> You wouldn't bind the refresh token directly to a private key, for the
> same reason that you don't bind the refresh token directly to the
> client secret.  You bind refresh tokens to clients, and then you
> require client authentication.

From beaton@google.com  Thu Jun 16 08:51:19 2011
Return-Path: 
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 9C6AF9E8021 for ; Thu, 16 Jun 2011 08:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.939
X-Spam-Level: 
X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+VYqZ+-HaWL for ; Thu, 16 Jun 2011 08:51:19 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 992179E8022 for ; Thu, 16 Jun 2011 08:51:17 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5GFpBOE023436 for ; Thu, 16 Jun 2011 08:51:16 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308239476; bh=hb6vi86zhUO+GBv2tgFsCoEPlOA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YaN9dZun/ylsnSRl9SNSNTXSaE/hQrCaItC54eM1+b1Z7WWkqyBuuYJIGEQeRXRCF HzCWKcvV2f+Kc7APSRAAA==
Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz33.hot.corp.google.com with ESMTP id p5GFp4cj026215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 08:51:09 -0700
Received: by pwj9 with SMTP id 9so769257pwj.20 for ; Thu, 16 Jun 2011 08:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y5aCDJVAkSV+L5N1JP2pWK19ukujyfKenKgsDzw40dk=; b=pSdN3NxdAnD02foFXtJhfBkP/z63ii5T1DzwrNgOLxjccg0dwp1kRggmNlQGw96geA 68Tnn2kY25luppcRdbbg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fe1aQixLVM9NDsE/CAV6hHqHwDSjzM2ho2xiF0NoLHkkPubeK7XNN68IXEzmWWr3hi EADn7MwtNOL1N4b0BsLw==
MIME-Version: 1.0
Received: by 10.143.5.19 with SMTP id h19mr227415wfi.38.1308239463693; Thu, 16 Jun 2011 08:51:03 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 08:51:03 -0700 (PDT)
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C0A@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C15@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
Date: Thu, 16 Jun 2011 08:51:03 -0700
Message-ID: 
From: Brian Eaton 
To: Thomas Hardjono 
Content-Type: multipart/alternative; boundary=001636e0a5b183bd6004a5d63c24
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:51:19 -0000

--001636e0a5b183bd6004a5d63c24
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono  wrote:

> >>> Requiring client authentication doesn't defend against
> >>> attacks directly; it makes recovery after a successful
> >>> attack easier.
>
> I presume you mean direct attacks on the authorization server.
>

Also attacks on the clients.


> But wouldn't requiring OAuth clients to authenticate (in
> some manner to the authorization server) at least reduce
> the opportunity for DOS attacks to the authorization server.
>

One more reason to use client authentication for the access token endpoint.

--001636e0a5b183bd6004a5d63c24
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono <hardjono@mit.edu> wrote:
<=
div class=3D"gmail_quote">


>>> Requiring client authentication doesn't =
defend against

>>> attacks directly; it makes recovery after a successful

>>> attack easier.




I presume you mean direct attacks on the authorization server.

Also attacks on the clients.
=A0


But wouldn't requiring OAuth clients to authenticate (in

some manner to the authorization server) at least reduce

the opportunity for DOS attacks to the authorization server.

One more reason to use client authentication for the =
access token endpoint.=A0


--001636e0a5b183bd6004a5d63c24--

From cmortimore@salesforce.com  Thu Jun 16 08:54:16 2011
Return-Path: 
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 2255C9E804B for ; Thu, 16 Jun 2011 08:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2hxAM26XVKU for ; Thu, 16 Jun 2011 08:54:15 -0700 (PDT)
Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by ietfa.amsl.com (Postfix) with SMTP id DAC0B9E8022 for ; Thu, 16 Jun 2011 08:54:14 -0700 (PDT)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKTfonJrcH5y7hssUoYRQ2r7RENRF6jETJ@postini.com; Thu, 16 Jun 2011 08:54:14 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 16 Jun 2011 08:54:14 -0700
From: Chuck Mortimore 
To: Eran Hammer-Lahav , "Lodderstedt, Torsten" , "oauth@ietf.org" 
Date: Thu, 16 Jun 2011 08:53:28 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnALwJeCgAAE6gmAAAFyrYAAAGH/wAABbt7AAH/TfEAAOPvrgAACq+II=
Message-ID: <77AEC44D4DA08A46ADAA723286626BC1B05ED41856@EXSFM-MB01.internal.salesforce.com>
References:  <90C41DD21FB7C64BB94121FBBC2E7234475E986ACE@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AEF@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986AFD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5D3@QEO40072.de.t-online.corp>, <90C41DD21FB7C64BB94121FBBC2E7234475E986CC6@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986CC6@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated text for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 15:54:16 -0000

Agree with Torsten's assessment here. =20
________________________________________
From: Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Thursday, June 16, 2011 8:34 AM
To: Lodderstedt, Torsten; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Tony said a new text is coming. Once that is posted, I=92ll ask the list fo=
r a hum.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 16, 2011 2:00 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: AW: Updated text for Native Apps

In my perception, the main concern raised at the F2F was the absent of the =
implicit grant in the text. That=92s what Chuck added including a discussio=
n of the pros and cons.

Most of the discussion in the thread you referred to was about refresh toke=
ns support in the implicit grant type, which was caused by an additional qu=
estion by Chuck. This would be a fundamental change to the protocol and we =
had a lively discussion about this idea. In the end, I have not seen a prop=
osal to add this feature to the spec.

This discussion is independent of the native apps text Chuck proposed (http=
://www.ietf.org/mail-archive/web/oauth/current/msg06444.html) and I have no=
t seen any objection on this text. I therefore consider this a consensous.

So please consider the proposed text for the next revision of the draft.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 19:35
An: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Updated text for Native Apps

That=92s an odd way of looking at it. I=92m looking at over 30 responses to=
 the text with clear disagreement on how native applications should be depl=
oyed using different grant types. To say that there is consensus to the tex=
t, but not to the other comments objecting to it is ignoring the lack of co=
nsensus=85

If you think you can propose a new text that will be endorsed by the group,=
 please go ahead. But the F2F action item carries no weight if the list doe=
sn=92t like what is suggested.

What is clear from the discussion is that we have some unresolved issues ar=
ound refresh tokens and client authentication which are at the heart of adv=
ising about native applications. It would be impossible to make recommendat=
ions without resolving these issues first (and once we do, I would argue no=
 additional text would be needed).

EHL



From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:24 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Not seeing what you write about below, I think that the basic text that was=
 discussed at the F2F has consensus around the guidance (with some changes =
that were discussed and Chuck provided), I think that some of the other tho=
ughts people have thrown out don=92t. I disagree with dropping the text as =
there is not consensus to do that, since there was an action item to put te=
xt back in.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

This working group has failed, for well over a year, to reach any sort of c=
onsensus regarding which grant types are suitable for a given client type. =
There was no draft between 00 and 16 in which we had agreement on the defin=
ition of client types, or the exclusivity of any flow to any given type. Tr=
ying to reach such a conclusion is a waste of time.

The main reason for this is lack of deployment experience. We have pretty g=
ood experience with some cases like a server-based client capable of keepin=
g secrets, and browser-based clients executing fully visible source code. W=
e clearly do not even have a clear definition of what is a native applicati=
on and the recent attempt to define a native application client type seems =
to cause more confusion than help.

While there is clearly an expectation that the specification will offer gui=
dance to native application developers, I have yet to see any such text gai=
ning consensus.

My suggestion is to drop this attempt, but if a new text gain consensus, I=
=92ll incorporate it.

EHL


From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 15, 2011 10:10 AM
To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps

Since Torsten and I had the action item to propose text we will update the =
text based upon the list and give you back an update

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated text for Native Apps

Is there an updated text based on the long thread?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Tuesday, May 31, 2011 10:37 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated text for Native Apps

Minor updates for section 9 based upon feedback from the list

-cmort

----------------


9.  Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application).  Nati=
ve applications require special consideration related to security, platform=
 capabilities, and overall end-user experience.  The following are examples=
 of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of a redirection URI identifyin=
g a custom URI scheme (registered with the operating system to invoke the n=
ative application as handler), manual copy-and-paste, running a local webse=
rver, browser plug-ins, or by providing a redirection URI identifying a ser=
ver-hosted resource under the native application's control, which in turn m=
akes the response available to the native application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedding a u=
ser-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience. =
 The end-user may also rely on extensions or add-ons to assist with authent=
ication (e.g. password managers or 2-factor device reader).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions offered by many user-agents.  Embedded user-agents educate end-user =
to trust unidentified requests for authentication (making phishing attacks =
easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without client password credentials, due to their inability to =
keep those credentials confidential.
   o  Native applications that use the implicit grant type may offer optimi=
zed performance in some scenarios due to reduced network requests
   o  The implicit grant type does not return a refresh token

From beaton@google.com  Thu Jun 16 09:19:09 2011
Return-Path: 
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 CCB439E807A for ; Thu, 16 Jun 2011 09:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.946
X-Spam-Level: 
X-Spam-Status: No, score=-105.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cheX0Na13iiU for ; Thu, 16 Jun 2011 09:19:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D284A9E8071 for ; Thu, 16 Jun 2011 09:19:08 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p5GGJ7Ht014534 for ; Thu, 16 Jun 2011 09:19:07 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308241148; bh=xrp1MyukAAZsWUkOSRpcmYS0XUQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=EIx39t8ACMC/OGrYBN7Zzyz3XjAZ8GD/ERqzFAE6iorihSR2PV2K7mncAOuYj6MF8 l7VL3cS1NWQxblepsZktg==
Received: from pwi12 (pwi12.prod.google.com [10.241.219.12]) by kpbe17.cbf.corp.google.com with ESMTP id p5GGIahT005422 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 09:19:06 -0700
Received: by pwi12 with SMTP id 12so791275pwi.28 for ; Thu, 16 Jun 2011 09:19:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s7t0HGyHa/YFWE5gIXKMj1Fa96PZQjx/ywRMhZPj36k=; b=UFoYFshP7PLnabdAxybNtqSlE0KJO/ZvLkdSEtWRFLHti2W8lyOPE88D1Z5ff/g695 FqNm4gddhlEcpouD0niA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TUikHhZwGyz4Xgl7b+VjkpUSabCKYzxmbUU1TvhZGmFtQ0qNpK82+kQFQKXfJbe2/S LIk7qitRWS8JqIO8EmpQ==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr212424wfa.323.1308241145493; Thu, 16 Jun 2011 09:19:05 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 09:19:05 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 16 Jun 2011 09:19:05 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e906f1c1f89304a5d6a087
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 16:19:10 -0000

--001636e906f1c1f89304a5d6a087
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav wr=
ote:

> 1. Why not require the registration of a redirection URI for implicit gra=
nt
> requests, removing the redirect_uri parameter completely from the request
> (the client can still use the state parameter)?
>

As others have stated, this is a bad idea because there are legitimate
reasons for a single client to have multiple redirect URIs.


> **
>
> 2. What is the value of the client_id when a redirection URI is not
> pre-registered? The client identity cannot be verified without other mean=
s
> for the purpose of informing the user who is asking for access, no refres=
h
> token is issued, and the redirect_uri parameter contains the only useful
> information for both the flow and identifying the client (to the extent i=
t
> can be trusted not to be an open redirector).
>

I think you're saying that redirect URIs should always be preregistered for
the implicit grant flow.  That's a very good idea.


> 3. Are there real use cases for performing redirection URI matching again=
st
> a pre-registered value, where partial (i.e. not string) comparison is
> needed? Why can=92t this be solved by simply using any URI variations int=
o the
> state parameter?
>

I don't understand this question.

> Authorization server who want to be fancy can allow you to register more
than one and let you indicate which one you want by adding a suffix to the
client id (say 'abcd-1' to pick URI 1).

This is a bad idea.  Client identifiers are like usernames; you wouldn't
tell a user to use a different variety of their username, don't tell
developers that they have to use a different variety of their client
identifiers.

Please don't tamper with these protocol flows.  The protocol flows are fine
as is.  There should be language making it clear that registration is
required.  Everyone is doing that already, so that's not a particularly
disruptive change.

--001636e906f1c1f89304a5d6a087
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav =
<eran@hueniverse.com> wrote:


1. Why not require the registration of a redirection URI for implicit g=
rant requests, removing the redirect_uri parameter completely from the requ=
est (the client can still use the state parameter)?



As others have stated, this is=
 a bad idea because there are legitimate reasons for a single client to hav=
e multiple redirect URIs.
=A0=A0


2. What is the value of the client_id=
 when a redirection URI is not pre-registered? The client identity cannot b=
e verified without other means for the purpose of informing the user who is=
 asking for access, no refresh token is issued, and the redirect_uri parame=
ter contains the only useful information for both the flow and identifying =
the client (to the extent it can be trusted not to be an open redirector).<=
/p>


I think you're saying that=
 redirect URIs should always be preregistered for the implicit grant flow. =
=A0That's a very good idea.
=A0


3. Are there real use cases for performing redirection URI matching aga=
inst a pre-registered value, where partial (i.e. not string) comparison is =
needed? Why can=92t this be solved by simply using any URI variations into =
the state parameter?



I don't understand this qu=
estion.
=A0

This is a bad idea. =A0Client ide=
ntifiers are like usernames; you wouldn't tell a user to use a differen=
t variety of their username, don't tell developers that they have to us=
e a different variety of their client identifiers.



Please don't tamper with thes=
e protocol flows. =A0The protocol flows are fine as is. =A0There should be =
language making it clear that registration is required. =A0Everyone is doin=
g that already, so that's not a particularly disruptive change.<=
/div>



--001636e906f1c1f89304a5d6a087--

From zachary.zeltsan@alcatel-lucent.com  Thu Jun 16 10:35:00 2011
Return-Path: 
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 2AF5211E80BF for ; Thu, 16 Jun 2011 10:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5d9vdTj01kz for ; Thu, 16 Jun 2011 10:34:56 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF121F8442 for ; Thu, 16 Jun 2011 10:34:56 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5GHYrYb015801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 12:34:53 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5GHYq29027723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jun 2011 12:34:52 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 16 Jun 2011 12:34:52 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'Lodderstedt, Torsten'" , "'Eran Hammer-Lahav'" , "'Torsten Lodderstedt'" , "'Brian Eaton'" 
Date: Thu, 16 Jun 2011 12:34:50 -0500
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtAAEkxo8A==
Message-ID: <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp>
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_5710F82C0E73B04FA559560098BF95B12508529EC7USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 17:35:00 -0000

--_000_5710F82C0E73B04FA559560098BF95B12508529EC7USNAVSXCHMBSA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with the statement. Authorization server provides information about=
 a client to a user based on the client's identifier, which client has pres=
ented to the server. If authorization server cannot validate the client's i=
dentity claim, it must make the user aware.

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_5710F82C0E73B04FA559560098BF95B12508529EC7USNAVSXCHMBSA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









I agree with the statement. Authorization server p=
rovides=20
information about a client to a user based on the client's identifier,=
=20
which client has presented to the server. If authorization server cannot=20
validate the client's identity claim, it must make the user=20
aware.






From: oauth-bounces@ietf.org=20
[mailto:oauth-bounces@ietf.org] On Behalf Of Lodderstedt,=20
Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran=
=20
Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth=20
WG
Subject: Re: [OAUTH-WG] review of=20
draft-ietf-oauth-v2-16







The=20
ability to describe a client to the user does not depend on the authenticat=
ion=20
but on the identification of the client and the meta data available to the =
authz=20
server. The only difference between identified and authenticated clients is=
 the=20
trust level the authz server has regarding the client’s identity. It =
must=20
clearly indicate this fact to the end-user.


 


regards,


Torsten.


 






Von:=20
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Gesendet: Mittwoc=
h,=20
15. Juni=20
2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAu=
th=20
WG
Betreff: Re: [OAUTH-WG] review of=20
draft-ietf-oauth-v2-16


 


I=20
agree to the extent that the user can be trusted to know how they got to th=
e=20
authorization endpoint.


 


If=20
the client cannot be authenticated, the authorization server is limited in =
the=20
information it can offer the user to make the decision. It is extremely har=
d to=20
come up with language that will tell the user to only approve the applicati=
on,=20
claiming to be X, if they got here from X directly. There might be ways to=
=20
improve security a bit using Origin header etc. but overall, if the client =
is=20
not authenticated, the authorization server can’t really describe it =
to the=20
user.


 


EHL


 


 






From:=20
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=20
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10=20
AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re:=
=20
[OAUTH-WG] review of draft-ietf-oauth-v2-16


 


I fully agree with Brian and would =
like to=20
add some thoughts: 

Not authenticating the client does not directly=
=20
create a security problem at all. If we would follow this line, every e-Mai=
l=20
client out there would be considered insecure because the client itself is =
never=20
authenticated. Not even Kerbereos has a concept of client authentication.=20


In my opinion, OAuth client authentication (in delegated authorizat=
ion=20
scenarios) is an improvement over classical approaches. But I do not see a=
=20
degration in security if it is not applicable. As long as the _user_ author=
izes=20
the client's access (and the duration of the token) and is able to revoke t=
he=20
tokens at any time, the situation is much better than with classical approa=
ches.=20


regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eato=
n:=20





Hey Peter=20
- 




 




I haven't read all of your comments=
 yet, but=20
I wanted to clarify one point about client impersonation and installed apps=
.=20
 The cuirrent text is unrealistic, but your request would push it the =
wrong=20
way.  CC'ing Torsten as well.




 




---------------------




OLD:<=
BR>  The authorization server SHOULD issue acces=
s=20
tokens with limited
  scope a=
nd=20
duration to clients incapable of authenticating.

NEW:
&nbs=
p; If the=20
authorization server issues access tokens to clients
  that are incapable of authenticating, the s=
cope=20
and duration of
  such tokens=
 SHOULD=20
be limited.

RATIONALE: We're n=
ot=20
actively RECOMMENDING authorization servers are to
issue such tokens, are we?






---------------------




 




We=20
are most definitely recommending that clients that have no way of authentic=
ating=20
are issued long-lived credentials to access user=20
data.




 




Most installed applications wor=
k as=20
follows:




-=20
they ask the user for their password




-=20
they save the password to disk




 




That's a horrible security prob=
lem,=20
because it means you cannot upgrade user authentication to anything stronge=
r=20
than a password.  Client certificates, one time passwords, risk based=
=20
authentication, throw it all out the window.  If you're going to let=20
installed apps authenticate with just a password, nothing else you do to im=
prove=20
authentication is going to help.




 




This is a blocking issue for ro=
lling=20
out stronger forms of user authentication, and it's one of the main reasons=
 I=20
care about OAuth2.  




 


Think IMAP and XMPP clients running=
 on=20
Windows desktops.  They are important, and we need a way to migrate th=
em=20
off of saving passwords.




 =





So=20
the current text basically says that you should issue temporary credentials=
 to=20
native apps.  That's not practical.  Native apps end up needing=20
permanent or near-permanent credentials.  Expirations need to be measu=
red=20
in months.  And the credentials are going to be issued to stock IMAP a=
nd=20
XMPP clients that don't have any way of authenticating=20
themselves.




 




The advantage with OAuth2 over=
=20
passwords is that




a)=20
the refresh tokens are unguessable.




b)=20
the refresh tokens aren't sent directly to the IMAP and XMPP servers, they =
are=20
restricted to authorization servers.




c)=20
if you've got a managed machine (think Kerberos logins), you can create flo=
ws=20
that bridge from those managed credentials to temporary access=20
credentials.




 




Cheers,




Brian


--_000_5710F82C0E73B04FA559560098BF95B12508529EC7USNAVSXCHMBSA_--

From eran@hueniverse.com  Thu Jun 16 10:49:04 2011
Return-Path: 
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 E9DEB9E8012 for ; Thu, 16 Jun 2011 10:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DRB-r5gtxgt for ; Thu, 16 Jun 2011 10:49:03 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 2F7AB9E8004 for ; Thu, 16 Jun 2011 10:49:03 -0700 (PDT)
Received: (qmail 15897 invoked from network); 16 Jun 2011 17:49:00 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 17:49:00 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Jun 2011 10:48:53 -0700
From: Eran Hammer-Lahav 
To: Brian Eaton 
Date: Thu, 16 Jun 2011 10:48:29 -0700
Thread-Topic: [OAUTH-WG] Redirection URI and Implicit grant
Thread-Index: AcwsRdjgz3KHA0JCRYigKb8dK0mqlQAB4gmg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986D2A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
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_90C41DD21FB7C64BB94121FBBC2E7234475E986D2AP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 17:49:05 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D2AP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think we want the same thing and I can adjust my proposal to align with y=
our comments below. I'll post in a separate thread.

EHL




From: Brian Eaton [mailto:beaton@google.com]
Sent: Thursday, June 16, 2011 9:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant

On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav > wrote:
1. Why not require the registration of a redirection URI for implicit grant=
 requests, removing the redirect_uri parameter completely from the request =
(the client can still use the state parameter)?

As others have stated, this is a bad idea because there are legitimate reas=
ons for a single client to have multiple redirect URIs.

2. What is the value of the client_id when a redirection URI is not pre-reg=
istered? The client identity cannot be verified without other means for the=
 purpose of informing the user who is asking for access, no refresh token i=
s issued, and the redirect_uri parameter contains the only useful informati=
on for both the flow and identifying the client (to the extent it can be tr=
usted not to be an open redirector).

I think you're saying that redirect URIs should always be preregistered for=
 the implicit grant flow.  That's a very good idea.

3. Are there real use cases for performing redirection URI matching against=
 a pre-registered value, where partial (i.e. not string) comparison is need=
ed? Why can't this be solved by simply using any URI variations into the st=
ate parameter?

I don't understand this question.

> Authorization server who want to be fancy can allow you to register more =
than one and let you indicate which one you want by adding a suffix to the =
client id (say 'abcd-1' to pick URI 1).

This is a bad idea.  Client identifiers are like usernames; you wouldn't te=
ll a user to use a different variety of their username, don't tell develope=
rs that they have to use a different variety of their client identifiers.

Please don't tamper with these protocol flows.  The protocol flows are fine=
 as is.  There should be language making it clear that registration is requ=
ired.  Everyone is doing that already, so that's not a particularly disrupt=
ive change.

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D2AP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I think w=
e want the same thing and I can adjust my proposal to align with your comme=
nts below. I’ll post in a separate thread.
 
EHL
 <=
/span>
 
 
 
<=
span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: =
Brian Eaton [mailto:beaton@google.com] 
Sent: Thursday, June 16, =
2011 9:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
S=
ubject: Re: [OAUTH-WG] Redirection URI and Implicit grant
 
On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
<=
p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:=
auto'>1. Why not require the registration of a redirection URI for implicit=
 grant requests, removing the redirect_uri parameter completely from the re=
quest (the client can still use the state parameter)?
<=
/div>
 
As others have stated, this is a bad idea because the=
re are legitimate reasons for a single client to have multiple redirect URI=
s.
  
2. What is the value of the client_id when a redirection URI is not pre-re=
gistered? The client identity cannot be verified without other means for th=
e purpose of informing the user who is asking for access, no refresh token =
is issued, and the redirect_uri parameter contains the only useful informat=
ion for both the flow and identifying the client (to the extent it can be t=
rusted not to be an open redirector).
 
I think you're saying that redirect URIs should always be preregister=
ed for the implicit grant flow.  That's a very good idea.
 
3. Are there real u=
se cases for performing redirection URI matching against a pre-registered v=
alue, where partial (i.e. not string) comparison is needed? Why can’t=
 this be solved by simply using any URI variations into the state parameter=
?
&nb=
sp;
I don't understand this questi=
on.
 
> Authorization server=
 who want to be fancy can allow you to register more than one and let you i=
ndicate which one you want by adding a suffix to the client id (say 'abcd-1=
' to pick URI 1).
 
This is a bad idea.  Client identifiers are like usernames; you wou=
ldn't tell a user to use a different variety of their username, don't tell =
developers that they have to use a different variety of their client identi=
fiers.
&nb=
sp;
Please d=
on't tamper with these protocol flows.  The protocol flows are fine as=
 is.  There should be language making it clear that registration is re=
quired.  Everyone is doing that already, so that's not a particularly =
disruptive change.
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D2AP3PW5EX1MB01E_--

From eran@hueniverse.com  Thu Jun 16 10:52:31 2011
Return-Path: 
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 45FF911E80E0 for ; Thu, 16 Jun 2011 10:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level: 
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.242,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdI4TZCrEEpk for ; Thu, 16 Jun 2011 10:52:27 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E7D969E8017 for ; Thu, 16 Jun 2011 10:52:20 -0700 (PDT)
Received: (qmail 20567 invoked from network); 16 Jun 2011 17:52:20 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 17:52:20 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Jun 2011 10:52:18 -0700
From: Eran Hammer-Lahav 
To: "Zeltsan, Zachary (Zachary)" , "'Lodderstedt, Torsten'" , 'Torsten Lodderstedt' , 'Brian Eaton' 
Date: Thu, 16 Jun 2011 10:51:54 -0700
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtAAEkxo8AABGXeg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp> <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.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_90C41DD21FB7C64BB94121FBBC2E7234475E986D30P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 17:52:31 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D30P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine=
 print. We know this as a fact. If you can't validate the client identifier=
, you should not show the user any information about the client that you ca=
nnot vouch for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com=
]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Bria=
n Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about=
 a client to a user based on the client's identifier, which client has pres=
ented to the server. If authorization server cannot validate the client's i=
dentity claim, it must make the user aware.

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D30P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
This is nice on paper but doesn’t work.
<=
p class=3DMsoNormal> 
The user will see the client name or logo and will not read any of =
the fine print. We know this as a fact. If you can’t validate the cli=
ent identifier, you should not show the user any information about the clie=
nt that you cannot vouch for. Disclaimers and scary pages are useless.=

 
EHL
 
<=
b>From: Zeltsan, Zachary (Zachary) [mailto:zac=
hary.zeltsan@alcatel-lucent.com] 
Sent: Thursday, June 16, 2011 1=
0:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten L=
odderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: =
[OAUTH-WG] review of draft-ietf-oauth-v2-16
 
I agree with the statement. Authorization server provides information abo=
ut a client to a user based on the client's identifier, which client h=
as presented to the server. If authorization server cannot validate th=
e client's identity claim, it must make the user aware.
 
<=
div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <=
b>On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 16, =
2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Ea=
ton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draf=
t-ietf-oauth-v2-16
The ability to describe a client to the us=
er does not depend on the authentication but on the identification of the c=
lient and the meta data available to the authz server. The only difference =
between identified and authenticated clients is the trust level the authz s=
erver has regarding the client’s identity. It must clearly indicate t=
his fact to the end-user.
=
 
regards,=

Torsten.
 
Von: E=
ran Hammer-Lahav [mailto:eran@hueniverse.com] 
Gesendet: Mittwoch=
, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Br=
ian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review o=
f draft-ietf-oauth-v2-16
 
I agree to the extent =
that the user can be trusted to know how they got to the authorization endp=
oint.
 
If the client cannot be authenticated, =
the authorization server is limited in the information it can offer the use=
r to make the decision. It is extremely hard to come up with language that =
will tell the user to only approve the application, claiming to be X, if th=
ey got here from X directly. There might be ways to improve security a bit =
using Origin header etc. but overall, if the client is not authenticated, t=
he authorization server can’t really describe it to the user.
 
EHL
 
 <=
/span>
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=
 Behalf Of Torsten Lodderstedt
Sent: Thursday, June 02, 2011 =
2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject:=
 Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
 
I ful=
ly agree with Brian and would like to add some thoughts: 

Not authen=
ticating the client does not directly create a security problem at all. If =
we would follow this line, every e-Mail client out there would be considere=
d insecure because the client itself is never authenticated. Not even Kerbe=
reos has a concept of client authentication. 

In my opinion, OAuth c=
lient authentication (in delegated authorization scenarios) is an improveme=
nt over classical approaches. But I do not see a degration in security if i=
t is not applicable. As long as the _user_ authorizes the client's access (=
and the duration of the token) and is able to revoke the tokens at any time=
, the situation is much better than with classical approaches. 

rega=
rds,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton: 
Hey Peter - 
=

 
I=
 haven't read all of your comments yet, but I wanted to clarify one point a=
bout client impersonation and installed apps.  The cuirrent text is un=
realistic, but your request would push it the wrong way.  CC'ing Torst=
en as well.
 =

---------------------
OLD:
  The authorization server SHOULD issue access tok=
ens with limited
  scope and =
duration to clients incapable of authenticating.

NEW:
  If=
 the authorization server issues access tokens to clients
  that are incapable of authenticating, the sc=
ope and duration of
  such to=
kens SHOULD be limited.

RATION=
ALE: We're not actively RECOMMENDING authorization servers are toissue such tokens, are we?
---------------------
 
We are most definitely recommending that cli=
ents that have no way of authenticating are issued long-lived credentials t=
o access user data.
 
=

Most installed applications work as follows:
- they ask the user for their password
<=
p class=3DMsoNormal>- they=
 save the password to disk
 
That's a horrible security problem, because it means you canno=
t upgrade user authentication to anything stronger than a password.  C=
lient certificates, one time passwords, risk based authentication, throw it=
 all out the window.  If you're going to let installed apps authentica=
te with just a password, nothing else you do to improve authentication is g=
oing to help.
 
=

=
This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.  
 
Think IMAP and XMPP clients running on Windows desktops. &=
nbsp;They are important, and we need a way to migrate them off of saving pa=
sswords.
=
 
So the current text basically says that you s=
hould issue temporary credentials to native apps.  That's not practica=
l.  Native apps end up needing permanent or near-permanent credentials=
.  Expirations need to be measured in months.  And the credential=
s are going to be issued to stock IMAP and XMPP clients that don't have any=
 way of authenticating themselves.
 
The advantage with OAuth2 over passwords is that<=
/o:p>
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMP=
P servers, they are restricted to authorization servers.<=
/p>
c) if you've got a managed machine (think Kerberos logins), you ca=
n create flows that bridge from those managed credentials to temporary acce=
ss credentials.
 
Cheers,
Brian
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D30P3PW5EX1MB01E_--

From beaton@google.com  Thu Jun 16 10:55:27 2011
Return-Path: 
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 F141C11E8090 for ; Thu, 16 Jun 2011 10:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.951
X-Spam-Level: 
X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h65ZczboDmnN for ; Thu, 16 Jun 2011 10:55:26 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8B11E80AA for ; Thu, 16 Jun 2011 10:55:20 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p5GHtEMp029182 for ; Thu, 16 Jun 2011 10:55:14 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308246919; bh=7TRDXrY/jQv0S17rv2satFJRbD4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ncbGee/frfYlrAOpCN3CZfMBkcKcn6GecSZb0g0fxSVXSceM291NQD/pKVmgEEkrU iJNEczKZoYOhXwGTtp6iQ==
Received: from pvc12 (pvc12.prod.google.com [10.241.209.140]) by wpaz1.hot.corp.google.com with ESMTP id p5GHt0H2010861 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 10:55:07 -0700
Received: by pvc12 with SMTP id 12so1330442pvc.28 for ; Thu, 16 Jun 2011 10:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I6oMOFwzcTwvL8/t1M3XpJoBS3OlVO3UWZrCvb5Nngw=; b=EleDBn4sLDAF6i1mcQNH3X9ogQs7THK4V4guYN17gT1YiEhlYlJShQcQSvZ9DmS/4r ItDhhMl5rMchN3JBzENQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FfG0kebi0rWlrWuKq233cCu2soxmmTGcke0HNj7djqHNbfNSt35Hr+q15BNscU4mqG u2rOxcaq1GNSbZAlDxlQ==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr247414wfa.323.1308246907476; Thu, 16 Jun 2011 10:55:07 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 10:55:07 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp> <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 16 Jun 2011 10:55:07 -0700
Message-ID: 
From: Brian Eaton 
To: Eran Hammer-Lahav 
Content-Type: multipart/alternative; boundary=001636e906f132da8704a5d7f823
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 17:55:27 -0000

--001636e906f132da8704a5d7f823
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav wr=
ote:

> This is nice on paper but doesn=92t work.
>

I have to agree.  It doesn't matter what the spec says on this point.  No
one is going to take advice from the spec about what the text on their
approval page ought to say.

--001636e906f132da8704a5d7f823
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav <<=
a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com> wr=
ote:


<=
p class=3D"MsoNormal">This i=
s nice on paper but doesn=92t work.



I have to agree. =A0It doesn't matter what the spec says on this p=
oint. =A0No one is going to take advice from the spec about what the text o=
n their approval page ought to say.


--001636e906f132da8704a5d7f823--

From torsten@lodderstedt.net  Thu Jun 16 12:31:29 2011
Return-Path: 
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 E7E5211E8158 for ; Thu, 16 Jun 2011 12:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsMbvS9loBNu for ; Thu, 16 Jun 2011 12:31:27 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by ietfa.amsl.com (Postfix) with ESMTP id F365611E8110 for ; Thu, 16 Jun 2011 12:31:26 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXIHj-0004lU-Tg; Thu, 16 Jun 2011 21:31:24 +0200
Message-ID: <4DFA5A13.4030102@lodderstedt.net>
Date: Thu, 16 Jun 2011 21:31:31 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Shane B Weeden 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<90C41DD21FB7C64BB94121FBBC2E7234475E986B88@P3PW5EX1MB01.EX1.SECURESERVER.NET>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:31:30 -0000

> What seems to be missing in the discussion and the security considerations
> of the spec is a decent list of general and grant-type-specific security
> implications/pros/cons for the system if meaningful client authentication
> at the token endpoint is available or not available.
>

What about this? 
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01

regards,
Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Thu Jun 16 12:42:13 2011
Return-Path: 
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 C0DF711E8205 for ; Thu, 16 Jun 2011 12:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3X9HHEO4LS3 for ; Thu, 16 Jun 2011 12:42:13 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id C162111E8110 for ; Thu, 16 Jun 2011 12:42:12 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXISB-00055E-2X; Thu, 16 Jun 2011 21:42:11 +0200
Message-ID: <4DFA5C9A.7060403@lodderstedt.net>
Date: Thu, 16 Jun 2011 21:42:18 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Thomas Hardjono 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:42:13 -0000

-1 making client authentication required at the access token endpoint

Client authentication is useful in some situations to raise the security 
level. But requiring it will either keep out native apps or force there 
developers to use useless/insecure secrets (I would call this "pseudo 
security").

+1 making the client authentication required for certain client types.

for a definition of client types and there respective security 
properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10

In my opinion, the security considerations section already gives a clear 
guideline when client authentication should be used and when the authz 
server should rely on other mechanims.

regards,
Torsten.

Am 16.06.2011 17:08, schrieb Thomas Hardjono:
> Apologies for the late response.
>
>
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, June 15, 2011 1:27 PM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Client authentication requirement
>>
>> Client authentication has been one of the main problem areas in OAuth
>> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
>> confusing).
>>
>> Because of the desire to allow any client type in any deployment
>> environment, we ended up with a barely defined client authentication
>> model. We offer password-based client authentication using HTTP Basic
>> (and an alternative parameter), but leave it optional.
> I would to suggest that perhaps we need a better definition of the "client" by way of identifying one or two (or three) types of clients and listing their respective security properties/capabilities. For example, if a client can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509 processing, then list this, etc. etc.
>
> In this way developers can at least map (in the minds) which client type matches their deployment scenario, based on the best-match capabilities list.
>
>
>> I would like to go back to requiring client authentication for the
>> access token endpoint, using HTTP Basic or other schemes. To leave the
>> door open for clients incapable of authenticating to use the endpoint,
>> we will add a security consideration section discussing the
>> ramifications of using the access token endpoint without client
>> authentication.
>>
>> This suggestions is linked to the topic of refresh tokens which I'll
>> post separately.
>>
>> EHL
> +1 agree that client authentication (to access token endpoint) should be made a requirement.
>
> /thomas/
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From beaton@google.com  Thu Jun 16 12:47:04 2011
Return-Path: 
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 44CF011E8277 for ; Thu, 16 Jun 2011 12:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.955
X-Spam-Level: 
X-Spam-Status: No, score=-105.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESRujs8gOZZE for ; Thu, 16 Jun 2011 12:47:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6B11E8279 for ; Thu, 16 Jun 2011 12:47:03 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p5GJl2tk003610 for ; Thu, 16 Jun 2011 12:47:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308253622; bh=mr34VrhFX3gjrvLMRsnjxOc6OoA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rqU+bn6qXgJgDRrqxB9yWHy4HCricOpuNBJOVwi72URRSPx/wuMWPHbp2yOmxDZiI TULQaHpYz9IX4dYcOs3xw==
Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by hpaq12.eem.corp.google.com with ESMTP id p5GJkxLR018123 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 12:47:01 -0700
Received: by pwj7 with SMTP id 7so634092pwj.5 for ; Thu, 16 Jun 2011 12:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yeHsop1nB8ZG7ZDGrWQvXiqJ5wdjiMETCT3ymYa4oIg=; b=x1v2a1hzta2l5ThTx55I/zTV+f6NgKPNCTB6INTn0tsGf7A1B1ffgSn3ho5Yvx2Qbh Ed5QaPdQViO3iHnPDf5g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dq8AGs4GkN4NCUd7ckkR43skKxe9UQCynpUsc6Ld42hHdcrO60mlWJW/D/VcWhaS/q LziREA4CoA114kDfgXjg==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr269830wfa.323.1308253619304; Thu, 16 Jun 2011 12:46:59 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 12:46:59 -0700 (PDT)
In-Reply-To: <4DFA5C9A.7060403@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>
Date: Thu, 16 Jun 2011 12:46:59 -0700
Message-ID: 
From: Brian Eaton 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001636e906f1413a8904a5d9884b
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:47:04 -0000

--001636e906f1413a8904a5d9884b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> -1 making client authentication required at the access token endpoint
>
> Client authentication is useful in some situations to raise the security
> level. But requiring it will either keep out native apps or force there
> developers to use useless/insecure secrets (I would call this "pseudo
> security").
>

Are you seriously arguing that including the phrase "notasecret" in the
request would make native applications less secure?

--001636e906f1413a8904a5d9884b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt <=
;torsten@lodderstedt.net>=
 wrote:

MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:47:46 -0000

Agree with Torsten -- I would hate for us to repeat the
"anonymous/anonymous" thing that Google implemented for OAuth1.

 -- Justin

On Thu, 2011-06-16 at 15:42 -0400, Torsten Lodderstedt wrote:
> -1 making client authentication required at the access token endpoint
> 
> Client authentication is useful in some situations to raise the security 
> level. But requiring it will either keep out native apps or force there 
> developers to use useless/insecure secrets (I would call this "pseudo 
> security").
> 
> +1 making the client authentication required for certain client types.
> 
> for a definition of client types and there respective security 
> properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10
> 
> In my opinion, the security considerations section already gives a clear 
> guideline when client authentication should be used and when the authz 
> server should rely on other mechanims.
> 
> regards,
> Torsten.
> 
> Am 16.06.2011 17:08, schrieb Thomas Hardjono:
> > Apologies for the late response.
> >
> >
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> >> Of Eran Hammer-Lahav
> >> Sent: Wednesday, June 15, 2011 1:27 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] Client authentication requirement
> >>
> >> Client authentication has been one of the main problem areas in OAuth
> >> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
> >> confusing).
> >>
> >> Because of the desire to allow any client type in any deployment
> >> environment, we ended up with a barely defined client authentication
> >> model. We offer password-based client authentication using HTTP Basic
> >> (and an alternative parameter), but leave it optional.
> > I would to suggest that perhaps we need a better definition of the "client" by way of identifying one or two (or three) types of clients and listing their respective security properties/capabilities. For example, if a client can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509 processing, then list this, etc. etc.
> >
> > In this way developers can at least map (in the minds) which client type matches their deployment scenario, based on the best-match capabilities list.
> >
> >
> >> I would like to go back to requiring client authentication for the
> >> access token endpoint, using HTTP Basic or other schemes. To leave the
> >> door open for clients incapable of authenticating to use the endpoint,
> >> we will add a security consideration section discussing the
> >> ramifications of using the access token endpoint without client
> >> authentication.
> >>
> >> This suggestions is linked to the topic of refresh tokens which I'll
> >> post separately.
> >>
> >> EHL
> > +1 agree that client authentication (to access token endpoint) should be made a requirement.
> >
> > /thomas/
> >
> >
> >
> > _______________________________________________
> > 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



From torsten@lodderstedt.net  Thu Jun 16 12:48:07 2011
Return-Path: 
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 A7EF311E827C for ; Thu, 16 Jun 2011 12:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJExpFN1uXoU for ; Thu, 16 Jun 2011 12:48:07 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id A40AC11E8268 for ; Thu, 16 Jun 2011 12:48:06 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXIXs-0000Oq-CH; Thu, 16 Jun 2011 21:48:04 +0200
Message-ID: <4DFA5DFB.9060602@lodderstedt.net>
Date: Thu, 16 Jun 2011 21:48:11 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Doug Tangren 
References: 	<4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>		<4DE541B5.6080605@aol.com>		<4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com>	<90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<63366D5A116E514AA4A9872D3C53353956F676C5B4@QEO40072.de.t-online.corp> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050601060608000504010006"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: paul Tarjan , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:48:07 -0000

This is a multi-part message in MIME format.
--------------050601060608000504010006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

token_type is defined in the core spec only and indicates the token type 
to the client and not the resource server.

So either the core spec defines a way to distinguish token types towards 
resource servers (probably by utilizing the token_type parameter) or the 
respective schemes (BEARER, MAC) define ways to recognize the differences.

regards,
Torsten.

Am 16.06.2011 15:38, schrieb Doug Tangren:
>
> -Doug Tangren
> http://lessis.mehe
>
>
>     Just one question:
>     Is the assumption of the group that bearer tokens are the only
>     type of tokens to be used in conjunction with URI query
>     parameters? Otherwise, a mechanism is needed to distinguish bearer
>     and other tokens, e.g. another parameter (token_type?).
>
>
> I thought the idea was that token_type was a way to define general 
> extensions which define protocols to provide access_tokens to 
> resources servicers.
>
> I think its up to the provider of access_tokens to document which of 
> these token_types they support and how to distinguish them if there 
> are multiple token_types what use access_tokens in query parameters. I 
> think its up to the extension authors to provide a consistent naming 
> scheme with the base oauth2's defined vocabulary.
>
> Where it gets confusing, is when multiple token_type extensions all 
> use different vocabulary for roughly the same thing. I say that in 
> regards to the naming of query parameters.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------050601060608000504010006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    token_type is defined in the core spec only and indicates the token
    type to the client and not the resource server.

    

    So either the core spec defines a way to distinguish token types
    towards resource servers (probably by utilizing the token_type
    parameter) or the respective schemes (BEARER, MAC) define ways to
    recognize the differences.

    

    regards,

    Torsten.

    

    Am 16.06.2011 15:38, schrieb Doug Tangren:
    


      -Doug Tangren

      http://lessis.mehe
      

      

      

      

        

          Just one question:

          Is the assumption of the group that bearer tokens are the only
          type of tokens to be used in conjunction with URI query
          parameters? Otherwise, a mechanism is needed to distinguish
          bearer and other tokens, e.g. another parameter (token_type?).

          

        

        


        

        
I thought the idea was that token_type was a way to define
          general extensions which define protocols to provide
          access_tokens to resources servicers. 

        


        

        
I think its up to the provider of access_tokens to document
          which of these token_types they support and how to distinguish
          them if there are multiple token_types what use access_tokens
          in query parameters. I think its up to the extension authors
          to provide a consistent naming scheme with the base oauth2's
          defined vocabulary. 

        


        

        
Where it gets confusing, is when multiple token_type
          extensions all use different vocabulary for roughly the same
          thing. I say that in regards to the naming of query
          parameters.

      

      

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


    

  


--------------050601060608000504010006--

From zachary.zeltsan@alcatel-lucent.com  Thu Jun 16 12:50:52 2011
Return-Path: 
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 9431211E80F2 for ; Thu, 16 Jun 2011 12:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYNcOLXN10DB for ; Thu, 16 Jun 2011 12:50:45 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 042D611E80E5 for ; Thu, 16 Jun 2011 12:50:44 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5GJofhp028276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2011 14:50:41 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5GJoexu004040 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jun 2011 14:50:40 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 16 Jun 2011 14:50:40 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'Eran Hammer-Lahav'" , "'Lodderstedt, Torsten'" , "'Torsten Lodderstedt'" , "'Brian Eaton'" 
Date: Thu, 16 Jun 2011 14:50:38 -0500
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtAAEkxo8AABGXegAAG9ynA=
Message-ID: <5710F82C0E73B04FA559560098BF95B12508529FAF@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp> <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_5710F82C0E73B04FA559560098BF95B12508529FAFUSNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:50:52 -0000

--_000_5710F82C0E73B04FA559560098BF95B12508529FAFUSNAVSXCHMBSA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> If you can't validate the client identifier, you should not show the user=
 any information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resour=
ce owner (user) is done before the authorization server authenticates the c=
lient.
How authorization server can validate the client's identifier before authen=
ticating the client?

Zachary
________________________________
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Loddersted=
t'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine=
 print. We know this as a fact. If you can't validate the client identifier=
, you should not show the user any information about the client that you ca=
nnot vouch for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com=
]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Bria=
n Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about=
 a client to a user based on the client's identifier, which client has pres=
ented to the server. If authorization server cannot validate the client's i=
dentity claim, it must make the user aware.

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_5710F82C0E73B04FA559560098BF95B12508529FAFUSNAVSXCHMBSA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









> If you can’t=20
validate the client identifier, you should not show the user any informatio=
n=20
about the client that you cannot vouch for.


According to the flow described in section 1.2, authorizati=
on by=20
the resource owner (user) is done before the authorization server authentic=
ates=20
the client.


How authorization server can validate the client's identifi=
er=20
before authenticating the client?


 


Zachary





From: Eran Hammer-Lahav=20
[mailto:eran@hueniverse.com] 
Sent: Thursday, June 16, 2011 1:52=
=20
PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torst=
en=20
Lodderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE:=
=20
[OAUTH-WG] review of draft-ietf-oauth-v2-16







This=20
is nice on paper but doesn’t work.


 


The=20
user will see the client name or logo and will not read any of the fine pri=
nt.=20
We know this as a fact. If you can’t validate the client identifier, =
you should=20
not show the user any information about the client that you cannot vouch fo=
r.=20
Disclaimers and scary pages are useless.


 


EHL


 






From:=20
Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com]=20

Sent: Thursday, June 16, 2011 10:35 AM
To: 'Loddersted=
t,=20
Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc:=
=20
'OAuth WG'
Subject: RE: [OAUTH-WG] review of=20
draft-ietf-oauth-v2-16


 


I=
 agree=20
with the statement. Authorization server provides information about a clien=
t=20
to a user based on the client's identifier, which client has presented=
 to=20
the server. If authorization server cannot validate the client's ident=
ity=20
claim, it must make the user aware.


 








From:=20
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=20
Lodderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38=20
AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian=20
Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of=20
draft-ietf-oauth-v2-16


The=20
ability to describe a client to the user does not depend on the authenticat=
ion=20
but on the identification of the client and the meta data available to the =
authz=20
server. The only difference between identified and authenticated clients is=
 the=20
trust level the authz server has regarding the client’s identity. It =
must=20
clearly indicate this fact to the end-user.


 


regards,


Torsten.


 






Von:=20
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Gesendet: Mittwoc=
h,=20
15. Juni=20
2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAu=
th=20
WG
Betreff: Re: [OAUTH-WG] review of=20
draft-ietf-oauth-v2-16


 


I=20
agree to the extent that the user can be trusted to know how they got to th=
e=20
authorization endpoint.


 


If=20
the client cannot be authenticated, the authorization server is limited in =
the=20
information it can offer the user to make the decision. It is extremely har=
d to=20
come up with language that will tell the user to only approve the applicati=
on,=20
claiming to be X, if they got here from X directly. There might be ways to=
=20
improve security a bit using Origin header etc. but overall, if the client =
is=20
not authenticated, the authorization server can’t really describe it =
to the=20
user.


 


EHL


 


 






From:=20
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=20
Torsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10=20
AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re:=
=20
[OAUTH-WG] review of draft-ietf-oauth-v2-16


 


I fully agree with Brian and would like to add some th=
oughts:=20


Not authenticating the client does not directly create a security=20
problem at all. If we would follow this line, every e-Mail client out there=
=20
would be considered insecure because the client itself is never authenticat=
ed.=20
Not even Kerbereos has a concept of client authentication. 

In my=20
opinion, OAuth client authentication (in delegated authorization scenarios)=
 is=20
an improvement over classical approaches. But I do not see a degration in=20
security if it is not applicable. As long as the _user_ authorizes the clie=
nt's=20
access (and the duration of the token) and is able to revoke the tokens at =
any=20
time, the situation is much better than with classical approaches.=20


regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eato=
n:=20





Hey Peter - 




 




I haven't read all of your comments yet, but I wanted =
to=20
clarify one point about client impersonation and installed apps.  The=
=20
cuirrent text is unrealistic, but your request would push it the wrong way.=
=20
 CC'ing Torsten as well.




 




---------------------




OLD:
  The authorization server SHOULD issue acces=
s=20
tokens with limited
  scope a=
nd=20
duration to clients incapable of authenticating.

NEW:
&nbs=
p; If the=20
authorization server issues access tokens to clients
  that are incapable of authenticating, the s=
cope=20
and duration of
  such tokens=
 SHOULD=20
be limited.

RATIONALE: We're n=
ot=20
actively RECOMMENDING authorization servers are to
issue such tokens, are=20
we?






---------------------




 




We a=
re most=20
definitely recommending that clients that have no way of authenticating are=
=20
issued long-lived credentials to access user data.




 




Most=
=20
installed applications work as follows:




- th=
ey ask=20
the user for their password




- th=
ey save=20
the password to disk




 




That=
's a=20
horrible security problem, because it means you cannot upgrade user=20
authentication to anything stronger than a password.  Client certifica=
tes,=20
one time passwords, risk based authentication, throw it all out the window.=
=20
 If you're going to let installed apps authenticate with just a passwo=
rd,=20
nothing else you do to improve authentication is going to=20
help.




 




This=
 is a=20
blocking issue for rolling out stronger forms of user authentication, and i=
t's=20
one of the main reasons I care about OAuth2.  




 


Think IMAP and XMPP clients running on Windows desktop=
s.=20
 They are important, and we need a way to migrate them off of saving=20
passwords.




 =





So t=
he=20
current text basically says that you should issue temporary credentials to=
=20
native apps.  That's not practical.  Native apps end up needing=20
permanent or near-permanent credentials.  Expirations need to be measu=
red=20
in months.  And the credentials are going to be issued to stock IMAP a=
nd=20
XMPP clients that don't have any way of authenticating=20
themselves.




 




The =
advantage=20
with OAuth2 over passwords is that




a) t=
he=20
refresh tokens are unguessable.




b) t=
he=20
refresh tokens aren't sent directly to the IMAP and XMPP servers, they are=
=20
restricted to authorization servers.




c) i=
f you've=20
got a managed machine (think Kerberos logins), you can create flows that br=
idge=20
from those managed credentials to temporary access=20
credentials.




 




Cheers,




Brian


--_000_5710F82C0E73B04FA559560098BF95B12508529FAFUSNAVSXCHMBSA_--

From torsten@lodderstedt.net  Thu Jun 16 12:56:27 2011
Return-Path: 
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 E05EC11E8185 for ; Thu, 16 Jun 2011 12:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbvanoHle3MM for ; Thu, 16 Jun 2011 12:56:27 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0311E8167 for ; Thu, 16 Jun 2011 12:56:27 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXIfx-0000cf-47; Thu, 16 Jun 2011 21:56:25 +0200
Message-ID: <4DFA5FEF.90201@lodderstedt.net>
Date: Thu, 16 Jun 2011 21:56:31 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Brian Eaton 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020603040706080500050106"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 19:56:28 -0000

This is a multi-part message in MIME format.
--------------020603040706080500050106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Certainly not. Are we discussing to make client authentication required 
just for syntactical purposes?

To me, "notasecret" logically means to abandon on client authentication.

regards,
Torsten.

Am 16.06.2011 21:46, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt 
> > wrote:
>
>     -1 making client authentication required at the access token endpoint
>
>     Client authentication is useful in some situations to raise the
>     security level. But requiring it will either keep out native apps
>     or force there developers to use useless/insecure secrets (I would
>     call this "pseudo security").
>
>
> Are you seriously arguing that including the phrase "notasecret" in 
> the request would make native applications less secure?

--------------020603040706080500050106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Certainly not. Are we discussing to make client authentication
    required just for syntactical purposes? 

    

    To me, "notasecret" logically means to abandon on client
    authentication. 

    

    regards,

    Torsten.

    

    Am 16.06.2011 21:46, schrieb Brian Eaton:
    
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
      <torsten@lodderstedt.net>
      wrote:

      

        

          -1 making client authentication required at the access token
          endpoint

          

          Client authentication is useful in some situations to raise
          the security level. But requiring it will either keep out
          native apps or force there developers to use useless/insecure
          secrets (I would call this "pseudo security").

        

        


        

        
Are you seriously arguing that including the phrase
          "notasecret" in the request would make native applications
          less secure?

      

    

  


--------------020603040706080500050106--

From beaton@google.com  Thu Jun 16 13:02:39 2011
Return-Path: 
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 6CEC511E8279 for ; Thu, 16 Jun 2011 13:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.957
X-Spam-Level: 
X-Spam-Status: No, score=-105.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNW0NEIQWlmu for ; Thu, 16 Jun 2011 13:02:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A339111E8238 for ; Thu, 16 Jun 2011 13:02:37 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p5GK2PIo006478 for ; Thu, 16 Jun 2011 13:02:31 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308254551; bh=EljxvH722z8wWSRYnZWH16UW3jU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=k54nBIbO8F5+hPGcOOdIhTvcEV3Vo9REFgAmnNwq5GKY3HrCzYqBirh0xWpuy3j7/ whCdqCGjhWfjK3r3l77wg==
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by wpaz5.hot.corp.google.com with ESMTP id p5GK2N2N030768 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 13:02:24 -0700
Received: by pzk10 with SMTP id 10so1739861pzk.21 for ; Thu, 16 Jun 2011 13:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BNM/BLtXBWX//SW4GngZqwnzGdGDFnlfibExtTn1wBQ=; b=MJPu6+iO7kp33N+Iy7E9U+IOuKAk3r0SiHCjcZCiYr6eqLlH686URZNs9LGQJAzAYK nOYxdmppHaJG08RFB3xg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wWGQ8SEfz7Pb6O4BZ9FmR4DG0jxi6wXr2PYsXU/Red2NFJwsNsXAptYZfEtSvGRijo PUaAxK/gfsJQNPmQ5htw==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr274875wfa.323.1308254543384; Thu, 16 Jun 2011 13:02:23 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 13:02:23 -0700 (PDT)
In-Reply-To: <4DFA5FEF.90201@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>
Date: Thu, 16 Jun 2011 13:02:23 -0700
Message-ID: 
From: Brian Eaton 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001636e906f155926204a5d9bfcb
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:02:39 -0000

--001636e906f155926204a5d9bfcb
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> **
> Certainly not. Are we discussing to make client authentication required
> just for syntactical purposes?
>

That is what I'd like to see.

>From my perspective, no harm is done by making client authentication a
syntactical requirement of the protocol.

- clients that can't keep secrets aren't harmed; they have the exact same
security they do today.
- everyone else benefits because the spec becomes simpler and more
consistent.

--001636e906f155926204a5d9bfcb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt <=
;torsten@lodderstedt.net>=
 wrote:

    Certainly not. Are we discussing to make client authentication
    required just for syntactical purposes? 
That is what I'd like to see.

From=
 my perspective, no harm is done by making client authentication a syntacti=
cal requirement of the protocol.



- clients that can't keep secrets aren't harmed=
; they have the exact same security they do today.
- everyone els=
e benefits because the spec becomes simpler and more consistent.


--001636e906f155926204a5d9bfcb--

From torsten@lodderstedt.net  Thu Jun 16 13:05:43 2011
Return-Path: 
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 DDDAD11E817F for ; Thu, 16 Jun 2011 13:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Level: 
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuWWhD998YG8 for ; Thu, 16 Jun 2011 13:05:43 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2724C11E80ED for ; Thu, 16 Jun 2011 13:05:43 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXIov-0006Cv-IM; Thu, 16 Jun 2011 22:05:41 +0200
Message-ID: <4DFA621B.7060904@lodderstedt.net>
Date: Thu, 16 Jun 2011 22:05:47 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Brian Eaton 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net>		<4DFA5FEF.90201@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000701000104070401090500"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:05:44 -0000

This is a multi-part message in MIME format.
--------------000701000104070401090500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Am 16.06.2011 22:02, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt 
> > wrote:
>
>     Certainly not. Are we discussing to make client authentication
>     required just for syntactical purposes?
>
>
> That is what I'd like to see.
>
> From my perspective, no harm is done by making client authentication a 
> syntactical requirement of the protocol.
>
> - clients that can't keep secrets aren't harmed; they have the exact 
> same security they do today.
> - everyone else benefits because the spec becomes simpler and more 
> consistent.

No, it's not simpler nor clearer. Such a client secret is useless, so 
the security implications have to be explained anyway. Moreover, 
whatever the spec will state people would start to _rely_ on client 
secrets even for native apps, which is a really bad idea.

regards,
Torsten.

--------------000701000104070401090500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    

    

    Am 16.06.2011 22:02, schrieb Brian Eaton:
    
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
      <torsten@lodderstedt.net>
      wrote:

      

        

          
 Certainly not. Are we
            discussing to make client authentication required just for
            syntactical purposes? 

          

        

        


        

        
That is what I'd like to see.

        


        

        
From my perspective, no harm is done by making client
          authentication a syntactical requirement of the protocol.

        


        

        
- clients that can't keep secrets aren't harmed; they have
          the exact same security they do today.

        
- everyone else benefits because the spec becomes simpler
          and more consistent.

      

    

    

    No, it's not simpler nor clearer. Such a client secret is useless,
    so the security implications have to be explained anyway. Moreover,
    whatever the spec will state people would start to _rely_ on client
    secrets even for native apps, which is a really bad idea.

    

    regards,

    Torsten.

  


--------------000701000104070401090500--

From jricher@mitre.org  Thu Jun 16 13:20:56 2011
Return-Path: 
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 38BD511E82BF for ; Thu, 16 Jun 2011 13:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.402
X-Spam-Level: 
X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPcMi+cVPbBl for ; Thu, 16 Jun 2011 13:20:55 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 638C611E82B8 for ; Thu, 16 Jun 2011 13:20:55 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AFB0721B0F49; Thu, 16 Jun 2011 16:20:54 -0400 (EDT)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A99AC21B0AEE; Thu, 16 Jun 2011 16:20:54 -0400 (EDT)
Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Thu, 16 Jun 2011 16:20:54 -0400
From: Justin Richer 
To: Torsten Lodderstedt 
In-Reply-To: <4DFA621B.7060904@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Jun 2011 16:19:05 -0400
Message-ID: <1308255545.18341.9.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:20:56 -0000

> >         Certainly not. Are we discussing to make client
> >         authentication required just for syntactical purposes? 
> > 
> > That is what I'd like to see.
> > 
> > 
> > From my perspective, no harm is done by making client authentication
> > a syntactical requirement of the protocol.
> > 
> > 
> > - clients that can't keep secrets aren't harmed; they have the exact
> > same security they do today.
> > - everyone else benefits because the spec becomes simpler and more
> > consistent.
> 
> No, it's not simpler nor clearer. Such a client secret is useless, so
> the security implications have to be explained anyway. Moreover,
> whatever the spec will state people would start to _rely_ on client
> secrets even for native apps, which is a really bad idea.

Not only does it give the wrong impression for developers using this, it
forces client developers to use a pattern that doesn't make sense. I
really don't like the approach of "if you're not going to really use
this, then use this well-known dummy value instead." I'd rather have the
useless bits simply not sent instead of filled in with nonsense values. 

This is getting back to the one-size-fits-all OAuth 1.0 approach that we
were trying to get *away* from here. At least, I thought we were.

 -- Justin


From beaton@google.com  Thu Jun 16 13:21:10 2011
Return-Path: 
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 46EBC11E82C5 for ; Thu, 16 Jun 2011 13:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.959
X-Spam-Level: 
X-Spam-Status: No, score=-105.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6zXlHqQ9BU4 for ; Thu, 16 Jun 2011 13:21:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86711E82B8 for ; Thu, 16 Jun 2011 13:21:09 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p5GKL6jq026230 for ; Thu, 16 Jun 2011 13:21:06 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308255666; bh=9PXNkKcDOhsCb17ceOgJLLiaIII=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=DkP43X/lNGvY+wPAACwuwXZicPtlb3/neiK6PMPxXoqTJ2YTPo1m17MarL/oyfMif YLr5Wh4riKnB5tjU+aIjw==
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by wpaz21.hot.corp.google.com with ESMTP id p5GKKshU005380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 13:21:00 -0700
Received: by pzk10 with SMTP id 10so1751405pzk.21 for ; Thu, 16 Jun 2011 13:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GYiqfclbeS+hU83bL3gx30NOvhJxFmPI9Zgg8U8Ntzw=; b=hLtr4zKozxptV7xEZ0IgjOYHpLU3D6cAf7xCn1ty6AvgBaJA14depg4vcIIvA+7dIF 17vXnda4c0Cs1PkWqgiQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ef7Im9UWsu2asrYhBHjYQa861Y2sAmOTXDG0MJMoKTZbQJlaTHbgrKOtPZb0MFeI7r tgCAm6SHLC60F81oTeig==
MIME-Version: 1.0
Received: by 10.142.68.12 with SMTP id q12mr277028wfa.323.1308255653895; Thu, 16 Jun 2011 13:20:53 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 13:20:53 -0700 (PDT)
In-Reply-To: <4DFA621B.7060904@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>
Date: Thu, 16 Jun 2011 13:20:53 -0700
Message-ID: 
From: Brian Eaton 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001636e906f1869d5004a5da01c4
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:21:10 -0000

--001636e906f1869d5004a5da01c4
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> **
> No, it's not simpler nor clearer. Such a client secret is useless, so the
> security implications have to be explained anyway.
>

The issue really isn't the security implications being unclear; the issue is
that the normative language that describes the protocol flows is ambiguous.

Moreover, whatever the spec will state people would start to _rely_ on
> client secrets even for native apps, which is a really bad idea.
>

OK, so you are arguing that baking the string "notasecret" into a client
application makes that client application less secure.  That's not really
plausible.

--001636e906f1869d5004a5da01c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <=
torsten@lodderstedt.net><=
/span> wrote:



 =20
   =20
   =20
 =20
  
No, it's not simpler nor cl=
earer. Such a client secret is useless,
    so the security implications have to be explained anyway.

The issue really isn't the security implicatio=
ns being unclear; the issue is that the normative language that describes t=
he protocol flows is ambiguous.



Moreover,
    whatever the spec will state people would start to _rely_ on client
    secrets even for native apps, which is a really bad idea.

OK, so you are arguing that baking the string &quo=
t;notasecret" into a client application makes that client application =
less secure. =A0That's not really plausible.




--001636e906f1869d5004a5da01c4--

From eran@hueniverse.com  Thu Jun 16 13:24:08 2011
Return-Path: 
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 36A3111E82D6 for ; Thu, 16 Jun 2011 13:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieDHw7UxPe63 for ; Thu, 16 Jun 2011 13:24:04 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7D5BA11E82BF for ; Thu, 16 Jun 2011 13:24:02 -0700 (PDT)
Received: (qmail 19009 invoked from network); 16 Jun 2011 20:23:59 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 20:23:58 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Jun 2011 13:23:55 -0700
From: Eran Hammer-Lahav 
To: "torsten@lodderstedt.net" , "Lodderstedt, Torsten" , Brian Eaton 
Date: Thu, 16 Jun 2011 13:23:31 -0700
Thread-Topic: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwsUoct/LDH2WucQteTs5IZZ8UubAAEE1vg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986D9B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DE68847.8090808@stpeter.im><4DE75359.6070109@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET><63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp><90C41DD21FB7C64BB94121FBBC2E7234475E986CC4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <668693429-1308248613-cardhu_decombobulator_blackberry.rim.net-2055818697-@b5.c11.bise7.blackberry>
In-Reply-To: <668693429-1308248613-cardhu_decombobulator_blackberry.rim.net-2055818697-@b5.c11.bise7.blackberry>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986D9BP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:24:08 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9BP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The user should be informed and in control, but there is a limit to how muc=
h information you can give with confidence. My point is that it is really h=
ard to provide the user with trustworthy information without client registr=
ation and secure client credentials or pre-registered callback.

If you have a client identifier without secret (via the authentication code=
) or registered callback, that client identifier is useless and must not be=
 used.

EHL

From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net]
Sent: Thursday, June 16, 2011 11:24 AM
To: Eran Hammer-Lahav; Lodderstedt, Torsten; Brian Eaton
Cc: OAuth WG
Subject: AW: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I thought keeping the user informed and in control are core principles of o=
Auth? Do you suggest not informing the user is better than stating somethin=
g like: "the client should be XXX, accept the request only if you are sure =
...."

regards,
Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland

________________________________
From: Eran Hammer-Lahav 
Date: Thu, 16 Jun 2011 08:32:55 -0700
To: Lodderstedt, Torsten; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Easier said than done. If you don't have strong trust, giving the user hint=
s will cause more harm than good.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the_user_ authorizes =
the client's access (and the duration of the token) and is able to revoke t=
he tokens at any time, the situation is much better than with classical app=
roaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9BP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
The user should be informed and in control, but there is a limit to =
how much information you can give with confidence. My point is that it is r=
eally hard to provide the user with trustworthy information without client =
registration and secure client credentials or pre-registered callback.=

 
If you have a client identifier without secret (v=
ia the authentication code) or registered callback, that client identifier =
is useless and must not be used.
=
 
EHL
 
From: t=
orsten@lodderstedt.net [mailto:torsten@lodderstedt.net] 
Sent: Th=
ursday, June 16, 2011 11:24 AM
To: Eran Hammer-Lahav; Lodderstedt=
, Torsten; Brian Eaton
Cc: OAuth WG
Subject: AW: RE: [O=
AUTH-WG] review of draft-ietf-oauth-v2-16
=

 
I thought keeping the user informed and in control ar=
e core principles of oAuth? Do you suggest not informing the user is better=
 than stating something like: "the client should be XXX, accept the re=
quest only if you are sure ...."

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland=
 
From: Eran Hammer-Lah=
av <eran@hueniverse.com> 
Date: Thu, 16 Jun 2011 08:32:55 -0700
=

To: Lodderstedt, Torsten<t.lodderst=
edt@telekom.de>; Torsten Lodderstedt<torsten@lodderstedt.net>; Bri=
an Eaton<beaton@google.com>
Cc: OAuth WG<oauth@ietf.org>
<=
/div>
Subject:=
 RE: [OAUTH-WG] review of draft=
-ietf-oauth-v2-16
 
Easier said than done. If you don’t have strong trust=
, giving the user hints will cause more harm than good.
 
EHL
 =

Fr=
om: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.=
de] 
Sent: Thursday, June 16, 2011 1:38 AM
To: Eran Ham=
mer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Su=
bject: AW: [OAUTH-WG] review of draft-ietf-oauth-v2-16
 
The ability to describe a client to the user does not depend on=
 the authentication but on the identification of the client and the meta da=
ta available to the authz server. The only difference between identified an=
d authenticated clients is the trust level the authz server has regarding t=
he client’s identity. It must clearly indicate this fact to the end-u=
ser.
 
regards,
Torsten.
 
Von: Eran Hammer-Lahav [m=
ailto:eran@hueniverse.com] 
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc:=
 OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-=
v2-16
 
I agree to the extent that the user can b=
e trusted to know how they got to the authorization endpoint.
 
If the client cannot be authenticated, the authorization s=
erver is limited in the information it can offer the user to make the decis=
ion. It is extremely hard to come up with language that will tell the user =
to only approve the application, claiming to be X, if they got here from X =
directly. There might be ways to improve security a bit using Origin header=
 etc. but overall, if the client is not authenticated, the authorization se=
rver can’t really describe it to the user.
 
EHL
 <=
/span>
 
From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tors=
ten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] rev=
iew of draft-ietf-oauth-v2-16
 
I fully agree with Brian=
 and would like to add some thoughts: 

Not authenticating the client=
 does not directly create a security problem at all. If we would follow thi=
s line, every e-Mail client out there would be considered insecure because =
the client itself is never authenticated. Not even Kerbereos has a concept =
of client authentication. 

In my opinion, OAuth client authenticatio=
n (in delegated authorization scenarios) is an improvement over classical a=
pproaches. But I do not see a degration in security if it is not applicable=
. As long as the_user_ authorizes the client's access (and the duration of =
the token) and is able to revoke the tokens at any time, the situation is m=
uch better than with classical approaches. 

regards,
Torsten.
=

Am 01.06.2011 21:06, schrieb Brian Eaton: 
Hey Peter - 
 
I haven't read all o=
f your comments yet, but I wanted to clarify one point about client imperso=
nation and installed apps.  The cuirrent text is unrealistic, but your=
 request would push it the wrong way.  CC'ing Torsten as well.
 
---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients=
 incapable of authenticating.

=
NEW:
  If the authorization s=
erver issues access tokens to clients
  that are incapable of authenticating, the scope and duration of<=
/span>
  such tokens SHOULD be limit=
ed.

RATIONALE: We're not activ=
ely RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------
 
We are most definitely recommending that clients that have no wa=
y of authenticating are issued long-lived credentials to access user data.<=
o:p>
 
Most installe=
d applications work as follows:
- they ask the u=
ser for their password
- they save the password =
to disk
 
<=
p class=3DMsoNormal>That's=
 a horrible security problem, because it means you cannot upgrade user auth=
entication to anything stronger than a password.  Client certificates,=
 one time passwords, risk based authentication, throw it all out the window=
.  If you're going to let installed apps authenticate with just a pass=
word, nothing else you do to improve authentication is going to help.<=
/o:p>
 
This is a blocking =
issue for rolling out stronger forms of user authentication, and it's one o=
f the main reasons I care about OAuth2.  
<=
div>
 
Th=
ink IMAP and XMPP clients running on Windows desktops.  They are impor=
tant, and we need a way to migrate them off of saving passwords.=

 =

So the current text basically says that you should issue tempora=
ry credentials to native apps.  That's not practical.  Native app=
s end up needing permanent or near-permanent credentials.  Expirations=
 need to be measured in months.  And the credentials are going to be i=
ssued to stock IMAP and XMPP clients that don't have any way of authenticat=
ing themselves.
 
The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
<=
p class=3DMsoNormal>b) the=
 refresh tokens aren't sent directly to the IMAP and XMPP servers, they are=
 restricted to authorization servers.
c) if you'=
ve got a managed machine (think Kerberos logins), you can create flows that=
 bridge from those managed credentials to temporary access credentials.
 
Cheers,
Brian
=

=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9BP3PW5EX1MB01E_--

From torsten@lodderstedt.net  Thu Jun 16 13:26:01 2011
Return-Path: 
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 038E011E82D1 for ; Thu, 16 Jun 2011 13:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9vxKwS1IrrX for ; Thu, 16 Jun 2011 13:26:00 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by ietfa.amsl.com (Postfix) with ESMTP id EE92D11E82CB for ; Thu, 16 Jun 2011 13:25:20 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXJ7v-0004UM-J7; Thu, 16 Jun 2011 22:25:19 +0200
Message-ID: <4DFA66B5.1090205@lodderstedt.net>
Date: Thu, 16 Jun 2011 22:25:25 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Brian Eaton 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net>		<4DFA5FEF.90201@lodderstedt.net>		<4DFA621B.7060904@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070306060706090606040306"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:26:01 -0000

This is a multi-part message in MIME format.
--------------070306060706090606040306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

no I'm saying people will use real secrets and rely on them - just as 
with OAuth 1.0

Am 16.06.2011 22:20, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt 
> > wrote:
>
>     No, it's not simpler nor clearer. Such a client secret is useless,
>     so the security implications have to be explained anyway.
>
>
> The issue really isn't the security implications being unclear; the 
> issue is that the normative language that describes the protocol flows 
> is ambiguous.
>
>     Moreover, whatever the spec will state people would start to
>     _rely_ on client secrets even for native apps, which is a really
>     bad idea.
>
>
> OK, so you are arguing that baking the string "notasecret" into a 
> client application makes that client application less secure.  That's 
> not really plausible.

--------------070306060706090606040306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    no I'm saying people will use real secrets and rely on them - just
    as with OAuth 1.0 

    

    Am 16.06.2011 22:20, schrieb Brian Eaton:
    
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
      wrote:

      

        

          
No, it's not simpler nor
            clearer. Such a client secret is useless, so the security
            implications have to be explained anyway.

        

        


        

        
The issue really isn't the security implications being
          unclear; the issue is that the normative language that
          describes the protocol flows is ambiguous.

        


        

        

          
Moreover, whatever the
            spec will state people would start to _rely_ on client
            secrets even for native apps, which is a really bad idea.

        

        


        

        
OK, so you are arguing that baking the string "notasecret"
          into a client application makes that client application less
          secure.  That's not really plausible.

      

    

  


--------------070306060706090606040306--

From eran@hueniverse.com  Thu Jun 16 13:26:05 2011
Return-Path: 
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 9D30111E82BD for ; Thu, 16 Jun 2011 13:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level: 
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuWmnUgIAuD4 for ; Thu, 16 Jun 2011 13:26:00 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4D57511E82DE for ; Thu, 16 Jun 2011 13:25:39 -0700 (PDT)
Received: (qmail 5804 invoked from network); 16 Jun 2011 20:25:38 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2011 20:25:38 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 16 Jun 2011 13:25:36 -0700
From: Eran Hammer-Lahav 
To: "Zeltsan, Zachary (Zachary)" , "'Lodderstedt, Torsten'" , 'Torsten Lodderstedt' , 'Brian Eaton' 
Date: Thu, 16 Jun 2011 13:25:12 -0700
Thread-Topic: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Thread-Index: AcwhBNaw7424v1o7QUa98g6OEzR+ugKizD7wABwEgtAAEkxo8AABGXegAAG9ynAAA6kPUA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986D9D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4DE68847.8090808@stpeter.im>  <4DE75359.6070109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234475E986B62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F676C5BC@QEO40072.de.t-online.corp> <5710F82C0E73B04FA559560098BF95B12508529EC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986D30@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5710F82C0E73B04FA559560098BF95B12508529FAF@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <5710F82C0E73B04FA559560098BF95B12508529FAF@USNAVSXCHMBSA3.ndc.alcatel-lucent.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_90C41DD21FB7C64BB94121FBBC2E7234475E986D9DP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: 'OAuth WG' 
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:26:06 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9DP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If this is an implicit grant, using the redirection URI registered before. =
If this is the authorization code, the server knows that the client will ha=
ve to present a secret later to get access, so it can make that information=
 available with confidence. If someone else is asking using a stole identif=
ier, they will not go far without the secret, and the user data will remain=
 safe.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com=
]
Sent: Thursday, June 16, 2011 12:51 PM
To: Eran Hammer-Lahav; 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'; 'Bria=
n Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

> If you can't validate the client identifier, you should not show the user=
 any information about the client that you cannot vouch for.
According to the flow described in section 1.2, authorization by the resour=
ce owner (user) is done before the authorization server authenticates the c=
lient.
How authorization server can validate the client's identifier before authen=
ticating the client?

Zachary
________________________________
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Loddersted=
t'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
This is nice on paper but doesn't work.

The user will see the client name or logo and will not read any of the fine=
 print. We know this as a fact. If you can't validate the client identifier=
, you should not show the user any information about the client that you ca=
nnot vouch for. Disclaimers and scary pages are useless.

EHL

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com=
]
Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt, Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Bria=
n Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with the statement. Authorization server provides information about=
 a client to a user based on the client's identifier, which client has pres=
ented to the server. If authorization server cannot validate the client's i=
dentity claim, it must make the user aware.

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Hammer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the authent=
ication but on the identification of the client and the meta data available=
 to the authz server. The only difference between identified and authentica=
ted clients is the trust level the authz server has regarding the client's =
identity. It must clearly indicate this fact to the end-user.

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 15. Juni 2011 21:20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree to the extent that the user can be trusted to know how they got to =
the authorization endpoint.

If the client cannot be authenticated, the authorization server is limited =
in the information it can offer the user to make the decision. It is extrem=
ely hard to come up with language that will tell the user to only approve t=
he application, claiming to be X, if they got here from X directly. There m=
ight be ways to improve security a bit using Origin header etc. but overall=
, if the client is not authenticated, the authorization server can't really=
 describe it to the user.

EHL


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eaton
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts:

Not authenticating the client does not directly create a security problem a=
t all. If we would follow this line, every e-Mail client out there would be=
 considered insecure because the client itself is never authenticated. Not =
even Kerbereos has a concept of client authentication.

In my opinion, OAuth client authentication (in delegated authorization scen=
arios) is an improvement over classical approaches. But I do not see a degr=
ation in security if it is not applicable. As long as the _user_ authorizes=
 the client's access (and the duration of the token) and is able to revoke =
the tokens at any time, the situation is much better than with classical ap=
proaches.

regards,
Torsten.

Am 01.06.2011 21:06, schrieb Brian Eaton:
Hey Peter -

I haven't read all of your comments yet, but I wanted to clarify one point =
about client impersonation and installed apps.  The cuirrent text is unreal=
istic, but your request would push it the wrong way.  CC'ing Torsten as wel=
l.

---------------------
OLD:
  The authorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of authenticating.

NEW:
  If the authorization server issues access tokens to clients
  that are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.

RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
---------------------

We are most definitely recommending that clients that have no way of authen=
ticating are issued long-lived credentials to access user data.

Most installed applications work as follows:
- they ask the user for their password
- they save the password to disk

That's a horrible security problem, because it means you cannot upgrade use=
r authentication to anything stronger than a password.  Client certificates=
, one time passwords, risk based authentication, throw it all out the windo=
w.  If you're going to let installed apps authenticate with just a password=
, nothing else you do to improve authentication is going to help.

This is a blocking issue for rolling out stronger forms of user authenticat=
ion, and it's one of the main reasons I care about OAuth2.

Think IMAP and XMPP clients running on Windows desktops.  They are importan=
t, and we need a way to migrate them off of saving passwords.

So the current text basically says that you should issue temporary credenti=
als to native apps.  That's not practical.  Native apps end up needing perm=
anent or near-permanent credentials.  Expirations need to be measured in mo=
nths.  And the credentials are going to be issued to stock IMAP and XMPP cl=
ients that don't have any way of authenticating themselves.

The advantage with OAuth2 over passwords is that
a) the refresh tokens are unguessable.
b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, th=
ey are restricted to authorization servers.
c) if you've got a managed machine (think Kerberos logins), you can create =
flows that bridge from those managed credentials to temporary access creden=
tials.

Cheers,
Brian

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9DP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
If this is an implicit grant, using the redirection URI registered b=
efore. If this is the authorization code, the server knows that the client =
will have to present a secret later to get access, so it can make that info=
rmation available with confidence. If someone else is asking using a stole =
identifier, they will not go far without the secret, and the user data will=
 remain safe.
 <=
/o:p>
EHL
 
From: Zeltsan, Zachary (Za=
chary) [mailto:zachary.zeltsan@alcatel-lucent.com] 
Sent: Thursda=
y, June 16, 2011 12:51 PM
To: Eran Hammer-Lahav; 'Lodderstedt, To=
rsten'; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oauth-v2-16
 
> If you can’t validate the client identifier, you should n=
ot show the user any information about the client that you cannot vouch for=
.
A=
ccording to the flow described in section 1.2, authorization by the resourc=
e owner (user) is done before the authorization server authenticates the cl=
ient.
How authorization server can validate the client's identifier before aut=
henticating the client?<=
/span>
 =

Zachary=

From: Eran Hammer-Lahav [mailto:eran@hu=
eniverse.com] 
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Lodderstedt, Torsten'; 'Torsten Lodderstedt'=
; 'Brian Eaton'
Cc: 'OAuth WG'
Subject: RE: [OAUTH-WG] =
review of draft-ietf-oauth-v2-16
This is nice on paper but do=
esn’t work.
&nb=
sp;
The user will see the clien=
t name or logo and will not read any of the fine print. We know this as a f=
act. If you can’t validate the client identifier, you should not show=
 the user any information about the client that you cannot vouch for. Discl=
aimers and scary pages are useless.
 
EHL<=
/o:p>
 
From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com] Sent: Thursday, June 16, 2011 10:35 AM
To: 'Lodderstedt,=
 Torsten'; Eran Hammer-Lahav; 'Torsten Lodderstedt'; 'Brian Eaton'
Cc=
: 'OAuth WG'
Subject: RE: [OAUTH-WG] review of draft-ietf-oau=
th-v2-16
 <=
/o:p>
I agree with the statement. Autho=
rization server provides information about a client to a user based on=
 the client's identifier, which client has presented to the server. If auth=
orization server cannot validate the client's identity claim, it =
must make the user aware.=

 
From: oauth-bounces@ie=
tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Tor=
sten
Sent: Thursday, June 16, 2011 4:38 AM
To: Eran Ham=
mer-Lahav; Torsten Lodderstedt; Brian Eaton
Cc: OAuth WG
Su=
bject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Th=
e ability to describe a client to the user does not depend on the authentic=
ation but on the identification of the client and the meta data available t=
o the authz server. The only difference between identified and authenticate=
d clients is the trust level the authz server has regarding the client̵=
7;s identity. It must clearly indicate this fact to the end-user.
 
regards,
Torsten.
 
Von: Eran Hammer-Lahav [mailto:eran@hueni=
verse.com] 
Gesendet: Mittwoch, 15. Juni 2011 21:=
20
An: Torsten Lodderstedt; Brian Eaton
Cc: OAuth WGBetreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16=

 
I agree to the extent that the user can be trusted to k=
now how they got to the authorization endpoint.
 
If the client cannot be authenticated, the authorization server is limit=
ed in the information it can offer the user to make the decision. It is ext=
remely hard to come up with language that will tell the user to only approv=
e the application, claiming to be X, if they got here from X directly. Ther=
e might be ways to improve security a bit using Origin header etc. but over=
all, if the client is not authenticated, the authorization server can’=
;t really describe it to the user.
 
EHL
 
 
<=
p class=3DMsoNormal>From: oauth-bounces@iet=
f.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderste=
dt
Sent: Thursday, June 02, 2011 2:10 AM
To: Brian Eato=
n
Cc: OAuth WG
Subject: Re: [OAUTH-WG] review of draft-=
ietf-oauth-v2-16
 
I fully agree with Brian and would li=
ke to add some thoughts: 

Not authenticating the client does not dir=
ectly create a security problem at all. If we would follow this line, every=
 e-Mail client out there would be considered insecure because the client it=
self is never authenticated. Not even Kerbereos has a concept of client aut=
hentication. 

In my opinion, OAuth client authentication (in delegat=
ed authorization scenarios) is an improvement over classical approaches. Bu=
t I do not see a degration in security if it is not applicable. As long as =
the _user_ authorizes the client's access (and the duration of the token) a=
nd is able to revoke the tokens at any time, the situation is much better t=
han with classical approaches. 

regards,
Torsten.

Am 01.06=
.2011 21:06, schrieb Brian Eaton: 
=
Hey Peter - 
 =

I haven't read all of your commen=
ts yet, but I wanted to clarify one point about client impersonation and in=
stalled apps.  The cuirrent text is unrealistic, but your request woul=
d push it the wrong way.  CC'ing Torsten as well.
=

 
---------------------
OLD:
  The a=
uthorization server SHOULD issue access tokens with limited
  scope and duration to clients incapable of=
 authenticating.

NEW:  If the authorization server issues =
access tokens to clients
  th=
at are incapable of authenticating, the scope and duration of
  such tokens SHOULD be limited.
RATIONALE: We're not actively RECOMMEND=
ING authorization servers are to
i=
ssue such tokens, are we?
----------=
-----------
 
We=
 are most definitely recommending that clients that have no way of authenti=
cating are issued long-lived credentials to access user data.
 
<=
span style=3D'font-family:"Arial","sans-serif"'>Most installed applications=
 work as follows:
- they ask the user for their =
password
- they save the password to disk=

 
That's a horrible =
security problem, because it means you cannot upgrade user authentication t=
o anything stronger than a password.  Client certificates, one time pa=
sswords, risk based authentication, throw it all out the window.  If y=
ou're going to let installed apps authenticate with just a password, nothin=
g else you do to improve authentication is going to help.=

 
This is a blocking issue for ro=
lling out stronger forms of user authentication, and it's one of the main r=
easons I care about OAuth2.  
 
Think IMAP and=
 XMPP clients running on Windows desktops.  They are important, and we=
 need a way to migrate them off of saving passwords.
 
<=
div>
S=
o the current text basically says that you should issue temporary credentia=
ls to native apps.  That's not practical.  Native apps end up nee=
ding permanent or near-permanent credentials.  Expirations need to be =
measured in months.  And the credentials are going to be issued to sto=
ck IMAP and XMPP clients that don't have any way of authenticating themselv=
es.
 
The advant=
age with OAuth2 over passwords is that
a) the re=
fresh tokens are unguessable.
b) the refresh tok=
ens aren't sent directly to the IMAP and XMPP servers, they are restricted =
to authorization servers.
c) if you've got a man=
aged machine (think Kerberos logins), you can create flows that bridge from=
 those managed credentials to temporary access credentials.
 
Cheers,
=

Brian
=
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986D9DP3PW5EX1MB01E_--

From beaton@google.com  Thu Jun 16 13:30:52 2011
Return-Path: 
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 3547711E82E0 for ; Thu, 16 Jun 2011 13:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgIfPkraLq8z for ; Thu, 16 Jun 2011 13:30:51 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0D39B11E82E3 for ; Thu, 16 Jun 2011 13:30:49 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p5GKUiTL013103 for ; Thu, 16 Jun 2011 13:30:49 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308256249; bh=i/tc6JgA1Who9o+Mmv8GV9UDZTE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BuTbEa7LdzFDHK81cHPl9XrIYgasq5IuWcGnqOZhrC48VArMnNrgwyxq2CcOZzPin C/JOsr1dJkCVDPAkTz2SA==
Received: from pwj5 (pwj5.prod.google.com [10.241.219.69]) by wpaz37.hot.corp.google.com with ESMTP id p5GKUWkw016580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 13:30:33 -0700
Received: by pwj5 with SMTP id 5so1000783pwj.12 for ; Thu, 16 Jun 2011 13:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k8PdXVm0s4h5Fjz4c5UrzNbNxQdKICsty8vOWltHOc0=; b=eLIiHB0E4Dy+G0GRhOWxlH5agTSGBtPob9CbUkuMWz0Q0goQ4IwLjqFBNZMtAUYUlx V2gL6C8CpH1jTUAUoiTw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rMHcEPw5hQVwUpXn0NmW2SKBycx5AS4kYA/KK/A2UQz/QRF2AUYumUqqT0ONf3SCPc x/tBNewws41FbnHTWhkA==
MIME-Version: 1.0
Received: by 10.142.44.16 with SMTP id r16mr246985wfr.406.1308256232099; Thu, 16 Jun 2011 13:30:32 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 13:30:31 -0700 (PDT)
In-Reply-To: <4DFA66B5.1090205@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>
Date: Thu, 16 Jun 2011 13:30:31 -0700
Message-ID: 
From: Brian Eaton 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=000e0cd1a0e6fd517d04a5da2328
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:30:52 -0000

--000e0cd1a0e6fd517d04a5da2328
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> **
> no I'm saying people will use real secrets and rely on them - just as with
> OAuth 1.0
>

=)

People are going to ignore what the spec says on this.  If you read through
the mailing list threads on this topic, you'll notice several people have
stated quite clearly that they are going to be baking secrets into installed
applications, and that they think they have reasonable mitigations in place
for the security risk.

It's not that those people are dumb, either.  They understand exactly what
they are doing.  And their native applications are not going to be any less
secure because of the choices they are making.

--000e0cd1a0e6fd517d04a5da2328
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <=
torsten@lodderstedt.net><=
/span> wrote:



 =20
   =20
 =20
  

    no I'm saying people will use real secrets and rely on them - just
    as with OAuth 1.0 

=3D)
=


People are going to ignore what the spec says on this. =
=A0If you read through the mailing list threads on this topic, you'll n=
otice several people have stated quite clearly that they are going to be ba=
king secrets into installed applications, and that they think they have rea=
sonable mitigations in place for the security risk.



It's not that those people are dumb, either. =A0The=
y understand exactly what they are doing. =A0And their native applications =
are not going to be any less secure because of the choices they are making.=





--000e0cd1a0e6fd517d04a5da2328--

From torsten@lodderstedt.net  Thu Jun 16 13:49:56 2011
Return-Path: 
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 3D51F11E80E5 for ; Thu, 16 Jun 2011 13:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.223
X-Spam-Level: 
X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viiSWr+vHZN8 for ; Thu, 16 Jun 2011 13:49:53 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id C66D411E82E8 for ; Thu, 16 Jun 2011 13:49:52 -0700 (PDT)
Received: from [87.142.242.63] (helo=[192.168.71.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXJVe-0003Ut-Vk; Thu, 16 Jun 2011 22:49:51 +0200
Message-ID: <4DFA6C76.8050601@lodderstedt.net>
Date: Thu, 16 Jun 2011 22:49:58 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Brian Eaton 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net>		<4DFA5FEF.90201@lodderstedt.net>		<4DFA621B.7060904@lodderstedt.net>		<4DFA66B5.1090205@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090107020100070705080609"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:49:56 -0000

This is a multi-part message in MIME format.
--------------090107020100070705080609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 16.06.2011 22:30, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt 
> > wrote:
>
>     no I'm saying people will use real secrets and rely on them - just
>     as with OAuth 1.0
>
>
> =)
>
> People are going to ignore what the spec says on this.  If you read 
> through the mailing list threads on this topic, you'll notice several 
> people have stated quite clearly that they are going to be baking 
> secrets into installed applications, and that they think they have 
> reasonable mitigations in place for the security risk.
>
> It's not that those people are dumb, either.  They understand exactly 
> what they are doing.  And their native applications are not going to 
> be any less secure because of the choices they are making.

If those people have reasonable means in place to protect secrets on 
deployment channels and in the local installation - fine. I would be 
eager to learn more about those means because I would be willed to 
utilize them as well.

My current assumption is that in a open market scenario secrets can be 
reverse engineered from binary or source code. Since the same secret is 
used for all installations of the same software, an attacker can utilize 
it to built a counterfeit app. Because of this risk, I would not 
recommend to rely on the secret for authenticating such an app.

The situation may vary for corporate/enterprise scenarios, where an 
application can be installed by an administrator and equiped with an 
installation specific id/secret during this process. In that case, the 
authz server can rely on the secret for authenticating and authorizing 
the client.

That's why the security considerations section states:

    ... The authorization server MAY issue
    a client password or other credentials for a specific installation of
    a native application on a specific device.

regards,
Torsten.

--------------090107020100070705080609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Am 16.06.2011 22:30, schrieb Brian Eaton:
    
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
      wrote:

      

        

          
 no I'm saying people
            will use real secrets and rely on them - just as with OAuth
            1.0 

          

        

        


        

        
=)

        


        

        
People are going to ignore what the spec says on this.  If
          you read through the mailing list threads on this topic,
          you'll notice several people have stated quite clearly that
          they are going to be baking secrets into installed
          applications, and that they think they have reasonable
          mitigations in place for the security risk.

        


        

        
It's not that those people are dumb, either.  They
          understand exactly what they are doing.  And their native
          applications are not going to be any less secure because of
          the choices they are making.

      

    

    

    If those people have reasonable means in place to protect secrets on
    deployment channels and in the local installation - fine. I would be
    eager to learn more about those means because I would be willed to
    utilize them as well.

    

    My current assumption is that in a open market scenario secrets can
    be reverse engineered from binary or source code. Since the same
    secret is used for all installations of the same software, an
    attacker can utilize it to built a counterfeit app. Because of this
    risk, I would not recommend to rely on the secret for authenticating
    such an app.

    

    The situation may vary for corporate/enterprise scenarios, where an
    application can be installed by an administrator and equiped with an
    installation specific id/secret during this process. In that case,
    the authz server can rely on the secret for authenticating and
    authorizing the client.

    

    That's why the security considerations section states:

    
   ... The authorization server MAY issue
   a client password or other credentials for a specific installation of
   a native application on a specific device.

    regards,

    Torsten.

  


--------------090107020100070705080609--

From beaton@google.com  Thu Jun 16 13:51:56 2011
Return-Path: 
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 847F111E80E5 for ; Thu, 16 Jun 2011 13:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLnRu1Iwawtp for ; Thu, 16 Jun 2011 13:51:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54B11E8146 for ; Thu, 16 Jun 2011 13:51:55 -0700 (PDT)
Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p5GKpsGU032569 for ; Thu, 16 Jun 2011 13:51:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308257515; bh=JX480NbmPElViNj+V9rRz0LSeVU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Zra2/CcI8du/HiXf0vkF67xsp/xJ9B9x+XoDSrM0mzz5TNHF2nHyVrnFgCpnT5FnG 5n9FAjIobbysnOhN9IJ0A==
Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by hpaq6.eem.corp.google.com with ESMTP id p5GKokU2028984 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 13:51:53 -0700
Received: by pwi6 with SMTP id 6so1223651pwi.18 for ; Thu, 16 Jun 2011 13:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O1kjvQ7ROOP2j1oUAu9BVkiHzLyqQuALXN5blZO3Z7I=; b=IJl3aOCfGW3i4p6i5CoJbjOWtw4CCJPO0UNNFI1XH9Bx+asruYHQMjEfS/7vflr7kg dbPj3LBPb+OQX/E3OK7w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G/Y6QR88Oc3LEiLh9tNzVDF/JcAx8UgqWmpEh9zAkE9Cns8+iCgkE3kHVFtzEO/PVR U1KCh5q9LnrnrzFM4ofw==
MIME-Version: 1.0
Received: by 10.142.61.7 with SMTP id j7mr214771wfa.266.1308257512750; Thu, 16 Jun 2011 13:51:52 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 13:51:52 -0700 (PDT)
In-Reply-To: <4DFA6C76.8050601@lodderstedt.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>  <4DFA6C76.8050601@lodderstedt.net>
Date: Thu, 16 Jun 2011 13:51:52 -0700
Message-ID: 
From: Brian Eaton 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001636e0a4e4527d2604a5da70fe
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 20:51:56 -0000

--001636e0a4e4527d2604a5da70fe
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> **
> If those people have reasonable means in place to protect secrets on
> deployment channels and in the local installation - fine. I would be eager
> to learn more about those means because I would be willed to utilize them as
> well.
>

No, they don't have anything that really protects the secrets.  They are
just willing to accept the risk.

In particular, they realize that having the client application present a
secret doesn't increase the risk at all.

--001636e0a4e4527d2604a5da70fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <=
torsten@lodderstedt.net><=
/span> wrote:



 =20
   =20
 =20
  
If those people have reasonable=
 means in place to protect secrets on
    deployment channels and in the local installation - fine. I would be
    eager to learn more about those means because I would be willed to
    utilize them as well.

No, the=
y don't have anything that really protects the secrets. =A0They are jus=
t willing to accept the risk.

In particular, they =
realize that having the client application present a secret doesn't inc=
rease the risk at all.




--001636e0a4e4527d2604a5da70fe--

From igor.faynberg@alcatel-lucent.com  Thu Jun 16 14:15:01 2011
Return-Path: 
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 3D49F11E82FD for ; Thu, 16 Jun 2011 14:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfTg4Uricql4 for ; Thu, 16 Jun 2011 14:15:00 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 08FBC11E82A2 for ; Thu, 16 Jun 2011 14:14:59 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5GLExZD003040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Jun 2011 16:14:59 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5GLEwdZ014100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Jun 2011 16:14:59 -0500
Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5GLEvX3022932; Thu, 16 Jun 2011 16:14:58 -0500 (CDT)
Message-ID: <4DFA7251.9060602@alcatel-lucent.com>
Date: Thu, 16 Jun 2011 17:14:57 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net>		<4DFA5FEF.90201@lodderstedt.net>		<4DFA621B.7060904@lodderstedt.net>		<4DFA66B5.1090205@lodderstedt.net>		<4DFA6C76.8050601@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060609070103050004070005"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 21:15:01 -0000

This is a multi-part message in MIME format.
--------------060609070103050004070005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 6/16/2011 4:51 PM, Brian Eaton wrote:
> On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt 
> > wrote:
>
>     If those people have reasonable means in place to protect secrets
>     on deployment channels and in the local installation - fine. I
>     would be eager to learn more about those means because I would be
>     willed to utilize them as well.
>
>
> No, they don't have anything that really protects the secrets.  They 
> are just willing to accept the risk.
And what about the people who are not willing to accept the risk?  (I am 
one of them!)

Igor

>
>

--------------060609070103050004070005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    

    On 6/16/2011 4:51 PM, Brian Eaton wrote:
    
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
      wrote:

      

        

          
If those people have
            reasonable means in place to protect secrets on deployment
            channels and in the local installation - fine. I would be
            eager to learn more about those means because I would be
            willed to utilize them as well.

          

        

        


        

        
No, they don't have anything that really protects the
          secrets.  They are just willing to accept the risk.

      

    

    And what about the people who are not willing to accept the risk? 
    (I am one of them!)

    

    Igor

    

    

      

        


        

        

      

      

    

  


--------------060609070103050004070005--

From igor.faynberg@alcatel-lucent.com  Thu Jun 16 14:16:34 2011
Return-Path: 
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 CC83A11E8234 for ; Thu, 16 Jun 2011 14:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4-u2Tuj6iTP for ; Thu, 16 Jun 2011 14:16:34 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD111E82A2 for ; Thu, 16 Jun 2011 14:16:33 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5GLGXjq004065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Jun 2011 16:16:33 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5GLGWgC004501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Jun 2011 16:16:33 -0500
Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5GLGW1e024376; Thu, 16 Jun 2011 16:16:32 -0500 (CDT)
Message-ID: <4DFA72B0.8080309@alcatel-lucent.com>
Date: Thu, 16 Jun 2011 17:16:32 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>		<4DFA5C9A.7060403@lodderstedt.net>		<4DFA5FEF.90201@lodderstedt.net>		<4DFA621B.7060904@lodderstedt.net>		<4DFA66B5.1090205@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090301020601050504070206"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 21:16:34 -0000

This is a multi-part message in MIME format.
--------------090301020601050504070206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I agree with the factual information, but I disagree with the conclusion.

Indeed, there were postings from people who will "bake secrets into 
installed applications."  But there have also been postings from people 
(like Torsten and me) who said they "will use real secrets and rely on 
them."

I don't see why the latter group has to be ignored, but I surely 
disagree that "people are going to ignore what the spec says on this."

Igor


On 6/16/2011 4:30 PM, Brian Eaton wrote:
> On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt 
> > wrote:
>
>     no I'm saying people will use real secrets and rely on them - just
>     as with OAuth 1.0
>
>
> =)
>
> People are going to ignore what the spec says on this.  If you read 
> through the mailing list threads on this topic, you'll notice several 
> people have stated quite clearly that they are going to be baking 
> secrets into installed applications, and that they think they have 
> reasonable mitigations in place for the security risk.
>
> It's not that those people are dumb, either.  They understand exactly 
> what they are doing.  And their native applications are not going to 
> be any less secure because of the choices they are making.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------090301020601050504070206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    I agree with the factual information, but I disagree with the
    conclusion. 

    

    Indeed, there were postings from people who will "bake secrets into
    installed applications."  But there have also been postings from
    people (like Torsten and me) who said they "will use real secrets
    and rely on them."

    

    I don't see why the latter group has to be ignored, but I surely
    disagree that "people are going to ignore what the spec says on
    this."  

    

    Igor

    

    

    On 6/16/2011 4:30 PM, Brian Eaton wrote:
    
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
      wrote:

      

        

          
 no I'm saying people
            will use real secrets and rely on them - just as with OAuth
            1.0 

          

        

        


        

        
=)

        


        

        
People are going to ignore what the spec says on this.  If
          you read through the mailing list threads on this topic,
          you'll notice several people have stated quite clearly that
          they are going to be baking secrets into installed
          applications, and that they think they have reasonable
          mitigations in place for the security risk.

        


        

        
It's not that those people are dumb, either.  They
          understand exactly what they are doing.  And their native
          applications are not going to be any less secure because of
          the choices they are making.

      

      

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


    

  


--------------090301020601050504070206--

From beaton@google.com  Thu Jun 16 15:11:08 2011
Return-Path: 
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 2148511E81A8 for ; Thu, 16 Jun 2011 15:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.961
X-Spam-Level: 
X-Spam-Status: No, score=-105.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mmsq6w96TKV for ; Thu, 16 Jun 2011 15:11:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3064211E819E for ; Thu, 16 Jun 2011 15:11:05 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5GMAsTb019862 for ; Thu, 16 Jun 2011 15:10:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308262254; bh=gldCfUEOUGhb7+5IM9YrJJD/SI0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QrNel5cCNpZhfK2O0s1nYjVhcPkr/BiPNzXNYuEh8k84GrjYNwjnlKS5qfgXRqIHT W60+GZ4fUv5RhmJ4mZLmA==
Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq7.eem.corp.google.com with ESMTP id p5GMAlra007043 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 15:10:52 -0700
Received: by pwi5 with SMTP id 5so1053805pwi.31 for ; Thu, 16 Jun 2011 15:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bxsg14JfGRqf9eTF1/aB+8zsmvmK3PB8RADjTXVkkYA=; b=f9pVdb/kva3doxyJl8DEClsej4pzHQzVY+7Gr7GQYm1N/jTi2aUTvJEoXTBUNUB0Sm bdjLa/jaMZcYer9e2Dxw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dNyomUE8RVuG6ShYikiCVcgR2QZy1onlP1ND4Dx9JIwGhsdpMgsqdsySxHnX23iyh5 1UrmUajtZ4B6vW+Ctn4A==
MIME-Version: 1.0
Received: by 10.142.52.3 with SMTP id z3mr312606wfz.95.1308262247072; Thu, 16 Jun 2011 15:10:47 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Thu, 16 Jun 2011 15:10:46 -0700 (PDT)
In-Reply-To: <4DFA7251.9060602@alcatel-lucent.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>  <4DFA6C76.8050601@lodderstedt.net>  <4DFA7251.9060602@alcatel-lucent.com>
Date: Thu, 16 Jun 2011 15:10:46 -0700
Message-ID: 
From: Brian Eaton 
To: igor.faynberg@alcatel-lucent.com
Content-Type: multipart/alternative; boundary=000e0cd2117e8285b804a5db8afa
X-System-Of-Record: true
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 22:11:08 -0000

--000e0cd2117e8285b804a5db8afa
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg <
igor.faynberg@alcatel-lucent.com> wrote:

> **
>
>
> On 6/16/2011 4:51 PM, Brian Eaton wrote:
>
> On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> If those people have reasonable means in place to protect secrets on
>> deployment channels and in the local installation - fine. I would be eager
>> to learn more about those means because I would be willed to utilize them as
>> well.
>>
>
>  No, they don't have anything that really protects the secrets.  They are
> just willing to accept the risk.
>
> And what about the people who are not willing to accept the risk?  (I am
> one of them!)
>

If you aren't willing to accept the risk of native apps that can't keep
secrets, don't support such apps.  You're done.

What the spec says does not impact what risk you need to take on.

--000e0cd2117e8285b804a5db8afa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg <igor.faynberg@alcatel-lucent.=
com> wrote:



 =20
   =20
 =20
  

    

    

    On 6/16/2011 4:51 PM, Brian Eaton wrote:
    
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodd=
erstedt <torsten@lodderstedt.net>
      wrote:

      

        

          
If those people have
            reasonable means in place to protect secrets on deployment
            channels and in the local installation - fine. I would be
            eager to learn more about those means because I would be
            willed to utilize them as well.

          

        

        


        

        
No, they don't have anything that really protects the
          secrets. =A0They are just willing to accept the risk.

      

    

    And what about the people who are not willing to accept the risk?=A0
    (I am one of them!)

If you ar=
en't willing to accept the risk of native apps that can't keep secr=
ets, don't support such apps. =A0You're done.



What the spec says does not impact what risk you need to take on.



=A0


--000e0cd2117e8285b804a5db8afa--

From wmills@yahoo-inc.com  Thu Jun 16 16:23:41 2011
Return-Path: 
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 956C111E80A0 for ; Thu, 16 Jun 2011 16:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+eyxJ6GPu+P for ; Thu, 16 Jun 2011 16:23:40 -0700 (PDT)
Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id 4DFB311E8089 for ; Thu, 16 Jun 2011 16:23:40 -0700 (PDT)
Received: from [98.139.91.68] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 23:23:38 -0000
Received: from [98.139.91.13] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 23:23:38 -0000
Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 23:23:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 9181.15612.bm@omp1013.mail.sp2.yahoo.com
Received: (qmail 23334 invoked by uid 60001); 16 Jun 2011 23:23:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1308266617; bh=TUp3ACJgjr/JTYv6m2bsJ+HIeUSmAntGJPW9SG2Qtz4=; 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=d11PFkO3NbwL2CvoQxmrJ7S9phjkYbbR37QZsZGAcRAzb7wMbsT4fXPBzNwcm7f9Lgk8rskAPPYaYUgA860qfMkAB00oxwGMPxC5w0PJfz5dMm7iSR9HQIGOH/JVaKFFYmu2YN/3oCfNdiVDvP/XflVd9UTwvfzdt0wF9jC8gI4=
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=aFkMUy1jYn0AcHoXbz7jzZTHf8Cjwzy9fjOdlFhtjsPvsF6CVE9hn8o2EUsyAOiXMlwCpFnfx1VeltbhAF0wV+0QSPtDQ4Xzm5eXYGhuT8++SRGlh1F0VWh2caUcMzOOvU3k4HqJs9RXdHk5lDpTpSKKXeqApUXZWPmW1ad8uaE=;
X-YMail-OSG: K5G6T.4VM1m4fqHsxatJsMTbCPZ_sTAW7H4NN9LY2WTj9AI UiNgDfOKtV7RKdqhbQmmtBhMFY.7wVRLTU23vmervz_2k7qRT1h.M80dkzcm TPkqAFZM.TBQc5pRhvVwo.UjewQ5c5XR_kKw55KX42fncbOSxLhB3uHsVRgc 9c2CZetgSU6YNqT9jtzkMm37rz7VijmHjo.9QjxhhBlAWZoJXKMUnqxg5qaZ cmjQxo.Dc3Q0OBqUMsRFiITaACrekBaHX4mL4yQCZAv0sHDlCJ86OYLbddmD jfgHXwkL9AZYr1mLgL_HvYxxo2HtYedp5ii57u6Qpen1.wEp_QMABOlV8ze9 b2KceCAGtJ1a2Atbbqfo7WK9CtYQkI3moJp.f6XoZQ4JVNyUsbFRy6pbdCBZ WodzFUk7O5StKFI0AT9Ijw7WcTw2g34.wnKB6F9k32Wbli1MKzgLeY9uOMRC QqRuTqfoGfBjskCWm0ua42UV6dZAHhJblSiONaw7MDDEAGj1cHl3VAVWMPKN KPFnPFqKri8Vm5.Gq._2jHg--
Received: from [216.145.52.206] by web31811.mail.mud.yahoo.com via HTTP; Thu, 16 Jun 2011 16:23:37 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Message-ID: <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Thu, 16 Jun 2011 16:23:37 -0700 (PDT)
From: "William J. Mills" 
To: Eran Hammer-Lahav , Phil Hunt ,  "Manger, James H" 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1514146131-1308266617=:96163"
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jun 2011 23:23:41 -0000

--0-1514146131-1308266617=:96163
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Probably defining a token type of "multiple_tokens" would be my preference,=
 and if you get that back then you have to parse an array of {type, token}*=
.=A0 What that array looks like could be JSON in the payload, or something =
else.=A0 That leaves the single token use case alone.=0A=0A=0A=0A__________=
______________________=0AFrom: Eran Hammer-Lahav =0ATo=
: Phil Hunt ; "Manger, James H" =0ACc: OAuth WG =0ASent: Wednesday, June 15, 20=
11 10:46 PM=0ASubject: Re: [OAUTH-WG] issuing multiple tokens=0A=0AIt is no=
t an important enough feature. Parsing an array response when 99.99% will b=
e a single object array is annoying. Also, what would you return in case of=
 error? A single object? What is the client supposed to do if it gets an em=
pty array? Array with more than one token?=0A=0A*This* would be the hack...=
 If this is something people want to deploy, a full proposal end-to-end is =
required. And not now.=0A=0AEHL=0A=0A=0A> -----Original Message-----=0A> Fr=
om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A> Of=
 Phil Hunt=0A> Sent: Wednesday, June 15, 2011 10:40 PM=0A> To: Manger, Jame=
s H=0A> Cc: OAuth WG=0A> Subject: Re: [OAUTH-WG] issuing multiple tokens=0A=
> =0A> +1=0A> =0A> Phil=0A> =0A> @independentid=0A> www.independentid.com=
=0A> phil.hunt@oracle.com=0A> =0A> =0A> =0A> =0A> =0A> On 2011-06-15, at 10=
:01 PM, Manger, James H wrote:=0A> =0A> > Torsten Lodderstedt needs to issu=
e multiple tokens; Igor Faynberg said +1=0A> to that; John Bradley identifi=
ed that OpenID Connect needs to request=0A> multiple tokens; Eran Hammer-La=
hav even mentioned a no-token flow as=0A> something that could make sense; =
...=0A> >=0A> > Issuing 0, 1 or more tokens looks like an important enough =
feature to fix=0A> now, instead of trying to hack it in after the spec is f=
inalised.=0A> >=0A> >=0A> > Changing the access token response [5.1] to be =
a JSON array of JSON=0A> objects (one JSON object per issued token) seems l=
ike a simple way to get=0A> this important functionality -- with very limit=
ed overhead for services that will=0A> only ever issue a single token, and =
client written just for those services.=0A> >=0A> > P.S. Does Facebook retu=
rn a JSON object for its access token response (as=0A> in draft-ietf-oauth-=
v2-12 that they reference), or x-www-form-urlencoded=0A> as the example at =
http://developers.facebook.com/docs/authentication/=0A> implies [4th screen=
 shot down]?=0A> >=0A> > --=0A> > James Manger=0A> >=0A> >=0A> > Eran said =
(on a different thread):=0A> >=0A> > ...if the client can authenticate with=
 the authorization server. Why not just=0A> include the client identifier a=
nd user identifier and let the authorization=0A> server lookup what the use=
r already authorized?=0A> >=0A> >=0A> > Igor Faynberg wrote:=0A> >=0A> > +1=
=0A> >=0A> > Torsten Lodderstedt wrote:=0A> >> Hi,=0A> >>=0A> >> I also see=
 the need to request and issue multiple tokens in a single=0A> >> authoriza=
tion process. There has already been some discussion about=0A> >> this topi=
c roughly a year ago:=0A> >> - http://www.ietf.org/mail-archive/web/oauth/c=
urrent/msg02688.html.=0A> >> - http://www.ietf.org/mail-archive/web/oauth/c=
urrent/msg03639.html=0A> >>=0A> >> We at Deutsche Telekom have implemented =
an OAuth 2.0 extension=0A> >> supporting that use case. It's called "bulk a=
uthorization".=0A> >>=0A> >> Would that be an interessting topic we could d=
iscuss at IETF-81 for=0A> >> the re-chartering?=A0 I could present our appr=
oach there.=0A> >>=0A> >> regards,=0A> >> Torsten.=0A> >=0A> >> Am 10.06.20=
11 21:08, schrieb John Bradley:=0A> >>> We have identified the need to requ=
est multiple tokens as one issue=0A> >>> that we would have to extend.=0A> =
> _______________________________________________=0A> > OAuth mailing list=
=0A> > OAuth@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/oauth=0A>=
 =0A> _______________________________________________=0A> OAuth mailing lis=
t=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A____=
___________________________________________=0AOAuth mailing list=0AOAuth@ie=
tf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--0-1514146131-1308266617=:96163
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Probably defining a token type of "multiple_tokens" would be my preferenc=
e, and if you get that back then you have to parse an array of {type, token=
}*.  What that array looks like could be JSON in the payload, or somet=
hing else.  That leaves the single token use case alone.

From: Era=
n Hammer-Lahav <eran@hueniverse.com>
To: Phil Hunt <phil.hunt@oracle.com>; "Manger, Ja=
mes H" <James.H.Manger@team.telstra.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Wednesday, June 15, 2011 10:46 PM
=
Subject: Re: [OAUTH-WG] is=
suing multiple tokens

=0AIt is not an important enough featur=
e. Parsing an array response when 99.99% will be a single object array is a=
nnoying. Also, what would you return in case of error? A single object? Wha=
t is the client supposed to do if it gets an empty array? Array with more t=
han one token?

*This* would be the hack... If this is something peop=
le want to deploy, a full proposal end-to-end is required. And not now.
=

EHL


> -----Original Message-----
> From: o=
auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B=
ehalf
> Of Phil Hunt
> Sent: Wednesday, June 15, 2011 10:40 PM<=
br>> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUT=
H-WG] issuing multiple tokens
> 
> +1
> 
> Phil
=
> 
> @independentid
> www.independentid.=
com
> phil.hunt@oracle.com
> 
> 
> > 
> 
> On 2011-06-15, at 10:01 PM, Manger, James H wrote:<=
br>> 
> > Torsten Lodderstedt needs to issue multiple tokens; I=
gor Faynberg said +1
> to that; John Bradley identified that OpenID C=
onnect needs to request
> multiple tokens; Eran Hammer-Lahav even men=
tioned a no-token flow as
> something that could make sense; ...
&=
gt; >
> > Issuing 0, 1 or more tokens looks like an important e=
nough feature to fix
> now, instead of trying to hack it in after the=
 spec is finalised.
> >
> >
> > Changing the acc=
ess token response [5.1] to be a JSON array of JSON
> objects (one JS=
ON object per issued token) seems like a simple way to get
> this
 important functionality -- with very limited overhead for services that wi=
ll
> only ever issue a single token, and client written just for thos=
e services.
> >
> > P.S. Does Facebook return a JSON obje=
ct for its access token response (as
> in draft-ietf-oauth-v2-12 that=
 they reference), or x-www-form-urlencoded
> as the example at http:/=
/developers.facebook.com/docs/authentication/
> implies [4th screen s=
hot down]?
> >
> > --
> > James Manger
> &=
gt;
> >
> > Eran said (on a different thread):
> &g=
t;
> > ...if the client can authenticate with the authorization se=
rver. Why not just
> include the client identifier and user identifie=
r and let the authorization
> server lookup what the user already aut=
horized?
> >
> >
> > Igor Faynberg wrote:
>=
; >
> > +1
> >
> > Torsten Lodderstedt
 wrote:
> >> Hi,
> >>
> >> I also see t=
he need to request and issue multiple tokens in a single
> >> a=
uthorization process. There has already been some discussion about
> =
>> this topic roughly a year ago:
> >> - http://www.ietf.=
org/mail-archive/web/oauth/current/msg02688.html.
> >> - http:/=
/www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> >>=

> >> We at Deutsche Telekom have implemented an OAuth 2.0 exte=
nsion
> >> supporting that use case. It's called "bulk authoriz=
ation".
> >>
> >> Would that be an interessting top=
ic we could discuss at IETF-81 for
> >> the re-chartering? =
; I could present our approach there.
> >>
> >> reg=
ards,
> >> Torsten.
> >
> >> Am 10.06.2011=
 21:08, schrieb John Bradley:
> >>> We have
 identified the need to request multiple tokens as one issue
> >&g=
t;> that we would have to extend.
> > _________________________=
______________________
> > OAuth mailing list
> > OAuth@ietf.org=

> > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> OAuth mailin=
g list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau=
th
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<=
br>

--0-1514146131-1308266617=:96163--

From James.H.Manger@team.telstra.com  Thu Jun 16 17:40:43 2011
Return-Path: 
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 4B9B911E80BF for ; Thu, 16 Jun 2011 17:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfY8z4VGyv-k for ; Thu, 16 Jun 2011 17:40:42 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6D13F1F0C3B for ; Thu, 16 Jun 2011 17:40:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,378,1304258400"; d="scan'208";a="40354048"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 17 Jun 2011 10:40:40 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6379"; a="29243892"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccni.tcif.telstra.com.au with ESMTP; 17 Jun 2011 10:40:40 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 17 Jun 2011 10:40:39 +1000
From: "Manger, James H" 
To: "oauth@ietf.org" 
Date: Fri, 17 Jun 2011 10:40:36 +1000
Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type
Thread-Index: AcwsLiJnxSKchXmsRAWfG/8rejmu9wATbQFA
Message-ID: <255B9BB34FB7D647A506DC292726F6E112869E49BC@WSMSG3153V.srv.dir.telstra.com>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4DE541B5.6080605@aol.com>  <4E1F6AAD24975D4BA5B16804296739433810E906@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B03@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <1308232867.29889.131.camel@ground>
In-Reply-To: <1308232867.29889.131.camel@ground>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 00:40:43 -0000

> If we're changing the bearer token's name, are we going to change the
> parameter name inside of MAC as well? At the moment, it's "id", which
> I've always found an odd naming choice.
>
> I would argue for consistency across the three main documents.


OAuth2 should be consistent with the authentication schemes for which it dy=
namically issues credentials - not the other way around.

The root cause of the naming inconsistencies is that OAuth2 puts a massive =
focus on "Access Token", instead of on "Dynamically-issued credentials".

An "access token response" is a dynamically-issued credential. First you ne=
ed to know the type of credential (token_type), then you need any extra val=
ues specific to that type. [Plus you need metadata about the credentials (e=
xpires_in, scope, how/where to renew/revoke, where to use!!).]

For the BEARER type you need: token.
For the MAC type you need: id, key, algorithm, issue time.
For the BASIC type you need: username, password.
For the TLS client cert type you need: certificate, private key.
...

The MAC spec defines mac_key and mac_algorithm fields, but uses the access_=
token label instead of defining a mac_id field. It has to because OAuth2 tr=
eats access_token as a central concept, instead of a credential-specific fi=
eld.

I am sure developers would more easily understand (get a better mental mode=
l) if an "access token responses" looked like the following examples:
 {"type":"bearer", "token":"SlAV32hkKG", ...}
 {"type":"mac", "id":"SlAV32hkKG", "key":"adijq39jdlaska9asud", "algorithm"=
:"hmac-sha-256", ...}

Is it worth clarifying?
Probably, for clarity in the long term.
But obviously there has been a huge amount invested in the current "access =
token" focus. I am certainly not going to object to the much simpler fix of=
 renaming bearer_token to access_token.

--
James Manger

From James.H.Manger@team.telstra.com  Thu Jun 16 21:04:07 2011
Return-Path: 
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 A5EB111E816D for ; Thu, 16 Jun 2011 21:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXpjEA92c4bo for ; Thu, 16 Jun 2011 21:04:05 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6C11E80F2 for ; Thu, 16 Jun 2011 21:04:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,379,1304258400"; d="scan'208,217";a="36202394"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 17 Jun 2011 14:04:04 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6379"; a="29134673"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcdvi.tcif.telstra.com.au with ESMTP; 17 Jun 2011 14:04:01 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 17 Jun 2011 14:04:02 +1000
From: "Manger, James H" 
To: OAuth WG 
Date: Fri, 17 Jun 2011 14:04:01 +1000
Thread-Topic: [OAUTH-WG] issuing multiple tokens
Thread-Index: AcwsfG6aCmqVi9kLSLuude8GYJnWzQADdPxQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com>
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11286A56A2CWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 04:04:07 -0000

--_000_255B9BB34FB7D647A506DC292726F6E11286A56A2CWSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> [Issuing multiple tokens] is not an important enough feature. Parsing an =
array response when

> 99.99% will be a single object array is annoying.



I would agree... if I believed the 99.99%, but not if it will be 80% and fa=
lling in a year or two.



A major benefit of OAuth2 is that resource servers only handle limited-life=
time, limited-capability access tokens so there is limited damage and easie=
r recovery if one resource service is compromised. If the same access token=
 works at all the resource servers that a client app uses, then an attacker=
 that compromises one resource server can re-use the access tokens elsewher=
e. The bigger your portfolio of services, the worse the risk.



> Also, what would you return in case of error? A single object?



Yes. It is not that hard to test if JSON.parse(...) returns an array or a s=
ingle object with an error field, or to notice the 4xx status code.



> What is the client supposed to do if it gets an empty array?



The delegation succeeded, but you don't need to use temporary credentials (=
perhaps client auth is sufficient, perhaps a [MAC] cookie was issued, perha=
ps the service is using URIs-as-capabilities...). Continue on to use the AP=
I.



> Array with more than one token?



If the client app hasn't bothered to write the extra code to handle multipl=
e tokens then it just uses the first token. If separate tokens are now need=
ed for servers that previously shared the same token, then the service has =
made a deliberate decision to increase security in a way that wasn't backwa=
rdly compatible.



> *This* would be the hack... If this is something people want to deploy,

> a full proposal end-to-end is required. And not now.



I few proposals have been made in the past. Some try hard to leave the sing=
le token case alone, but always at a cost to complexity: eg the first token=
 needs to be handled differently to the other tokens.





Responding to William Mills' comments:

>> Probably defining a token type of "multiple_tokens" would be my preferen=
ce,

>> and if you get that back then you have to parse an array of {type, token=
}*.

>>  What that array looks like could be JSON in the payload, or something e=
lse.

>>  That leaves the single token use case alone.



This is a good example of how it is awkward to add multiple token support l=
ater.

With this suggestion a service that starts issuing multiple tokens (eg for =
clients to access an enhanced version of an API) can't just add an extra to=
ken for the enhanced API that old clients will ignore. Instead, it has to c=
hange the top-level token_type, which will fail in all old clients. It also=
 leaves other top-level mandatory fields such as access_token with confusin=
g semantics.





--

James Manger


--_000_255B9BB34FB7D647A506DC292726F6E11286A56A2CWSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











> [Issuing multiple t=
okens] is not an important enough feature. Parsing an array response when


> 99.99% will be a si=
ngle object array is annoying.


 =



I would agree… if =
I believed the 99.99%, but not if it will be 80% and falling in a year or t=
wo.


 =



A major benefit of OAuth=
2 is that resource servers only handle limited-lifetime, limited-capability=
 access tokens so there is limited damage and easier recovery if one resour=
ce service is compromised. If the same
 access token works at all the resource servers that a client app uses, the=
n an attacker that compromises one resource server can re-use the access to=
kens elsewhere. The bigger your portfolio of services, the worse the risk.<=
o:p>


 =



> Also, what would yo=
u return in case of error? A single object?


 =



Yes. It is not that hard=
 to test if JSON.parse(…) returns an array or a single object with an=
 error field, or to notice the 4xx status code.


 =



> What is the client =
supposed to do if it gets an empty array?


 =



The delegation succeeded=
, but you don’t need to use temporary credentials (perhaps client aut=
h is sufficient, perhaps a [MAC] cookie was issued, perhaps the service is =
using URIs-as-capabilities…). Continue on
 to use the API.


 =



> Array with more tha=
n one token?


 =



If the client app hasn&#=
8217;t bothered to write the extra code to handle multiple tokens then it j=
ust uses the first token. If separate tokens are now needed for servers tha=
t previously shared the same token, then the
 service has made a deliberate decision to increase security in a way that =
wasn’t backwardly compatible.


 =



> *This* would be the=
 hack... If this is something people want to deploy,


> a full proposal end=
-to-end is required. And not now.






I few proposals have bee=
n made in the past. Some try hard to leave the single token case alone, but=
 always at a cost to complexity: eg the first token needs to be handled dif=
ferently to the other tokens.


 =



 =



Responding to William Mi=
lls’ comments:


>> Probably defini=
ng a token type of "multiple_tokens" would be my preference,=



>> and if you get =
that back then you have to parse an array of {type, token}*.


>>  What that=
 array looks like could be JSON in the payload, or something else.


>>  That leav=
es the single token use case alone.


 =



This is a good example o=
f how it is awkward to add multiple token support later.<=
/p>

With this suggestion a s=
ervice that starts issuing multiple tokens (eg for clients to access an enh=
anced version of an API) can’t just add an extra token for the enhanc=
ed API that old clients will ignore. Instead,
 it has to change the top-level token_type, which will fail in all old clie=
nts. It also leaves other top-level mandatory fields such as access_token w=
ith confusing semantics.


 


 




--


James Manger








--_000_255B9BB34FB7D647A506DC292726F6E11286A56A2CWSMSG3153Vsrv_--

From eran@hueniverse.com  Thu Jun 16 22:26:16 2011
Return-Path: 
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 8DAD511E809F for ; Thu, 16 Jun 2011 22:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMnJ0lotD27R for ; Thu, 16 Jun 2011 22:26:14 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 1CDE611E808F for ; Thu, 16 Jun 2011 22:26:13 -0700 (PDT)
Received: (qmail 32289 invoked from network); 17 Jun 2011 05:26:13 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jun 2011 05:26:13 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 16 Jun 2011 22:26:12 -0700
From: Eran Hammer-Lahav 
To: "Manger, James H" , OAuth WG 
Date: Thu, 16 Jun 2011 22:25:47 -0700
Thread-Topic: [OAUTH-WG] issuing multiple tokens
Thread-Index: AcwsfG6aCmqVi9kLSLuude8GYJnWzQADdPxQAAktEDA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.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_90C41DD21FB7C64BB94121FBBC2E7234475E986E2DP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 05:26:16 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986E2DP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm standing behind my 99.99% projection for the next 5 years.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
anger, James H
Sent: Thursday, June 16, 2011 9:04 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] issuing multiple tokens

> [Issuing multiple tokens] is not an important enough feature. Parsing an =
array response when
> 99.99% will be a single object array is annoying.

I would agree... if I believed the 99.99%, but not if it will be 80% and fa=
lling in a year or two.

A major benefit of OAuth2 is that resource servers only handle limited-life=
time, limited-capability access tokens so there is limited damage and easie=
r recovery if one resource service is compromised. If the same access token=
 works at all the resource servers that a client app uses, then an attacker=
 that compromises one resource server can re-use the access tokens elsewher=
e. The bigger your portfolio of services, the worse the risk.

> Also, what would you return in case of error? A single object?

Yes. It is not that hard to test if JSON.parse(...) returns an array or a s=
ingle object with an error field, or to notice the 4xx status code.

> What is the client supposed to do if it gets an empty array?

The delegation succeeded, but you don't need to use temporary credentials (=
perhaps client auth is sufficient, perhaps a [MAC] cookie was issued, perha=
ps the service is using URIs-as-capabilities...). Continue on to use the AP=
I.

> Array with more than one token?

If the client app hasn't bothered to write the extra code to handle multipl=
e tokens then it just uses the first token. If separate tokens are now need=
ed for servers that previously shared the same token, then the service has =
made a deliberate decision to increase security in a way that wasn't backwa=
rdly compatible.

> *This* would be the hack... If this is something people want to deploy,
> a full proposal end-to-end is required. And not now.
I few proposals have been made in the past. Some try hard to leave the sing=
le token case alone, but always at a cost to complexity: eg the first token=
 needs to be handled differently to the other tokens.


Responding to William Mills' comments:
>> Probably defining a token type of "multiple_tokens" would be my preferen=
ce,
>> and if you get that back then you have to parse an array of {type, token=
}*.
>>  What that array looks like could be JSON in the payload, or something e=
lse.
>>  That leaves the single token use case alone.

This is a good example of how it is awkward to add multiple token support l=
ater.
With this suggestion a service that starts issuing multiple tokens (eg for =
clients to access an enhanced version of an API) can't just add an extra to=
ken for the enhanced API that old clients will ignore. Instead, it has to c=
hange the top-level token_type, which will fail in all old clients. It also=
 leaves other top-level mandatory fields such as access_token with confusin=
g semantics.


--
James Manger

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986E2DP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I’m=
 standing behind my 99.99% projection for the next 5 years.
 
EHL
&n=
bsp;
From:<=
span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, =
James H
Sent: Thursday, June 16, 2011 9:04 PM
To: OAuth=
 WG
Subject: Re: [OAUTH-WG] issuing multiple tokens
 
> [Issuing multiple tok=
ens] is not an important enough feature. Parsing an array response when
> 99.99% will be a single object array is annoying.
&n=
bsp;
I would agree… if I believed the 99.99%, but not if it will b=
e 80% and falling in a year or two.
 
A major benefit =
of OAuth2 is that resource servers only handle limited-lifetime, limited-ca=
pability access tokens so there is limited damage and easier recovery if on=
e resource service is compromised. If the same access token works at all th=
e resource servers that a client app uses, then an attacker that compromise=
s one resource server can re-use the access tokens elsewhere. The bigger yo=
ur portfolio of services, the worse the risk.
 
> A=
lso, what would you return in case of error? A single object?
=
 
Yes. It is not that hard to test if JSON.parse(…) returns a=
n array or a single object with an error field, or to notice the 4xx status=
 code.
 
> What is the client supposed to do if i=
t gets an empty array?
 
The delegation succeeded, but=
 you don’t need to use temporary credentials (perhaps client auth is =
sufficient, perhaps a [MAC] cookie was issued, perhaps the service is using=
 URIs-as-capabilities…). Continue on to use the API.
&nb=
sp;
> Array with more than one token?
 
If the=
 client app hasn’t bothered to write the extra code to handle multipl=
e tokens then it just uses the first token. If separate tokens are now need=
ed for servers that previously shared the same token, then the service has =
made a deliberate decision to increase security in a way that wasn’t =
backwardly compatible.
 
> *This* would be the hack=
... If this is something people want to deploy,
> a full proposal end-to-end is required. And not now.<=
/o:p>
I few proposals have been made in the past. Some try hard to leave the s=
ingle token case alone, but always at a cost to complexity: eg the first to=
ken needs to be handled differently to the other tokens.<=
/p>
 =
;
 
Responding to William Mills’ comments:=

&g=
t;> Probably defining a token type of "multiple_tokens" would =
be my preference,
>> and if you get that back then you have t=
o parse an array of {type, token}*.
>>  What that array =
looks like could be JSON in the payload, or something else.
>>=
;  That leaves the single token use case alone.
<=
p class=3DMsoNormal> 
This is a good example of how it is awkward to add multiple token support =
later.
With this suggestion a service that starts issuing multipl=
e tokens (eg for clients to access an enhanced version of an API) can’=
;t just add an extra token for the enhanced API that old clients will ignor=
e. Instead, it has to change the top-level token_type, which will fail in a=
ll old clients. It also leaves other top-level mandatory fields such as acc=
ess_token with confusing semantics.
 
 
--
James Manger
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475E986E2DP3PW5EX1MB01E_--

From torsten@lodderstedt.net  Thu Jun 16 22:27:50 2011
Return-Path: 
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 C30A511E809F for ; Thu, 16 Jun 2011 22:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW3PC-xQ8gYf for ; Thu, 16 Jun 2011 22:27:50 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id A938311E808F for ; Thu, 16 Jun 2011 22:27:49 -0700 (PDT)
Received: from [79.253.48.203] (helo=[192.168.71.26]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXRas-0007CO-VN; Fri, 17 Jun 2011 07:27:47 +0200
Message-ID: <4DFAE5DA.1030602@lodderstedt.net>
Date: Fri, 17 Jun 2011 07:27:54 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Thomas Hardjono 
References: 			<4DE5EE7F.4040907@lodderstedt.net>				<28715F7E-4774-4940-872B-66E512BA6091@kiva.org>		<9B083EA0-55F4-4B5C-9746-92EB1490A149@kiva.org> <4DE7510A.2000800@lodderstedt.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Text for Native Applications
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 05:27:50 -0000

Hi Thomas,

Am 02.06.2011 21:17, schrieb Thomas Hardjono:
> Hi Torsten, folks,
>
> I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and also the text of Section 9 of oath-draft16.
>
> I think there seems to be a disconnect (may be its just me).
>
> (a) Oauth2.0 today is designed for low-assurance environments. So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on.
>
> ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1
>
>
> (b) The current text of Section 9 says:
>
> ]]]] Native applications SHOULD use the authorization code
> ]]]] grant type flow without client password credentials (due to their
> ]]]] inability to keep the credentials confidential) to obtain
> ]]]] short-lived access tokens, and use refresh tokens to maintain access.
>
> When it comes to "keeping secrets" I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misunderstood the definition of a native application?

I would assume "a browser" refers to apps running within the browser. 
http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 calls them 
user-agent-based apps. For both user-agent-based and native apps, the 
text states the assumption that "The OAuth protocol data and credentials 
are accessible to the end-user.". So both are equivalent with respect to 
the topic discused in this thread. For native apps, another important 
issue is the way their client secret (today) is typically assigned and 
distributed (backed into the binary). So the same secret is accessible 
in all installations. This is considered bad practice by many people.

Web applications are quite different since the OAuth credentials are 
kept in a server under control of the service provider and not 
accessible to the end-user.

regards,
Torsten.

> Thanks.
>
> /thomas/
>
>
>
> _________________________________
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Torsten Lodderstedt
>> Sent: Thursday, June 02, 2011 5:00 AM
>> To: Skylar Woodward
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Text for Native Applications
>>
>> Dave, Skylar,
>>
>> the assumption of the OAuth 2.0 security threat model
>> (http://tools.ietf.org/html/draft-lodderstedt-oauth-security-
>> 01#section-4.1)
>> is that client secrets, which are distributed with applications, cannot
>> reliably kept confidential. Therefore the advice is given to use other
>> means to validate the client identity (e.g. user consent, platform
>> security measures).
>>
>> I would highly appreciate if you would review this document and give us
>> feedback.
>>
>> thanks in advance,
>> Torsten.
>>
>> Am 01.06.2011 22:07, schrieb Skylar Woodward:
>>> On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:
>>>
>>>> for mounting the attack.  I firmly believe that secrets can be
>>>> sufficiently obfuscated in code delivered in binary format without
>>>> the benefit of a symbol table, so as to be sufficiently resistant to
>>>> discovery via disassembly by attackers you'd expect to encounter in
>> a
>>>> typical commercial environment.  I'm not talking about printable
>>> I have empirical evidence to support this. At Yahoo! we devised one
>> of the most complex systems I've ever seen in a publicly distributed
>> program (Messenger). It was disassembled in 3 days. Scott Renfro (now
>> over with David at Facebook) and likely Bill Mills can also vouch for
>> the difficulty of this having also studied the case well.
>>> Moreover if a hardware-enforced system like that of Playstation 3 can
>> be broken, then so can most systems. The PS3 protection mechanisms
>> are/were very sophisticated.
>>> Even if a system is not yet cracked or is very hard, you have to
>> assume it can be cracked. History has shown this to be true nearly
>> without exception - at least to the point it is not worth considering
>> for the OAuth use cases.
>>> skylar
>>>
>>> _______________________________________________
>>> 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

From torsten@lodderstedt.net  Fri Jun 17 00:40:39 2011
Return-Path: 
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 6479411E80DD for ; Fri, 17 Jun 2011 00:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR6VrmQhjIfj for ; Fri, 17 Jun 2011 00:40:38 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05B11E808A for ; Fri, 17 Jun 2011 00:40:37 -0700 (PDT)
Received: from [80.67.16.116] (helo=webmailfront05.ispgateway.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QXTfN-0006cR-VU; Fri, 17 Jun 2011 09:40:34 +0200
Received: from proxy2.t-online.net (proxy2.t-online.net [195.243.113.251]) by webmail.df.eu (Horde Framework) with HTTP; Fri, 17 Jun 2011 09:40:33 +0200
Message-ID: <20110617094033.5359726zl63xc2kg@webmail.df.eu>
Date: Fri, 17 Jun 2011 09:40:33 +0200
From: Torsten Lodderstedt 
To: Eran Hammer-Lahav 
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2)
X-Originating-IP: 195.243.113.251
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 07:40:39 -0000

this is kind of a self-fulfilling prophecy. If we do not encourage  
implementors to use service-specific tokens by supporting it in OAuth  
most people will not consider it.

As James pointed out, there are good reasons to use service-specific  
tokens in multi-service environments. That's why Deutsche Telekom  
employs a strict security policy to use different tokens for different  
services. And as a multi-service provider an increasing percentage of  
our apps need to access multiple services. That's why we have  
implemented support for issuing multiple tokens in a single  
authorization flow. We will have this feature in production before  
IETF-81.

regards,
Torsten.

Zitat von Eran Hammer-Lahav :

> I'm standing behind my 99.99% projection for the next 5 years.
>
> EHL
>
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On  
> Behalf Of Manger, James H
> Sent: Thursday, June 16, 2011 9:04 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>
>> [Issuing multiple tokens] is not an important enough feature.  
>> Parsing an array response when
>> 99.99% will be a single object array is annoying.
>
> I would agree... if I believed the 99.99%, but not if it will be 80%  
> and falling in a year or two.
>
> A major benefit of OAuth2 is that resource servers only handle  
> limited-lifetime, limited-capability access tokens so there is  
> limited damage and easier recovery if one resource service is  
> compromised. If the same access token works at all the resource  
> servers that a client app uses, then an attacker that compromises  
> one resource server can re-use the access tokens elsewhere. The  
> bigger your portfolio of services, the worse the risk.
>
>> Also, what would you return in case of error? A single object?
>
> Yes. It is not that hard to test if JSON.parse(...) returns an array  
> or a single object with an error field, or to notice the 4xx status  
> code.
>
>> What is the client supposed to do if it gets an empty array?
>
> The delegation succeeded, but you don't need to use temporary  
> credentials (perhaps client auth is sufficient, perhaps a [MAC]  
> cookie was issued, perhaps the service is using  
> URIs-as-capabilities...). Continue on to use the API.
>
>> Array with more than one token?
>
> If the client app hasn't bothered to write the extra code to handle  
> multiple tokens then it just uses the first token. If separate  
> tokens are now needed for servers that previously shared the same  
> token, then the service has made a deliberate decision to increase  
> security in a way that wasn't backwardly compatible.
>
>> *This* would be the hack... If this is something people want to deploy,
>> a full proposal end-to-end is required. And not now.
> I few proposals have been made in the past. Some try hard to leave  
> the single token case alone, but always at a cost to complexity: eg  
> the first token needs to be handled differently to the other tokens.
>
>
> Responding to William Mills' comments:
>>> Probably defining a token type of "multiple_tokens" would be my preference,
>>> and if you get that back then you have to parse an array of {type, token}*.
>>>  What that array looks like could be JSON in the payload, or  
>>> something else.
>>>  That leaves the single token use case alone.
>
> This is a good example of how it is awkward to add multiple token  
> support later.
> With this suggestion a service that starts issuing multiple tokens  
> (eg for clients to access an enhanced version of an API) can't just  
> add an extra token for the enhanced API that old clients will  
> ignore. Instead, it has to change the top-level token_type, which  
> will fail in all old clients. It also leaves other top-level  
> mandatory fields such as access_token with confusing semantics.
>
>
> --
> James Manger
>





From eran@hueniverse.com  Fri Jun 17 00:46:53 2011
Return-Path: 
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 0D0B011E813A for ; Fri, 17 Jun 2011 00:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZvzsOt4goL4 for ; Fri, 17 Jun 2011 00:46:52 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5FD3911E808A for ; Fri, 17 Jun 2011 00:46:52 -0700 (PDT)
Received: (qmail 6789 invoked from network); 17 Jun 2011 07:46:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jun 2011 07:46:51 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 17 Jun 2011 00:46:51 -0700
From: Eran Hammer-Lahav 
To: Torsten Lodderstedt 
Date: Fri, 17 Jun 2011 00:46:26 -0700
Thread-Topic: [OAUTH-WG] issuing multiple tokens
Thread-Index: Acwswdx76oiIcDgKQN+tuXPIWDaotAAAEvvQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110617094033.5359726zl63xc2kg@webmail.df.eu>
In-Reply-To: <20110617094033.5359726zl63xc2kg@webmail.df.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 07:46:53 -0000

OAuth has been successful because of its simple architecture and because it=
 is based on actual deployment experience. Offering multi-token responses w=
ould be premature standardization. I am not convinced that adding it later =
would entail any real technical difficulty.

EHL=20

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Friday, June 17, 2011 12:41 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; OAuth WG
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>=20
> this is kind of a self-fulfilling prophecy. If we do not encourage implem=
entors
> to use service-specific tokens by supporting it in OAuth most people will=
 not
> consider it.
>=20
> As James pointed out, there are good reasons to use service-specific toke=
ns
> in multi-service environments. That's why Deutsche Telekom employs a stri=
ct
> security policy to use different tokens for different services. And as a =
multi-
> service provider an increasing percentage of our apps need to access
> multiple services. That's why we have implemented support for issuing
> multiple tokens in a single authorization flow. We will have this feature=
 in
> production before IETF-81.
>=20
> regards,
> Torsten.
>=20
> Zitat von Eran Hammer-Lahav :
>=20
> > I'm standing behind my 99.99% projection for the next 5 years.
> >
> > EHL
> >
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Manger, James H
> > Sent: Thursday, June 16, 2011 9:04 PM
> > To: OAuth WG
> > Subject: Re: [OAUTH-WG] issuing multiple tokens
> >
> >> [Issuing multiple tokens] is not an important enough feature.
> >> Parsing an array response when
> >> 99.99% will be a single object array is annoying.
> >
> > I would agree... if I believed the 99.99%, but not if it will be 80%
> > and falling in a year or two.
> >
> > A major benefit of OAuth2 is that resource servers only handle
> > limited-lifetime, limited-capability access tokens so there is limited
> > damage and easier recovery if one resource service is compromised. If
> > the same access token works at all the resource servers that a client
> > app uses, then an attacker that compromises one resource server can
> > re-use the access tokens elsewhere. The bigger your portfolio of
> > services, the worse the risk.
> >
> >> Also, what would you return in case of error? A single object?
> >
> > Yes. It is not that hard to test if JSON.parse(...) returns an array
> > or a single object with an error field, or to notice the 4xx status
> > code.
> >
> >> What is the client supposed to do if it gets an empty array?
> >
> > The delegation succeeded, but you don't need to use temporary
> > credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie
> > was issued, perhaps the service is using URIs-as-capabilities...).
> > Continue on to use the API.
> >
> >> Array with more than one token?
> >
> > If the client app hasn't bothered to write the extra code to handle
> > multiple tokens then it just uses the first token. If separate tokens
> > are now needed for servers that previously shared the same token, then
> > the service has made a deliberate decision to increase security in a
> > way that wasn't backwardly compatible.
> >
> >> *This* would be the hack... If this is something people want to
> >> deploy, a full proposal end-to-end is required. And not now.
> > I few proposals have been made in the past. Some try hard to leave the
> > single token case alone, but always at a cost to complexity: eg the
> > first token needs to be handled differently to the other tokens.
> >
> >
> > Responding to William Mills' comments:
> >>> Probably defining a token type of "multiple_tokens" would be my
> preference,
> >>> and if you get that back then you have to parse an array of {type,
> token}*.
> >>>  What that array looks like could be JSON in the payload, or
> >>> something else.
> >>>  That leaves the single token use case alone.
> >
> > This is a good example of how it is awkward to add multiple token
> > support later.
> > With this suggestion a service that starts issuing multiple tokens
> > (eg for clients to access an enhanced version of an API) can't just
> > add an extra token for the enhanced API that old clients will
> > ignore. Instead, it has to change the top-level token_type, which
> > will fail in all old clients. It also leaves other top-level
> > mandatory fields such as access_token with confusing semantics.
> >
> >
> > --
> > James Manger
> >
>=20
>=20
>=20


From dnelson@elbrys.com  Fri Jun 17 04:41:31 2011
Return-Path: 
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 BB2D39E8020 for ; Fri, 17 Jun 2011 04:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da6xACIC17-a for ; Fri, 17 Jun 2011 04:41:31 -0700 (PDT)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id D59569E8008 for ; Fri, 17 Jun 2011 04:41:30 -0700 (PDT)
Received: from mail-yi0-f41.google.com ([209.85.218.41]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTfs9aU9NrSqMvA/daLVT4OgAn0dhnw8l@postini.com; Fri, 17 Jun 2011 04:41:30 PDT
Received: by mail-yi0-f41.google.com with SMTP id 13so1712564yia.0 for ; Fri, 17 Jun 2011 04:41:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.29.73 with SMTP id h49mr2867836yha.453.1308310889212; Fri, 17 Jun 2011 04:41:29 -0700 (PDT)
Received: by 10.236.143.65 with HTTP; Fri, 17 Jun 2011 04:41:29 -0700 (PDT)
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>  <4DFA6C76.8050601@lodderstedt.net>  <4DFA7251.9060602@alcatel-lucent.com> 
Date: Fri, 17 Jun 2011 07:41:29 -0400
Message-ID: 
From: Dave Nelson 
To: Brian Eaton 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 11:41:31 -0000

> If you aren't willing to accept the risk of native apps that can't keep
> secrets, don't support such apps.

We continue to say "can't keep secrets".  I think what we mean is
"can't keep secrets that are embedded in the code".  One could imagine
an install-time, leap-of-faith binding to a remotely received secret,
via some on-line registration process, that the native app asks the
operating system to store for it securely.  The user can make an
assertion of trust in the validity of the app that he/she has
downloaded and is subsequently installing.  Of course, that initial
faith might be misplaced, but that's true of almost all
user-installable software, even that receive on physical media.  If
browsers are trusted to store secrets securely, then that same
capability is available to native apps.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From sweeden@au1.ibm.com  Fri Jun 17 05:20:52 2011
Return-Path: 
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 C65301F0C3B for ; Fri, 17 Jun 2011 05:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.374
X-Spam-Level: 
X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9osydiZn5bXG for ; Fri, 17 Jun 2011 05:20:52 -0700 (PDT)
Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by ietfa.amsl.com (Postfix) with ESMTP id BE6141F0C48 for ; Fri, 17 Jun 2011 05:20:46 -0700 (PDT)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp04.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5HCEULB032158 for ; Fri, 17 Jun 2011 22:14:30 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5HCJXQo1093692 for ; Fri, 17 Jun 2011 22:19:33 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5HCKZ2n024590 for ; Fri, 17 Jun 2011 22:20:36 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5HCKWZx024471; Fri, 17 Jun 2011 22:20:32 +1000
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DFA5C9A.7060403@lodderstedt.net>	 <4DFA5FEF.90201@lodderstedt.net>	 <4DFA621B.7060904@lodderstedt.net>	 <4DFA66B5.1090205@lodderstedt.net>	 <4DFA6C76.8050601@lodderstedt.net>	 <4DFA7251.9060602@alcatel-lucent.com>	 
X-KeepSent: 28B1A1F2:041BCB54-4A2578B2:004118B4; type=4; name=$KeepSent
To: Dave Nelson 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Fri, 17 Jun 2011 22:14:58 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 17/06/2011 22:23:56
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 12:20:52 -0000

As I understand it, what you've described is precisely the intent of the
refresh token. The online registration process you refer to is a
corresponding one-time authorization code flow. The authorization code
effectively becomes a one-time-use, short-lived credential for the client
instance which it should use immediately (since it has been exposed to the
resource owner via the user-agent in getting to the client) to directly
request an access token (typically short-lived and may not be needed
immediately) and refresh token (typically long-lived). The refresh token is
stored securely locally. It is essentially an instance secret bound to the
client id and representing the original resource owner grant. Provided:
1. The resource owner and user-agent safely deliver the authorization code
to the client instance in first place
2. The client uses it immediately in secure transport-level communications
to the authorization server and then securely stores the long-lived refresh
token
3. The client always uses the refresh token in secure transport-level
communications to the authorization server to get an access token (and
optionally rollover the refresh token)
.. then securely authenticating the client doesn't seem to be a big deal.

I trust "the list" will correct me if that's a wrong interpretation of a
classic native app scenario.

It still leads to my question from some posts ago about why then is it
advantageous to require client authentication at all for the authorization
code flow in classic web app three-legged scenarios, and I am yet to fully
digest Torsten's response to that (
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01). About the
only documented advantage I've seen to date has to do with the
recovery/next steps from a compromised refresh token, but the usefulness of
that idea has been debated as well.





From:	Dave Nelson 
To:	Brian Eaton 
Cc:	"oauth@ietf.org" 
Date:	17-06-11 09:45 PM
Subject:	Re: [OAUTH-WG] Client authentication requirement
Sent by:	oauth-bounces@ietf.org



> If you aren't willing to accept the risk of native apps that can't keep
> secrets, don't support such apps.

We continue to say "can't keep secrets".  I think what we mean is
"can't keep secrets that are embedded in the code".  One could imagine
an install-time, leap-of-faith binding to a remotely received secret,
via some on-line registration process, that the native app asks the
operating system to store for it securely.  The user can make an
assertion of trust in the validity of the app that he/she has
downloaded and is subsequently installing.  Of course, that initial
faith might be misplaced, but that's true of almost all
user-installable software, even that receive on physical media.  If
browsers are trusted to store secrets securely, then that same
capability is available to native apps.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



From jricher@mitre.org  Fri Jun 17 06:46:19 2011
Return-Path: 
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 A470E11E80B9 for ; Fri, 17 Jun 2011 06:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.435
X-Spam-Level: 
X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVS+a4cN7RZy for ; Fri, 17 Jun 2011 06:46:18 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0629111E80A4 for ; Fri, 17 Jun 2011 06:46:17 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFF9421B0BFF for ; Fri, 17 Jun 2011 09:46:14 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AFD6F21B0BEC for ; Fri, 17 Jun 2011 09:46:14 -0400 (EDT)
Received: from [172.31.4.213] (172.31.4.213) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 17 Jun 2011 09:46:14 -0400
Message-ID: <4DFB5AA6.7040706@mitre.org>
Date: Fri, 17 Jun 2011 09:46:14 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: 
References: 	<4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com>	<255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>		<90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------050701080800080507000904"
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 13:46:19 -0000

--------------050701080800080507000904
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I completely agree that the single-token case needs to be left alone, 
and I rather like this idea. The AS would return something like:

{
  access_token: [
     {
       access_token: "1234656",
       expires_in: 3600,
       token_type: bearer
     },
     {
       access_token: "abcdefg",
       expires_in: 3600,
       token_type: MAC,
       mac_stuff: "goes_here"
     }
   ],
   token_type: multiple
}

This would not only let clients who are doing the common one-token flow 
ignore the "multiple" token type, it would also allow for re-use of 
token storage libraries for the inner token bits. And you could go crazy 
and pass a multiple token full of multiple tokens, too. It's turtles all 
the way down!

  -- Justin

On 6/16/2011 7:23 PM, William J. Mills wrote:
> Probably defining a token type of "multiple_tokens" would be my 
> preference, and if you get that back then you have to parse an array 
> of {type, token}*.  What that array looks like could be JSON in the 
> payload, or something else.  That leaves the single token use case alone.
>
> ------------------------------------------------------------------------
> *From:* Eran Hammer-Lahav 
> *To:* Phil Hunt ; "Manger, James H" 
> 
> *Cc:* OAuth WG 
> *Sent:* Wednesday, June 15, 2011 10:46 PM
> *Subject:* Re: [OAUTH-WG] issuing multiple tokens
>
> It is not an important enough feature. Parsing an array response when 
> 99.99% will be a single object array is annoying. Also, what would you 
> return in case of error? A single object? What is the client supposed 
> to do if it gets an empty array? Array with more than one token?
>
> *This* would be the hack... If this is something people want to 
> deploy, a full proposal end-to-end is required. And not now.
>
> EHL
>
>
> > -----Original Message-----
> > From: oauth-bounces@ietf.org  
> [mailto:oauth-bounces@ietf.org ] On Behalf
> > Of Phil Hunt
> > Sent: Wednesday, June 15, 2011 10:40 PM
> > To: Manger, James H
> > Cc: OAuth WG
> > Subject: Re: [OAUTH-WG] issuing multiple tokens
> >
> > +1
> >
> > Phil
> >
> > @independentid
> > www.independentid.com 
> > phil.hunt@oracle.com 
> >
> >
> >
> >
> >
> > On 2011-06-15, at 10:01 PM, Manger, James H wrote:
> >
> > > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg 
> said +1
> > to that; John Bradley identified that OpenID Connect needs to request
> > multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
> > something that could make sense; ...
> > >
> > > Issuing 0, 1 or more tokens looks like an important enough feature 
> to fix
> > now, instead of trying to hack it in after the spec is finalised.
> > >
> > >
> > > Changing the access token response [5.1] to be a JSON array of JSON
> > objects (one JSON object per issued token) seems like a simple way 
> to get
> > this important functionality -- with very limited overhead for 
> services that will
> > only ever issue a single token, and client written just for those 
> services.
> > >
> > > P.S. Does Facebook return a JSON object for its access token 
> response (as
> > in draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded
> > as the example at http://developers.facebook.com/docs/authentication/
> > implies [4th screen shot down]?
> > >
> > > --
> > > James Manger
> > >
> > >
> > > Eran said (on a different thread):
> > >
> > > ...if the client can authenticate with the authorization server. 
> Why not just
> > include the client identifier and user identifier and let the 
> authorization
> > server lookup what the user already authorized?
> > >
> > >
> > > Igor Faynberg wrote:
> > >
> > > +1
> > >
> > > Torsten Lodderstedt wrote:
> > >> Hi,
> > >>
> > >> I also see the need to request and issue multiple tokens in a single
> > >> authorization process. There has already been some discussion about
> > >> this topic roughly a year ago:
> > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
> > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
> > >>
> > >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
> > >> supporting that use case. It's called "bulk authorization".
> > >>
> > >> Would that be an interessting topic we could discuss at IETF-81 for
> > >> the re-chartering?  I could present our approach there.
> > >>
> > >> regards,
> > >> Torsten.
> > >
> > >> Am 10.06.2011 21:08, schrieb John Bradley:
> > >>> We have identified the need to request multiple tokens as one issue
> > >>> that we would have to extend.
> > > _______________________________________________
> > > 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
>
>


--------------050701080800080507000904
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit



  
    
  
  
    I completely agree that the single-token case needs to be left
    alone, and I rather like this idea. The AS would return something
    like:

    

    { 

     access_token: [

        { 

          access_token: "1234656",

          expires_in: 3600,

          token_type: bearer

        },

        {

          access_token: "abcdefg",

          expires_in: 3600,

          token_type: MAC,

          mac_stuff: "goes_here"

        }

      ],

      token_type: multiple

    }

    

    This would not only let clients who are doing the common one-token
    flow ignore the "multiple" token type, it would also allow for
    re-use of token storage libraries for the inner token bits. And you
    could go crazy and pass a multiple token full of multiple tokens,
    too. It's turtles all the way down!

    

     -- Justin 

    

    On 6/16/2011 7:23 PM, William J. Mills wrote:
    

      

        
Probably defining a token type of "multiple_tokens"
            would be my preference, and if you get that back then you
            have to parse an array of {type, token}*.  What that array
            looks like could be JSON in the payload, or something else. 
            That leaves the single token use case alone.

          

        


        

        

          

              
From:
              Eran Hammer-Lahav <eran@hueniverse.com>

              To: Phil
              Hunt <phil.hunt@oracle.com>; "Manger, James H"
              <James.H.Manger@team.telstra.com>

              Cc: OAuth
              WG <oauth@ietf.org>

              Sent:
              Wednesday, June 15, 2011 10:46 PM

              Subject:
              Re: [OAUTH-WG] issuing multiple tokens

            

            It is not an important enough feature. Parsing an array
            response when 99.99% will be a single object array is
            annoying. Also, what would you return in case of error? A
            single object? What is the client supposed to do if it gets
            an empty array? Array with more than one token?

            

            *This* would be the hack... If this is something people want
            to deploy, a full proposal end-to-end is required. And not
            now.

            

            EHL

            

            

            > -----Original Message-----

            > From: oauth-bounces@ietf.org
            [mailto:oauth-bounces@ietf.org]
            On Behalf

            > Of Phil Hunt

            > Sent: Wednesday, June 15, 2011 10:40 PM

            > To: Manger, James H

            > Cc: OAuth WG

            > Subject: Re: [OAUTH-WG] issuing multiple tokens

            > 

            > +1

            > 

            > Phil

            > 

            > @independentid

            > www.independentid.com

            > phil.hunt@oracle.com

            > 

            > 

            > 

            > 

            > 

            > On 2011-06-15, at 10:01 PM, Manger, James H wrote:

            > 

            > > Torsten Lodderstedt needs to issue multiple
            tokens; Igor Faynberg said +1

            > to that; John Bradley identified that OpenID Connect
            needs to request

            > multiple tokens; Eran Hammer-Lahav even mentioned a
            no-token flow as

            > something that could make sense; ...

            > >

            > > Issuing 0, 1 or more tokens looks like an
            important enough feature to fix

            > now, instead of trying to hack it in after the spec is
            finalised.

            > >

            > >

            > > Changing the access token response [5.1] to be a
            JSON array of JSON

            > objects (one JSON object per issued token) seems like a
            simple way to get

            > this important functionality -- with very limited
            overhead for services that will

            > only ever issue a single token, and client written just
            for those services.

            > >

            > > P.S. Does Facebook return a JSON object for its
            access token response (as

            > in draft-ietf-oauth-v2-12 that they reference), or
            x-www-form-urlencoded

            > as the example at
            http://developers.facebook.com/docs/authentication/

            > implies [4th screen shot down]?

            > >

            > > --

            > > James Manger

            > >

            > >

            > > Eran said (on a different thread):

            > >

            > > ...if the client can authenticate with the
            authorization server. Why not just

            > include the client identifier and user identifier and
            let the authorization

            > server lookup what the user already authorized?

            > >

            > >

            > > Igor Faynberg wrote:

            > >

            > > +1

            > >

            > > Torsten Lodderstedt wrote:

            > >> Hi,

            > >>

            > >> I also see the need to request and issue
            multiple tokens in a single

            > >> authorization process. There has already been
            some discussion about

            > >> this topic roughly a year ago:

            > >> -
            http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.

            > >> -
            http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html

            > >>

            > >> We at Deutsche Telekom have implemented an
            OAuth 2.0 extension

            > >> supporting that use case. It's called "bulk
            authorization".

            > >>

            > >> Would that be an interessting topic we could
            discuss at IETF-81 for

            > >> the re-chartering?  I could present our
            approach there.

            > >>

            > >> regards,

            > >> Torsten.

            > >

            > >> Am 10.06.2011 21:08, schrieb John Bradley:

            > >>> We have identified the need to request
            multiple tokens as one issue

            > >>> that we would have to extend.

            > > _______________________________________________

            > > 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

            

            

          

        

      

    

    

  


--------------050701080800080507000904--

From torsten@lodderstedt.net  Fri Jun 17 08:31:21 2011
Return-Path: 
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 6C70511E819F for ; Fri, 17 Jun 2011 08:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fFdq1-cITAb for ; Fri, 17 Jun 2011 08:31:20 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id DA89511E8179 for ; Fri, 17 Jun 2011 08:31:19 -0700 (PDT)
Received: from [80.187.106.79] (helo=nothing) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QXb0t-0005qV-7n; Fri, 17 Jun 2011 17:31:17 +0200
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>  <4DFA6C76.8050601@lodderstedt.net>  <4DFA7251.9060602@alcatel-lucent.com>   
User-Agent: K-9 Mail for Android
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----VYODNSN0MVWSVMG64QWY0N47V8HM1M"
From: Torsten Lodderstedt 
Date: Fri, 17 Jun 2011 17:31:04 +0200
To: Shane B Weeden ,Dave Nelson 
Message-ID: 
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 15:31:21 -0000

------VYODNSN0MVWSVMG64QWY0N47V8HM1M
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Shane B Weeden  schrieb:

>As I understand it, what you've described is precisely the intent of
>the
>refresh token. The online registration process you refer to is a
>corresponding one-time authorization code flow. The authorization code
>effectively becomes a one-time-use, short-lived credential for the
>client
>instance which it should use immediately (since it has been exposed to
>the
>resource owner via the user-agent in getting to the client) to directly
>request an access token (typically short-lived and may not be needed
>immediately) and refresh token (typically long-lived). The refresh
>token is
>stored securely locally. It is essentially an instance secret bound to
>the
>client id and representing the original resource owner grant. Provided:
>1. The resource owner and user-agent safely deliver the authorization
>code
>to the client instance in first place
>2. The client uses it immediately in secure transport-level
>communications
>to the authorization server and then securely stores the long-lived
>refresh
>token
>3. The client always uses the refresh token in secure transport-level
>communications to the authorization server to get an access token (and
>optionally rollover the refresh token)
>.. then securely authenticating the client doesn't seem to be a big
>deal.
>
>I trust "the list" will correct me if that's a wrong interpretation of
>a
>classic native app scenario.

I fully agree with your description.

>
>It still leads to my question from some posts ago about why then is it
>advantageous to require client authentication at all for the
>authorization
>code flow in classic web app three-legged scenarios, and I am yet to
>fully
>digest Torsten's response to that (
>http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01).

I hope it was delicious :-). 
Pls. note: Mark & Phil were involved as well.

About
>the
>only documented advantage I've seen to date has to do with the
>recovery/next steps from a compromised refresh token, but the
>usefulness of
>that idea has been debated as well.

In my opinion, there are the following advantages:
- the user can be provided with trustworthy information about the client
- the authentication is a further measure against guessing attacks on authz codes and refresh tokens (beside high entropy and short duration)
- it might make token theft more difficult given the secret is stored somewhere/somehow else than the refresh tokens

regards,
Torsten.

>
>
>
>
>
>From:	Dave Nelson 
>To:	Brian Eaton 
>Cc:	"oauth@ietf.org" 
>Date:	17-06-11 09:45 PM
>Subject:	Re: [OAUTH-WG] Client authentication requirement
>Sent by:	oauth-bounces@ietf.org
>
>
>
>> If you aren't willing to accept the risk of native apps that can't
>keep
>> secrets, don't support such apps.
>
>We continue to say "can't keep secrets". I think what we mean is
>"can't keep secrets that are embedded in the code". One could imagine
>an install-time, leap-of-faith binding to a remotely received secret,
>via some on-line registration process, that the native app asks the
>operating system to store for it securely. The user can make an
>assertion of trust in the validity of the app that he/she has
>downloaded and is subsequently installing. Of course, that initial
>faith might be misplaced, but that's true of almost all
>user-installable software, even that receive on physical media. If
>browsers are trusted to store secrets securely, then that same
>capability is available to native apps.
>
>Regards,
>
>Dave
>
>David B. Nelson
>Sr. Software Architect
>Elbrys Networks, Inc.
>www.elbrys.com
>+1.603.570.2636
>_______________________________________________
>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

------VYODNSN0MVWSVMG64QWY0N47V8HM1M
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Shane B Weeden <sweeden@au1.ibm.com> schrieb:



>As I understand it, what you've described is precisely the intent of

>the

>refresh token. The online registration process you refer to is a

>corresponding one-time authorization code flow. The authorization code

>effectively becomes a one-time-use, short-lived credential for the

>client

>instance which it should use immediately (since it has been exposed to

>the

>resource owner via the user-agent in getting to the client) to directly

>request an access token (typically short-lived and may not be needed

>immediately) and refresh token (typically long-lived). The refresh

>token is

>stored securely locally. It is essentially an instance secret bound to

>the

>client id and representing the original resource owner grant. Provided:

>1. The resource owner and user-agent safely deliver the authorization

>code

>to the client instance in first place

>2. The client uses it immediately in secure transport-level

>communications

>to the authorization server and then securely stores the long-lived

>refresh

>token

>3. The client always uses the refresh token in secure transport-level

>communications to the authorization server to get an access token (and

>optionally rollover the refresh token)

>.. then securely authenticating the client doesn't seem to be a big

>deal.

>

>I trust "the list" will correct me if that's a wrong interpretation of

>a

>classic native app scenario.



I fully agree with your description.



>

>It still leads to my question from some posts ago about why then is it

>advantageous to require client authentication at all for the

>authorization

>code flow in classic web app three-legged scenarios, and I am yet to

>fully

>digest Torsten's response to that (

>http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01).



I hope it was delicious :-). 

Pls. note: Mark & Phil were involved as well.



 About

>the

>only documented advantage I've seen to date has to do with the

>recovery/next steps from a compromised refresh token, but the

>usefulness of

>that idea has been debated as well.



In my opinion, there are the following advantages:

- the user can be provided with trustworthy information about the client

- the authentication is a further measure against guessing attacks on authz codes and refresh tokens (beside high entropy and short duration)

- it might make token theft more difficult given the secret is stored somewhere/somehow else than the refresh tokens



regards,

Torsten.



>

>

>

>

>

>From:	Dave Nelson <dnelson@elbrys.com>

>To:	Brian Eaton <beaton@google.com>

>Cc:	"oauth@ietf.org" <oauth@ietf.org>

>Date:	17-06-11 09:45 PM

>Subject:	Re: [OAUTH-WG] Client authentication requirement

>Sent by:	oauth-bounces@ietf.org

>

>

>

>> If you aren't willing to accept the risk of native apps that can't

>keep

>> secrets, don't support such apps.

>

>We continue to say "can't keep secrets".  I think what we mean is

>"can't keep secrets that are embedded in the code".  One could imagine

>an install-time, leap-of-faith binding to a remotely received secret,

>via some on-line registration process, that the native app asks the

>operating system to store for it securely.  The user can make an

>assertion of trust in the validity of the app that he/she has

>downloaded and is subsequently installing.  Of course, that initial

>faith might be misplaced, but that's true of almost all

>user-installable software, even that receive on physical media.  If

>browsers are trusted to store secrets securely, then that same

>capability is available to native apps.

>

>Regards,

>

>Dave

>

>David B. Nelson

>Sr. Software Architect

>Elbrys Networks, Inc.

>www.elbrys.com

>+1.603.570.2636

>_______________________________________________

>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


------VYODNSN0MVWSVMG64QWY0N47V8HM1M--


From recordond@gmail.com  Fri Jun 17 12:13:32 2011
Return-Path: 
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 40E169E8031 for ; Fri, 17 Jun 2011 12:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58G90xtj3mpx for ; Fri, 17 Jun 2011 12:13:31 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 969809E803A for ; Fri, 17 Jun 2011 12:13:30 -0700 (PDT)
Received: by vws12 with SMTP id 12so2767263vws.31 for ; Fri, 17 Jun 2011 12:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=meg9JspZzfb4h8lUvrBfKoi348rUNdxHbwODN6jAKK0=; b=VCATYMhB9xBL62oyxerj8H587bRya3RCqf6O48FqThcyeLj/tLbv/0IYfNV+uWT+HG 75TEfgsOLJDs60fWjklQPOB0HW7T4qidlYqaYxJ0z7ZhwURN2zn4rr0qXQHCnbShWzN3 o3x+j+x4ztkO7sbkfb9HGqP0BmMXpjTK1IHFc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ob87Qaa5iZadyabfCdDVlyjjXS9jvGtPaQfrshovC+D+JihZsb9xBtVH1KWa5dQ7Bc heY/oH2Bf44cGxdkpI3j9Tu05HaJyv1msIu1++pqC5KBGCxayTw/NPj5KqkFP/fek8Ul JbPaJkjjFFLW1WC05CqsFlhrBkTh59ZGc5Euw=
MIME-Version: 1.0
Received: by 10.52.68.162 with SMTP id x2mr884550vdt.116.1308338009318; Fri, 17 Jun 2011 12:13:29 -0700 (PDT)
Received: by 10.52.162.195 with HTTP; Fri, 17 Jun 2011 12:13:29 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110617094033.5359726zl63xc2kg@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 17 Jun 2011 12:13:29 -0700
Message-ID: 
From: David Recordon 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 19:13:32 -0000

+1 Eran

On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav  w=
rote:
> OAuth has been successful because of its simple architecture and because =
it is based on actual deployment experience. Offering multi-token responses=
 would be premature standardization. I am not convinced that adding it late=
r would entail any real technical difficulty.
>
> EHL
>
>> -----Original Message-----
>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>> Sent: Friday, June 17, 2011 12:41 AM
>> To: Eran Hammer-Lahav
>> Cc: Manger, James H; OAuth WG
>> Subject: Re: [OAUTH-WG] issuing multiple tokens
>>
>> this is kind of a self-fulfilling prophecy. If we do not encourage imple=
mentors
>> to use service-specific tokens by supporting it in OAuth most people wil=
l not
>> consider it.
>>
>> As James pointed out, there are good reasons to use service-specific tok=
ens
>> in multi-service environments. That's why Deutsche Telekom employs a str=
ict
>> security policy to use different tokens for different services. And as a=
 multi-
>> service provider an increasing percentage of our apps need to access
>> multiple services. That's why we have implemented support for issuing
>> multiple tokens in a single authorization flow. We will have this featur=
e in
>> production before IETF-81.
>>
>> regards,
>> Torsten.
>>
>> Zitat von Eran Hammer-Lahav :
>>
>> > I'm standing behind my 99.99% projection for the next 5 years.
>> >
>> > EHL
>> >
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Manger, James H
>> > Sent: Thursday, June 16, 2011 9:04 PM
>> > To: OAuth WG
>> > Subject: Re: [OAUTH-WG] issuing multiple tokens
>> >
>> >> [Issuing multiple tokens] is not an important enough feature.
>> >> Parsing an array response when
>> >> 99.99% will be a single object array is annoying.
>> >
>> > I would agree... if I believed the 99.99%, but not if it will be 80%
>> > and falling in a year or two.
>> >
>> > A major benefit of OAuth2 is that resource servers only handle
>> > limited-lifetime, limited-capability access tokens so there is limited
>> > damage and easier recovery if one resource service is compromised. If
>> > the same access token works at all the resource servers that a client
>> > app uses, then an attacker that compromises one resource server can
>> > re-use the access tokens elsewhere. The bigger your portfolio of
>> > services, the worse the risk.
>> >
>> >> Also, what would you return in case of error? A single object?
>> >
>> > Yes. It is not that hard to test if JSON.parse(...) returns an array
>> > or a single object with an error field, or to notice the 4xx status
>> > code.
>> >
>> >> What is the client supposed to do if it gets an empty array?
>> >
>> > The delegation succeeded, but you don't need to use temporary
>> > credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie
>> > was issued, perhaps the service is using URIs-as-capabilities...).
>> > Continue on to use the API.
>> >
>> >> Array with more than one token?
>> >
>> > If the client app hasn't bothered to write the extra code to handle
>> > multiple tokens then it just uses the first token. If separate tokens
>> > are now needed for servers that previously shared the same token, then
>> > the service has made a deliberate decision to increase security in a
>> > way that wasn't backwardly compatible.
>> >
>> >> *This* would be the hack... If this is something people want to
>> >> deploy, a full proposal end-to-end is required. And not now.
>> > I few proposals have been made in the past. Some try hard to leave the
>> > single token case alone, but always at a cost to complexity: eg the
>> > first token needs to be handled differently to the other tokens.
>> >
>> >
>> > Responding to William Mills' comments:
>> >>> Probably defining a token type of "multiple_tokens" would be my
>> preference,
>> >>> and if you get that back then you have to parse an array of {type,
>> token}*.
>> >>> =A0What that array looks like could be JSON in the payload, or
>> >>> something else.
>> >>> =A0That leaves the single token use case alone.
>> >
>> > This is a good example of how it is awkward to add multiple token
>> > support later.
>> > With this suggestion a service that starts issuing multiple tokens
>> > (eg for clients to access an enhanced version of an API) can't just
>> > add an extra token for the enhanced API that old clients will
>> > ignore. Instead, it has to change the top-level token_type, which
>> > will fail in all old clients. It also leaves other top-level
>> > mandatory fields such as access_token with confusing semantics.
>> >
>> >
>> > --
>> > James Manger
>> >
>>
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From jricher@mitre.org  Fri Jun 17 12:15:55 2011
Return-Path: 
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 01492228013 for ; Fri, 17 Jun 2011 12:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.458
X-Spam-Level: 
X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CpZpyQFujRJ for ; Fri, 17 Jun 2011 12:15:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 65AB4228012 for ; Fri, 17 Jun 2011 12:15:53 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E751721B1E75 for ; Fri, 17 Jun 2011 15:15:52 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E00D521B1E58 for ; Fri, 17 Jun 2011 15:15:52 -0400 (EDT)
Received: from [172.31.4.213] (172.31.4.213) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 17 Jun 2011 15:15:52 -0400
Message-ID: <4DFBA7E8.20101@mitre.org>
Date: Fri, 17 Jun 2011 15:15:52 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: 
References: 	<4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com>	<255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>		<90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070901030204030406070006"
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 19:15:55 -0000

--------------070901030204030406070006
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Incidentally, I'd like to clarify my position that the below or any 
other kind of multi-token formatting doesn't belong in the core spec.

  -- Justin

On 6/17/2011 9:46 AM, Justin Richer wrote:
> I completely agree that the single-token case needs to be left alone, 
> and I rather like this idea. The AS would return something like:
>
> {
>  access_token: [
>     {
>       access_token: "1234656",
>       expires_in: 3600,
>       token_type: bearer
>     },
>     {
>       access_token: "abcdefg",
>       expires_in: 3600,
>       token_type: MAC,
>       mac_stuff: "goes_here"
>     }
>   ],
>   token_type: multiple
> }
>
> This would not only let clients who are doing the common one-token 
> flow ignore the "multiple" token type, it would also allow for re-use 
> of token storage libraries for the inner token bits. And you could go 
> crazy and pass a multiple token full of multiple tokens, too. It's 
> turtles all the way down!
>
>  -- Justin
>
> On 6/16/2011 7:23 PM, William J. Mills wrote:
>> Probably defining a token type of "multiple_tokens" would be my 
>> preference, and if you get that back then you have to parse an array 
>> of {type, token}*.  What that array looks like could be JSON in the 
>> payload, or something else.  That leaves the single token use case alone.
>>
>> ------------------------------------------------------------------------
>> *From:* Eran Hammer-Lahav 
>> *To:* Phil Hunt ; "Manger, James H" 
>> 
>> *Cc:* OAuth WG 
>> *Sent:* Wednesday, June 15, 2011 10:46 PM
>> *Subject:* Re: [OAUTH-WG] issuing multiple tokens
>>
>> It is not an important enough feature. Parsing an array response when 
>> 99.99% will be a single object array is annoying. Also, what would 
>> you return in case of error? A single object? What is the client 
>> supposed to do if it gets an empty array? Array with more than one token?
>>
>> *This* would be the hack... If this is something people want to 
>> deploy, a full proposal end-to-end is required. And not now.
>>
>> EHL
>>
>>
>> > -----Original Message-----
>> > From: oauth-bounces@ietf.org  
>> [mailto:oauth-bounces@ietf.org ] On Behalf
>> > Of Phil Hunt
>> > Sent: Wednesday, June 15, 2011 10:40 PM
>> > To: Manger, James H
>> > Cc: OAuth WG
>> > Subject: Re: [OAUTH-WG] issuing multiple tokens
>> >
>> > +1
>> >
>> > Phil
>> >
>> > @independentid
>> > www.independentid.com 
>> > phil.hunt@oracle.com 
>> >
>> >
>> >
>> >
>> >
>> > On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>> >
>> > > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg 
>> said +1
>> > to that; John Bradley identified that OpenID Connect needs to request
>> > multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as
>> > something that could make sense; ...
>> > >
>> > > Issuing 0, 1 or more tokens looks like an important enough 
>> feature to fix
>> > now, instead of trying to hack it in after the spec is finalised.
>> > >
>> > >
>> > > Changing the access token response [5.1] to be a JSON array of JSON
>> > objects (one JSON object per issued token) seems like a simple way 
>> to get
>> > this important functionality -- with very limited overhead for 
>> services that will
>> > only ever issue a single token, and client written just for those 
>> services.
>> > >
>> > > P.S. Does Facebook return a JSON object for its access token 
>> response (as
>> > in draft-ietf-oauth-v2-12 that they reference), or 
>> x-www-form-urlencoded
>> > as the example at http://developers.facebook.com/docs/authentication/
>> > implies [4th screen shot down]?
>> > >
>> > > --
>> > > James Manger
>> > >
>> > >
>> > > Eran said (on a different thread):
>> > >
>> > > ...if the client can authenticate with the authorization server. 
>> Why not just
>> > include the client identifier and user identifier and let the 
>> authorization
>> > server lookup what the user already authorized?
>> > >
>> > >
>> > > Igor Faynberg wrote:
>> > >
>> > > +1
>> > >
>> > > Torsten Lodderstedt wrote:
>> > >> Hi,
>> > >>
>> > >> I also see the need to request and issue multiple tokens in a single
>> > >> authorization process. There has already been some discussion about
>> > >> this topic roughly a year ago:
>> > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
>> > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>> > >>
>> > >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
>> > >> supporting that use case. It's called "bulk authorization".
>> > >>
>> > >> Would that be an interessting topic we could discuss at IETF-81 for
>> > >> the re-chartering?  I could present our approach there.
>> > >>
>> > >> regards,
>> > >> Torsten.
>> > >
>> > >> Am 10.06.2011 21:08, schrieb John Bradley:
>> > >>> We have identified the need to request multiple tokens as one issue
>> > >>> that we would have to extend.
>> > > _______________________________________________
>> > > 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
>>
>>
>


--------------070901030204030406070006
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit



  
    
  
  
    Incidentally, I'd like to clarify my position that the below or any
    other kind of multi-token formatting doesn't belong in the core
    spec.

    

     -- Justin

    

    On 6/17/2011 9:46 AM, Justin Richer wrote:
    

      
      I completely agree that the single-token case needs to be left
      alone, and I rather like this idea. The AS would return something
      like:

      

      { 

       access_token: [

          { 

            access_token: "1234656",

            expires_in: 3600,

            token_type: bearer

          },

          {

            access_token: "abcdefg",

            expires_in: 3600,

            token_type: MAC,

            mac_stuff: "goes_here"

          }

        ],

        token_type: multiple

      }

      

      This would not only let clients who are doing the common one-token
      flow ignore the "multiple" token type, it would also allow for
      re-use of token storage libraries for the inner token bits. And
      you could go crazy and pass a multiple token full of multiple
      tokens, too. It's turtles all the way down!

      

       -- Justin 

      

      On 6/16/2011 7:23 PM, William J. Mills wrote:
      

        

          
Probably defining a token type of "multiple_tokens"
              would be my preference, and if you get that back then you
              have to parse an array of {type, token}*.  What that array
              looks like could be JSON in the payload, or something
              else.  That leaves the single token use case alone.

            

          


          

          

            

                
From:
                Eran Hammer-Lahav <eran@hueniverse.com>

                To: Phil
                Hunt <phil.hunt@oracle.com>;
                "Manger, James H" <James.H.Manger@team.telstra.com>

                Cc: OAuth
                WG <oauth@ietf.org>

                Sent:
                Wednesday, June 15, 2011 10:46 PM

                Subject:
                Re: [OAUTH-WG] issuing multiple tokens

              

              It is not an important enough feature. Parsing an array
              response when 99.99% will be a single object array is
              annoying. Also, what would you return in case of error? A
              single object? What is the client supposed to do if it
              gets an empty array? Array with more than one token?

              

              *This* would be the hack... If this is something people
              want to deploy, a full proposal end-to-end is required.
              And not now.

              

              EHL

              

              

              > -----Original Message-----

              > From: oauth-bounces@ietf.org
              [mailto:oauth-bounces@ietf.org]
              On Behalf

              > Of Phil Hunt

              > Sent: Wednesday, June 15, 2011 10:40 PM

              > To: Manger, James H

              > Cc: OAuth WG

              > Subject: Re: [OAUTH-WG] issuing multiple tokens

              > 

              > +1

              > 

              > Phil

              > 

              > @independentid

              > www.independentid.com

              > phil.hunt@oracle.com

              > 

              > 

              > 

              > 

              > 

              > On 2011-06-15, at 10:01 PM, Manger, James H wrote:

              > 

              > > Torsten Lodderstedt needs to issue multiple
              tokens; Igor Faynberg said +1

              > to that; John Bradley identified that OpenID Connect
              needs to request

              > multiple tokens; Eran Hammer-Lahav even mentioned a
              no-token flow as

              > something that could make sense; ...

              > >

              > > Issuing 0, 1 or more tokens looks like an
              important enough feature to fix

              > now, instead of trying to hack it in after the spec
              is finalised.

              > >

              > >

              > > Changing the access token response [5.1] to be a
              JSON array of JSON

              > objects (one JSON object per issued token) seems like
              a simple way to get

              > this important functionality -- with very limited
              overhead for services that will

              > only ever issue a single token, and client written
              just for those services.

              > >

              > > P.S. Does Facebook return a JSON object for its
              access token response (as

              > in draft-ietf-oauth-v2-12 that they reference), or
              x-www-form-urlencoded

              > as the example at http://developers.facebook.com/docs/authentication/

              > implies [4th screen shot down]?

              > >

              > > --

              > > James Manger

              > >

              > >

              > > Eran said (on a different thread):

              > >

              > > ...if the client can authenticate with the
              authorization server. Why not just

              > include the client identifier and user identifier and
              let the authorization

              > server lookup what the user already authorized?

              > >

              > >

              > > Igor Faynberg wrote:

              > >

              > > +1

              > >

              > > Torsten Lodderstedt wrote:

              > >> Hi,

              > >>

              > >> I also see the need to request and issue
              multiple tokens in a single

              > >> authorization process. There has already
              been some discussion about

              > >> this topic roughly a year ago:

              > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.

              > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html

              > >>

              > >> We at Deutsche Telekom have implemented an
              OAuth 2.0 extension

              > >> supporting that use case. It's called "bulk
              authorization".

              > >>

              > >> Would that be an interessting topic we could
              discuss at IETF-81 for

              > >> the re-chartering?  I could present our
              approach there.

              > >>

              > >> regards,

              > >> Torsten.

              > >

              > >> Am 10.06.2011 21:08, schrieb John Bradley:

              > >>> We have identified the need to request
              multiple tokens as one issue

              > >>> that we would have to extend.

              > > _______________________________________________

              > > 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

              

              

            

          

        

      

      

    

    

  


--------------070901030204030406070006--

From phil.hunt@oracle.com  Fri Jun 17 12:31:32 2011
Return-Path: 
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 45BE19E8027 for ; Fri, 17 Jun 2011 12:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd7SsNR0fJVp for ; Fri, 17 Jun 2011 12:31:30 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1D20C9E800A for ; Fri, 17 Jun 2011 12:31:29 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5HJVMZA013701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jun 2011 19:31:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5HJVLQA026540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Jun 2011 19:31:22 GMT
Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5HJVGqf016327 for ; Fri, 17 Jun 2011 14:31:16 -0500
Received: from [192.168.1.3] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Jun 2011 12:31:16 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 17 Jun 2011 12:31:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DAD1274-A9B6-41FE-9707-BBC1D03F4F2E@oracle.com>
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110617094033.5359726zl63xc2kg@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
To: OAuth WG 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090206.4DFBAB8C.00B0:SCFSTAT5015188,ss=1,fgs=0
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 19:31:32 -0000

-1 on the reason not to discuss the issue now.

The current limited deployment case experience of OAuth does not =
necessarily indicate the expected use in the future. We already know it =
to be MUCH broader as the password anti-pattern is very large indeed.

I will also point out that this is a V. 2 specification. Thus now is not =
necessarily the time to artificially limit scope as it might be for a =
version 1 specification which may with good reason want to limit the use =
cases.

That said, *I do agree the idea is late in the V2 process*. If we can't =
develop a solid answer cleanly, and if it is too disruptive...we simply =
cannot pursue. Because of this, I want to have more discussion before =
dismissing the idea.

I am looking at potentially similar issues as previously raised by =
Torsten. My thoughts are:

The single-token schema may be fine for single-property cloud sites to =
go with the current single-token spec, but I'm sure multi-property sites =
will have these issues very quickly.

It also occurs to me that MAC tokens should have limited sharing of keys =
(e.g. to single client-server pairs), so that will tend to drive token =
services to want to issue more tokens then say with bearer tokens which =
could more easily be used in multi-property scenarios.  Of course, I =
haven't thought this through yet...this is just a top-of-the-head, what =
are the ramification thoughts.

I would like to see more discussion.

Thanks,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-17, at 12:13 PM, David Recordon wrote:

> +1 Eran
>=20
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav =
 wrote:
>> OAuth has been successful because of its simple architecture and =
because it is based on actual deployment experience. Offering =
multi-token responses would be premature standardization. I am not =
convinced that adding it later would entail any real technical =
difficulty.
>>=20
>> EHL
>>=20
>>> -----Original Message-----
>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>>> Sent: Friday, June 17, 2011 12:41 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Manger, James H; OAuth WG
>>> Subject: Re: [OAUTH-WG] issuing multiple tokens
>>>=20
>>> this is kind of a self-fulfilling prophecy. If we do not encourage =
implementors
>>> to use service-specific tokens by supporting it in OAuth most people =
will not
>>> consider it.
>>>=20
>>> As James pointed out, there are good reasons to use service-specific =
tokens
>>> in multi-service environments. That's why Deutsche Telekom employs a =
strict
>>> security policy to use different tokens for different services. And =
as a multi-
>>> service provider an increasing percentage of our apps need to access
>>> multiple services. That's why we have implemented support for =
issuing
>>> multiple tokens in a single authorization flow. We will have this =
feature in
>>> production before IETF-81.
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> Zitat von Eran Hammer-Lahav :
>>>=20
>>>> I'm standing behind my 99.99% projection for the next 5 years.
>>>>=20
>>>> EHL
>>>>=20
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>> Of Manger, James H
>>>> Sent: Thursday, June 16, 2011 9:04 PM
>>>> To: OAuth WG
>>>> Subject: Re: [OAUTH-WG] issuing multiple tokens
>>>>=20
>>>>> [Issuing multiple tokens] is not an important enough feature.
>>>>> Parsing an array response when
>>>>> 99.99% will be a single object array is annoying.
>>>>=20
>>>> I would agree... if I believed the 99.99%, but not if it will be =
80%
>>>> and falling in a year or two.
>>>>=20
>>>> A major benefit of OAuth2 is that resource servers only handle
>>>> limited-lifetime, limited-capability access tokens so there is =
limited
>>>> damage and easier recovery if one resource service is compromised. =
If
>>>> the same access token works at all the resource servers that a =
client
>>>> app uses, then an attacker that compromises one resource server can
>>>> re-use the access tokens elsewhere. The bigger your portfolio of
>>>> services, the worse the risk.
>>>>=20
>>>>> Also, what would you return in case of error? A single object?
>>>>=20
>>>> Yes. It is not that hard to test if JSON.parse(...) returns an =
array
>>>> or a single object with an error field, or to notice the 4xx status
>>>> code.
>>>>=20
>>>>> What is the client supposed to do if it gets an empty array?
>>>>=20
>>>> The delegation succeeded, but you don't need to use temporary
>>>> credentials (perhaps client auth is sufficient, perhaps a [MAC] =
cookie
>>>> was issued, perhaps the service is using URIs-as-capabilities...).
>>>> Continue on to use the API.
>>>>=20
>>>>> Array with more than one token?
>>>>=20
>>>> If the client app hasn't bothered to write the extra code to handle
>>>> multiple tokens then it just uses the first token. If separate =
tokens
>>>> are now needed for servers that previously shared the same token, =
then
>>>> the service has made a deliberate decision to increase security in =
a
>>>> way that wasn't backwardly compatible.
>>>>=20
>>>>> *This* would be the hack... If this is something people want to
>>>>> deploy, a full proposal end-to-end is required. And not now.
>>>> I few proposals have been made in the past. Some try hard to leave =
the
>>>> single token case alone, but always at a cost to complexity: eg the
>>>> first token needs to be handled differently to the other tokens.
>>>>=20
>>>>=20
>>>> Responding to William Mills' comments:
>>>>>> Probably defining a token type of "multiple_tokens" would be my
>>> preference,
>>>>>> and if you get that back then you have to parse an array of =
{type,
>>> token}*.
>>>>>>  What that array looks like could be JSON in the payload, or
>>>>>> something else.
>>>>>>  That leaves the single token use case alone.
>>>>=20
>>>> This is a good example of how it is awkward to add multiple token
>>>> support later.
>>>> With this suggestion a service that starts issuing multiple tokens
>>>> (eg for clients to access an enhanced version of an API) can't just
>>>> add an extra token for the enhanced API that old clients will
>>>> ignore. Instead, it has to change the top-level token_type, which
>>>> will fail in all old clients. It also leaves other top-level
>>>> mandatory fields such as access_token with confusing semantics.
>>>>=20
>>>>=20
>>>> --
>>>> James Manger
>>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From wmills@yahoo-inc.com  Fri Jun 17 13:02:32 2011
Return-Path: 
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 97AF89E8057 for ; Fri, 17 Jun 2011 13:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N8q3bS7BvET for ; Fri, 17 Jun 2011 13:02:31 -0700 (PDT)
Received: from nm28-vm0.bullet.mail.ac4.yahoo.com (nm28-vm0.bullet.mail.ac4.yahoo.com [98.139.52.246]) by ietfa.amsl.com (Postfix) with SMTP id E6F059E8030 for ; Fri, 17 Jun 2011 13:02:30 -0700 (PDT)
Received: from [98.139.52.192] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jun 2011 20:02:27 -0000
Received: from [98.139.52.143] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jun 2011 20:02:27 -0000
Received: from [127.0.0.1] by omp1026.mail.ac4.yahoo.com with NNFMP; 17 Jun 2011 20:02:27 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 559613.14462.bm@omp1026.mail.ac4.yahoo.com
Received: (qmail 49364 invoked by uid 60001); 17 Jun 2011 20:02:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1308340945; bh=vOQlmqEPbok8GIRLVvnCeaqtAm88OvQ58vmvy9ta+h0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cveizDU1rfDJxdSQvK9g11IwLjaXoyRRzENjybGAfY6ddWPYEF5Q06bUTZxD/pWrshafM8HkBds5tUCjclj+8A7DV3i2x7zS7ZmNVo8+DCFPaSHZbCciKN122Bq7t6wgAdtvLDWxd2Do57lHSkI6QlXh71WkaN5YjTe73QFzuNE=
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:In-Reply-To:MIME-Version:Content-Type; b=B5mxWjh9P3CIiH7ZGpSaF8kOxg6HSwFO2Eky1nttXs+ixyRYkUD9Oi9Nc1idmQHl2jz0XTxzhe4P03iZqzaMGtHt04c8K20i0/ywYda4+7KhycIwFpKZB69qzWz4CLgmheqAIiuIlG6pSOZw5BNSfemlX1ipoteU7NYmoquHXlk=;
X-YMail-OSG: iooS2Q0VM1lpFSlzXM_Z1xcN9sBO9_r7F48XvZ1OOOLeCw6 NSbV9S8oy5ETzTFRtkIebbAbSvNTrgOfpcrVpt4qg8_5r922vGZoXlHgr5L. Ngk6EnK93hiYRo8pz1dc8jRv1ldeK4GzLWXjktF6rR4PNtDPAOTEIz1KTVYO PQBxbGUDzBIEjTviHZTua5xeRWWWSfnWu2sZmv7_V80dIamUmYbGeSmb8NhY mZpSQzNRtoHp_TPFd8OfS3yGfIY8Jm7IIqwUgJIrwo97Rnsov0RF4jL8AcrD CBgS.D2HHiHHRMPrHS7cWK896bCe11kq7oES4RtqNzkwxUYWZ4VRJaHy7CL6 tkF9yhsiYGVvmj7DtozIX4W_tjnSLsIg.ph9AOjVdFTt0fJ9bRRh0S8rAern iBbieW212e8swbJBDlAEzZZBVb8wybiisxkAW779DfRLZ24IEfkM_lLLs_aH nIU_htJRdp.iRKpIPMLdUe_0QrQgZINSbPv9kKkWGWK1w6v7YPHv6NVWDiQB zGSQ-
Received: from [209.131.51.114] by web31802.mail.mud.yahoo.com via HTTP; Fri, 17 Jun 2011 13:02:21 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References: 	<4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com>	<255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>		<90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>  <4DFBA7E8.20101@mitre.org>
Message-ID: <1308340941.22630.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Fri, 17 Jun 2011 13:02:21 -0700 (PDT)
From: "William J. Mills" 
To: Justin Richer , "oauth@ietf.org" 
In-Reply-To: <4DFBA7E8.20101@mitre.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1344166475-1308340941=:22630"
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 20:02:32 -0000

--0-1344166475-1308340941=:22630
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This feels right to me.=A0 Additionally, any client consuming multiple toke=
ns (whcih would be new) shoudl be able to add something onto the token requ=
est indicating they are capable of such.=A0 This means we never break exist=
ing clients.=0A=0A=0A=0A________________________________=0AFrom: Justin Ric=
her =0ATo: oauth@ietf.org=0ASent: Friday, June 17, 2011 =
12:15 PM=0ASubject: Re: [OAUTH-WG] issuing multiple tokens=0A=0AIncidentall=
y, I'd like to clarify my position that the below or any=0A    other kind o=
f multi-token formatting doesn't belong in the core=0A    spec.=0A=0A=A0-- =
Justin=0A=0AOn 6/17/2011 9:46 AM, Justin Richer wrote: =0AI completely agre=
e that the single-token case needs to be left alone, and I rather like this=
 idea. The AS would return something like:=0A>=0A>{ =0A>=A0access_token: [=
=0A>=A0=A0=A0 { =0A>=A0=A0=A0=A0=A0 access_token: "1234656",=0A>=A0=A0=A0=
=A0=A0 expires_in: 3600,=0A>=A0=A0=A0=A0=A0 token_type: bearer=0A>=A0=A0=A0=
 },=0A>=A0=A0=A0 {=0A>=A0=A0=A0=A0=A0 access_token: "abcdefg",=0A>=A0=A0=A0=
=A0=A0 expires_in: 3600,=0A>=A0=A0=A0=A0=A0 token_type: MAC,=0A>=A0=A0=A0=
=A0=A0 mac_stuff: "goes_here"=0A>=A0=A0=A0 }=0A>=A0 ],=0A>=A0 token_type: m=
ultiple=0A>}=0A>=0A>This would not only let clients who are doing the commo=
n one-token=0A      flow ignore the "multiple" token type, it would also al=
low for=0A      re-use of token storage libraries for the inner token bits.=
 And=0A      you could go crazy and pass a multiple token full of multiple=
=0A      tokens, too. It's turtles all the way down!=0A>=0A>=A0-- Justin =
=0A>=0A>On 6/16/2011 7:23 PM, William J. Mills wrote: =0A>Probably defining=
 a token type of "multiple_tokens" would be my preference, and if you get t=
hat back then you have to parse an array of {type, token}*.=A0 What that ar=
ray looks like could be JSON in the payload, or something else.=A0 That lea=
ves the single token use case alone.=0A>>=0A>>=0A>>=0A>>=0A>>______________=
__________________=0A>>From: Eran Hammer-Lahav =0A>>To=
: Phil Hunt ; "Manger, James H" =0A>>Cc: OAuth WG =0A>>Sent: Wednesday, June 15=
, 2011 10:46 PM=0A>>Subject: Re: [OAUTH-WG] issuing multiple tokens=0A>>=0A=
>>It is not an important enough feature. Parsing an array=0A              r=
esponse when 99.99% will be a single object array is=0A              annoyi=
ng. Also, what would you return in case of error? A=0A              single =
object? What is the client supposed to do if it=0A              gets an emp=
ty array? Array with more than one token?=0A>>=0A>>*This* would be the hack=
... If this is something people=0A              want to deploy, a full prop=
osal end-to-end is required.=0A              And not now.=0A>>=0A>>EHL=0A>>=
=0A>>=0A>>> -----Original Message-----=0A>>> From: oauth-bounces@ietf.org [=
mailto:oauth-bounces@ietf.org] On Behalf=0A>>> Of Phil Hunt=0A>>> Sent: Wed=
nesday, June 15, 2011 10:40 PM=0A>>> To: Manger, James H=0A>>> Cc: OAuth WG=
=0A>>> Subject: Re: [OAUTH-WG] issuing multiple tokens=0A>>> =0A>>> +1=0A>>=
> =0A>>> Phil=0A>>> =0A>>> @independentid=0A>>> www.independentid.com=0A>>>=
 phil.hunt@oracle.com=0A>>> =0A>>> =0A>>> =0A>>> =0A>>> =0A>>> On 2011-06-1=
5, at 10:01 PM, Manger, James H wrote:=0A>>> =0A>>> > Torsten Lodderstedt n=
eeds to issue multiple=0A              tokens; Igor Faynberg said +1=0A>>> =
to that; John Bradley identified that OpenID Connect=0A              needs =
to request=0A>>> multiple tokens; Eran Hammer-Lahav even mentioned a=0A    =
          no-token flow as=0A>>> something that could make sense; ...=0A>>>=
 >=0A>>> > Issuing 0, 1 or more tokens looks like an=0A              import=
ant enough feature to fix=0A>>> now, instead of trying to hack it in after =
the spec=0A              is finalised.=0A>>> >=0A>>> >=0A>>> > Changing the=
 access token response [5.1] to be a=0A              JSON array of JSON=0A>=
>> objects (one JSON object per issued token) seems like=0A              a =
simple way to get=0A>>> this important functionality -- with very limited=
=0A              overhead for services that will=0A>>> only ever issue a si=
ngle token, and client written=0A              just for those services.=0A>=
>> >=0A>>> > P.S. Does Facebook return a JSON object for its=0A            =
  access token response (as=0A>>> in draft-ietf-oauth-v2-12 that they refer=
ence), or=0A              x-www-form-urlencoded=0A>>> as the example at htt=
p://developers.facebook.com/docs/authentication/=0A>>> implies [4th screen =
shot down]?=0A>>> >=0A>>> > --=0A>>> > James Manger=0A>>> >=0A>>> >=0A>>> >=
 Eran said (on a different thread):=0A>>> >=0A>>> > ...if the client can au=
thenticate with the=0A              authorization server. Why not just=0A>>=
> include the client identifier and user identifier and=0A              let=
 the authorization=0A>>> server lookup what the user already authorized?=0A=
>>> >=0A>>> >=0A>>> > Igor Faynberg wrote:=0A>>> >=0A>>> > +1=0A>>> >=0A>>>=
 > Torsten Lodderstedt wrote:=0A>>> >> Hi,=0A>>> >>=0A>>> >> I also see the=
 need to request and issue=0A              multiple tokens in a single=0A>>=
> >> authorization process. There has already=0A              been some dis=
cussion about=0A>>> >> this topic roughly a year ago:=0A>>> >> - http://www=
.ietf.org/mail-archive/web/oauth/current/msg02688.html.=0A>>> >> - http://w=
ww.ietf.org/mail-archive/web/oauth/current/msg03639.html=0A>>> >>=0A>>> >> =
We at Deutsche Telekom have implemented an=0A              OAuth 2.0 extens=
ion=0A>>> >> supporting that use case. It's called "bulk=0A              au=
thorization".=0A>>> >>=0A>>> >> Would that be an interessting topic we coul=
d=0A              discuss at IETF-81 for=0A>>> >> the re-chartering?=A0 I c=
ould present our=0A              approach there.=0A>>> >>=0A>>> >> regards,=
=0A>>> >> Torsten.=0A>>> >=0A>>> >> Am 10.06.2011 21:08, schrieb John Bradl=
ey:=0A>>> >>> We have identified the need to request=0A              multip=
le tokens as one issue=0A>>> >>> that we would have to extend.=0A>>> > ____=
___________________________________________=0A>>> > OAuth mailing list=0A>>=
> > OAuth@ietf.org=0A>>> > https://www.ietf.org/mailman/listinfo/oauth=0A>>=
> =0A>>> _______________________________________________=0A>>> OAuth mailin=
g list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/oau=
th=0A>>_______________________________________________=0A>>OAuth mailing li=
st=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=
=0A>>=0A>>=0A>=0A=0A_______________________________________________=0AOAuth=
 mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oaut=
h
--0-1344166475-1308340941=:22630
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


This feels right to me.  Additionally, any client consuming multiple=
 tokens (whcih would be new) shoudl be able to add something onto the token=
 request indicating they are capable of such.  This means we never bre=
ak existing clients.

From: Justin Richer <jricher@mitre.org>
<=
b>To: oauth@ietf.org
Sent: Friday, June 17, 2011 12:=
15 PM
Subject: Re: [OAU=
TH-WG]
 issuing multiple tokens

=0A=0A=0A  =0A=0A    =0A  Incidental=
ly, I'd like to clarify my position that the below or any=0A    other kind =
of multi-token formatting doesn't belong in the core=0A    spec.
=0A    =

=0A     -- Justin
=0A    
=0A    On 6/17/2011 9:46 AM, Justi=
n Richer wrote:=0A    
=0A=0A      =0A      I comp=
letely agree that the single-token case needs to be left=0A      alone, and=
 I rather like this idea. The AS would return something=0A      like:
=
=0A      
=0A      { 
=0A       access_token: [
=0A      &nbs=
p;   { 
=0A            access_token: =
"1234656",
=0A            expires_in: 3600,
=
=0A            token_type: bearer
=0A      &nbs=
p;   },
=0A          {
=0A        =
    access_token: "abcdefg",
=0A         &=
nbsp;  expires_in: 3600,
=0A            to=
ken_type: MAC,
=0A            mac_stuff: "goes_=
here"
=0A          }
=0A        ],
=0A      &n=
bsp; token_type: multiple
=0A      }
=0A      
=0A      This would=
 not only let clients who are doing the common one-token=0A      flow ignor=
e the "multiple" token type, it would also allow for=0A      re-use of toke=
n storage libraries for the inner token bits. And=0A      you could go craz=
y and pass a multiple token full of multiple=0A      tokens, too. It's turt=
les all the way down!
=0A      
=0A       -- Justin 
=0A     =
 
=0A      On 6/16/2011 7:23 PM, William J. Mills wrote:=0A      =0A        
=0A          
Probably defining =
a token type of "multiple_tokens"=0A              would be my preference, a=
nd if you get that back then you=0A              have to parse an array of =
{type, token}*.  What that array=0A              looks like could be J=
SON in the payload, or something=0A              else.  That leaves th=
e single token use case alone.
=0A            
=0A          =


=0A          
=0A          
=0A            =

=0A                
<=
b>From:=0A                Era=
n Hammer-Lahav <eran@hueniverse.com>
=0A             =
   To: Phil=0A            =
    Hunt <phil.hunt@oracle.com>;=0A                "Ma=
nger, James H" <James.H.Manger@team.tel=
stra.com>
=0A                <oauth@ietf.org>
=
=0A                Sent:=
=0A                Wednesday, June 15, 2011 10:46 PM
=0A                =
Subject:=0A               =
 Re: [OAUTH-WG] issuing multiple tokens
=0A              
=0A =
             It is not an important enough feature. Parsing an array=0A    =
          response when 99.99% will be a single object array is=0A         =
     annoying. Also, what would you return in case of error? A=0A          =
    single object? What is the client supposed to do if it=0A              =
gets an empty array? Array with more than one token?
=0A              =0A              *This* would be the hack... If this is something people=
=0A              want to deploy, a full proposal end-to-end is required.=0A=
              And not now.
=0A              
=0A              EHL
=
=0A              
=0A              
=0A              > -----Origin=
al Message-----
=0A              > From: oauth-bounces@ietf.org=0A              [mailto:oauth-bounces@ietf.org]=0A       =
       On Behalf
=0A              > Of Phil Hunt
=0A              =
> Sent: Wednesday, June 15, 2011 10:40 PM
=0A              > To: M=
anger, James H
=0A              > Cc: OAuth WG
=0A              &g=
t; Subject: Re: [OAUTH-WG] issuing multiple tokens
=0A              >=
 
=0A              > +1
=0A              > 
=0A             =
 > Phil
=0A              > 
=0A              > @independenti=
d
=0A              > www.independentid.com
=0A              &=
gt; phil.hunt@oracle.com
=0A=
              > 
=0A              > 
=0A              > 
=
=0A              > 
=0A              > 
=0A              > O=
n 2011-06-15, at 10:01 PM, Manger, James H wrote:
=0A              > =

=0A              > > Torsten Lodderstedt needs to issue multiple=
=0A              tokens; Igor Faynberg said +1
=0A              > to =
that; John Bradley identified that OpenID Connect=0A              needs to =
request
=0A              > multiple tokens; Eran Hammer-Lahav even me=
ntioned a=0A              no-token flow as
=0A              > somethi=
ng that could make sense; ...
=0A              > >
=0A         =
     > > Issuing 0, 1 or more tokens looks like an=0A              im=
portant enough feature to fix
=0A              > now, instead of tryi=
ng to hack it in after the spec=0A              is finalised.
=0A       =
       > >
=0A              > >
=0A              > >=
; Changing the access token response [5.1] to be a=0A              JSON arr=
ay of JSON
=0A              > objects (one JSON object per issued tok=
en) seems like=0A              a simple way to get
=0A              >=
 this important functionality -- with very limited=0A              overhead=
 for services that will
=0A              > only ever issue a single t=
oken, and client written=0A              just for those services.
=0A   =
           > >
=0A              > > P.S. Does Facebook retur=
n a JSON object for its=0A              access token response (as
=0A   =
           > in draft-ietf-oauth-v2-12 that they reference), or=0A      =
        x-www-form-urlencoded
=0A              > as the example at ht=
tp://developers.facebook.com/docs/authentication/
=0A              > =
implies [4th screen shot down]?
=0A              > >
=0A       =
       > > --
=0A              > > James Manger
=0A      =
        > >
=0A              > >
=0A              > &g=
t; Eran said (on a different thread):
=0A              > >
=0A =
             > > ...if the client can authenticate with the=0A       =
       authorization server. Why not just
=0A              > include =
the client identifier and user identifier and=0A              let the autho=
rization
=0A              > server lookup what the user already autho=
rized?
=0A              > >
=0A              > >
=0A  =
            > > Igor Faynberg wrote:
=0A              > >=0A              > > +1
=0A              > >
=0A        =
      > > Torsten Lodderstedt wrote:
=0A              > >>=
; Hi,
=0A              > >>
=0A              > >> I=
 also see the need to request and issue=0A              multiple tokens in =
a single
=0A              > >> authorization process. There has=
 already=0A              been some discussion about
=0A              >=
; >> this topic roughly a year ago:
=0A              > >>=
 - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
=0A=
              > >> - http://www.ietf.org/mail-archive/web/oauth/cu=
rrent/msg03639.html
=0A              > >>
=0A              &=
gt; >> We at Deutsche Telekom have implemented an=0A              OAu=
th 2.0 extension
=0A              > >> supporting that use case=
. It's called "bulk=0A              authorization".
=0A              >=
; >>
=0A              > >> Would that be an interessting =
topic we could=0A              discuss at IETF-81 for
=0A              &=
gt; >> the re-chartering?  I could present our=0A              a=
pproach there.
=0A              > >>
=0A              > &=
gt;> regards,
=0A              > >> Torsten.
=0A         =
     > >
=0A              > >> Am 10.06.2011 21:08, schri=
eb John Bradley:
=0A              > >>> We have identified t=
he need to request=0A              multiple tokens as one issue
=0A     =
         > >>> that we would have to extend.
=0A            =
  > > _______________________________________________
=0A         =
     > > OAuth mailing list
=0A              > > OAuth@ietf.org
=0A              > > https://www.ietf.org/mailman/listinfo/oauth
=0A              =
> 
=0A              > ____________________________________________=
___
=0A              > OAuth mailing list
=0A              > OAuth@ietf.org
=0A              > https://www.ietf.org/mailman/listinfo/oauth
=0A         =
     _______________________________________________
=0A              OA=
uth mailing list
=0A              OAuth@ietf=
.org
=0A              https://www.ietf.org/mailman/l=
istinfo/oauth
=0A              
=0A              
=0A         =
   
=0A          
=0A        
=0A      
=0A     =
 
=0A    =0A    
=0A  =0A
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.iet=
f.org/mailman/listinfo/oauth



--0-1344166475-1308340941=:22630--

From phil.hunt@oracle.com  Fri Jun 17 13:04:10 2011
Return-Path: 
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 375AC9E8035 for ; Fri, 17 Jun 2011 13:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw1lH45XSSLR for ; Fri, 17 Jun 2011 13:04:09 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id DD1B69E8030 for ; Fri, 17 Jun 2011 13:04:08 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5HK44mj028637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2011 20:04:06 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5HK42ex006043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 20:04:03 GMT
Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5HK3vbK006114; Fri, 17 Jun 2011 15:03:57 -0500
Received: from [192.168.1.3] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Jun 2011 13:03:56 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-8--678645210
From: Phil Hunt 
In-Reply-To: <1308340941.22630.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Fri, 17 Jun 2011 13:03:56 -0700
Message-Id: <64D92CA3-7D30-4625-B037-6CE7C61353FC@oracle.com>
References: 	<4DF3198C.8080901@lodderstedt.net>	<4DF64BF3.7010602@alcatel-lucent.com>	<255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>		<90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET>	<1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com>  <4DFBA7E8.20101@mitre.org> <1308340941.22630.YahooMailNeo@web31802.mail.mud.yahoo.com>
To: "William J. Mills" 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090205.4DFBB337.000E:SCFSTAT5015188,ss=1,fgs=0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jun 2011 20:04:10 -0000

--Apple-Mail-8--678645210
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1

Seems a reasonable approach/requirement.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-17, at 1:02 PM, William J. Mills wrote:

> This feels right to me.  Additionally, any client consuming multiple =
tokens (whcih would be new) shoudl be able to add something onto the =
token request indicating they are capable of such.  This means we never =
break existing clients.
>=20
> From: Justin Richer 
> To: oauth@ietf.org
> Sent: Friday, June 17, 2011 12:15 PM
> Subject: Re: [OAUTH-WG] issuing multiple tokens
>=20
> Incidentally, I'd like to clarify my position that the below or any =
other kind of multi-token formatting doesn't belong in the core spec.
>=20
>  -- Justin
>=20
> On 6/17/2011 9:46 AM, Justin Richer wrote:
>>=20
>> I completely agree that the single-token case needs to be left alone, =
and I rather like this idea. The AS would return something like:
>>=20
>> {=20
>>  access_token: [
>>     {=20
>>       access_token: "1234656",
>>       expires_in: 3600,
>>       token_type: bearer
>>     },
>>     {
>>       access_token: "abcdefg",
>>       expires_in: 3600,
>>       token_type: MAC,
>>       mac_stuff: "goes_here"
>>     }
>>   ],
>>   token_type: multiple
>> }
>>=20
>> This would not only let clients who are doing the common one-token =
flow ignore the "multiple" token type, it would also allow for re-use of =
token storage libraries for the inner token bits. And you could go crazy =
and pass a multiple token full of multiple tokens, too. It's turtles all =
the way down!
>>=20
>>  -- Justin=20
>>=20
>> On 6/16/2011 7:23 PM, William J. Mills wrote:
>>>=20
>>> Probably defining a token type of "multiple_tokens" would be my =
preference, and if you get that back then you have to parse an array of =
{type, token}*.  What that array looks like could be JSON in the =
payload, or something else.  That leaves the single token use case =
alone.
>>>=20
>>> From: Eran Hammer-Lahav 
>>> To: Phil Hunt ; "Manger, James H" =

>>> Cc: OAuth WG 
>>> Sent: Wednesday, June 15, 2011 10:46 PM
>>> Subject: Re: [OAUTH-WG] issuing multiple tokens
>>>=20
>>> It is not an important enough feature. Parsing an array response =
when 99.99% will be a single object array is               annoying. =
Also, what would you return in case of error? A single object? What is =
the client supposed to do if it gets an empty array? Array with more =
than one token?
>>>=20
>>> *This* would be the hack... If this is something people want to =
deploy, a full proposal end-to-end is required.               And not =
now.
>>>=20
>>> EHL
>>>=20
>>>=20
>>> > -----Original Message-----
>>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> > Of Phil Hunt
>>> > Sent: Wednesday, June 15, 2011 10:40 PM
>>> > To: Manger, James H
>>> > Cc: OAuth WG
>>> > Subject: Re: [OAUTH-WG] issuing multiple tokens
>>> >=20
>>> > +1
>>> >=20
>>> > Phil
>>> >=20
>>> > @independentid
>>> > www.independentid.com
>>> > phil.hunt@oracle.com
>>> >=20
>>> >=20
>>> >=20
>>> >=20
>>> >=20
>>> > On 2011-06-15, at 10:01 PM, Manger, James H wrote:
>>> >=20
>>> > > Torsten Lodderstedt needs to issue multiple tokens; Igor =
Faynberg said +1
>>> > to that; John Bradley identified that OpenID Connect needs to =
request
>>> > multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow =
as
>>> > something that could make sense; ...
>>> > >
>>> > > Issuing 0, 1 or more tokens looks like an important enough =
feature to fix
>>> > now, instead of trying to hack it in after the spec is finalised.
>>> > >
>>> > >
>>> > > Changing the access token response [5.1] to be a JSON array of =
JSON
>>> > objects (one JSON object per issued token) seems like a simple way =
to get
>>> > this important functionality -- with very limited overhead for =
services that will
>>> > only ever issue a single token, and client written just for those =
services.
>>> > >
>>> > > P.S. Does Facebook return a JSON object for its access token =
response (as
>>> > in draft-ietf-oauth-v2-12 that they reference), or =
x-www-form-urlencoded
>>> > as the example at =
http://developers.facebook.com/docs/authentication/
>>> > implies [4th screen shot down]?
>>> > >
>>> > > --
>>> > > James Manger
>>> > >
>>> > >
>>> > > Eran said (on a different thread):
>>> > >
>>> > > ...if the client can authenticate with the authorization server. =
Why not just
>>> > include the client identifier and user identifier and let the =
authorization
>>> > server lookup what the user already authorized?
>>> > >
>>> > >
>>> > > Igor Faynberg wrote:
>>> > >
>>> > > +1
>>> > >
>>> > > Torsten Lodderstedt wrote:
>>> > >> Hi,
>>> > >>
>>> > >> I also see the need to request and issue multiple tokens in a =
single
>>> > >> authorization process. There has already been some discussion =
about
>>> > >> this topic roughly a year ago:
>>> > >> - =
http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
>>> > >> - =
http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html
>>> > >>
>>> > >> We at Deutsche Telekom have implemented an OAuth 2.0 extension
>>> > >> supporting that use case. It's called "bulk authorization".
>>> > >>
>>> > >> Would that be an interessting topic we could discuss at IETF-81 =
for
>>> > >> the re-chartering?  I could present our approach there.
>>> > >>
>>> > >> regards,
>>> > >> Torsten.
>>> > >
>>> > >> Am 10.06.2011 21:08, schrieb John Bradley:
>>> > >>> We have identified the need to request multiple tokens as one =
issue
>>> > >>> that we would have to extend.
>>> > > _______________________________________________
>>> > > OAuth mailing list
>>> > > OAuth@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/oauth
>>> >=20
>>> > _______________________________________________
>>> > 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
>>>=20
>>>=20
>>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail-8--678645210
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Phil

@independentid
www.independentid.com
phil.hunt@oracle.com








On 2011-06-17, at 1:02 PM, William J. Mills =
wrote:

This feels right to me.  =
Additionally, any client consuming multiple tokens (whcih would be new) =
shoudl be able to add something onto the token request indicating they =
are capable of such.  This means we never break existing =
clients.

From: Justin Richer <jricher@mitre.org>
To: oauth@ietf.org
Sent: Friday, June 17, 2011 =
12:15 PM
Subject: =
Re: [OAUTH-WG]
 issuing multiple tokens




 =20

   =20
  Incidentally, I'd like to clarify my position that the below or any
    other kind of multi-token formatting doesn't belong in the core
    spec.

    

     -- Justin

    

    On 6/17/2011 9:46 AM, Justin Richer wrote:
    


     =20
      I completely agree that the single-token case needs to be left
      alone, and I rather like this idea. The AS would return something
      like:

      

      { 

       access_token: [

          { 

            access_token: "1234656",

            expires_in: 3600,

            token_type: bearer

          },

          {

            access_token: "abcdefg",

            expires_in: 3600,

            token_type: MAC,

            mac_stuff: "goes_here"

          }

        ],

        token_type: multiple

      }

      

      This would not only let clients who are doing the common one-token
      flow ignore the "multiple" token type, it would also allow for
      re-use of token storage libraries for the inner token bits. And
      you could go crazy and pass a multiple token full of multiple
      tokens, too. It's turtles all the way down!

      

       -- Justin 

      

      On 6/16/2011 7:23 PM, William J. Mills wrote:
      

        

          
Probably defining a token type of "multiple_tokens"
              would be my preference, and if you get that back then you
              have to parse an array of {type, token}*.  What that =
array
              looks like could be JSON in the payload, or something
              else.  That leaves the single token use case =
alone.

            

          


          

          

            

                
From:
                Eran Hammer-Lahav <eran@hueniverse.com>

                To: =
Phil
                Hunt <phil.hunt@oracle.com>;
                "Manger, James H" <James.H.Manger@team.te=
lstra.com>

                Cc: =
OAuth
                WG <oauth@ietf.org>

                Sent:
                Wednesday, June 15, 2011 10:46 PM

                Subject:
                Re: [OAUTH-WG] issuing multiple tokens

              

              It is not an important enough feature. Parsing an array
              response when 99.99% will be a single object array is
              annoying. Also, what would you return in case of error? A
              single object? What is the client supposed to do if it
              gets an empty array? Array with more than one token?

              

              *This* would be the hack... If this is something people
              want to deploy, a full proposal end-to-end is required.
              And not now.

              

              EHL

              

              

              > -----Original Message-----

              > From: oauth-bounces@ietf.org
              [mailto:oauth-bounces@ietf.org]
              On Behalf

              > Of Phil Hunt

              > Sent: Wednesday, June 15, 2011 10:40 PM

              > To: Manger, James H

              > Cc: OAuth WG

              > Subject: Re: [OAUTH-WG] issuing multiple tokens

              > 

              > +1

              > 

              > Phil

              > 

              > @independentid

              > www.independentid.com

              > phil.hunt@oracle.com

              > 

              > 

              > 

              > 

              > 

              > On 2011-06-15, at 10:01 PM, Manger, James H =
wrote:

              > 

              > > Torsten Lodderstedt needs to issue multiple
              tokens; Igor Faynberg said +1

              > to that; John Bradley identified that OpenID Connect
              needs to request

              > multiple tokens; Eran Hammer-Lahav even mentioned a
              no-token flow as

              > something that could make sense; ...

              > >

              > > Issuing 0, 1 or more tokens looks like an
              important enough feature to fix

              > now, instead of trying to hack it in after the spec
              is finalised.

              > >

              > >

              > > Changing the access token response [5.1] to be a
              JSON array of JSON

              > objects (one JSON object per issued token) seems like
              a simple way to get

              > this important functionality -- with very limited
              overhead for services that will

              > only ever issue a single token, and client written
              just for those services.

              > >

              > > P.S. Does Facebook return a JSON object for its
              access token response (as

              > in draft-ietf-oauth-v2-12 that they reference), or
              x-www-form-urlencoded

              > as the example at http://develo=
pers.facebook.com/docs/authentication/

              > implies [4th screen shot down]?

              > >

              > > --

              > > James Manger

              > >

              > >

              > > Eran said (on a different thread):

              > >

              > > ...if the client can authenticate with the
              authorization server. Why not just

              > include the client identifier and user identifier and
              let the authorization

              > server lookup what the user already authorized?

              > >

              > >

              > > Igor Faynberg wrote:

              > >

              > > +1

              > >

              > > Torsten Lodderstedt wrote:

              > >> Hi,

              > >>

              > >> I also see the need to request and issue
              multiple tokens in a single

              > >> authorization process. There has already
              been some discussion about

              > >> this topic roughly a year ago:

              > >> - =
http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.

              > >> - =
http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html

              > >>

              > >> We at Deutsche Telekom have implemented an
              OAuth 2.0 extension

              > >> supporting that use case. It's called "bulk
              authorization".

              > >>

              > >> Would that be an interessting topic we could
              discuss at IETF-81 for

              > >> the re-chartering?  I could present our
              approach there.

              > >>

              > >> regards,

              > >> Torsten.

              > >

              > >> Am 10.06.2011 21:08, schrieb John =
Bradley:

              > >>> We have identified the need to request
              multiple tokens as one issue

              > >>> that we would have to extend.

              > > =
_______________________________________________

              > > 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

              

              

            

          

        

      

      

    

    

 =20

_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<=
br>
_______________________________________________=

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail-8--678645210--

From mscurtescu@google.com  Fri Jun 17 19:14:40 2011
Return-Path: 
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 279FD11E81D0 for ; Fri, 17 Jun 2011 19:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah9T5dePZ8iu for ; Fri, 17 Jun 2011 19:14:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3210E11E81D9 for ; Fri, 17 Jun 2011 19:14:39 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p5I2Eb3t030762 for ; Fri, 17 Jun 2011 19:14:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308363278; bh=hvCzPNKD0HW2FOe3Bajjg6tYq+Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mYngCKcvxls79X/i55b6nvhgFXP066vfkdSiAI+MIHXA8nHBA6zJVqQXA+1C1FwTl /9v9rL6tVqKNP/UM+9lHg==
Received: from gya6 (gya6.prod.google.com [10.243.49.6]) by wpaz24.hot.corp.google.com with ESMTP id p5I2EaOg005432 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Jun 2011 19:14:36 -0700
Received: by gya6 with SMTP id 6so77680gya.17 for ; Fri, 17 Jun 2011 19:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=cpgDZrLeA8MyhwjlWMut9zVrfKt3Q+nTpvWi30rrNQk=; b=SIRoiolCppqr5GCYvS4Ewrh2C9LMqXXcq6K5w/UFc/KqpLY7ht3sJwcxIwZ+Sf2VqN 9uMWliXTqRpixmeYSlHg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=xUBZGmtL+Ybpxmc3PCfrNEFKeNCqyUmz9wdrFUWIa+NQNh8127abuONkAH68KOCBLw 2oRnoqFqCS46apAg625Q==
Received: by 10.101.147.20 with SMTP id z20mr3197144ann.79.1308363276216; Fri, 17 Jun 2011 19:14:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.14.19 with HTTP; Fri, 17 Jun 2011 19:14:16 -0700 (PDT)
In-Reply-To: 
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110617094033.5359726zl63xc2kg@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
From: Marius Scurtescu 
Date: Fri, 17 Jun 2011 19:14:16 -0700
Message-ID: 
To: David Recordon 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 02:14:40 -0000

On Fri, Jun 17, 2011 at 12:13 PM, David Recordon  wrot=
e:
> +1 Eran
>
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav =
 wrote:
>> OAuth has been successful because of its simple architecture and because=
 it is based on actual deployment experience. Offering multi-token response=
s would be premature standardization. I am not convinced that adding it lat=
er would entail any real technical difficulty.

+1

OpenID Connect is a good example that adding it later is not that
difficult. In this case the other token is returned as a separate
parameter, which is much better IMO than an array.

Marius

From mscurtescu@google.com  Fri Jun 17 19:23:25 2011
Return-Path: 
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 B589B11E81DF for ; Fri, 17 Jun 2011 19:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qylECCl6q+-N for ; Fri, 17 Jun 2011 19:23:24 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0111E80F8 for ; Fri, 17 Jun 2011 19:23:18 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p5I2NHBv031582 for ; Fri, 17 Jun 2011 19:23:17 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308363797; bh=L3G25MDWNy3qoW3HhNDtF+jRo6M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VJf4H1KhEkHLXGygZr6vEVOGK3bMFPifjtoh1dkhc08FlqVo+dvPtRTiRTu0kgkxa nba+6LUvISosS5wB5MrjQ==
Received: from gxk26 (gxk26.prod.google.com [10.202.11.26]) by wpaz24.hot.corp.google.com with ESMTP id p5I2NGHu010852 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Jun 2011 19:23:16 -0700
Received: by gxk26 with SMTP id 26so1999564gxk.4 for ; Fri, 17 Jun 2011 19:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fbbKBVrMqY7iBk5sTcSYkdxMI/RKNQmBeGKvq4q91f8=; b=ftfRq0Iy1TrzqDRp27qNXrnc5n1oFoAmJ2yrZ3iclrvh+eEGAB60VXE0UiDc/pqg13 xqf9Nhb/OpF9UpzH4meA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=g1EuvMu3g2wk+a5TzAzAso8I37nO27lb0776OEQgj2MPhE+9kdXhGFR5yoiSQWTBb8 v/gCi8RrX+BHnzuIg++Q==
Received: by 10.101.184.37 with SMTP id l37mr3032360anp.167.1308363796091; Fri, 17 Jun 2011 19:23:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.14.19 with HTTP; Fri, 17 Jun 2011 19:22:56 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986C18@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C18@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu 
Date: Fri, 17 Jun 2011 19:22:56 -0700
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 02:23:25 -0000

On Wed, Jun 15, 2011 at 6:09 PM, Eran Hammer-Lahav  wrote:
>
>> -----Original Message-----
>> From: Shane B Weeden [mailto:sweeden@au1.ibm.com]
>> Sent: Wednesday, June 15, 2011 3:19 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
>>
>> > From: Eran Hammer-Lahav 
>> > To: OAuth WG 
>> > Date: 16-06-11 05:43 AM
>> > Subject: [OAUTH-WG] Redirection URI and Implicit grant Sent by:
>> > oauth-bounces@ietf.org
>> >
>> > This is coming from recent experience building a full web service and
>> > multiple clients using OAuth 2.0. I am going to make these changes to
>> > my own implementation and would like to raise the questions here and
>> > discuss possible changes.
>> >
>> > A few questions:
>> >
>> > 1. Why not require the registration of a redirection URI for implicit
>> > grant requests, removing the redirect_uri parameter completely from
>> > the request (the client can still use the state
>> parameter)?
>>
>> I can imagine situations where one-or-more redirect URI's may be required
>> rather than a single explicit URI. I think that either a child-urlpath-of-the-
>> registered URI, and/or the ability to register multiple valid URI's for a
>> particular client id allows this without being overly restrictive.
>>
>
> Then just use multiple client identifiers if you need multiple redirection URIs, or better yet, use the state parameter and route the request on the client side based on the state value.

If you allow localhost or non-routable IP addresses in the redirect
URI this is not possible.


> Authorization server who want to be fancy can allow you to register more than one and let you indicate which one you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1).

What Brian said. Plus, this is extremely fragile and confusing, as
soon as the client edits its registration information the order may
change.


Marius

From mscurtescu@google.com  Fri Jun 17 19:25:47 2011
Return-Path: 
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 BA2BD11E811F for ; Fri, 17 Jun 2011 19:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrD-BHeE+skx for ; Fri, 17 Jun 2011 19:25:47 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2474311E80F8 for ; Fri, 17 Jun 2011 19:25:47 -0700 (PDT)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5I2PjA0027339 for ; Fri, 17 Jun 2011 19:25:46 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308363946; bh=AYbw4vl6/3UobWanB/J0LTCnEpA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=eBOJxbk6bHVYaL+++1fYzw3twZ2J4UEbHRg4Ec39LqNYss4OPPDJNaboNKYwdO2X/ CafdCSO65BWzfnJox0kfQ==
Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq11.eem.corp.google.com with ESMTP id p5I2POlr001535 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Jun 2011 19:25:44 -0700
Received: by yib12 with SMTP id 12so2143720yib.16 for ; Fri, 17 Jun 2011 19:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=O9RtwJW8YJjms3jqDcuqDVyu3PbB9ZrbkVhSrA62VbQ=; b=xIHy4/+BvWUwIYQEVt/nW5I0d9cCXNZspJerNPqMkIIVHumam1TZ31b66bT8L58OHX P3cMD9ypKn97Yd7zDHHg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=N1px3vnCRsjEZUI6wJC191I4aw9o1d1l7i/65NECuhgdb2kn8Gr1rVQ2npQ8nCLHMV v1cdVRpz5yIxW15lMG/w==
Received: by 10.101.19.8 with SMTP id w8mr3113900ani.57.1308363944174; Fri, 17 Jun 2011 19:25:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.14.19 with HTTP; Fri, 17 Jun 2011 19:25:24 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11286961CF7@WSMSG3153V.srv.dir.telstra.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986B71@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11286961CF7@WSMSG3153V.srv.dir.telstra.com>
From: Marius Scurtescu 
Date: Fri, 17 Jun 2011 19:25:24 -0700
Message-ID: 
To: "Manger, James H" 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 02:25:47 -0000

On Wed, Jun 15, 2011 at 7:36 PM, Manger, James H
 wrote:
> It seems like an authorization server receiving a request with an
> unregistered redirect_uri of https://example.org/ can tell the user:
>
>
>
> =A0 =93Permission will be passed to your browser then onto *example.org*=
=94
>
>
>
> An authorization server receiving a request with a registered redirect_ur=
i
> of https://example.net/ can tell the user:
>
>
>
> =A0 =93Permission will be passed to your browser then onto *WidgetXYZ by =
Example
> Inc (example.net) [logo]*=94
>
>
>
> Where the label, company, and logo are extra details from the registratio=
n,
> hopefully after some verification by the authorization server that all th=
ese
> details are a consistent set. That verification could come from some
> discovery on the redirect_uri, or from reputation stats =96 perhaps even
> without a priori registration.
>
>
>
> We might be better off ditching the client_id field and just keeping
> redirect_uri in the implicit grant. If the value is registered (or the
> server has done some discovery on it, or has some reputation stats for it=
)
> it can display a more user-friendly permission message.

Several clients may register the exact same redirect URI: localhost or
non-routable IP address. You cannot uniquely identify the client based
on the redirect URI.

Similarly, you cannot perform discovery in these cases either.

Marius

From torsten@lodderstedt.net  Fri Jun 17 23:25:00 2011
Return-Path: 
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 39D6311E80B3 for ; Fri, 17 Jun 2011 23:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRjSV+adyTTm for ; Fri, 17 Jun 2011 23:24:59 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26911E807C for ; Fri, 17 Jun 2011 23:24:58 -0700 (PDT)
Received: from [79.253.59.13] (helo=[192.168.71.31]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QXoxl-0004he-0t; Sat, 18 Jun 2011 08:24:57 +0200
References:  <4DF3198C.8080901@lodderstedt.net> <4DF64BF3.7010602@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E112869E4184@WSMSG3153V.srv.dir.telstra.com>  <90C41DD21FB7C64BB94121FBBC2E7234475E986C38@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1308266617.96163.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E11286A56A2C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986E2D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110617094033.5359726zl63xc2kg@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E7234475E986E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
User-Agent: K-9 Mail for Android
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----YYJ5WAANM36GNKIPYBJ6J9RL0L3WS2"
From: Torsten Lodderstedt 
Date: Sat, 18 Jun 2011 08:24:49 +0200
To: Marius Scurtescu , David Recordon 
Message-ID: 
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] issuing multiple tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 06:25:00 -0000

------YYJ5WAANM36GNKIPYBJ6J9RL0L3WS2
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

I assume you refer to the openid parameter. This parameter is not general purpose but problem specific. Thus it is in my opinion not suited as an example for a general purpose standard.

regards,
Torsten.



Marius Scurtescu  schrieb:

On Fri, Jun 17, 2011 at 12:13 PM, David Recordon  wrote:
> +1 Eran
>
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav  wrote:
>> OAuth has been successful because of its simple architecture and because it is based on actual deployment experience. Offering multi-token responses would be premature standardization. I am not convinced that adding it later would entail any real technical difficulty.

+1

OpenID Connect is a good example that adding it later is not that
difficult. In this case the other token is returned as a separate
parameter, which is much better IMO than an array.

Marius
_____________________________________________

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------YYJ5WAANM36GNKIPYBJ6J9RL0L3WS2
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

I assume you refer to the openid parameter. This parameter is not general purpose but problem specific. Thus it is in my opinion not suited as an example for a general purpose standard.



regards,

Torsten.





Marius Scurtescu <mscurtescu@google.com> schrieb:


On Fri, Jun 17, 2011 at 12:13 PM, David Recordon <recordond@gmail.com> wrote:
> +1 Eran
>
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> OAuth has been successful because of its simple architecture and because it is based on actual deployment experience. Offering multi-token responses would be premature standardization. I am not convinced that adding it later would entail any real technical difficulty.

+1

OpenID Connect is a good example that adding it later is not that
difficult. In this case the other token is returned as a separate
parameter, which is much better IMO than an array.

Marius

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------YYJ5WAANM36GNKIPYBJ6J9RL0L3WS2--


From cmortimore@salesforce.com  Sat Jun 18 12:42:28 2011
Return-Path: 
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 7A76B11E8223 for ; Sat, 18 Jun 2011 12:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84KD45qWGj47 for ; Sat, 18 Jun 2011 12:42:27 -0700 (PDT)
Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by ietfa.amsl.com (Postfix) with SMTP id 993EC11E8220 for ; Sat, 18 Jun 2011 12:42:27 -0700 (PDT)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKTfz/oooQFwJeORVVGQ1D54LWIpUoHIFC@postini.com; Sat, 18 Jun 2011 12:42:27 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Sat, 18 Jun 2011 12:42:26 -0700
From: Chuck Mortimore 
To: "oauth@ietf.org" 
Date: Sat, 18 Jun 2011 12:42:25 -0700
Thread-Topic: New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCg==
Message-ID: 
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CA224DB11BE41cmortimoresalesforcecom_"
MIME-Version: 1.0
Subject: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 19:42:28 -0000

--_000_CA224DB11BE41cmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A number of us in the community have been working on a general model for th=
e use of Assertions in OAuth2 for both client authentication, as well as au=
thorization grants.  We've reached general consensus on a doc that I've pub=
lished as a draft:

http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt

Feedback and discussion welcome!

Thanks

-cmort

--_000_CA224DB11BE41cmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



New Assertion Draft for review


A number of us =
in the community have been working on a general model for the use of Assert=
ions in OAuth2 for both client authentication, as well as authorization gra=
nts.  We’ve reached general consensus on a doc that I’ve p=
ublished as a draft:



=
http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt



Feedback and discussion welcome!



Thanks



-cmort




--_000_CA224DB11BE41cmortimoresalesforcecom_--

From Michael.Jones@microsoft.com  Sat Jun 18 13:08:11 2011
Return-Path: 
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 E945211E8203 for ; Sat, 18 Jun 2011 13:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9PyxRE3uQwa for ; Sat, 18 Jun 2011 13:08:10 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A0B6111E81FD for ; Sat, 18 Jun 2011 13:08:10 -0700 (PDT)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 18 Jun 2011 13:08:10 -0700
Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.197]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0289.008; Sat, 18 Jun 2011 13:08:09 -0700
From: Mike Jones 
To: Chuck Mortimore , "oauth@ietf.org" 
Thread-Topic: New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCgAAsHeQ
Date: Sat, 18 Jun 2011 20:08:08 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394348CD832D@TK5EX14MBXC202.redmond.corp.microsoft.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394348CD832DTK5EX14MBXC202r_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 20:08:12 -0000

--_000_4E1F6AAD24975D4BA5B168042967394348CD832DTK5EX14MBXC202r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Chuck.  Adding context, this document moves the common parts of the =
SAML Profile and the JWT Profile to a common assertions spec.  The token-type specific parts w=
ill then become profiles of this common doc.

Thanks for spearheading this, Chuck!

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Saturday, June 18, 2011 12:42 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] New Assertion Draft for review

A number of us in the community have been working on a general model for th=
e use of Assertions in OAuth2 for both client authentication, as well as au=
thorization grants.  We've reached general consensus on a doc that I've pub=
lished as a draft:

http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt

Feedback and discussion welcome!

Thanks

-cmort

--_000_4E1F6AAD24975D4BA5B168042967394348CD832DTK5EX14MBXC202r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





New Assertion Draft for review






Thanks Chuck.  Addin=
g context, this document moves the common parts of the
SAML Profile and the
JWT Profile to a common assertions spec.  The token-type specific=
 parts will then become profiles of this common doc.


 <=
/p>

Thanks for spearheading t=
his, Chuck!


 <=
/p>

    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike


 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Chuck Mortimore

Sent: Saturday, June 18, 2011 12:42 PM

To: oauth@ietf.org

Subject: [OAUTH-WG] New Assertion Draft for review=







 


A number of us in the community have b=
een working on a general model for the use of Assertions in OAuth2 for both=
 client authentication, as well as authorization grants.
  We’ve reached general consensus on a doc that I’ve publi=
shed as a draft:



=
http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt



Feedback and discussion welcome!



Thanks



-cmort 






--_000_4E1F6AAD24975D4BA5B168042967394348CD832DTK5EX14MBXC202r_--

From hardjono@mit.edu  Mon Jun 20 11:00:09 2011
Return-Path: 
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 781E411E815E for ; Mon, 20 Jun 2011 11:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.312
X-Spam-Level: 
X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt7DoO3xJcSR for ; Mon, 20 Jun 2011 11:00:08 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8211E80B2 for ; Mon, 20 Jun 2011 11:00:08 -0700 (PDT)
X-AuditID: 1209190f-b7b0eae000000a42-80-4dff8aac6995
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E2.62.02626.CAA8FFD4; Mon, 20 Jun 2011 14:00:12 -0400 (EDT)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p5KI06bm019358;  Mon, 20 Jun 2011 14:00:06 -0400
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p5KHxhG9019208; Mon, 20 Jun 2011 14:00:04 -0400
Received: from oc11exhub1.exchange.mit.edu (18.9.3.11) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 20 Jun 2011 13:59:48 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub1.exchange.mit.edu ([18.9.3.11]) with mapi; Mon, 20 Jun 2011 13:59:54 -0400
From: Thomas Hardjono 
To: Shane B Weeden 
Date: Mon, 20 Jun 2011 13:59:53 -0400
Thread-Topic: [OAUTH-WG] Client authentication requirement
Thread-Index: AcwtA5+G8KVruI2qSXe2FX15tE3yUgCbgvZg
Message-ID: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DFA5C9A.7060403@lodderstedt.net>  <4DFA5FEF.90201@lodderstedt.net>  <4DFA621B.7060904@lodderstedt.net>  <4DFA66B5.1090205@lodderstedt.net>  <4DFA6C76.8050601@lodderstedt.net>  <4DFA7251.9060602@alcatel-lucent.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRmVeSWpSXmKPExsUixCmqrLum67+vwZVGC4uTb1+xWfzYtJHJ gcnjzfMljB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4sbCJseCXXMW+B7PZGxinyHUxcnJICJhI vL3bwgphi0lcuLeerYuRi0NIYB+jxIlTp9ghnAOMEi1rPzJCOMcZJXbNnwZVtpVRor/vFlTZ BEaJT+/OsYAMYxPQkDj3ey9QgoNDBMi+M60aJMwsoCqxfvVFJhCbBcg+eGQX2G5hAUuJv8dB yjmByq0k3nR2QtlGEpMvPGIEsXkFAiQ2f/oBtXg+u0TX5iNggzgFXCXe/J8N1sAI9MT3U2uY IJaJS9x6Mp8J4jlBiUWz9zDDPPpv10M2iHpRiTvt6xlB7mQW0JRYv0sfolVRYkr3Q3aIvYIS J2c+YZnAKDkLydRZCB2zkHTMQtKxgJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5q SukmRnBsSvLvYPx2UOkQowAHoxIPb0/pf18h1sSy4srcQ4ySHExKorz8HUAhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIrzxj//5CvGmJFZWpRblw6SkOViUxHnLvYHaBNITS1KzU1MLUotgsjIc HEoSvIs6gbKCRanpqRVpmTklCGkmDk6Q4TxAw++B1PAWFyTmFmemQ+RPMSpKifN+AkkIgCQy SvPgemGp8xWjONArwryLQap4gGkXrvsV0GAmoMH/X4FcXVySiJCSamBkqnA9re/+t//79+DX 7cap0bo81gGRd9f8ObtdXHDFvNtOCqYvPy2Rnhr8r88o+ZcJ693XZ7+LNv349uzVuvr2n7vX FddImhSdSFt5szhE8M+u5zX3mTpeZe7nrBB7+GV9e5V1VoX4hwl31n6zPfxuEfP/sFmfvu5p 1Lx8Pip/o5Hh6838D50fKbEUZyQaajEXFScCAJiJfSt4AwAA
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jun 2011 18:00:09 -0000

DQoNCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo+IFNlbnQ6IEZy
aWRheSwgSnVuZSAxNywgMjAxMSAxMTozMSBBTQ0KPiBUbzogU2hhbmUgQiBXZWVkZW47IERhdmUg
TmVsc29uDQo+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBD
bGllbnQgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQNCj4gDQo+IFNoYW5lIEIgV2VlZGVuIDxz
d2VlZGVuQGF1MS5pYm0uY29tPiBzY2hyaWViOg0KPiANCj4gPkFzIEkgdW5kZXJzdGFuZCBpdCwg
d2hhdCB5b3UndmUgZGVzY3JpYmVkIGlzIHByZWNpc2VseSB0aGUgaW50ZW50IG9mDQo+ID50aGUg
cmVmcmVzaCB0b2tlbi4gVGhlIG9ubGluZSByZWdpc3RyYXRpb24gcHJvY2VzcyB5b3UgcmVmZXIg
dG8gaXMgYQ0KPiA+Y29ycmVzcG9uZGluZyBvbmUtdGltZSBhdXRob3JpemF0aW9uIGNvZGUgZmxv
dy4gVGhlIGF1dGhvcml6YXRpb24gY29kZQ0KPiA+ZWZmZWN0aXZlbHkgYmVjb21lcyBhIG9uZS10
aW1lLXVzZSwgc2hvcnQtbGl2ZWQgY3JlZGVudGlhbCBmb3IgdGhlDQo+ID5jbGllbnQgaW5zdGFu
Y2Ugd2hpY2ggaXQgc2hvdWxkIHVzZSBpbW1lZGlhdGVseSAoc2luY2UgaXQgaGFzIGJlZW4NCj4g
PmV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyIHZpYSB0aGUgdXNlci1hZ2VudCBpbiBnZXR0
aW5nIHRvIHRoZQ0KPiA+Y2xpZW50KSB0byBkaXJlY3RseSByZXF1ZXN0IGFuIGFjY2VzcyB0b2tl
biAodHlwaWNhbGx5IHNob3J0LWxpdmVkIGFuZA0KPiA+bWF5IG5vdCBiZSBuZWVkZWQNCj4gPmlt
bWVkaWF0ZWx5KSBhbmQgcmVmcmVzaCB0b2tlbiAodHlwaWNhbGx5IGxvbmctbGl2ZWQpLiBUaGUg
cmVmcmVzaA0KPiA+dG9rZW4gaXMgc3RvcmVkIHNlY3VyZWx5IGxvY2FsbHkuIEl0IGlzIGVzc2Vu
dGlhbGx5IGFuIGluc3RhbmNlIHNlY3JldA0KPiA+Ym91bmQgdG8gdGhlIGNsaWVudCBpZCBhbmQg
cmVwcmVzZW50aW5nIHRoZSBvcmlnaW5hbCByZXNvdXJjZSBvd25lcg0KPiA+Z3JhbnQuIFByb3Zp
ZGVkOg0KPiA+MS4gVGhlIHJlc291cmNlIG93bmVyIGFuZCB1c2VyLWFnZW50IHNhZmVseSBkZWxp
dmVyIHRoZSBhdXRob3JpemF0aW9uDQo+ID5jb2RlIHRvIHRoZSBjbGllbnQgaW5zdGFuY2UgaW4g
Zmlyc3QgcGxhY2UgMi4gVGhlIGNsaWVudCB1c2VzIGl0DQo+ID5pbW1lZGlhdGVseSBpbiBzZWN1
cmUgdHJhbnNwb3J0LWxldmVsIGNvbW11bmljYXRpb25zIHRvIHRoZQ0KPiA+YXV0aG9yaXphdGlv
biBzZXJ2ZXIgYW5kIHRoZW4gc2VjdXJlbHkgc3RvcmVzIHRoZSBsb25nLWxpdmVkIHJlZnJlc2gN
Cj4gPnRva2VuIDMuIFRoZSBjbGllbnQgYWx3YXlzIHVzZXMgdGhlIHJlZnJlc2ggdG9rZW4gaW4g
c2VjdXJlDQo+ID50cmFuc3BvcnQtbGV2ZWwgY29tbXVuaWNhdGlvbnMgdG8gdGhlIGF1dGhvcml6
YXRpb24gc2VydmVyIHRvIGdldCBhbg0KPiA+YWNjZXNzIHRva2VuIChhbmQgb3B0aW9uYWxseSBy
b2xsb3ZlciB0aGUgcmVmcmVzaCB0b2tlbikgLi4gdGhlbg0KPiA+c2VjdXJlbHkgYXV0aGVudGlj
YXRpbmcgdGhlIGNsaWVudCBkb2Vzbid0IHNlZW0gdG8gYmUgYSBiaWcgZGVhbC4NCj4gPg0KPiA+
SSB0cnVzdCAidGhlIGxpc3QiIHdpbGwgY29ycmVjdCBtZSBpZiB0aGF0J3MgYSB3cm9uZyBpbnRl
cnByZXRhdGlvbiBvZg0KPiA+YSBjbGFzc2ljIG5hdGl2ZSBhcHAgc2NlbmFyaW8uDQo+IA0KPiBJ
IGZ1bGx5IGFncmVlIHdpdGggeW91ciBkZXNjcmlwdGlvbi4NCj4gDQoNClNoYW5lOg0KVGhlIGlz
c3VlIGlzIGFjdHVhbGx5IGJlc3Qgc3VtbWFyaXplZCBieSB5b3VyIG93biBlbWFpbC4gIENsaWVu
dCBhdXRoZW50aWNhdGlvbiBpcyBub3QgbmVlZGVkIHByb3ZpZGVkICgxKSwgKDIpIGFuZCAoMyku
ICBUaGlzIGlzIGEgbG90IG9mIGFzc3VtcHRpb25zIHRvIHJlbHkgb24uDQoNCj4gPiAgIDEuIFRo
ZSByZXNvdXJjZSBvd25lciBhbmQgdXNlci1hZ2VudCBzYWZlbHkgZGVsaXZlciB0aGUgDQo+ID4g
ICBhdXRob3JpemF0aW9uICBjb2RlIHRvIHRoZSBjbGllbnQgaW5zdGFuY2UgaW4gZmlyc3QgcGxh
Y2UNCg0KV2hhdCBkb2VzICJzYWZlbHkgZGVsaXZlciIgbWVhbj8gSG93IGlzIGl0IGltcGxlbWVu
dGVkIGFuZCBkZXBsb3llZD8NCg0KDQo+ID4gICAyLiBUaGUgY2xpZW50IHVzZXMgaXQNCj4gPiAg
IGltbWVkaWF0ZWx5IGluIHNlY3VyZSB0cmFuc3BvcnQtbGV2ZWwgY29tbXVuaWNhdGlvbnMgDQo+
ID4gICB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZW4gc2VjdXJlbHkgc3RvcmVz
IA0KPiA+ICAgdGhlIGxvbmctbGl2ZWQgcmVmcmVzaCB0b2tlbi4NCg0KV2hhdCBpcyB0aGUgdGlt
ZS1saW1pdCBmb3IgImltbWVkaWF0ZWx5Ij8gKDYwIHNlY3MsIDMwIG1pbnMsIDI0aHI/KS4NCg0K
DQo+ID4gICAzLiBUaGUgY2xpZW50IGFsd2F5cyB1c2VzIHRoZSByZWZyZXNoIHRva2VuIGluIHNl
Y3VyZQ0KPiA+ICAgdHJhbnNwb3J0LWxldmVsIGNvbW11bmljYXRpb25zIHRvIHRoZSBhdXRob3Jp
emF0aW9uIA0KPiA+ICAgc2VydmVyIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4NCg0KT2F1dGgyLjAt
ZHJhZnQxNiBvbmx5IGRldm90ZXMgdHdvIGxpbmVzIHRvIFg1MDkgY2VydGlmaWNhdGVzIChTZWN0
aW9uIDEwLjYpLCBmb3IgdGhlIGF1dGhvcml6YXRpb24tc2VydmVyIGFuZCBjbGllbnQgaW50ZXJh
Y3Rpb24uICBJdHMgbm90IGNsZWFyIGhvdyBiaW5kaW5nIGlzIGRvbmUgKGVnLiBiaW5kaW5nIG9m
IHRoZSBUTFMgc2Vzc2lvbiBhbmQgdHJhbnNhY3Rpb24pLCBmb3IgZXhhbXBsZSBmb3IgYXVkaXQv
bG9nZ2luZyBwdXJwb3Nlcy4gDQoNCi90aG9tYXMvDQoNCg0KDQoNCg0KDQo=

From hardjono@mit.edu  Mon Jun 20 11:32:04 2011
Return-Path: 
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 8AEEF11E81DC for ; Mon, 20 Jun 2011 11:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.169
X-Spam-Level: 
X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VsDMuZ99lqY for ; Mon, 20 Jun 2011 11:32:03 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8969F11E81DB for ; Mon, 20 Jun 2011 11:32:03 -0700 (PDT)
X-AuditID: 1209190f-b7b0eae000000a42-1d-4dff92272920
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 22.34.02626.7229FFD4; Mon, 20 Jun 2011 14:32:07 -0400 (EDT)
Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p5KIW2I9021675;  Mon, 20 Jun 2011 14:32:02 -0400
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p5KIUqmN019625; Mon, 20 Jun 2011 14:32:02 -0400
Received: from w92exhub8.exchange.mit.edu (18.7.73.14) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 20 Jun 2011 14:31:15 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub8.exchange.mit.edu ([18.7.73.14]) with mapi; Mon, 20 Jun 2011 14:31:22 -0400
From: Thomas Hardjono 
To: Chuck Mortimore , "oauth@ietf.org" 
Date: Mon, 20 Jun 2011 14:31:20 -0400
Thread-Topic: New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCgBhrCTw
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsUixG6noqs+6b+vwSIeiyvPvrJanHz7is2B yWPJkp9MHovPdzEFMEVx2aSk5mSWpRbp2yVwZWx985ul4B1fxZ6jMg2MT7m7GDk5JARMJM5/ eMwCYYtJXLi3nq2LkYtDSGAfo8Ty3m1MEM4BRolnj25DOVcZJXYu+sMI4WxllFj7bTVUZgKj xN6mfcwgw9gENCTO/d7LDmKLCMRK9J1cCxZnEVCV2NK8iAnEFhbQlti1eBYLRI2OxJtt+1gh bCOJG1dfg/XyCgRI9C5cCGYLCZhJPNxzkg3E5hQwl/hxcxFYLyPQ4d9PrQGbySwgLnHryXwm iIcEJRbN3sMM89y/XQ/ZIOpFJe60r2eEqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hAXppFpKx s5C0zELSMgtJywJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhBMcgpyb+D 8dtBpUOMAhyMSjy8PaX/fYVYE8uKK3MPMUpyMCmJ8q6fCBTiS8pPqcxILM6ILyrNSS0+xCjB wawkwhv/+J+vEG9KYmVValE+TEqag0VJnLfcG6hNID2xJDU7NbUgtQgmK8PBoSTBWwIyVLAo NT21Ii0zpwQhzcTBCTKcB2h4GkgNb3FBYm5xZjpE/hSjopQ4rxlIQgAkkVGaB9cLS5GvGMWB XhHm/dkPVMUDTK9w3a+ABjMBDf7/CuTq4pJEhJRUA2NA4pc1V4wipX5bZUhx7vbd1KAirDg/ 8OHFY3nJoV8fPOWYEFRRcKLwsKCPj4165CuX6XHPZZ34bc19Tt6Yd+mN2KGuO1av2ReEiNXx VDY+VW0TutR1tXFpQT7LolbuJzmed5qeMJQF3C7j/mHTor3tJkveyQ1SCxYdSuXJ62g2Tb3P 5nTKWomlOCPRUIu5qDgRAFZ80mNsAwAA
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jun 2011 18:32:04 -0000

Chuck,

This is a good draft. Real progress.  I wish we had this draft before the W=
G spent so much time in IETF-Prague arguing about the assertions text.

Just a short question.  Section 5.1 states that the principal identity SHOU=
LD be the client_id (for the OAuth client):

   Principal  A unique identifier for the subject of the assertion.
      When using assertions for client authentication, the Principal
      SHOULD be the client_id of the OAuth client.  When using
      assertions as an authorization grant, the Principal MUST identify
      an authorized accessor for whom the access token is being
      requested (typically the resource owner, or an authorized
      delegate).

Why is this a "SHOULD"?  (I would think this is a "MUST).

In Section 6.1 "The Principal MUST identify an authorized accessor". In Sec=
tion 6.3  "The Principal MUST identify an authorized accessor...".


PS. More broadly, I'm thinking not only of a model where the OAuth-client g=
ets an assertion from the STS/IdP server, but also of a situation in where =
the human-user (resource owner) specifically names the Subject (the OAuth C=
lient) in a multi-hop delegation case.

More questions later.

Thanks.

/thomas/


__________________________
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Chuck Mortimore
> Sent: Saturday, June 18, 2011 3:42 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] New Assertion Draft for review
>=20
> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as
> well as authorization grants.  We've reached general consensus on a doc
> that I've published as a draft:
>=20
> http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt
>=20
> Feedback and discussion welcome!
>=20
> Thanks
>=20
> -cmort=20

From tonynad@microsoft.com  Mon Jun 20 11:46:12 2011
Return-Path: 
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 9CC3511E80CC for ; Mon, 20 Jun 2011 11:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level: 
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW4uGqrjatK6 for ; Mon, 20 Jun 2011 11:46:11 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6811E808E for ; Mon, 20 Jun 2011 11:46:11 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 20 Jun 2011 11:46:10 -0700
Received: from TX2EHSOBE008.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 20 Jun 2011 11:46:10 -0700
Received: from mail175-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 20 Jun 2011 18:46:09 +0000
Received: from mail175-tx2 (localhost.localdomain [127.0.0.1])	by mail175-tx2-R.bigfish.com (Postfix) with ESMTP id 720221098360	for ; Mon, 20 Jun 2011 18:46:09 +0000 (UTC)
X-SpamScore: -27
X-BigFish: PS-27(zz9371M148cMzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail175-tx2: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2 (MessageSwitch) id 1308595569249775_2027; Mon, 20 Jun 2011 18:46:09 +0000 (UTC)
Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.250])	by mail175-tx2.bigfish.com (Postfix) with ESMTP id 219741AD0055; Mon, 20 Jun 2011 18:46:09 +0000 (UTC)
Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 20 Jun 2011 18:46:06 +0000
Received: from CH1PRD0302MB118.namprd03.prod.outlook.com ([169.254.2.45]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.056; Mon, 20 Jun 2011 18:46:05 +0000
From: Anthony Nadalin 
To: Mike Jones , Chuck Mortimore , "oauth@ietf.org" 
Thread-Topic: New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCgAAsHeQAGHi4EA=
Date: Mon, 20 Jun 2011 18:46:05 +0000
Message-ID: 
References:  <4E1F6AAD24975D4BA5B168042967394348CD832D@TK5EX14MBXC202.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348CD832D@TK5EX14MBXC202.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.28.29.69]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E72312BBDACH1PRD0302MB118_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%SALESFORCE.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: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jun 2011 18:46:12 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72312BBDACH1PRD0302MB118_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This also moves the client_credentials authentication material out of the c=
ore and into a core companion specification.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
ike Jones
Sent: Saturday, June 18, 2011 1:08 PM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re: [OAUTH-WG] New Assertion Draft for review

Thanks Chuck.  Adding context, this document moves the common parts of the =
SAML Profile and the JWT Profile to a common assertions spec.  The token-type specific parts w=
ill then become profiles of this common doc.

Thanks for spearheading this, Chuck!

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck=
 Mortimore
Sent: Saturday, June 18, 2011 12:42 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] New Assertion Draft for review

A number of us in the community have been working on a general model for th=
e use of Assertions in OAuth2 for both client authentication, as well as au=
thorization grants.  We've reached general consensus on a doc that I've pub=
lished as a draft:

http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt

Feedback and discussion welcome!

Thanks

-cmort

--_000_B26C1EF377CB694EAB6BDDC8E624B6E72312BBDACH1PRD0302MB118_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





New Assertion Draft for review






This also moves the clien=
t_credentials authentication material out of the core and into a core compa=
nion specification.


 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Saturday, June 18, 2011 1:08 PM

To: Chuck Mortimore; oauth@ietf.org

Subject: Re: [OAUTH-WG] New Assertion Draft for review






 


Thanks Chuck.  Addin=
g context, this document moves the common parts of the
SAML Profile and the
JWT Profile to a common assertions spec.  The token-type specific=
 parts will then become profiles of this common doc.


 <=
/p>

Thanks for spearheading t=
his, Chuck!


 <=
/p>

    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike


 <=
/p>





From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore

Sent: Saturday, June 18, 2011 12:42 PM

To: oauth@ietf.org

Subject: [OAUTH-WG] New Assertion Draft for review=







 


A number of us in the community have been working on a g=
eneral model for the use of Assertions in OAuth2 for both client authentica=
tion, as well as authorization grants.  We’ve
 reached general consensus on a doc that I’ve published as a draft:


=
http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt



Feedback and discussion welcome!



Thanks



-cmort 






--_000_B26C1EF377CB694EAB6BDDC8E624B6E72312BBDACH1PRD0302MB118_--

From cmortimore@salesforce.com  Mon Jun 20 12:16:48 2011
Return-Path: 
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 A070E11E81E4 for ; Mon, 20 Jun 2011 12:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNMJdE18zUB0 for ; Mon, 20 Jun 2011 12:16:46 -0700 (PDT)
Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by ietfa.amsl.com (Postfix) with SMTP id 6BD6A11E80FC for ; Mon, 20 Jun 2011 12:16:45 -0700 (PDT)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKTf+cnc6oVRYL6d+M0HMDhaDvcKjludVc@postini.com; Mon, 20 Jun 2011 12:16:46 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 20 Jun 2011 12:16:45 -0700
From: Chuck Mortimore 
To: Thomas Hardjono , "oauth@ietf.org" 
Date: Mon, 20 Jun 2011 12:16:41 -0700
Thread-Topic: New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCgBhrCTwAAIC/kA=
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CA24EAA91BEC5cmortimoresalesforcecom_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jun 2011 19:16:48 -0000

--_000_CA24EAA91BEC5cmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks Thomas - it's good to hear that it's on the right track....took awhi=
le to get both understanding and agreement.

There was a good deal of debate on SHOULD vs MUST for client_id in section =
5.1.   The argument for SHOULD was generally that there are use-cases where=
 the client_id provided as a parameter is enough, the client_id can be impl=
ied, or the assertion format may not easily allow for it.

As long as the Authorization Server can correlate the client with the keyin=
g material it uses for verification of the assertion then I think SHOULD is=
 enough.   ( note, I started out on the other side of this argument )    Th=
e SAML and JWT profiles we expect can turn this to a MUST, but we want the =
general guidance to be a little less strict.

That's the thinking...

-cmort


On 6/20/11 11:31 AM, "Thomas Hardjono"  wrote:



Chuck,

This is a good draft. Real progress.  I wish we had this draft before the W=
G spent so much time in IETF-Prague arguing about the assertions text.

Just a short question.  Section 5.1 states that the principal identity SHOU=
LD be the client_id (for the OAuth client):

   Principal  A unique identifier for the subject of the assertion.
      When using assertions for client authentication, the Principal
      SHOULD be the client_id of the OAuth client.  When using
      assertions as an authorization grant, the Principal MUST identify
      an authorized accessor for whom the access token is being
      requested (typically the resource owner, or an authorized
      delegate).

Why is this a "SHOULD"?  (I would think this is a "MUST).

In Section 6.1 "The Principal MUST identify an authorized accessor". In Sec=
tion 6.3  "The Principal MUST identify an authorized accessor...".


PS. More broadly, I'm thinking not only of a model where the OAuth-client g=
ets an assertion from the STS/IdP server, but also of a situation in where =
the human-user (resource owner) specifically names the Subject (the OAuth C=
lient) in a multi-hop delegation case.

More questions later.

Thanks.

/thomas/


__________________________
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Chuck Mortimore
> Sent: Saturday, June 18, 2011 3:42 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] New Assertion Draft for review
>
> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as
> well as authorization grants.  We've reached general consensus on a doc
> that I've published as a draft:
>
> http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt
>
> Feedback and discussion welcome!
>
> Thanks
>
> -cmort


--_000_CA24EAA91BEC5cmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: New Assertion Draft for review


Thanks Thomas &=
#8211; it’s good to hear that it’s on the right track....took a=
while to get both understanding and agreement.



There was a good deal of debate on SHOULD vs MUST for client_id in section =
5.1.   The argument for SHOULD was generally that there are use-c=
ases where the client_id provided as a parameter is enough, the client_id c=
an be implied, or the assertion format may not easily allow for it.  &=
nbsp;



As long as the Authorization Server can correlate the client with the keyin=
g material it uses for verification of the assertion then I think SHOULD is=
 enough.   ( note, I started out on the other side of this argume=
nt )    The SAML and JWT profiles we expect can turn this to=
 a MUST, but we want the general guidance to be a little less strict.



That’s the thinking...



-cmort





On 6/20/11 11:31 AM, "Thomas Hardjono" <hardjono@MIT.EDU> wrote:








Chuck,



This is a good draft. Real progress.  I wish we had this draft before =
the WG spent so much time in IETF-Prague arguing about the assertions text.=




Just a short question.  Section 5.1 states that the principal identity=
 SHOULD be the client_id (for the OAuth client):



   Principal  A unique identifier for the subject of th=
e assertion.

      When using assertions for client authen=
tication, the Principal

      SHOULD be the client_id of the OAuth cl=
ient.  When using

      assertions as an authorization grant, t=
he Principal MUST identify

      an authorized accessor for whom the acc=
ess token is being

      requested (typically the resource owner=
, or an authorized

      delegate).



Why is this a "SHOULD"?  (I would think this is a "MUST=
).



In Section 6.1 "The Principal MUST identify an authorized accessor&quo=
t;. In Section 6.3  "The Principal MUST identify an authorized ac=
cessor...".





PS. More broadly, I'm thinking not only of a model where the OAuth-client g=
ets an assertion from the STS/IdP server, but also of a situation in where =
the human-user (resource owner) specifically names the Subject (the OAuth C=
lient) in a multi-hop delegation case.



More questions later.



Thanks.



/thomas/





__________________________

> From: oauth-bounces@ietf.org [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]=
 On Behalf

> Of Chuck Mortimore

> Sent: Saturday, June 18, 2011 3:42 PM

> To: oauth@ietf.org

> Subject: [OAUTH-WG] New Assertion Draft for review

>

> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as=


> well as authorization grants.  We've reached general consensus on=
 a doc

> that I've published as a draft:

>

> http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt

>

> Feedback and discussion welcome!

>

> Thanks

>

> -cmort









--_000_CA24EAA91BEC5cmortimoresalesforcecom_--

From sweeden@au1.ibm.com  Tue Jun 21 16:18:23 2011
Return-Path: 
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 55EDA22800D for ; Tue, 21 Jun 2011 16:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.419
X-Spam-Level: 
X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obKVmnJxwT42 for ; Tue, 21 Jun 2011 16:18:22 -0700 (PDT)
Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5F228006 for ; Tue, 21 Jun 2011 16:18:22 -0700 (PDT)
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp06.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5LNHZNA030252 for ; Wed, 22 Jun 2011 09:17:35 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5LNHBO7913470 for ; Wed, 22 Jun 2011 09:17:11 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5LNIB0s002747 for ; Wed, 22 Jun 2011 09:18:11 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5LNIBhh002744; Wed, 22 Jun 2011 09:18:11 +1000
In-Reply-To: 
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DFA5FEF.90201@lodderstedt.net>	 <4DFA621B.7060904@lodderstedt.net>	 <4DFA66B5.1090205@lodderstedt.net>	 <4DFA6C76.8050601@lodderstedt.net>	 <4DFA7251.9060602@alcatel-lucent.com>	 	
X-KeepSent: 1F58A316:87F1119D-4A2578B6:007EF47D; type=4; name=$KeepSent
To: Thomas Hardjono 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Wed, 22 Jun 2011 09:08:04 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 22/06/2011 09:21:37
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Client authentication requirement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jun 2011 23:18:23 -0000

One might argue these are deployment-time considerations rather than spec
issues.



From:	Thomas Hardjono 
To:	Shane B Weeden/Australia/IBM@IBMAU
Cc:	"oauth@ietf.org" 
Date:	21-06-11 04:03 AM
Subject:	RE: [OAUTH-WG] Client authentication requirement





> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, June 17, 2011 11:31 AM
> To: Shane B Weeden; Dave Nelson
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> Shane B Weeden  schrieb:
>
> >As I understand it, what you've described is precisely the intent of
> >the refresh token. The online registration process you refer to is a
> >corresponding one-time authorization code flow. The authorization code
> >effectively becomes a one-time-use, short-lived credential for the
> >client instance which it should use immediately (since it has been
> >exposed to the resource owner via the user-agent in getting to the
> >client) to directly request an access token (typically short-lived and
> >may not be needed
> >immediately) and refresh token (typically long-lived). The refresh
> >token is stored securely locally. It is essentially an instance secret
> >bound to the client id and representing the original resource owner
> >grant. Provided:
> >1. The resource owner and user-agent safely deliver the authorization
> >code to the client instance in first place 2. The client uses it
> >immediately in secure transport-level communications to the
> >authorization server and then securely stores the long-lived refresh
> >token 3. The client always uses the refresh token in secure
> >transport-level communications to the authorization server to get an
> >access token (and optionally rollover the refresh token) .. then
> >securely authenticating the client doesn't seem to be a big deal.
> >
> >I trust "the list" will correct me if that's a wrong interpretation of
> >a classic native app scenario.
>
> I fully agree with your description.
>

Shane:
The issue is actually best summarized by your own email.  Client
authentication is not needed provided (1), (2) and (3).  This is a lot of
assumptions to rely on.

> >   1. The resource owner and user-agent safely deliver the
> >   authorization  code to the client instance in first place

What does "safely deliver" mean? How is it implemented and deployed?


> >   2. The client uses it
> >   immediately in secure transport-level communications
> >   to the authorization server and then securely stores
> >   the long-lived refresh token.

What is the time-limit for "immediately"? (60 secs, 30 mins, 24hr?).


> >   3. The client always uses the refresh token in secure
> >   transport-level communications to the authorization
> >   server to get an access token

Oauth2.0-draft16 only devotes two lines to X509 certificates (Section
10.6), for the authorization-server and client interaction.  Its not clear
how binding is done (eg. binding of the TLS session and transaction), for
example for audit/logging purposes.

/thomas/









From internet-drafts@ietf.org  Wed Jun 22 17:35:21 2011
Return-Path: 
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 ED96721F84D5; Wed, 22 Jun 2011 17:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfE07e+eIg5P; Wed, 22 Jun 2011 17:35:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3C21F84CF; Wed, 22 Jun 2011 17:35:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110623003520.13753.68501.idtracker@ietfa.amsl.com>
Date: Wed, 22 Jun 2011 17:35:20 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 00:35:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

	Title           : The OAuth 2.0 Protocol: Bearer Tokens
	Author(s)       : Michael B. Jones
                          Dick Hardt
                          David Recordon
	Filename        : draft-ietf-oauth-v2-bearer-06.txt
	Pages           : 17
	Date            : 2011-06-22

   This specification describes how to use bearer tokens when accessing
   OAuth 2.0 protected resources.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt

From Michael.Jones@microsoft.com  Wed Jun 22 17:53:25 2011
Return-Path: 
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 5C4DB228013 for ; Wed, 22 Jun 2011 17:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-8Ay+gPrQmR for ; Wed, 22 Jun 2011 17:53:23 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B805F22800E for ; Wed, 22 Jun 2011 17:53:23 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Jun 2011 17:53:23 -0700
Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.193]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0289.008; Wed, 22 Jun 2011 17:53:23 -0700
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Bearer Token Specification draft -06
Thread-Index: AcwxP+0eZ6OA/RCvSTCCsjpx71EG9w==
Date: Thu, 23 Jun 2011 00:53:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394348D04A47@TK5EX14MBXC202.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394348D04A47TK5EX14MBXC202r_"
MIME-Version: 1.0
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jun 2011 00:53:25 -0000

--_000_4E1F6AAD24975D4BA5B168042967394348D04A47TK5EX14MBXC202r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've published draft 06 of the OAuth Bearer Token Specification.  It contains the following change=
s:
*         Changed parameter name bearer_token to access_token, per working =
group consensus.
*         Changed HTTP status code for invalid_request error code from HTTP=
 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP wor=
king group experts.

It doesn't change the use of 403 (Forbidden) to (401) Unauthorized as had b=
een discussed as a possibility, also due to input from the same HTTP workin=
g group experts.

I believe that this addresses all the bearer token specification issues ari=
sing from the interim working group meeting and working group discussions s=
ince then.

The draft is available at these locations:

*         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06=
.pdf

*         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06=
.txt

*         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06=
.xml

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (wil=
l point to new versions as they are posted)

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will=
 point to new versions as they are posted)

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will=
 point to new versions as they are posted)

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will=
 point to new versions as they are posted)

*         http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion=
 repository, with html, pdf, txt, and html versions available)

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B168042967394348D04A47TK5EX14MBXC202r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I’ve published 
draft 06 of the 
OAuth Bearer Token Specification.  It contains the following chang=
es:



·     &=
nbsp;  
Changed parameter name
bearer_token to
access_token, per working group consen=
sus.




·     &=
nbsp;  
Changed HTTP status code=
 for
invalid_request error code from HTTP 4=
01 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP
 working group experts. 


 


It doesn’t change the use of 403 (Forbidden) t=
o (401) Unauthorized as had been discussed as a possibility, also due to in=
put from the same HTTP working group experts.


 


I believe that this addresses all the bearer token s=
pecification issues arising from the interim working group meeting and work=
ing group discussions since then.


 


The draft is available at these locations:


·        
http://www.ietf.org/internet-drafts/draft-ie=
tf-oauth-v2-bearer-06.pdf


·        
http://www.ietf.org/internet-drafts/draft-ie=
tf-oauth-v2-bearer-06.txt


·        
http://www.ietf.org/internet-drafts/draft-ie=
tf-oauth-v2-bearer-06.xml


·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer-06.html


·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer-06.pdf


·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer-06.txt


·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer-06.xml


·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer.html (will point to new versions as they are posted)=



·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer.pdf (will point to new versions as they are posted)<=
/p>

·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer.txt (will point to new versions as they are posted)<=
/p>

·        
http://self-issued.info/docs/draft-ietf-oaut=
h-v2-bearer.xml (will point to new versions as they are posted)<=
/p>

·        
http://svn.openid.net/repos/specifications/o=
auth/2.0/ (Subversion repository, with html, pdf, txt, and html versions av=
ailable)


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     -- Mike


 






--_000_4E1F6AAD24975D4BA5B168042967394348D04A47TK5EX14MBXC202r_--

From eve@xmlgrrl.com  Fri Jun 24 10:02:27 2011
Return-Path: 
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 8680F11E811D for ; Fri, 24 Jun 2011 10:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2n-y42AFk3R for ; Fri, 24 Jun 2011 10:02:26 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB511E80C8 for ; Fri, 24 Jun 2011 10:02:26 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id p5OH2P0p021073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 10:02:25 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Eve Maler 
Date: Fri, 24 Jun 2011 10:02:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>
To: oauth WG 
X-Mailer: Apple Mail (2.1084)
Subject: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:02:27 -0000

Zero response from the other list. Any suggestions from folks here?

Begin forwarded message:

> From: Eve Maler 
> Date: 20 June 2011 4:54:56 PM PDT
> To: oauth@googlegroups.com
> Subject: [oauth] Good list of OAuth open source?
> Reply-To: oauth@googlegroups.com
>=20
> The list at http://oauth.net/code/ seems really random and out of =
date. Does anyone have a current list of open-source software that =
supports OAuth, including drafts of 2.0?
>=20
> Thanks,
>=20
> 	Eve


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From recordond@gmail.com  Fri Jun 24 10:07:37 2011
Return-Path: 
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 683B311E80E4 for ; Fri, 24 Jun 2011 10:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level: 
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IccGQ2PBObdX for ; Fri, 24 Jun 2011 10:07:36 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4111E8108 for ; Fri, 24 Jun 2011 10:07:30 -0700 (PDT)
Received: by vws12 with SMTP id 12so3091947vws.31 for ; Fri, 24 Jun 2011 10:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dEdRqqSkPRZW2OJlNn2T0hRYwjtwMDavir0/ZKMuWyM=; b=crisvOrVDlrWIpYdmYL20z4FDfSw8nqudA7rRUcbACzQa9DkWb7gRSINDWpaxJNXrn JGQwxcWGJq933wS6XJH4K7PC80JJ1wi+1WpEARrVACOGrF/LO/Xht0/ncC+YkN5t/A6W od7n2nRDtPKkv33Zdo7RA2Xyav72HHThN/OnQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kA86Js3aS8bKsvZJPaF3MuSTQgyuVdwNYoBjUyDvmwVKHDgyCPHnHfYmeNIHyQVaKZ Irhqp5qgWwS546WaGLK6/upjk3n0iXUEPnnJyk8B6iFfYv0m38ASPI4RuZYbtgSSJe05 0PXvbrGTm5rA1Z7e26n4SGISM5emj6wxnptwI=
MIME-Version: 1.0
Received: by 10.52.24.66 with SMTP id s2mr4641027vdf.196.1308935249926; Fri, 24 Jun 2011 10:07:29 -0700 (PDT)
Received: by 10.52.168.4 with HTTP; Fri, 24 Jun 2011 10:07:29 -0700 (PDT)
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com> 
Date: Fri, 24 Jun 2011 10:07:29 -0700
Message-ID: 
From: David Recordon 
To: Eve Maler 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:07:37 -0000

I was trying to keep http://wiki.oauth.net/w/page/25236487/OAuth-2 up
to date but haven't in awhile.


On Fri, Jun 24, 2011 at 10:02 AM, Eve Maler  wrote:
> Zero response from the other list. Any suggestions from folks here?
>
> Begin forwarded message:
>
>> From: Eve Maler 
>> Date: 20 June 2011 4:54:56 PM PDT
>> To: oauth@googlegroups.com
>> Subject: [oauth] Good list of OAuth open source?
>> Reply-To: oauth@googlegroups.com
>>
>> The list at http://oauth.net/code/ seems really random and out of date. =
Does anyone have a current list of open-source software that supports OAuth=
, including drafts of 2.0?
>>
>> Thanks,
>>
>> =A0 =A0 =A0 Eve
>
>
> Eve Maler =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0http://www.xmlgrrl.com/blog
> +1 425 345 6756 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww=
w.twitter.com/xmlgrrl
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From eran@hueniverse.com  Fri Jun 24 10:09:22 2011
Return-Path: 
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 C29D911E80E4 for ; Fri, 24 Jun 2011 10:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Level: 
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyYGYJbEYNyx for ; Fri, 24 Jun 2011 10:09:22 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B2EBA11E8108 for ; Fri, 24 Jun 2011 10:09:21 -0700 (PDT)
Received: (qmail 29616 invoked from network); 24 Jun 2011 17:09:21 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Jun 2011 17:09:21 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 24 Jun 2011 10:09:19 -0700
From: Eran Hammer-Lahav 
To: Eve Maler , oauth WG 
Date: Fri, 24 Jun 2011 10:09:09 -0700
Thread-Topic: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Thread-Index: AcwykIMe99BB0oIyQMCRoBqs5T1RgAAANODA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0EFC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:09:22 -0000

oauth.net needs some love but I don't have the time. If anyone is intereste=
d in working on it, please contact me and I'll get you setup.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eve Maler
> Sent: Friday, June 24, 2011 10:02 AM
> To: oauth WG
> Subject: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>=20
> Zero response from the other list. Any suggestions from folks here?
>=20
> Begin forwarded message:
>=20
> > From: Eve Maler 
> > Date: 20 June 2011 4:54:56 PM PDT
> > To: oauth@googlegroups.com
> > Subject: [oauth] Good list of OAuth open source?
> > Reply-To: oauth@googlegroups.com
> >
> > The list at http://oauth.net/code/ seems really random and out of date.
> Does anyone have a current list of open-source software that supports
> OAuth, including drafts of 2.0?
> >
> > Thanks,
> >
> > 	Eve
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From maciej.machulak@gmail.com  Fri Jun 24 10:09:42 2011
Return-Path: 
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 D084611E813E for ; Fri, 24 Jun 2011 10:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.793
X-Spam-Level: 
X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM-Up6nuxQsp for ; Fri, 24 Jun 2011 10:09:42 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0511E80E4 for ; Fri, 24 Jun 2011 10:09:40 -0700 (PDT)
Received: by fxm15 with SMTP id 15so2274635fxm.31 for ; Fri, 24 Jun 2011 10:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PrPoxCh6yzKxDtEuI1RHx1KWH0MBnH8UaElbxEwIj8A=; b=J4DxNSHk+Vaw1o+YYzGDXQ86HrMt5X33CS7vDkojBx1arcKOiDT8K/27+1WruePGAa zaLstwzE1eHIHQOj950/8AooeHR+hC3arx6VcXuUWTbJf74RBs5SSpyQAYqAnEMpEydf SRLePt8vw8MnL7DIFfzWDx5nC+CHIKkrs1hNw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kWTXbW5tf8Pllb31e8YSdzrUTo2QKDO1QrQz8Jm2H5U4Of1d8T2cpIr90vstOhwuCH XOyFECbxFNeljlDEFPf/IKrd4CODhd/NHDiwKrYIk9aWW4dC+ubGREIqbZkkA3Ga28Hj Daot2cJEF5wAZKVZO19qz7B5f2QFFWQoykzPQ=
MIME-Version: 1.0
Received: by 10.223.16.136 with SMTP id o8mr4777440faa.21.1308935379900; Fri, 24 Jun 2011 10:09:39 -0700 (PDT)
Received: by 10.223.103.205 with HTTP; Fri, 24 Jun 2011 10:09:39 -0700 (PDT)
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com> 
Date: Fri, 24 Jun 2011 18:09:39 +0100
Message-ID: 
From: Maciej Machulak 
To: Eve Maler 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:09:43 -0000

I haven't seen such a list but it would be great to update the
existing one on oauth.net. There's the Apache Amber project [1] which
is the OAuth 2.0 implementation in Java used quite a lot. Could anyone
include it in the list, please?

Thank you in advance.

Cheers,
Maciej

[1] http://incubator.apache.org/projects/amber.html

On 24 June 2011 18:02, Eve Maler  wrote:
> Zero response from the other list. Any suggestions from folks here?
>
> Begin forwarded message:
>
>> From: Eve Maler 
>> Date: 20 June 2011 4:54:56 PM PDT
>> To: oauth@googlegroups.com
>> Subject: [oauth] Good list of OAuth open source?
>> Reply-To: oauth@googlegroups.com
>>
>> The list at http://oauth.net/code/ seems really random and out of date. =
Does anyone have a current list of open-source software that supports OAuth=
, including drafts of 2.0?
>>
>> Thanks,
>>
>> =C2=A0 =C2=A0 =C2=A0 Eve
>
>
> Eve Maler =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.xmlgrrl.c=
om/blog
> +1 425 345 6756 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.twitter.com/xmlgrrl
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--=20
Maciej Machulak
email: maciej.machulak@gmail.com
tel: +48 602 45 31 44
tel: +44 7999 606 767

From eran@hueniverse.com  Fri Jun 24 10:16:26 2011
Return-Path: 
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 47C9A11E815B for ; Fri, 24 Jun 2011 10:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level: 
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMaaluVgZ6+p for ; Fri, 24 Jun 2011 10:16:25 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 1AF3211E815D for ; Fri, 24 Jun 2011 10:16:25 -0700 (PDT)
Received: (qmail 8947 invoked from network); 24 Jun 2011 17:16:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Jun 2011 17:16:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 24 Jun 2011 10:16:16 -0700
From: Eran Hammer-Lahav 
To: David Recordon , Eve Maler 
Date: Fri, 24 Jun 2011 10:16:07 -0700
Thread-Topic: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Thread-Index: AcwykTsg1UozjxonSvaXZEgvvaC4aAAAPFaQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0EFF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:16:26 -0000

On the subject of OAuth 2.0 libraries...

Why would you need a library?? Seems to be much less work to just make the =
HTTP requests directly. And if you are using MAC, you need a MAC library, n=
ot an OAuth 2.0...

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of David Recordon
> Sent: Friday, June 24, 2011 10:07 AM
> To: Eve Maler
> Cc: oauth WG
> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>=20
> I was trying to keep http://wiki.oauth.net/w/page/25236487/OAuth-2 up to
> date but haven't in awhile.
>=20
>=20
> On Fri, Jun 24, 2011 at 10:02 AM, Eve Maler  wrote:
> > Zero response from the other list. Any suggestions from folks here?
> >
> > Begin forwarded message:
> >
> >> From: Eve Maler 
> >> Date: 20 June 2011 4:54:56 PM PDT
> >> To: oauth@googlegroups.com
> >> Subject: [oauth] Good list of OAuth open source?
> >> Reply-To: oauth@googlegroups.com
> >>
> >> The list at http://oauth.net/code/ seems really random and out of date=
.
> Does anyone have a current list of open-source software that supports
> OAuth, including drafts of 2.0?
> >>
> >> Thanks,
> >>
> >> =A0 =A0 =A0 Eve
> >
> >
> > Eve Maler =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0http://www.xmlgrrl.com/blog
> > +1 425 345 6756 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://=
www.twitter.com/xmlgrrl
> >
> > _______________________________________________
> > 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

From maciej.machulak@gmail.com  Fri Jun 24 10:23:32 2011
Return-Path: 
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 D0B4F11E815E for ; Fri, 24 Jun 2011 10:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.793
X-Spam-Level: 
X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn2oiGudMBef for ; Fri, 24 Jun 2011 10:23:31 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B34F11E809F for ; Fri, 24 Jun 2011 10:23:31 -0700 (PDT)
Received: by fxm15 with SMTP id 15so2281400fxm.31 for ; Fri, 24 Jun 2011 10:23:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+6JeGZJKHcJ7xvvaeY9xFV+Hm8mpYsnDBN/fdXtlYNQ=; b=txgRJlBZ3LvUNxOBJ+31hfgnOuxAcBpqogK6ttl+cWpxGDjhphW20BdiV1sZ4FVTnk mciK/6BWDXIxCKn56uQNiCj8qP/U+5ROqYD6iOE/Scg8LWbDigP4q2jnYYNd+XF8aNng yQtC8+PsxPRnPU8McWwlXkvFzJCaiBFGGzOlw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G5sXY+4/kTP5r/YdCKYUzGsIGpyYApdANGOOectcNwFhpgkpr4rZjx4DJ8tpmPiLLV S1v5fjY5978sVsYaa3HBrSs7NNTLMT57JdH6Ho+BLWJJaugVGLUx2YhXuIMkLqAvKE8P 1prdKE/csVvbjesoGezOoc7NLpHMB+J58TBVY=
MIME-Version: 1.0
Received: by 10.223.32.142 with SMTP id c14mr4688575fad.59.1308936210723; Fri, 24 Jun 2011 10:23:30 -0700 (PDT)
Received: by 10.223.103.205 with HTTP; Fri, 24 Jun 2011 10:23:30 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0EFF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>   <90C41DD21FB7C64BB94121FBBC2E7234475EAB0EFF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 24 Jun 2011 18:23:30 +0100
Message-ID: 
From: Maciej Machulak 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 17:23:33 -0000

These are not only client libraries, they work for AS and RS too.

Cheers,
Maciej

On 24 June 2011 18:16, Eran Hammer-Lahav  wrote:
> On the subject of OAuth 2.0 libraries...
>
> Why would you need a library?? Seems to be much less work to just make th=
e HTTP requests directly. And if you are using MAC, you need a MAC library,=
 not an OAuth 2.0...
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of David Recordon
>> Sent: Friday, June 24, 2011 10:07 AM
>> To: Eve Maler
>> Cc: oauth WG
>> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>>
>> I was trying to keep http://wiki.oauth.net/w/page/25236487/OAuth-2 up to
>> date but haven't in awhile.
>>
>>
>> On Fri, Jun 24, 2011 at 10:02 AM, Eve Maler  wrote:
>> > Zero response from the other list. Any suggestions from folks here?
>> >
>> > Begin forwarded message:
>> >
>> >> From: Eve Maler 
>> >> Date: 20 June 2011 4:54:56 PM PDT
>> >> To: oauth@googlegroups.com
>> >> Subject: [oauth] Good list of OAuth open source?
>> >> Reply-To: oauth@googlegroups.com
>> >>
>> >> The list at http://oauth.net/code/ seems really random and out of dat=
e.
>> Does anyone have a current list of open-source software that supports
>> OAuth, including drafts of 2.0?
>> >>
>> >> Thanks,
>> >>
>> >> =C2=A0 =C2=A0 =C2=A0 Eve
>> >
>> >
>> > Eve Maler =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.xmlgr=
rl.com/blog
>> > +1 425 345 6756 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.twitter.com/xmlgrrl
>> >
>> > _______________________________________________
>> > 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
>



--=20
Maciej Machulak
email: maciej.machulak@gmail.com
tel: +48 602 45 31 44
tel: +44 7999 606 767

From jricher@mitre.org  Fri Jun 24 11:13:32 2011
Return-Path: 
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 9369E9E8012 for ; Fri, 24 Jun 2011 11:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.073
X-Spam-Level: 
X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihXgs0yRFrXz for ; Fri, 24 Jun 2011 11:13:31 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E37539E8005 for ; Fri, 24 Jun 2011 11:13:30 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4CCF521B10AC; Fri, 24 Jun 2011 14:13:30 -0400 (EDT)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 470B321B1089; Fri, 24 Jun 2011 14:13:30 -0400 (EDT)
Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.159.2; Fri, 24 Jun 2011 14:13:30 -0400
From: Justin Richer 
To: Eve Maler 
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com> 
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 24 Jun 2011 14:11:31 -0400
Message-ID: <1308939091.27973.30.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 18:13:32 -0000

Eve,

We've been using (and contributing some to) the implementation in
SpringSecurity:

  http://static.springsource.org/spring-security/oauth/

I don't have a good list otherwise, though I'd be interested in seeing
the results as well.

To Eran: I really don't get your comment. Libraries are a very Good
Thing and their use and development should be greatly encouraged by the
OAuth community. The less that I have to write the Same Code As Last
Time the better. 

 -- Justin

On Fri, 2011-06-24 at 13:02 -0400, Eve Maler wrote:
> Zero response from the other list. Any suggestions from folks here?
> 
> Begin forwarded message:
> 
> > From: Eve Maler 
> > Date: 20 June 2011 4:54:56 PM PDT
> > To: oauth@googlegroups.com
> > Subject: [oauth] Good list of OAuth open source?
> > Reply-To: oauth@googlegroups.com
> > 
> > The list at http://oauth.net/code/ seems really random and out of date. Does anyone have a current list of open-source software that supports OAuth, including drafts of 2.0?
> > 
> > Thanks,
> > 
> > 	Eve
> 
> 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



From mscurtescu@google.com  Fri Jun 24 11:46:26 2011
Return-Path: 
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 6933B11E80C6 for ; Fri, 24 Jun 2011 11:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHQA8dKywHms for ; Fri, 24 Jun 2011 11:46:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8943911E8084 for ; Fri, 24 Jun 2011 11:46:25 -0700 (PDT)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p5OIkN22027068 for ; Fri, 24 Jun 2011 11:46:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308941184; bh=bA2pMy/szm3XbQk0ZIeEUe2aYcM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aovdFEFFswII98Y9Wbz3ENY+lq56YfxgssXzWxYGsr3BE0TGphCagf66Wd7vxfDR6 z7W7xLKY8HBHDRsSx7ykg==
Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by kpbe16.cbf.corp.google.com with ESMTP id p5OIkMvd017860 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Jun 2011 11:46:22 -0700
Received: by yxd5 with SMTP id 5so1881685yxd.35 for ; Fri, 24 Jun 2011 11:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hSaVMYdJU64zJZRbv/PZqLChUQKjGJuVao9HHRfgHZ4=; b=WgYuBZM+C1EDQUQXLylXDFeIx/zzgMmgbfM5w6Ehli+og9lqRkHNh9rKJsxZpm8amU /pdw1caLDcpyEYSBuBhw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BnCcrCr+p3xIgYdWpDtDlwT05p5tQRyADVkFEqr31SOBGyuRWQFSpkfrf4+s+SuQlW kz4aOKujWN4NQ9Ktj9Hw==
Received: by 10.100.53.14 with SMTP id b14mr3887774ana.57.1308941182104; Fri, 24 Jun 2011 11:46:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.14.19 with HTTP; Fri, 24 Jun 2011 11:46:02 -0700 (PDT)
In-Reply-To: <1308939091.27973.30.camel@ground>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>  <1308939091.27973.30.camel@ground>
From: Marius Scurtescu 
Date: Fri, 24 Jun 2011 11:46:02 -0700
Message-ID: 
To: Justin Richer 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 18:46:26 -0000

On Fri, Jun 24, 2011 at 11:11 AM, Justin Richer  wrote:
> To Eran: I really don't get your comment. Libraries are a very Good
> Thing and their use and development should be greatly encouraged by the
> OAuth community. The less that I have to write the Same Code As Last
> Time the better.

+1

If you look at code that is not using a library you will notice that
it is full of random validation, repeated all over the place. Also,
you would be surprised how many developers decide to parse JSON
responses manually, just by splitting on { : and ,

Marius

From eran@hueniverse.com  Fri Jun 24 12:00:31 2011
Return-Path: 
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 0127811E81EB for ; Fri, 24 Jun 2011 12:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA1bvagrSCEx for ; Fri, 24 Jun 2011 12:00:30 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7700911E8235 for ; Fri, 24 Jun 2011 12:00:11 -0700 (PDT)
Received: (qmail 31101 invoked from network); 24 Jun 2011 19:00:10 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Jun 2011 19:00:10 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 24 Jun 2011 12:00:09 -0700
From: Eran Hammer-Lahav 
To: Marius Scurtescu , Justin Richer 
Date: Fri, 24 Jun 2011 11:59:59 -0700
Thread-Topic: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Thread-Index: AcwynwnhthHkh0gOQ2eC36dg4GwFhgAAK9cg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0F65@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>  <1308939091.27973.30.camel@ground> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 19:00:31 -0000

Libraries are no cure for stupidity.

On the client side, you make two simple HTTP requests. The facilities to ma=
ke these requests should be available and easy to use. Parsing JSON respons=
es should be part of any modern web platform. The part that might need more=
 work is handling of refresh tokens, storing credentials, and setting up th=
e redirection endpoint. But these tend to be to application specific for a =
library to offer much value (unless it is a highly specific environment).

My point is that OAuth 2.0 was explicitly designed to work without a librar=
y on the client side, and it would actually be better if people building we=
b services using OAuth as a client understood what they are doing and how t=
he protocol works.

My entire Facebook OAuth login code in node.js is about 30 lines, and that =
includes all the event handlers for the HTTP client calls. It is actually s=
horter than my Twitter OAuth code which uses an OAuth 1.0 library.

What does add tremendous value is offering a service-specific SDK. In that =
context, OAuth is just a tiny detail.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Friday, June 24, 2011 11:46 AM
> To: Justin Richer
> Cc: oauth WG
> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>=20
> On Fri, Jun 24, 2011 at 11:11 AM, Justin Richer  wrote=
:
> > To Eran: I really don't get your comment. Libraries are a very Good
> > Thing and their use and development should be greatly encouraged by
> > the OAuth community. The less that I have to write the Same Code As
> > Last Time the better.
>=20
> +1
>=20
> If you look at code that is not using a library you will notice that it i=
s full of
> random validation, repeated all over the place. Also, you would be surpri=
sed
> how many developers decide to parse JSON responses manually, just by
> splitting on { : and ,
>=20
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From teohuiming@gmail.com  Fri Jun 24 13:48:59 2011
Return-Path: 
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 DC4C111E820C for ; Fri, 24 Jun 2011 13:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.793
X-Spam-Level: 
X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaJN9gVviNyE for ; Fri, 24 Jun 2011 13:48:59 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3463111E8178 for ; Fri, 24 Jun 2011 13:48:57 -0700 (PDT)
Received: by bwb17 with SMTP id 17so114499bwb.31 for ; Fri, 24 Jun 2011 13:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wWhQkhQuAPNM9mP6jf/f2K38Ptz/mrgKkVzRvIDW+7c=; b=Uu6rgXB1juoIDswgjjHDNsmRc3sjPr/R9F/O8goRUKZLGiBYtl52T9cQMCdof3M9oO s5ApP8MFisyCOt8XmV+h1IqErxB4Za+pmth/rB79ZdIV4ZUVFZZK+r4mQPnvlrsEIezQ o8QrNsab6ltLzeuZlRgKu6FhQcH1sUqJuKCTM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=enGpWmMKe63qDW7UUxcYsVorSaE0Oknvcwu6iuBdjKsQVTDipziHnFpLsEq0Q813eP zuxpcw3aUtz1rcNjBhKb1YcMa/h/qAi+hCeFhl72rNNAyJfXbI/+vWtjSG4Tt4ISoH6y uTiD2B4zqoedJp6hwvJrvmHkAOhCB5xYuix7M=
MIME-Version: 1.0
Received: by 10.204.16.129 with SMTP id o1mr2433009bka.36.1308948536824; Fri, 24 Jun 2011 13:48:56 -0700 (PDT)
Received: by 10.204.72.19 with HTTP; Fri, 24 Jun 2011 13:48:56 -0700 (PDT)
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com> 
Date: Sat, 25 Jun 2011 04:48:56 +0800
Message-ID: 
From: Teo Hui Ming 
To: Eve Maler 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 20:49:00 -0000

Hi, I notice most open source OAuth2 client/server libraries
implementation is only up to draft 10.

Here's a quick raw list in case you interested:
https://github.com/teohm/teohm.github.com/wiki/OAuth

Anyone knows if there is an open source OAuth2 server reference
implementation that reflects the latest draft 16, and unit-tested
against the security considerations in section 10?

On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
> Zero response from the other list. Any suggestions from folks here?
>
> Begin forwarded message:
>
>> From: Eve Maler 
>> Date: 20 June 2011 4:54:56 PM PDT
>> To: oauth@googlegroups.com
>> Subject: [oauth] Good list of OAuth open source?
>> Reply-To: oauth@googlegroups.com
>>
>> The list at http://oauth.net/code/ seems really random and out of date. =
Does anyone have a current list of open-source software that supports OAuth=
, including drafts of 2.0?
>>
>> Thanks,
>>
>> =C2=A0 =C2=A0 =C2=A0 Eve
>
>
> Eve Maler =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.xmlgrrl.c=
om/blog
> +1 425 345 6756 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.twitter.com/xmlgrrl
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--=20
Teo Hui Ming

From eve@xmlgrrl.com  Fri Jun 24 14:19:11 2011
Return-Path: 
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 9B6FF11E80FD for ; Fri, 24 Jun 2011 14:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m3+lFR4kvE1 for ; Fri, 24 Jun 2011 14:19:10 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9037A11E80FA for ; Fri, 24 Jun 2011 14:19:10 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id p5OLJAA6024103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 14:19:10 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler 
In-Reply-To: 
Date: Fri, 24 Jun 2011 14:19:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <788489B9-05FE-4939-A7DB-2F2E68B816D0@xmlgrrl.com>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>  
To: oauth WG 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 21:19:11 -0000

Thanks, y'all, for the responses. I've heard from others that a library =
can end up taking more time to figure out than just coding it fresh =
because the latter is just that simple, but I suspect this is a YMMV =
kind of thing. And it seems there's universal agreement that a MAC =
library would be a very good idea regardless.

	Eve

On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote:

> Hi, I notice most open source OAuth2 client/server libraries
> implementation is only up to draft 10.
>=20
> Here's a quick raw list in case you interested:
> https://github.com/teohm/teohm.github.com/wiki/OAuth
>=20
> Anyone knows if there is an open source OAuth2 server reference
> implementation that reflects the latest draft 16, and unit-tested
> against the security considerations in section 10?
>=20
> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
>> Zero response from the other list. Any suggestions from folks here?
>>=20
>> Begin forwarded message:
>>=20
>>> From: Eve Maler 
>>> Date: 20 June 2011 4:54:56 PM PDT
>>> To: oauth@googlegroups.com
>>> Subject: [oauth] Good list of OAuth open source?
>>> Reply-To: oauth@googlegroups.com
>>>=20
>>> The list at http://oauth.net/code/ seems really random and out of =
date. Does anyone have a current list of open-source software that =
supports OAuth, including drafts of 2.0?
>>>=20
>>> Thanks,
>>>=20
>>>       Eve
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
>=20
> --=20
> Teo Hui Ming
>=20


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From eran@hueniverse.com  Fri Jun 24 14:24:32 2011
Return-Path: 
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 F1CF111E8138 for ; Fri, 24 Jun 2011 14:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level: 
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjYmE9FpciP7 for ; Fri, 24 Jun 2011 14:24:31 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5C24811E810C for ; Fri, 24 Jun 2011 14:24:31 -0700 (PDT)
Received: (qmail 15337 invoked from network); 24 Jun 2011 21:24:30 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jun 2011 21:24:29 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 24 Jun 2011 14:24:19 -0700
From: Eran Hammer-Lahav 
To: Eve Maler , oauth WG 
Date: Fri, 24 Jun 2011 14:24:09 -0700
Thread-Topic: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
Thread-Index: AcwytGVAkP/ZY5JrTdOpt7AjHTpkrAAADB1A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0FC0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>   <788489B9-05FE-4939-A7DB-2F2E68B816D0@xmlgrrl.com>
In-Reply-To: <788489B9-05FE-4939-A7DB-2F2E68B816D0@xmlgrrl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 21:24:32 -0000

I maintain the node.js 'mac' module:

https://github.com/hueniverse/node-mac
or 'npm install mac'

A browser JS lib is available at:

https://sled.com/scripts/mac.js

Both are used in production.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eve Maler
> Sent: Friday, June 24, 2011 2:19 PM
> To: oauth WG
> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>=20
> Thanks, y'all, for the responses. I've heard from others that a library c=
an end
> up taking more time to figure out than just coding it fresh because the l=
atter
> is just that simple, but I suspect this is a YMMV kind of thing. And it s=
eems
> there's universal agreement that a MAC library would be a very good idea
> regardless.
>=20
> 	Eve
>=20
> On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote:
>=20
> > Hi, I notice most open source OAuth2 client/server libraries
> > implementation is only up to draft 10.
> >
> > Here's a quick raw list in case you interested:
> > https://github.com/teohm/teohm.github.com/wiki/OAuth
> >
> > Anyone knows if there is an open source OAuth2 server reference
> > implementation that reflects the latest draft 16, and unit-tested
> > against the security considerations in section 10?
> >
> > On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
> >> Zero response from the other list. Any suggestions from folks here?
> >>
> >> Begin forwarded message:
> >>
> >>> From: Eve Maler 
> >>> Date: 20 June 2011 4:54:56 PM PDT
> >>> To: oauth@googlegroups.com
> >>> Subject: [oauth] Good list of OAuth open source?
> >>> Reply-To: oauth@googlegroups.com
> >>>
> >>> The list at http://oauth.net/code/ seems really random and out of dat=
e.
> Does anyone have a current list of open-source software that supports
> OAuth, including drafts of 2.0?
> >>>
> >>> Thanks,
> >>>
> >>>       Eve
> >>
> >>
> >> Eve Maler                                  http://www.xmlgrrl.com/blog
> >> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> >
> > --
> > Teo Hui Ming
> >
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From phil.hunt@oracle.com  Fri Jun 24 14:34:28 2011
Return-Path: 
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 C42FE11E8185 for ; Fri, 24 Jun 2011 14:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level: 
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM59OQdXP18X for ; Fri, 24 Jun 2011 14:34:27 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 959BE11E8157 for ; Fri, 24 Jun 2011 14:34:27 -0700 (PDT)
Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5OLYNJi022583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 21:34:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5OLYMJO020096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 21:34:23 GMT
Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5OLYGjE024213; Fri, 24 Jun 2011 16:34:17 -0500
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Jun 2011 14:34:16 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475EAB0FC0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 24 Jun 2011 14:34:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>   <788489B9-05FE-4939-A7DB-2F2E68B816D0@xmlgrrl.com> <90C41DD21FB7C64BB94121FBBC2E7234475EAB0FC0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eve Maler 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet22.oracle.com [66.248.204.30]
X-CT-RefId: str=0001.0A090205.4E0502E2.010B:SCFSTAT5015188, ss=1, re=-4.000, fgs=0
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jun 2011 21:34:28 -0000

Eve,

Were you just asking about client libraries?  Or did you mean some open =
source for things like building authorization/token/resource service =
end-points?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-06-24, at 2:24 PM, Eran Hammer-Lahav wrote:

> I maintain the node.js 'mac' module:
>=20
> https://github.com/hueniverse/node-mac
> or 'npm install mac'
>=20
> A browser JS lib is available at:
>=20
> https://sled.com/scripts/mac.js
>=20
> Both are used in production.
>=20
> EHL
>=20
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Eve Maler
>> Sent: Friday, June 24, 2011 2:19 PM
>> To: oauth WG
>> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>>=20
>> Thanks, y'all, for the responses. I've heard from others that a =
library can end
>> up taking more time to figure out than just coding it fresh because =
the latter
>> is just that simple, but I suspect this is a YMMV kind of thing. And =
it seems
>> there's universal agreement that a MAC library would be a very good =
idea
>> regardless.
>>=20
>> 	Eve
>>=20
>> On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote:
>>=20
>>> Hi, I notice most open source OAuth2 client/server libraries
>>> implementation is only up to draft 10.
>>>=20
>>> Here's a quick raw list in case you interested:
>>> https://github.com/teohm/teohm.github.com/wiki/OAuth
>>>=20
>>> Anyone knows if there is an open source OAuth2 server reference
>>> implementation that reflects the latest draft 16, and unit-tested
>>> against the security considerations in section 10?
>>>=20
>>> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
>>>> Zero response from the other list. Any suggestions from folks here?
>>>>=20
>>>> Begin forwarded message:
>>>>=20
>>>>> From: Eve Maler 
>>>>> Date: 20 June 2011 4:54:56 PM PDT
>>>>> To: oauth@googlegroups.com
>>>>> Subject: [oauth] Good list of OAuth open source?
>>>>> Reply-To: oauth@googlegroups.com
>>>>>=20
>>>>> The list at http://oauth.net/code/ seems really random and out of =
date.
>> Does anyone have a current list of open-source software that supports
>> OAuth, including drafts of 2.0?
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>>      Eve
>>>>=20
>>>>=20
>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Teo Hui Ming
>>>=20
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>> _______________________________________________
>> 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


From matake@gmail.com  Fri Jun 24 17:17:25 2011
Return-Path: 
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 A643221F848B for ; Fri, 24 Jun 2011 17:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.793
X-Spam-Level: 
X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwQSRbeZGGv8 for ; Fri, 24 Jun 2011 17:17:23 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD2321F8489 for ; Fri, 24 Jun 2011 17:17:23 -0700 (PDT)
Received: by pzk5 with SMTP id 5so2237289pzk.31 for ; Fri, 24 Jun 2011 17:17:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=aoqdEETvhYRhs6Iu4idghMK9dNqtvW06xppvx9DJIS4=; b=xCmqvuaM4P1CgsiOjgh2KPM9wobwGA5k5DPSXqFA5uXHI3/3QN/pH01WJ70OzZzJzD yImWAVm2S7qd93mK4gz/qnV/8wmSgi/+T/21QMrJIgHu7aSnVIPHQABegkGqfZgKes8H f2mwW1+poROpyGE9OG7yBIWN+yXq38P/uxaVE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=F2e+nPAdbbC7KF9wK2AiiZawIeNWD356GoI54qZUQeBJo8euzF8wjwoJDhE8KEz1l4 xDkwQtEAIBGqMZkeztajx5JItSPcOu1FrOZN/JAXUlAEIpRAjeSdruX72IsTVeCR8Zmv CFC7Lex4RxZFMNMJkRd7znlR6ImUZNZHn0HaU=
Received: by 10.68.7.4 with SMTP id f4mr1971459pba.208.1308961042843; Fri, 24 Jun 2011 17:17:22 -0700 (PDT)
Received: from [10.0.1.3] (o143230.dynamic.ppp.asahi-net.or.jp [202.208.143.230]) by mx.google.com with ESMTPS id g8sm2414053pba.85.2011.06.24.17.17.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jun 2011 17:17:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "matake@gmail" 
In-Reply-To: 
Date: Sat, 25 Jun 2011 09:17:21 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>  
To: Teo Hui Ming 
X-Mailer: Apple Mail (2.1084)
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jun 2011 00:17:25 -0000

Hi,

I maintain Ruby OAuth2 server library.
https://github.com/nov/rack-oauth2

And sample servers on Heroku
http://rack-oauth2-sample.heroku.com/ (Bearer)
http://rack-oauth2-sample-mac.heroku.com/ (MAC)

I'm trying to keep them up to date, not exactly sure it's 100% following =
draft 16 though.

On 2011/06/25, at 5:48, Teo Hui Ming wrote:

> Hi, I notice most open source OAuth2 client/server libraries
> implementation is only up to draft 10.
>=20
> Here's a quick raw list in case you interested:
> https://github.com/teohm/teohm.github.com/wiki/OAuth
>=20
> Anyone knows if there is an open source OAuth2 server reference
> implementation that reflects the latest draft 16, and unit-tested
> against the security considerations in section 10?
>=20
> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
>> Zero response from the other list. Any suggestions from folks here?
>>=20
>> Begin forwarded message:
>>=20
>>> From: Eve Maler 
>>> Date: 20 June 2011 4:54:56 PM PDT
>>> To: oauth@googlegroups.com
>>> Subject: [oauth] Good list of OAuth open source?
>>> Reply-To: oauth@googlegroups.com
>>>=20
>>> The list at http://oauth.net/code/ seems really random and out of =
date. Does anyone have a current list of open-source software that =
supports OAuth, including drafts of 2.0?
>>>=20
>>> Thanks,
>>>=20
>>>       Eve
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
>=20
> --=20
> Teo Hui Ming
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From eve@xmlgrrl.com  Fri Jun 24 20:23:41 2011
Return-Path: 
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 880CA11E809E for ; Fri, 24 Jun 2011 20:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH7YN7jyC3YK for ; Fri, 24 Jun 2011 20:23:39 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5D511E807D for ; Fri, 24 Jun 2011 20:23:39 -0700 (PDT)
Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id p5P3Ncao028740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 20:23:38 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler 
In-Reply-To: 
Date: Fri, 24 Jun 2011 20:23:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <44E25951-A3CC-4DEE-B081-43534C7990F2@xmlgrrl.com>
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>   <788489B9-05FE-4939-A7DB-2F2E68B816D0@xmlgrrl.com> <90C41DD21FB7C64BB94121FBBC2E7234475EAB0FC0@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.1084)
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jun 2011 03:23:41 -0000

I'm interested in learning about all of the above (uh, below).

	Eve

On 24 Jun 2011, at 2:34 PM, Phil Hunt wrote:

> Eve,
>=20
> Were you just asking about client libraries?  Or did you mean some =
open source for things like building authorization/token/resource =
service end-points?
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
> On 2011-06-24, at 2:24 PM, Eran Hammer-Lahav wrote:
>=20
>> I maintain the node.js 'mac' module:
>>=20
>> https://github.com/hueniverse/node-mac
>> or 'npm install mac'
>>=20
>> A browser JS lib is available at:
>>=20
>> https://sled.com/scripts/mac.js
>>=20
>> Both are used in production.
>>=20
>> EHL
>>=20
>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>> Of Eve Maler
>>> Sent: Friday, June 24, 2011 2:19 PM
>>> To: oauth WG
>>> Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
>>>=20
>>> Thanks, y'all, for the responses. I've heard from others that a =
library can end
>>> up taking more time to figure out than just coding it fresh because =
the latter
>>> is just that simple, but I suspect this is a YMMV kind of thing. And =
it seems
>>> there's universal agreement that a MAC library would be a very good =
idea
>>> regardless.
>>>=20
>>> 	Eve
>>>=20
>>> On 24 Jun 2011, at 1:48 PM, Teo Hui Ming wrote:
>>>=20
>>>> Hi, I notice most open source OAuth2 client/server libraries
>>>> implementation is only up to draft 10.
>>>>=20
>>>> Here's a quick raw list in case you interested:
>>>> https://github.com/teohm/teohm.github.com/wiki/OAuth
>>>>=20
>>>> Anyone knows if there is an open source OAuth2 server reference
>>>> implementation that reflects the latest draft 16, and unit-tested
>>>> against the security considerations in section 10?
>>>>=20
>>>> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
>>>>> Zero response from the other list. Any suggestions from folks =
here?
>>>>>=20
>>>>> Begin forwarded message:
>>>>>=20
>>>>>> From: Eve Maler 
>>>>>> Date: 20 June 2011 4:54:56 PM PDT
>>>>>> To: oauth@googlegroups.com
>>>>>> Subject: [oauth] Good list of OAuth open source?
>>>>>> Reply-To: oauth@googlegroups.com
>>>>>>=20
>>>>>> The list at http://oauth.net/code/ seems really random and out of =
date.
>>> Does anyone have a current list of open-source software that =
supports
>>> OAuth, including drafts of 2.0?
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>>     Eve
>>>>>=20
>>>>>=20
>>>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Teo Hui Ming
>>>>=20
>>>=20
>>>=20
>>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>>=20
>>> _______________________________________________
>>> 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
>=20
>=20


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From teohuiming@gmail.com  Sat Jun 25 02:25:54 2011
Return-Path: 
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 1A94811E8077 for ; Sat, 25 Jun 2011 02:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.793
X-Spam-Level: 
X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weXwvBiOZDeg for ; Sat, 25 Jun 2011 02:25:50 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4609411E8071 for ; Sat, 25 Jun 2011 02:25:50 -0700 (PDT)
Received: by bwb17 with SMTP id 17so392365bwb.31 for ; Sat, 25 Jun 2011 02:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LfyVy1WTcTEkVqI17a7NwhSV8oRO/d7c1H8s0YPYaSA=; b=gxxuBvoz0Ur9kBiZNkz98O8fJnrf24zrZ3QG7CeoZKgi0ODzvGiLrrWohZ6oWRQTlq eVjXy2Kd5jTlc5Yo4CIuoRgroDgyQGnvm9c25rOMZd6BdJc508h4UMaryerC5Rh0JL5Y OklbFUnuOmO+SS7H39E8yjenlHUt7MVVqgQF8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o/z5cpvaDPUU3EpY0DzhamNaX3fhOx1Z4RdoqbBSaJECVbcwnr4pIymGLf1UxZy9xk fiVPbi31pMXlzPZyqMc68M+HHwt9+dp/AcDpkpVkoFbddDVQJnN9+wO+NiiuSeO/g328 gxeBvCcr/ark8+vqYhvxEhLrNmwri6D2s1KVE=
MIME-Version: 1.0
Received: by 10.204.141.205 with SMTP id n13mr2729827bku.198.1308993948089; Sat, 25 Jun 2011 02:25:48 -0700 (PDT)
Received: by 10.204.72.19 with HTTP; Sat, 25 Jun 2011 02:25:47 -0700 (PDT)
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>   
Date: Sat, 25 Jun 2011 17:25:47 +0800
Message-ID: 
From: Teo Hui Ming 
To: "matake@gmail" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jun 2011 09:25:54 -0000

Thanks for sharing, the code looks pretty neat!

On Sat, Jun 25, 2011 at 8:17 AM, matake@gmail  wrote:
> Hi,
>
> I maintain Ruby OAuth2 server library.
> https://github.com/nov/rack-oauth2
>
> And sample servers on Heroku
> http://rack-oauth2-sample.heroku.com/ (Bearer)
> http://rack-oauth2-sample-mac.heroku.com/ (MAC)
>
> I'm trying to keep them up to date, not exactly sure it's 100% following =
draft 16 though.
>
> On 2011/06/25, at 5:48, Teo Hui Ming wrote:
>
>> Hi, I notice most open source OAuth2 client/server libraries
>> implementation is only up to draft 10.
>>
>> Here's a quick raw list in case you interested:
>> https://github.com/teohm/teohm.github.com/wiki/OAuth
>>
>> Anyone knows if there is an open source OAuth2 server reference
>> implementation that reflects the latest draft 16, and unit-tested
>> against the security considerations in section 10?
>>
>> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
>>> Zero response from the other list. Any suggestions from folks here?
>>>
>>> Begin forwarded message:
>>>
>>>> From: Eve Maler 
>>>> Date: 20 June 2011 4:54:56 PM PDT
>>>> To: oauth@googlegroups.com
>>>> Subject: [oauth] Good list of OAuth open source?
>>>> Reply-To: oauth@googlegroups.com
>>>>
>>>> The list at http://oauth.net/code/ seems really random and out of date=
. Does anyone have a current list of open-source software that supports OAu=
th, including drafts of 2.0?
>>>>
>>>> Thanks,
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0 Eve
>>>
>>>
>>> Eve Maler =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.xmlgr=
rl.com/blog
>>> +1 425 345 6756 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.twitter.com/xmlgrrl
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>>
>> --
>> Teo Hui Ming
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>



--=20
Teo Hui Ming

From andrewarnott@gmail.com  Sat Jun 25 21:46:53 2011
Return-Path: 
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 01A0111E807C for ; Sat, 25 Jun 2011 21:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level: 
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHqSBpCp5DyV for ; Sat, 25 Jun 2011 21:46:51 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDED411E8072 for ; Sat, 25 Jun 2011 21:46:50 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1166330qyk.10 for ; Sat, 25 Jun 2011 21:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R86jIsFvFo/CIz2usrVz90sGcLQO5rSy//87OkUY9ZE=; b=L8GjHg9/xuFHEkRQoHu3KRpYFgMSffyvw6kcI7g2B8E5nutDtf9rTguHsJK6/89l4q ry0xhlvDzx98egl6FftXaoJQSOb8nPdEZPMudflelrcD4dca+0NjCP0Xa6ah2V6FYKeG QiNiUI2kHIW6GoT4n7xpKwGLWQKCSrqV8VEec=
Received: by 10.229.4.203 with SMTP id 11mr3687985qcs.72.1309063609196; Sat, 25 Jun 2011 21:46:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.34.202 with HTTP; Sat, 25 Jun 2011 21:46:29 -0700 (PDT)
In-Reply-To: 
References: <99DE6B14-4E30-4E0D-9711-33E68608491E@xmlgrrl.com>    
From: Andrew Arnott 
Date: Sat, 25 Jun 2011 21:46:29 -0700
Message-ID: 
To: Teo Hui Ming 
Content-Type: multipart/alternative; boundary=001517576d766a22ae04a6961f0b
Cc: oauth WG 
Subject: Re: [OAUTH-WG] Fwd: [oauth] Good list of OAuth open source?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Jun 2011 04:46:53 -0000

--001517576d766a22ae04a6961f0b
Content-Type: text/plain; charset=ISO-8859-1

DotNetOpenAuth (http://www.dotnetopenauth.net/) implements all 3 roles to
draft 16, but it isn't considered finished (at least till the spec is).  In
particular, while the happy path is pretty well done, error reporting is not
there much at all yet (mostly because that's been a turbulent area of the
spec among recent drafts).

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Sat, Jun 25, 2011 at 2:25 AM, Teo Hui Ming  wrote:

> Thanks for sharing, the code looks pretty neat!
>
> On Sat, Jun 25, 2011 at 8:17 AM, matake@gmail  wrote:
> > Hi,
> >
> > I maintain Ruby OAuth2 server library.
> > https://github.com/nov/rack-oauth2
> >
> > And sample servers on Heroku
> > http://rack-oauth2-sample.heroku.com/ (Bearer)
> > http://rack-oauth2-sample-mac.heroku.com/ (MAC)
> >
> > I'm trying to keep them up to date, not exactly sure it's 100% following
> draft 16 though.
> >
> > On 2011/06/25, at 5:48, Teo Hui Ming wrote:
> >
> >> Hi, I notice most open source OAuth2 client/server libraries
> >> implementation is only up to draft 10.
> >>
> >> Here's a quick raw list in case you interested:
> >> https://github.com/teohm/teohm.github.com/wiki/OAuth
> >>
> >> Anyone knows if there is an open source OAuth2 server reference
> >> implementation that reflects the latest draft 16, and unit-tested
> >> against the security considerations in section 10?
> >>
> >> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler  wrote:
> >>> Zero response from the other list. Any suggestions from folks here?
> >>>
> >>> Begin forwarded message:
> >>>
> >>>> From: Eve Maler 
> >>>> Date: 20 June 2011 4:54:56 PM PDT
> >>>> To: oauth@googlegroups.com
> >>>> Subject: [oauth] Good list of OAuth open source?
> >>>> Reply-To: oauth@googlegroups.com
> >>>>
> >>>> The list at http://oauth.net/code/ seems really random and out of
> date. Does anyone have a current list of open-source software that supports
> OAuth, including drafts of 2.0?
> >>>>
> >>>> Thanks,
> >>>>
> >>>>       Eve
> >>>
> >>>
> >>> Eve Maler                                  http://www.xmlgrrl.com/blog
> >>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>
> >>
> >>
> >> --
> >> Teo Hui Ming
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>
>
> --
> Teo Hui Ming
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001517576d766a22ae04a6961f0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

DotNetOpenAuth (http://www.dotne=
topenauth.net/) implements all 3 roles to draft 16, but it isn't co=
nsidered finished (at least till the spec is). =A0In particular, while the =
happy path is pretty well done, error reporting is not there much at all ye=
t (mostly because that's been a turbulent area of the spec among recent=
 drafts).



--
Andrew Arnott
"I [may] not agree with what =
you have to say, but I'll defend to the death your right to say it.&quo=
t; - S. G. Tallentyre



On Sat, Jun 25, 2011 at 2:25 AM, Teo Hui=
 Ming <teohuim=
ing@gmail.com> wrote:


Thanks for sharing, the code looks pretty neat!




On Sat, Jun 25, 2011 at 8:17 AM, matake@gmail <matake@gmail.com> wrote:

> Hi,

>

> I maintain Ruby OAuth2 server library.

> https=
://github.com/nov/rack-oauth2

>

> And sample servers on Heroku

> ht=
tp://rack-oauth2-sample.heroku.com/ (Bearer)

> http://rack-oauth2-sample-mac.heroku.com/ (MAC)

>

> I'm trying to keep them up to date, not exactly sure it's 100%=
 following draft 16 though.

>

> On 2011/06/25, at 5:48, Teo Hui Ming wrote:

>

>> Hi, I notice most open source OAuth2 client/server libraries

>> implementation is only up to draft 10.

>>

>> Here's a quick raw list in case you interested:

>> https://github.com/teohm/teohm.github.com/wiki/OAuth
>>

>> Anyone knows if there is an open source OAuth2 server reference
>> implementation that reflects the latest draft 16, and unit-tested<=
br>
>> against the security considerations in section 10?

>>

>> On Sat, Jun 25, 2011 at 1:02 AM, Eve Maler <eve@xmlgrrl.com> wrote:

>>> Zero response from the other list. Any suggestions from folks =
here?

>>>

>>> Begin forwarded message:

>>>

>>>> From: Eve Maler <eve=
@xmlgrrl.com>

>>>> Date: 20 June 2011 4:54:56 PM PDT

>>>> To: oauth@google=
groups.com

>>>> Subject: [oauth] Good list of OAuth open source?

>>>> Reply-To: oauth@=
googlegroups.com

>>>>

>>>> The list at http://oauth.net/code/ seems really random and out of date. Does=
 anyone have a current list of open-source software that supports OAuth, in=
cluding drafts of 2.0?



>>>>

>>>> Thanks,

>>>>

>>>> =A0 =A0 =A0 Eve

>>>

>>>

>>> Eve Maler =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0ht=
tp://www.xmlgrrl.com/blog

>>> +1 425 345 6756 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.twitter.c=
om/xmlgrrl

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

>>> https://www.ietf.org/mailman/listinfo/oauth

>>>

>>

>>

>>

>> --

>> Teo Hui Ming

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

>> https://www.ietf.org/mailman/listinfo/oauth

>

>







--

Teo Hui Ming

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--001517576d766a22ae04a6961f0b--

From andrewarnott@gmail.com  Mon Jun 27 08:47:54 2011
Return-Path: 
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 26C74228011 for ; Mon, 27 Jun 2011 08:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veSVZW1ayku2 for ; Mon, 27 Jun 2011 08:47:53 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6641222800E for ; Mon, 27 Jun 2011 08:47:53 -0700 (PDT)
Received: by qyk29 with SMTP id 29so3560870qyk.10 for ; Mon, 27 Jun 2011 08:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=G7wXHjNiv3IwIh9gcbwqZ80wny9rnv9jKLYbxmjZVXQ=; b=sWKyDtbKhaSCj3qsLVXOvcs5OAPajARkpp0Capb7utgNFsUSbT/CRHEzIVhm1Jqrv8 Z9h7LdYhRL0XdQA+UBhejca6ODWQWmaQKO9DrS+M4bNtSDPTtpEbt/JuxBwBzuzfZBjD gfPxaxahsvNGQCrzoT426A3R5qzxdZrDs19Oo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=jBF03U3UzLgzIVrA0xSZvnrNhtUTxyLd8zRTT7+rPo5+2Qr4XgpVUMhGmtcpehF2OF +UHde+CMhjR8UzC9Kux8koMgN8ye8f0Wz5Gr/cuW9Hf/TfT9QUrzUzhmdW7r59rQTPDm R/vTIWlQPExrMn8BJIRwWzqVlHrOCrV8evTMM=
Received: by 10.229.44.14 with SMTP id y14mr4726196qce.110.1309189668128; Mon, 27 Jun 2011 08:47:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.34.202 with HTTP; Mon, 27 Jun 2011 08:47:28 -0700 (PDT)
From: Andrew Arnott 
Date: Mon, 27 Jun 2011 08:47:28 -0700
Message-ID: 
To: "OAuth WG (oauth@ietf.org)" 
Content-Type: multipart/alternative; boundary=0016364ed7741cc84804a6b3795e
Subject: [OAUTH-WG] access/refresh token scope ambiguity
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 15:47:54 -0000

--0016364ed7741cc84804a6b3795e
Content-Type: text/plain; charset=ISO-8859-1

I was looking at the scenario of using a refresh token to obtain a new
access token, and noticed that in draft 16, Section 5.1 "Successful
Response" describes the scope parameter in a confusing way that suggests a
copy and paste error.  Included below, with [[emphasis added]].

   scope
         OPTIONAL.  The scope of the [[access request]] expressed as a list
         of space-delimited, case sensitive strings.  The value is
         defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter,
         and each string adds an additional access range to the
         requested scope.  The authorization server SHOULD include the
         parameter [[if the requested scope is different from the one
         requested by the client.]]

Why would the scope parameter in a response includes the scope of the
[[request]]? Particularly in light of what comes [[later]].  Also, how could
the requested scope be different from the one requested from the client.
 The client is the one making the request in the first place.


I'm also wondering if while using a refresh_token to obtain a new access
token, when the auth server has the opportunity to issue a new refresh_token
at the same time that the scope of the refresh token might change.  I would
hope not, but perhaps it may.  Considering the scenario where a client has a
powerful refresh token and wishes to obtain a limited access token (smaller
scope), would the scope parameter in the section 5.1 response match the
scope of the newly issued refresh token or the newly issued access token?
 I'm hoping the spec can be beefed up to remove any ambiguity here.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

--0016364ed7741cc84804a6b3795e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I was looking at the scenario of using a refresh token to obtain a new=
 access token, and noticed that in draft 16, Section 5.1 "Successful R=
esponse" describes the scope parameter in a confusing way that suggest=
s a copy and paste error. =A0Included below, with [[emphasis added]].




=A0 =A0scope
=A0 =A0 =A0 =A0 =A0OPTIONAL. =A0=
The scope of the [[access request]] expressed as a list
=A0 =A0 =
=A0 =A0 =A0of space-delimited, case sensitive strings. =A0The value is
=A0 =A0 =A0 =A0 =A0defined by the authorization server. =A0If the val=
ue contains



=A0 =A0 =A0 =A0 =A0multiple space-delimited strings, their order does =
not matter,
=A0 =A0 =A0 =A0 =A0and each string adds an additional=
 access range to the
=A0 =A0 =A0 =A0 =A0requested scope. =A0The a=
uthorization server SHOULD include the



=A0 =A0 =A0 =A0 =A0parameter [[if the requested scope is different fro=
m the one
=A0 =A0 =A0 =A0 =A0requested by the client.]]

Why would the scope parameter in a response includes the sc=
ope of the [[request]]? Particularly in light of what comes [[later]]. =A0A=
lso, how could the requested scope be different from the one requested from=
 the client. =A0The client is the one making the request in the first place=
.





I'm also wondering if while using a =
refresh_token to obtain a new access token, when the auth server has the op=
portunity to issue a new refresh_token at the same time that the scope of t=
he refresh token might change. =A0I would hope not, but perhaps it may. =A0=
Considering the scenario where a client has a powerful refresh token and wi=
shes to obtain a limited access token (smaller scope), would the scope para=
meter in the section 5.1 response match the scope of the newly issued refre=
sh token or the newly issued access token? =A0I'm hoping the spec can b=
e beefed up to remove any ambiguity here.


--
Andrew Arnott
"I [may] not agree with what you have to say, b=
ut I'll defend to the death your right to say it." - S. G. Tallent=
yre


--0016364ed7741cc84804a6b3795e--

From paul.madsen@gmail.com  Mon Jun 27 08:51:29 2011
Return-Path: 
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 EEA4E11E80C7 for ; Mon, 27 Jun 2011 08:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBjx1-MP0kWf for ; Mon, 27 Jun 2011 08:51:29 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 265BF11E809B for ; Mon, 27 Jun 2011 08:51:29 -0700 (PDT)
Received: by yxp4 with SMTP id 4so326984yxp.31 for ; Mon, 27 Jun 2011 08:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=f1WKoIu4KwfgUFXYy04RpmvEY9Rn9lip5tsqGLqlhRE=; b=jDudgRKKwADahRm1feRkXYkV0keQ6PhGHwnRYN4/iT1Thh2ULCyFKPbBaCzRiE0kCF InWG4yn5AszMGDDWPOAgWtX8XrtHzBYizsp3dpK0XjumOIFabYlTG5bQfQAxnlag8i5V xCh6ieYneyG2C4cRAwjj7rjLIcLtSy7XtjkR0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=DWkLQ19tjqMsVDMDvWBvrpnMHGnmUKqvU4j3Q/iWIBmegHi3Vk3etdszZTsc1MJ6we MGQgq7ZFME8/A7GcPdra/8qkfpiRGewlykd7tQRQdpixyNqIP974d4I0HDyJ3FqwWDti //Y5jz+tBQEZavDtHPjC9VaGbqbGAQVmZKA6U=
Received: by 10.101.148.37 with SMTP id a37mr1004499ano.158.1309189888294; Mon, 27 Jun 2011 08:51:28 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id b25sm5596638anb.20.2011.06.27.08.51.25 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 08:51:26 -0700 (PDT)
Message-ID: <4E08A70D.5020800@gmail.com>
Date: Mon, 27 Jun 2011 11:51:41 -0400
From: Paul Madsen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000203000702020000070306"
Subject: Re: [OAUTH-WG] access/refresh token scope ambiguity
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 15:51:30 -0000

This is a multi-part message in MIME format.
--------------000203000702020000070306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

presumably should be

if the *returned* scope is different from the one requested by the client.

On 6/27/11 11:47 AM, Andrew Arnott wrote:
> I was looking at the scenario of using a refresh token to obtain a new 
> access token, and noticed that in draft 16, Section 5.1 "Successful 
> Response" describes the scope parameter in a confusing way that 
> suggests a copy and paste error.  Included below, with [[emphasis added]].
>
>    scope
>          OPTIONAL.  The scope of the [[access request]] expressed as a 
> list
>          of space-delimited, case sensitive strings.  The value is
>          defined by the authorization server.  If the value contains
>          multiple space-delimited strings, their order does not matter,
>          and each string adds an additional access range to the
>          requested scope.  The authorization server SHOULD include the
>          parameter [[if the requested scope is different from the one
>          requested by the client.]]
>
> Why would the scope parameter in a response includes the scope of the 
> [[request]]? Particularly in light of what comes [[later]].  Also, how 
> could the requested scope be different from the one requested from the 
> client.  The client is the one making the request in the first place.
>
>
> I'm also wondering if while using a refresh_token to obtain a new 
> access token, when the auth server has the opportunity to issue a new 
> refresh_token at the same time that the scope of the refresh token 
> might change.  I would hope not, but perhaps it may.  Considering the 
> scenario where a client has a powerful refresh token and wishes to 
> obtain a limited access token (smaller scope), would the scope 
> parameter in the section 5.1 response match the scope of the newly 
> issued refresh token or the newly issued access token?  I'm hoping the 
> spec can be beefed up to remove any ambiguity here.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the 
> death your right to say it." - S. G. Tallentyre
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------000203000702020000070306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    presumably should be 

    

    if the *returned* scope is different from the one requested by the
    client.

    

    On 6/27/11 11:47 AM, Andrew Arnott wrote:
    

      
I was looking at the scenario of using a refresh token to
        obtain a new access token, and noticed that in draft 16, Section
        5.1 "Successful Response" describes the scope parameter in a
        confusing way that suggests a copy and paste error.  Included
        below, with [[emphasis added]].

      


      

      
   scope

      
         OPTIONAL.  The scope of the [[access request]]
        expressed as a list

      
         of space-delimited, case sensitive strings.  The
        value is

      
         defined by the authorization server.  If the value
        contains

      
         multiple space-delimited strings, their order does
        not matter,

      
         and each string adds an additional access range to
        the

      
         requested scope.  The authorization server SHOULD
        include the

      
         parameter [[if the requested scope is different from
        the one

      
         requested by the client.]]

      


      

      
Why would the scope parameter in a response includes the
        scope of the [[request]]? Particularly in light of what comes
        [[later]].  Also, how could the requested scope be different
        from the one requested from the client.  The client is the one
        making the request in the first place.

      


      

      


      

      
I'm also wondering if while using a refresh_token to obtain a
        new access token, when the auth server has the opportunity to
        issue a new refresh_token at the same time that the scope of the
        refresh token might change.  I would hope not, but perhaps it
        may.  Considering the scenario where a client has a powerful
        refresh token and wishes to obtain a limited access token
        (smaller scope), would the scope parameter in the section 5.1
        response match the scope of the newly issued refresh token or
        the newly issued access token?  I'm hoping the spec can be
        beefed up to remove any ambiguity here.

      --

      Andrew Arnott

      "I [may] not agree with what you have to say, but I'll defend to
      the death your right to say it." - S. G. Tallentyre

      

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


    

  


--------------000203000702020000070306--

From torsten@lodderstedt.net  Mon Jun 27 14:22:32 2011
Return-Path: 
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 AF10421F8663 for ; Mon, 27 Jun 2011 14:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toNSNuWsQvQ9 for ; Mon, 27 Jun 2011 14:22:32 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2296E21F8662 for ; Mon, 27 Jun 2011 14:22:31 -0700 (PDT)
Received: from [87.142.240.84] (helo=[192.168.71.35]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QbJGI-0007FJ-4B for oauth@ietf.org; Mon, 27 Jun 2011 23:22:30 +0200
Message-ID: <4E08F494.2010807@lodderstedt.net>
Date: Mon, 27 Jun 2011 23:22:28 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Subject: [OAUTH-WG] state parameter and XSRF detection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 21:22:32 -0000

Hi all,

while working on a new revision of the OAuth security document, a 
question arose I would like to clarify on the list.

The "state" parameter is supposed to be used to link a certain 
authorization request and response. Therefore, the client stores a value 
in this parameter that is somehow bound to a value retained on the 
device (the user agent) originating the authorization request.

The question now is: Would it be compliant with the core spec to use any 
other URI query parameter encoded in the redirect_uri, instead of the 
"state" parameter, to achieve the same goal? Probably the client already 
has a working "legacy" implementation it does not want to change just 
for OAuth2 compliance.

According to section 2.2.1, the redirection uri could contain a dynamic
portion:

"The authorization server SHOULD require the client to pre-register
    their redirection URI or at least certain components such as the
    scheme, host, port and path"

So this should be fine.

Any comments?

regards,
Torsten.


From mscurtescu@google.com  Mon Jun 27 14:49:04 2011
Return-Path: 
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 7F77B11E815E for ; Mon, 27 Jun 2011 14:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duG8S3HbKLMM for ; Mon, 27 Jun 2011 14:49:04 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AA8CE11E8156 for ; Mon, 27 Jun 2011 14:49:03 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p5RLn16S007872 for ; Mon, 27 Jun 2011 14:49:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309211342; bh=M0x9DeL1m9oi7Txx3LbivXHV/xI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ti1TrTV4jGb+rqPVW5dQJQvbgrzaf3sfs2Xbr4EhPMPODAFutjXuQi/9JeCVXb7N3 8inCfEEBiVRWb8n4X/a3w==
Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by kpbe14.cbf.corp.google.com with ESMTP id p5RLl7RR012290 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Jun 2011 14:49:00 -0700
Received: by qwa26 with SMTP id 26so3391861qwa.0 for ; Mon, 27 Jun 2011 14:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BkovV2zjm6Ii3N1CnzvRi/w57HZq0Xc8HTsf7Kf5f0s=; b=dKAZei0ocsCF7ERGEpBiEJ2wLT+SLDIzqgIKonvatCRNqKsZoyVMVHm1pCOXj9KNlB ExKf5tvkzr8MzM2h3GvA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fHpRoPrLrGsQsvh0nXSFcq/nFUZsEDOKyTQ5aCa7wt+dM/mdslcKB6zHiGiir+q82x i1ztld/GNNnb61BmAQpA==
Received: by 10.229.46.149 with SMTP id j21mr4955947qcf.294.1309211340135; Mon, 27 Jun 2011 14:49:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.6.133 with HTTP; Mon, 27 Jun 2011 14:48:40 -0700 (PDT)
In-Reply-To: <4E08F494.2010807@lodderstedt.net>
References: <4E08F494.2010807@lodderstedt.net>
From: Marius Scurtescu 
Date: Mon, 27 Jun 2011 14:48:40 -0700
Message-ID: 
To: Torsten Lodderstedt 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] state parameter and XSRF detection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 21:49:04 -0000

On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt
 wrote:
> Hi all,
>
> while working on a new revision of the OAuth security document, a questio=
n
> arose I would like to clarify on the list.
>
> The "state" parameter is supposed to be used to link a certain authorizat=
ion
> request and response. Therefore, the client stores a value in this parame=
ter
> that is somehow bound to a value retained on the device (the user agent)
> originating the authorization request.
>
> The question now is: Would it be compliant with the core spec to use any
> other URI query parameter encoded in the redirect_uri, instead of the
> "state" parameter, to achieve the same goal? Probably the client already =
has
> a working "legacy" implementation it does not want to change just for OAu=
th2
> compliance.
>
> According to section 2.2.1, the redirection uri could contain a dynamic
> portion:
>
> "The authorization server SHOULD require the client to pre-register
> =A0 their redirection URI or at least certain components such as the
> =A0 scheme, host, port and path"
>
> So this should be fine.
>
> Any comments?

It all depends on the authorization server. For example, currently
Google does strict matching on the redirect URI, so you must use
"state".

I think "state" is the only safe, portable option. Unless the OAuth 2
spec dictates how URI matching should be done.

Marius


>
> regards,
> Torsten.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From barryleiba.mailing.lists@gmail.com  Mon Jun 27 15:18:34 2011
Return-Path: 
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 CB26A1F0C4D for ; Mon, 27 Jun 2011 15:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juglUOM-qG3g for ; Mon, 27 Jun 2011 15:18:34 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B41ED1F0C49 for ; Mon, 27 Jun 2011 15:18:25 -0700 (PDT)
Received: by ywp31 with SMTP id 31so3057207ywp.31 for ; Mon, 27 Jun 2011 15:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=c65Pi6THKbnK8Aaa2T+ac8wVnyzdCpJmkOZi0AA6ydA=; b=R650XzrNVTzyXrWylocHLK7nUxeQTe/MycLMpLZVoSS+ZddbimFlT3g6TC87yNoIjw txtEZLmO346I5Wb1lgOUBjUbW5qpVfUFz0L0RH2isju2cg8upmXXXYuS62HYtf6AGbNM lIaLJ6paYCxAyYGO1BDxlnROawnXA/d8y0BH8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=jHt4zVkXQYBGYUAEiSfU+984f+CkG6mhEMGXUEmCn/xo14qQwvqeUI0sncijI6nBEJ r8MFzIaCvgWjEH4XBZBU8HXuF0NB5em2sWcUu9p//uKJvcO7pWwt+SBlLsEkknLzPeER pFsTButuSAhrsNXVQuDPSMmdZN6jtKvzwad60=
MIME-Version: 1.0
Received: by 10.146.28.25 with SMTP id b25mr171802yab.0.1309213104895; Mon, 27 Jun 2011 15:18:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.170.15 with HTTP; Mon, 27 Jun 2011 15:18:24 -0700 (PDT)
Date: Mon, 27 Jun 2011 18:18:24 -0400
X-Google-Sender-Auth: SWuy720nObu-_u1YhTvEVW_qUSo
Message-ID: 
From: Barry Leiba 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 22:18:34 -0000

The subject document, draft-lodderstedt-oauth-security, is now on our
charter, with the rechartering.  The authors have a new version ready,
and would like to post it this week.  The chairs have approved the
name "draft-ietf-oauth-v2-threatmodel-00" for this document, and if
there are no objections the authors will post the new version on
Friday.

Keep in mind that the first priority is still the OAuth 2.0 main spec,
so let's wrap that up.  We're aiming for working-group last call on
that within the month.

Barry, as chair

From sweeden@au1.ibm.com  Mon Jun 27 16:34:55 2011
Return-Path: 
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 8BF9E9E8009; Mon, 27 Jun 2011 16:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnUuvFwFq8PP; Mon, 27 Jun 2011 16:34:55 -0700 (PDT)
Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by ietfa.amsl.com (Postfix) with ESMTP id CDCFA9E8008; Mon, 27 Jun 2011 16:34:53 -0700 (PDT)
Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p5RNUPVE006926; Tue, 28 Jun 2011 09:30:25 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5RNYfCv1200190; Tue, 28 Jun 2011 09:34:45 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5RNYf1d013930; Tue, 28 Jun 2011 09:34:41 +1000
Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5RNYf3F013921; Tue, 28 Jun 2011 09:34:41 +1000
In-Reply-To: <4E08F494.2010807@lodderstedt.net>
References: <4E08F494.2010807@lodderstedt.net>
X-KeepSent: 22BA4605:528FCCB9-4A2578BC:007F176F; type=4; name=$KeepSent
To: Torsten Lodderstedt 
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: 
From: Shane B Weeden 
Date: Tue, 28 Jun 2011 09:13:46 +1000
X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4HF290 | June 6, 2011) at 28/06/2011 09:38:07
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: OAuth WG , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] state parameter and XSRF detection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Jun 2011 23:34:55 -0000

Sounds reasonable - subject to the content of the validation rules for a
registered redirect URI (section 10.11 TBD). The security considerations
doc (or section 10.13 of the spec itself which is TBD) should make it clear
that the state parameter must be provided by the client to prevent CSRF
against the redirect_uri unless the client is already using another
dynamically parameter in the redirect_uri for that purpose. Text should
also include some recommendation on state parameter entropy, along with
describing how it should be validated when the redirect_uri is accessed.

Regards,
Shane.



From:	Torsten Lodderstedt 
To:	OAuth WG 
Date:	28-06-11 07:26 AM
Subject:	[OAUTH-WG] state parameter and XSRF detection
Sent by:	oauth-bounces@ietf.org



Hi all,

while working on a new revision of the OAuth security document, a
question arose I would like to clarify on the list.

The "state" parameter is supposed to be used to link a certain
authorization request and response. Therefore, the client stores a value
in this parameter that is somehow bound to a value retained on the
device (the user agent) originating the authorization request.

The question now is: Would it be compliant with the core spec to use any
other URI query parameter encoded in the redirect_uri, instead of the
"state" parameter, to achieve the same goal? Probably the client already
has a working "legacy" implementation it does not want to change just
for OAuth2 compliance.

According to section 2.2.1, the redirection uri could contain a dynamic
portion:

"The authorization server SHOULD require the client to pre-register
    their redirection URI or at least certain components such as the
    scheme, host, port and path"

So this should be fine.

Any comments?

regards,
Torsten.

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



From stpeter@stpeter.im  Mon Jun 27 20:32:28 2011
Return-Path: 
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 0761111E8109 for ; Mon, 27 Jun 2011 20:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.974
X-Spam-Level: 
X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKD3-JekbGBu for ; Mon, 27 Jun 2011 20:32:26 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 21DDD11E810B for ; Mon, 27 Jun 2011 20:32:26 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 136044032B; Mon, 27 Jun 2011 21:33:19 -0600 (MDT)
Message-ID: <4E094B46.6020701@stpeter.im>
Date: Mon, 27 Jun 2011 21:32:22 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Barry Leiba 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 03:32:28 -0000

On 6/27/11 4:18 PM, Barry Leiba wrote:
> The subject document, draft-lodderstedt-oauth-security, is now on our
> charter, with the rechartering.  The authors have a new version ready,
> and would like to post it this week.  The chairs have approved the
> name "draft-ietf-oauth-v2-threatmodel-00" for this document, and if
> there are no objections the authors will post the new version on
> Friday.

Seems reasonable.

> Keep in mind that the first priority is still the OAuth 2.0 main spec,
> so let's wrap that up.  We're aiming for working-group last call on
> that within the month.

Does "within the month" mean "by the end of June"? :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From barryleiba.mailing.lists@gmail.com  Tue Jun 28 02:37:43 2011
Return-Path: 
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 7A1FE11E80CF for ; Tue, 28 Jun 2011 02:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAuH0imSrwqO for ; Tue, 28 Jun 2011 02:37:43 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F382411E80CD for ; Tue, 28 Jun 2011 02:37:42 -0700 (PDT)
Received: by gxk19 with SMTP id 19so3278357gxk.31 for ; Tue, 28 Jun 2011 02:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vAzwm4AJPdeQIasZ+M/h2cV8NX2LgMr+9sgWZ/6/oFo=; b=iQtpkaaVo6r5XRBCJEI4e3b2cC9+DBNFo/w9DZ78XXQYBBHNxhnS9o1NGlUZd0kIe1 6dDl8aUNkyUk/Ezt7CXne60ZoRJCvIbEdOlAUYDLruEgtvjgXb6cgtQYCUKKDRyngJDn srN//0TL0b4Jy1IL83h2jP44dveQqXCZ/u/i4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rlbbyOxvMiyTiO4yos2ep6+exGDZhn9gg9Dsnvi+g5LMuDnyc2aDkY9MehlJGC5YkX FVZfMFjt7KPZI/l5bPdTfESRCG3iCzl/+JL8fqSbGJhYtpnr/2abNGwbyTG2DKkFkhLc +QaKnvH6LmCS0hHSnOCdhD2gD3RDp9WllJWAs=
MIME-Version: 1.0
Received: by 10.146.28.25 with SMTP id b25mr726921yab.0.1309253862427; Tue, 28 Jun 2011 02:37:42 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.170.15 with HTTP; Tue, 28 Jun 2011 02:37:41 -0700 (PDT)
In-Reply-To: <4E094B46.6020701@stpeter.im>
References:  <4E094B46.6020701@stpeter.im>
Date: Tue, 28 Jun 2011 05:37:41 -0400
X-Google-Sender-Auth: 07bOoy6geadrgfUm98S1i1Y13zE
Message-ID: 
From: Barry Leiba 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 09:37:43 -0000

>> Keep in mind that the first priority is still the OAuth 2.0 main spec,
>> so let's wrap that up. =A0We're aiming for working-group last call on
>> that within the month.
>
> Does "within the month" mean "by the end of June"? :)

Yes; we're very aggressive, here in OAuth land.

On the other hand, maybe the end of July would do.

Barry

From mark.mcgloin@ie.ibm.com  Tue Jun 28 03:27:12 2011
Return-Path: 
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 CDD2321F862A; Tue, 28 Jun 2011 03:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEvsHmri6ktI; Tue, 28 Jun 2011 03:27:12 -0700 (PDT)
Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by ietfa.amsl.com (Postfix) with ESMTP id 0E01421F85FB; Tue, 28 Jun 2011 03:27:11 -0700 (PDT)
Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p5SAR9d3016509; Tue, 28 Jun 2011 10:27:09 GMT
Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5SAQxSa2564336; Tue, 28 Jun 2011 11:27:09 +0100
Received: from d06av08.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5SAQxv8027096; Tue, 28 Jun 2011 11:26:59 +0100
Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5SAQxNc027090; Tue, 28 Jun 2011 11:26:59 +0100
In-Reply-To: 
References: 
X-KeepSent: 1A52C5C0:67CA98B4-802578BD:0036A9C6; type=4; name=$KeepSent
To: Shane B Weeden 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Mark Mcgloin 
Date: Tue, 28 Jun 2011 11:26:21 +0100
X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 28/06/2011 11:26:22
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Draft 16 comment
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 10:27:12 -0000

The question below remains unanswered in relation to native apps being able
to use grant type auth code to utilize refresh tokens. Which of these is
the best option

1) Change oauth spec so client credentials are optional when requesting
access token for grant type 'authorization_code' and for refresh token
requests
2) Edit section 9 on security considerations to remove any references to
native apps using auth code

The difficulty with option 1 is how do you then prevent attackers using a
legitimate client identifier. If we change the spec to say the client
SHOULD pre-register it's redirect-uri, would that suffice?


Regards
Mark

oauth-bounces@ietf.org wrote on 23/05/2011 05:40:22:

> From:
>
> Shane B Weeden 
>
> To:
>
> oauth@ietf.org
>
> Date:
>
> 23/05/2011 06:26
>
> Subject:
>
> [OAUTH-WG] Draft 16 comment
>
> Sent by:
>
> oauth-bounces@ietf.org
>
>
> First, I'd like to add my support for Brian Eaton's comments on Draft 16.
> They actually helped clarify the comment I have below....
>
>
> I found section 9 to be in contradiction to a part of section 6. In
> particular in section 9:
>
>  Native applications SHOULD use the authorization code grant type flow
>  without client password credentials (due to their inability to keep
>  the credentials confidential) to obtain short-lived access tokens,
>  and use refresh tokens to maintain access.
>
> In section 6 the specification is quite clear that client authentication
is
> REQUIRED for the use of refresh tokens:
>
>    The authorization server MUST validate the client credentials, ensure
>    that the refresh token was issued to the authenticated client,
>    validate the refresh token, and verify that the resource owner's
>    authorization is still valid.
>
>
> My  understanding is that refresh tokens are being used as a kind of
> long-lived, rolling "instance secret" for the native application and
> represent the grant authorized by the end user during initial
establishment
> of the authorization code which is used to get the first refresh token.
>
> It seems to me this use case needs to be allowed for in the wording of
> section 6.
>
> Regards,
> Shane.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From t.lodderstedt@telekom.de  Tue Jun 28 03:57:28 2011
Return-Path: 
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 083B621F85F1; Tue, 28 Jun 2011 03:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBqVe0LGtMuv; Tue, 28 Jun 2011 03:57:26 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6860B21F85F9; Tue, 28 Jun 2011 03:57:25 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail71.telekom.de with ESMTP; 28 Jun 2011 12:57:19 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Tue, 28 Jun 2011 12:57:19 +0200
Received: from QEO40072.de.t-online.corp ([169.254.1.170]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Tue, 28 Jun 2011 12:57:04 +0200
From: "Lodderstedt, Torsten" 
To: Mark Mcgloin , Shane B Weeden 
Date: Tue, 28 Jun 2011 12:57:03 +0200
Thread-Topic: [OAUTH-WG] Draft 16 comment
Thread-Index: Acw1fgDOcje08MpeS6amk67BPQpE5QAAjbxw
Message-Id: <63366D5A116E514AA4A9872D3C53353956F93050A6@QEO40072.de.t-online.corp>
References:  
In-Reply-To: 
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Draft 16 comment
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 10:57:28 -0000

+1 for (1)

As pointed out in another posting (http://www.ietf.org/mail-archive/web/oau=
th/current/msg06723.html), I think we have consensus on the patterns for na=
tive app implementation. So in my opinion, we need to adjust the client aut=
hentication part to fit.

In my opinion, the authz server cannot prevent a client from using another =
clients id, even pre-registering a redirect_uri won't help. But this only m=
eans, the authz server cannot provide the user with trustworthy data regard=
ing the app. In this case it is the task of the user and the platform the a=
pp is running on to detect malicious clients (maleware, viruses).

regards,
Torsten.

> -----Urspr=FCngliche Nachricht-----
> Von: Mark Mcgloin [mailto:mark.mcgloin@ie.ibm.com]
> Gesendet: Dienstag, 28. Juni 2011 12:26
> An: Shane B Weeden
> Cc: oauth@ietf.org; oauth-bounces@ietf.org
> Betreff: Re: [OAUTH-WG] Draft 16 comment
>=20
> The question below remains unanswered in relation to native apps being
> able
> to use grant type auth code to utilize refresh tokens. Which of these
> is
> the best option
>=20
> 1) Change oauth spec so client credentials are optional when requesting
> access token for grant type 'authorization_code' and for refresh token
> requests
> 2) Edit section 9 on security considerations to remove any references
> to
> native apps using auth code
>=20
> The difficulty with option 1 is how do you then prevent attackers using
> a
> legitimate client identifier. If we change the spec to say the client
> SHOULD pre-register it's redirect-uri, would that suffice?
>=20
>=20
> Regards
> Mark
>=20
> oauth-bounces@ietf.org wrote on 23/05/2011 05:40:22:
>=20
> > From:
> >
> > Shane B Weeden 
> >
> > To:
> >
> > oauth@ietf.org
> >
> > Date:
> >
> > 23/05/2011 06:26
> >
> > Subject:
> >
> > [OAUTH-WG] Draft 16 comment
> >
> > Sent by:
> >
> > oauth-bounces@ietf.org
> >
> >
> > First, I'd like to add my support for Brian Eaton's comments on Draft
> 16.
> > They actually helped clarify the comment I have below....
> >
> >
> > I found section 9 to be in contradiction to a part of section 6. In
> > particular in section 9:
> >
> >  Native applications SHOULD use the authorization code grant type
> flow
> >  without client password credentials (due to their inability to keep
> >  the credentials confidential) to obtain short-lived access tokens,
> >  and use refresh tokens to maintain access.
> >
> > In section 6 the specification is quite clear that client
> authentication
> is
> > REQUIRED for the use of refresh tokens:
> >
> >    The authorization server MUST validate the client credentials,
> ensure
> >    that the refresh token was issued to the authenticated client,
> >    validate the refresh token, and verify that the resource owner's
> >    authorization is still valid.
> >
> >
> > My  understanding is that refresh tokens are being used as a kind of
> > long-lived, rolling "instance secret" for the native application and
> > represent the grant authorized by the end user during initial
> establishment
> > of the authorization code which is used to get the first refresh
> token.
> >
> > It seems to me this use case needs to be allowed for in the wording
> of
> > section 6.
> >
> > Regards,
> > Shane.
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From gffletch@aol.com  Tue Jun 28 08:47:26 2011
Return-Path: 
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 74C3A21F86B2 for ; Tue, 28 Jun 2011 08:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.509
X-Spam-Level: 
X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUxM4CDQKH2d for ; Tue, 28 Jun 2011 08:47:25 -0700 (PDT)
Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by ietfa.amsl.com (Postfix) with ESMTP id B5CED21F8694 for ; Tue, 28 Jun 2011 08:47:25 -0700 (PDT)
Received: from mtaout-mb01.r1000.mx.aol.com (mtaout-mb01.r1000.mx.aol.com [172.29.41.65]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p5SFlHjg016390 for ; Tue, 28 Jun 2011 11:47:17 -0400
Received: from palantir.local (unknown [10.181.183.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 67099E0001C3 for ; Tue, 28 Jun 2011 11:47:17 -0400 (EDT)
Message-ID: <4E09F785.7050007@aol.com>
Date: Tue, 28 Jun 2011 11:47:17 -0400
From: George Fletcher 
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070204000405050400020109"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:389923072:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d29414e09f7857ca1
X-AOL-IP: 10.181.183.133
Subject: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 15:47:26 -0000

This is a multi-part message in MIME format.
--------------070204000405050400020109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'm working on spec'ing out a use of the Resource Owner Password 
Credentials flow and in trying to map out possible error cases, realized 
that there is no good error for the case that the resource owner's 
password credentials are invalid. Section 4.3 of draft 16 references 
section 5.2 for errors. The list of available errors in section 5.2 are...

    error
          REQUIRED.  A single error code from the following:
          invalid_request
                The request is missing a required parameter, includes an
                unsupported parameter or parameter value, repeats a
                parameter, includes multiple credentials, utilizes more
                than one mechanism for authenticating the client, or is
                otherwise malformed.
          invalid_client
                Client authentication failed (e.g. unknown client, no
                client credentials included, multiple client credentials
                included, or unsupported credentials type).  The
                authorization server MAY return an HTTP 401
                (Unauthorized) status code to indicate which HTTP
                authentication schemes are supported.  If the client
                attempted to authenticate via the "Authorization" request
                header field, the authorization server MUST respond with
                an HTTP 401 (Unauthorized) status code, and include the
                "WWW-Authenticate" response header field matching the
                authentication scheme used by the client.
          invalid_grant
                The provided authorization grant is invalid, expired,
                revoked, does not match the redirection URI used in the
                authorization request, or was issued to another client.
          unauthorized_client
                The authenticated client is not authorized to use this
                authorization grant type.
          unsupported_grant_type
                The authorization grant type is not supported by the
                authorization server.
          invalid_scope
                The requested scope is invalid, unknown, malformed, or
                exceeds the scope granted by the resource owner.


I'm wondering if others have chosen one of these values to represent the 
"invalid_credentials" use case.

Thanks,
George


--------------070204000405050400020109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    I'm working on spec'ing
      out a use of the Resource Owner Password Credentials flow and in
      trying to map out possible error cases, realized that there is no
      good error for the case that the resource owner's password
      credentials are invalid. Section 4.3 of draft 16 references
      section 5.2 for errors. The list of available errors in section
      5.2 are...

      

    
    
   error
         REQUIRED.  A single error code from the following:
         invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter or parameter value, repeats a
               parameter, includes multiple credentials, utilizes more
               than one mechanism for authenticating the client, or is
               otherwise malformed.
         invalid_client
               Client authentication failed (e.g. unknown client, no
               client credentials included, multiple client credentials
               included, or unsupported credentials type).  The
               authorization server MAY return an HTTP 401
               (Unauthorized) status code to indicate which HTTP
               authentication schemes are supported.  If the client
               attempted to authenticate via the "Authorization" request
               header field, the authorization server MUST respond with
               an HTTP 401 (Unauthorized) status code, and include the
               "WWW-Authenticate" response header field matching the
               authentication scheme used by the client.
         invalid_grant
               The provided authorization grant is invalid, expired,
               revoked, does not match the redirection URI used in the
               authorization request, or was issued to another client.
         unauthorized_client
               The authenticated client is not authorized to use this
               authorization grant type.
         unsupported_grant_type
               The authorization grant type is not supported by the
               authorization server.
         invalid_scope
               The requested scope is invalid, unknown, malformed, or
               exceeds the scope granted by the resource owner.



    I'm wondering if others
      have chosen one of these values to represent the
      "invalid_credentials" use case.

      

      Thanks,

      George

    

  


--------------070204000405050400020109--

From bcampbell@pingidentity.com  Tue Jun 28 09:05:36 2011
Return-Path: 
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 6273E21F864B for ; Tue, 28 Jun 2011 09:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.377
X-Spam-Level: 
X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7VUG8tI2M0n for ; Tue, 28 Jun 2011 09:05:35 -0700 (PDT)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9516421F864A for ; Tue, 28 Jun 2011 09:05:35 -0700 (PDT)
Received: from mail-vx0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTgn7zicGySgI18Jhs1QSwVxlnTfl4r5f@postini.com; Tue, 28 Jun 2011 09:05:35 PDT
Received: by mail-vx0-f181.google.com with SMTP id 40so279874vxa.26 for ; Tue, 28 Jun 2011 09:05:34 -0700 (PDT)
Received: by 10.52.76.193 with SMTP id m1mr10991775vdw.204.1309277134062; Tue, 28 Jun 2011 09:05:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.185.98 with HTTP; Tue, 28 Jun 2011 09:05:04 -0700 (PDT)
In-Reply-To: <4E09F785.7050007@aol.com>
References: <4E09F785.7050007@aol.com>
From: Brian Campbell 
Date: Tue, 28 Jun 2011 10:05:04 -0600
Message-ID: 
To: George Fletcher 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 16:05:36 -0000

invalid_grant seems like the appropriate error as the username and
password are the grant in the context of the Resource Owner Password
Credentials flow/grant type.

On Tue, Jun 28, 2011 at 9:47 AM, George Fletcher  wrote:
>
> I'm working on spec'ing out a use of the Resource Owner Password Credenti=
als flow and in trying to map out possible error cases, realized that there=
 is no good error for the case that the resource owner's password credentia=
ls are invalid. Section 4.3 of draft 16 references section 5.2 for errors. =
The list of available errors in section 5.2 are...
>
>    error
>          REQUIRED.  A single error code from the following:
>          invalid_request
>                The request is missing a required parameter, includes an
>                unsupported parameter or parameter value, repeats a
>                parameter, includes multiple credentials, utilizes more
>                than one mechanism for authenticating the client, or is
>                otherwise malformed.
>          invalid_client
>                Client authentication failed (e.g. unknown client, no
>                client credentials included, multiple client credentials
>                included, or unsupported credentials type).  The
>                authorization server MAY return an HTTP 401
>                (Unauthorized) status code to indicate which HTTP
>                authentication schemes are supported.  If the client
>                attempted to authenticate via the "Authorization" request
>                header field, the authorization server MUST respond with
>                an HTTP 401 (Unauthorized) status code, and include the
>                "WWW-Authenticate" response header field matching the
>                authentication scheme used by the client.
>          invalid_grant
>                The provided authorization grant is invalid, expired,
>                revoked, does not match the redirection URI used in the
>                authorization request, or was issued to another client.
>          unauthorized_client
>                The authenticated client is not authorized to use this
>                authorization grant type.
>          unsupported_grant_type
>                The authorization grant type is not supported by the
>                authorization server.
>          invalid_scope
>                The requested scope is invalid, unknown, malformed, or
>                exceeds the scope granted by the resource owner.
>
> I'm wondering if others have chosen one of these values to represent the =
"invalid_credentials" use case.
>
> Thanks,
> George
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From igor.faynberg@alcatel-lucent.com  Tue Jun 28 09:14:41 2011
Return-Path: 
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 6843B11E808C for ; Tue, 28 Jun 2011 09:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MZNPDg5rVYJ for ; Tue, 28 Jun 2011 09:14:40 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 017F421F86D2 for ; Tue, 28 Jun 2011 09:14:39 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5SGEbLQ002614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 28 Jun 2011 11:14:37 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5SGEaqv017978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Jun 2011 11:14:37 -0500
Received: from [135.222.134.156] (USMUYN0L055118.mh.lucent.com [135.222.134.156]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5SGEaZj008330; Tue, 28 Jun 2011 11:14:36 -0500 (CDT)
Message-ID: <4E09FDEB.4040306@alcatel-lucent.com>
Date: Tue, 28 Jun 2011 12:14:35 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [OAUTH-WG] Draft 16 comment
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 16:14:41 -0000

I know I have harped on that too many times previously, but just for the 
purpose of counting "votes,"  I think that option 2) is NOT an option. 
(Vote: -2 for 2)

That leaves option 1) as a must as far as I am concerned.

Igor

On 6/28/2011 6:26 AM, Mark Mcgloin wrote:
> The question below remains unanswered in relation to native apps being able
> to use grant type auth code to utilize refresh tokens. Which of these is
> the best option
>
> 1) Change oauth spec so client credentials are optional when requesting
> access token for grant type 'authorization_code' and for refresh token
> requests
> 2) Edit section 9 on security considerations to remove any references to
> native apps using auth code
>
> The difficulty with option 1 is how do you then prevent attackers using a
> legitimate client identifier. If we change the spec to say the client
> SHOULD pre-register it's redirect-uri, would that suffice?
>
>
> Regards
> Mark
>
> oauth-bounces@ietf.org wrote on 23/05/2011 05:40:22:
>
>> From:
>>
>> Shane B Weeden
>>
>> To:
>>
>> oauth@ietf.org
>>
>> Date:
>>
>> 23/05/2011 06:26
>>
>> Subject:
>>
>> [OAUTH-WG] Draft 16 comment
>>
>> Sent by:
>>
>> oauth-bounces@ietf.org
>>
>>
>> First, I'd like to add my support for Brian Eaton's comments on Draft 16.
>> They actually helped clarify the comment I have below....
>>
>>
>> I found section 9 to be in contradiction to a part of section 6. In
>> particular in section 9:
>>
>>   Native applications SHOULD use the authorization code grant type flow
>>   without client password credentials (due to their inability to keep
>>   the credentials confidential) to obtain short-lived access tokens,
>>   and use refresh tokens to maintain access.
>>
>> In section 6 the specification is quite clear that client authentication
> is
>> REQUIRED for the use of refresh tokens:
>>
>>     The authorization server MUST validate the client credentials, ensure
>>     that the refresh token was issued to the authenticated client,
>>     validate the refresh token, and verify that the resource owner's
>>     authorization is still valid.
>>
>>
>> My  understanding is that refresh tokens are being used as a kind of
>> long-lived, rolling "instance secret" for the native application and
>> represent the grant authorized by the end user during initial
> establishment
>> of the authorization code which is used to get the first refresh token.
>>
>> It seems to me this use case needs to be allowed for in the wording of
>> section 6.
>>
>> Regards,
>> Shane.
>>
>> _______________________________________________
>> 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

From eran@hueniverse.com  Tue Jun 28 09:40:52 2011
Return-Path: 
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 69CFD11E8153 for ; Tue, 28 Jun 2011 09:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4uYKlng39sH for ; Tue, 28 Jun 2011 09:40:51 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 894FE11E813D for ; Tue, 28 Jun 2011 09:40:51 -0700 (PDT)
Received: (qmail 29972 invoked from network); 28 Jun 2011 16:40:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jun 2011 16:40:51 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 28 Jun 2011 09:40:38 -0700
From: Eran Hammer-Lahav 
To: Brian Campbell , George Fletcher 
Date: Tue, 28 Jun 2011 09:40:22 -0700
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw1rTq1GLjirUwcQBqmkHP3tRHcVwABNCJQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB13C1@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E09F785.7050007@aol.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jun 2011 16:40:52 -0000

Yep. Invalid grant is the right error code.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Brian Campbell
> Sent: Tuesday, June 28, 2011 9:05 AM
> To: George Fletcher
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Resource Owner Password Credentials
> question/feedback
>=20
> invalid_grant seems like the appropriate error as the username and
> password are the grant in the context of the Resource Owner Password
> Credentials flow/grant type.
>=20
> On Tue, Jun 28, 2011 at 9:47 AM, George Fletcher  wrote=
:
> >
> > I'm working on spec'ing out a use of the Resource Owner Password
> Credentials flow and in trying to map out possible error cases, realized =
that
> there is no good error for the case that the resource owner's password
> credentials are invalid. Section 4.3 of draft 16 references section 5.2 f=
or
> errors. The list of available errors in section 5.2 are...
> >
> >    error
> >          REQUIRED.  A single error code from the following:
> >          invalid_request
> >                The request is missing a required parameter, includes an
> >                unsupported parameter or parameter value, repeats a
> >                parameter, includes multiple credentials, utilizes more
> >                than one mechanism for authenticating the client, or is
> >                otherwise malformed.
> >          invalid_client
> >                Client authentication failed (e.g. unknown client, no
> >                client credentials included, multiple client credentials
> >                included, or unsupported credentials type).  The
> >                authorization server MAY return an HTTP 401
> >                (Unauthorized) status code to indicate which HTTP
> >                authentication schemes are supported.  If the client
> >                attempted to authenticate via the "Authorization" reques=
t
> >                header field, the authorization server MUST respond with
> >                an HTTP 401 (Unauthorized) status code, and include the
> >                "WWW-Authenticate" response header field matching the
> >                authentication scheme used by the client.
> >          invalid_grant
> >                The provided authorization grant is invalid, expired,
> >                revoked, does not match the redirection URI used in the
> >                authorization request, or was issued to another client.
> >          unauthorized_client
> >                The authenticated client is not authorized to use this
> >                authorization grant type.
> >          unsupported_grant_type
> >                The authorization grant type is not supported by the
> >                authorization server.
> >          invalid_scope
> >                The requested scope is invalid, unknown, malformed, or
> >                exceeds the scope granted by the resource owner.
> >
> > I'm wondering if others have chosen one of these values to represent th=
e
> "invalid_credentials" use case.
> >
> > Thanks,
> > George
> >
> >
> > _______________________________________________
> > 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

From tonynad@microsoft.com  Tue Jun 28 18:15:51 2011
Return-Path: 
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 3752C11E8127 for ; Tue, 28 Jun 2011 18:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level: 
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBxvoGeMwGwP for ; Tue, 28 Jun 2011 18:15:49 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5111E8096 for ; Tue, 28 Jun 2011 18:15:23 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 28 Jun 2011 18:15:22 -0700
Received: from AM1EHSOBE003.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 28 Jun 2011 18:15:22 -0700
Received: from mail48-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 29 Jun 2011 01:15:17 +0000
Received: from mail48-am1 (localhost.localdomain [127.0.0.1])	by mail48-am1-R.bigfish.com (Postfix) with ESMTP id 1B8B316F81F4	for ; Wed, 29 Jun 2011 01:15:18 +0000 (UTC)
X-SpamScore: 3
X-BigFish: PS3(zzzz1202h1082kzz8275bh8275dhz31h2a8h668h839h62h)
X-Spam-TCS-SCL: 1:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail48-am1: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=tonynad@microsoft.com; helo=CH1PRD0302HT003.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail48-am1 (localhost.localdomain [127.0.0.1]) by mail48-am1 (MessageSwitch) id 1309310117576831_1589; Wed, 29 Jun 2011 01:15:17 +0000 (UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.247])	by mail48-am1.bigfish.com (Postfix) with ESMTP id 7BAE7B5804E	for ; Wed, 29 Jun 2011 01:15:17 +0000 (UTC)
Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (157.55.61.146) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 29 Jun 2011 01:15:13 +0000
Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.239]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.056; Wed, 29 Jun 2011 01:15:11 +0000
From: Anthony Nadalin 
To: "OAuth WG (oauth@ietf.org)" 
Thread-Topic: Native Application Text
Thread-Index: Acw16NyZvC61BBzbTqSOVSJ2OxoVBg==
Date: Wed, 29 Jun 2011 01:15:10 +0000
Message-ID: 
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_B26C1EF377CB694EAB6BDDC8E624B6E723143605CH1PRD0302MB115_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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: TK5EX14MLTC104.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com
Subject: [OAUTH-WG] Native Application Text
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 01:15:51 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723143605CH1PRD0302MB115_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

9. Native Applications

A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application, etc.).=
  Native applications may require special consideration related to security=
, platform capabilities, and overall end-user experience.  The following ar=
e examples of how native applications may utilize OAuth:

   o  Initiate an Authorization Request using an external user-agent: The n=
ative application can capture the response from the authorization server us=
ing a variety of techniques such as the use of the various methods for redi=
rection including a URI identifying a custom URI scheme (registered with th=
e operating system to invoke the native application as handler), manual cop=
y-and-paste, running a local webserver, browser plug-ins, or by providing a=
 redirection URI identifying a server-hosted resource under the native appl=
ication's control, which in turn makes the response available to the native=
 application.
   o  Initiate an Authorization Request using an embedded user-agent:  The =
native application obtains the response by directly communicating with the =
embedded user-agent.  Techniques include monitoring state changes emitted d=
uring URL loading, monitoring http headers, accessing the user-agent's cook=
ie jar, etc.

When choosing between launching an external user-agent and an embedded user=
-agent, native application developers should consider the following:

   o  External user-agents may improve completion rate as the end-user may =
already have an active session with the authorization server removing the n=
eed to re-authenticate, and provide a familiar user-agent user experience a=
nd functionality.  The end-user may also rely on extensions or add-ons to a=
ssist with authentication (e.g. password managers or 2-factor device reader=
).
   o  Embedded user-agents may offer an improved end-user flow, as they rem=
ove the need to switch context and open new windows.
   o  Embedded user-agents pose a security challenge because end-users are =
authenticating in an unidentified window without access to the visual prote=
ctions found on by many of the external user-agents.  Embedded user-agents =
educate end-user to trust unidentified requests for authentication (making =
phishing attacks easier to execute).

When choosing between implicit and authorization code grant types, the foll=
owing should be considered:

   o  Native applications that use the authorization code grant type flow S=
HOULD do so without using client password credentials, due to the native ap=
plication's inability to keep those credentials secure.
   o  When using the implicit grant type flow a refresh token is not return=
ed


--_000_B26C1EF377CB694EAB6BDDC8E624B6E723143605CH1PRD0302MB115_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











9. Native Applications



A native application is a client which is installed and executes on the end=
-user's device (i.e. desktop application, native mobile application, etc.).=
  Native applications may require special consideration related to sec=
urity, platform capabilities, and overall
 end-user experience.  The following are examples of how native applic=
ations may utilize OAuth:



   o  Initiate an Authorization Request using an extern=
al user-agent: The native application can capture the response from the aut=
horization server using a variety of techniques such as the use of the vari=
ous methods for redirection including a URI identifying
 a custom URI scheme (registered with the operating system to invoke the na=
tive application as handler), manual copy-and-paste, running a local webser=
ver, browser plug-ins, or by providing a redirection URI identifying a serv=
er-hosted resource under the native
 application's control, which in turn makes the response available to the n=
ative application.

   o  Initiate an Authorization Request using an embedd=
ed user-agent:  The native application obtains the response by directl=
y communicating with the embedded user-agent.  Techniques include moni=
toring state changes emitted during URL loading, monitoring http
 headers, accessing the user-agent's cookie jar, etc.



When choosing between launching an external user-agent and an embedded user=
-agent, native application developers should consider the following:



   o  External user-agents may improve completion rate =
as the end-user may already have an active session with the authorization s=
erver removing the need to re-authenticate, and provide a familiar user-age=
nt user experience and functionality.  The end-user
 may also rely on extensions or add-ons to assist with authentication (e.g.=
 password managers or 2-factor device reader).

   o  Embedded user-agents may offer an improved end-us=
er flow, as they remove the need to switch context and open new windows.&nb=
sp;

   o  Embedded user-agents pose a security challenge be=
cause end-users are authenticating in an unidentified window without access=
 to the visual protections found on by many of the external user-agents. &n=
bsp;Embedded user-agents educate end-user to trust unidentified
 requests for authentication (making phishing attacks easier to execute).


When choosing between implicit and authorization code grant types, the foll=
owing should be considered:



   o  Native applications that use the authorization co=
de grant type flow SHOULD do so without using client password credentials, =
due to the native application’s inability to keep those credentials s=
ecure.

   o  When using the implicit grant type flow a refresh=
 token is not returned  


 






--_000_B26C1EF377CB694EAB6BDDC8E624B6E723143605CH1PRD0302MB115_--

From wmills@yahoo-inc.com  Tue Jun 28 18:36:21 2011
Return-Path: 
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 3B8CD22801B for ; Tue, 28 Jun 2011 18:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAmpkzNG2o6m for ; Tue, 28 Jun 2011 18:36:20 -0700 (PDT)
Received: from nm29.bullet.mail.sp2.yahoo.com (nm29.bullet.mail.sp2.yahoo.com [98.139.91.99]) by ietfa.amsl.com (Postfix) with SMTP id 3B111228018 for ; Tue, 28 Jun 2011 18:36:20 -0700 (PDT)
Received: from [98.139.91.66] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jun 2011 01:36:17 -0000
Received: from [98.139.91.8] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jun 2011 01:36:17 -0000
Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 29 Jun 2011 01:36:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 153089.73190.bm@omp1008.mail.sp2.yahoo.com
Received: (qmail 913 invoked by uid 60001); 29 Jun 2011 01:36:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1309311376; bh=LFcDgqKBGEF/QpSUHP24fZaLv4bDj6jQYl04UD4BxQc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NTxEkkJeYt7NOAJUuJBE4bEjcSya4SwlaTLJNgWKaZyDmO+HsnzQuY7KbIYHgVElqyCN2B6vzYRO54ATY0pd5qtav9jOdWLkaRZXyRXqCT4wEVKJA1FSGUNwC0ny1bDqyUV0Vt//B9goVCbx6gC/kap+GRez/XUKl7gYzGtrhj0=
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:In-Reply-To:MIME-Version:Content-Type; b=q0O68MYgy/K6XS8ljGRM4UKPKIih4sxZ67EjkELnI22U0P4A0BdhbQ6NI4OO3cx54upxuLujyA+Fh4Oyoq04gPWctdYL22kXqDzDPHvQTtK2jI+BOeIAUD4VVEYzjPrPaIgdrkRkYd1Fvc1U9xP+X6yA2DJSifSmHk1pdUXvUXc=;
X-YMail-OSG: UK2REasVM1n_I5kKNJUlvg6.5xQnCbjtHHjuDDs4.oOc5t9 EbTAY1UIOo3x94Pep7bqhmUnUsTsc40i7GfimIsZhvOERgfCG46c7L.82CZd _hO7nB_reAgxlcXBRxxOquFwLcVh14SYKDc_avQZbzXNDYssrOwLpNlIG_ai cqUx6N2foTzfhK4qxxEG1Hc7w2cf3IBsuQwcGStq4kUxixce9rw.kdNtK6Yr cOZjNwHJLtep7hzAOwBuJfePTYG2aco7PTNOynVdI7BkyeAFv6XnfvNuMrFu ibVzlW4.8aCJBIKevCtyhtJJxpYylSWZvqss2F9gbIxkQGeVv049JcQIkEZX aN5rHWXZTlL3cF6PKqptuBV29MDCPE2_jPDSPE9vr
Received: from [216.145.52.206] by web31811.mail.mud.yahoo.com via HTTP; Tue, 28 Jun 2011 18:36:16 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.310352
References: 
Message-ID: <1309311376.66076.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Tue, 28 Jun 2011 18:36:16 -0700 (PDT)
From: "William J. Mills" 
To: Anthony Nadalin , "OAuth WG \(oauth@ietf.org\)" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-341411841-1309311376=:66076"
Subject: Re: [OAUTH-WG] Native Application Text
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "William J. Mills" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 01:36:21 -0000

--0-341411841-1309311376=:66076
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

You text does not mention what will be a common use case, where the native =
app uses the password grant to fetch a refresh and access token.=C2=A0 Whet=
her or not an app can keep a secret, it's better to have it store the token=
 than the username/password pair.=0A=0A=0A=0A______________________________=
__=0AFrom: Anthony Nadalin =0ATo: "OAuth WG (oauth@i=
etf.org)" =0ASent: Tuesday, June 28, 2011 6:15 PM=0ASubject=
: [OAUTH-WG] Native Application Text=0A=0A =0A9. Native Applications=0A=0AA=
 native application is a client which is installed and executes on the end-=
user's device (i.e. desktop application, native mobile application, etc.). =
=C2=A0Native applications may require special consideration related to secu=
rity, platform capabilities, and overall=0A end-user experience. =C2=A0The =
following are examples of how native applications may utilize OAuth:=0A=0A=
=C2=A0=C2=A0=C2=A0o =C2=A0Initiate an Authorization Request using an extern=
al user-agent: The native application can capture the response from the aut=
horization server using a variety of techniques such as the use of the vari=
ous methods for redirection including a URI identifying=0A a custom URI sch=
eme (registered with the operating system to invoke the native application =
as handler), manual copy-and-paste, running a local webserver, browser plug=
-ins, or by providing a redirection URI identifying a server-hosted resourc=
e under the native=0A application's control, which in turn makes the respon=
se available to the native application.=0A=C2=A0=C2=A0=C2=A0o =C2=A0Initiat=
e an Authorization Request using an embedded user-agent: =C2=A0The native a=
pplication obtains the response by directly communicating with the embedded=
 user-agent. =C2=A0Techniques include monitoring state changes emitted duri=
ng URL loading, monitoring http=0A headers, accessing the user-agent's cook=
ie jar, etc.=0A=0AWhen choosing between launching an external user-agent an=
d an embedded user-agent, native application developers should consider the=
 following:=0A=0A=C2=A0=C2=A0=C2=A0o =C2=A0External user-agents may improve=
 completion rate as the end-user may already have an active session with th=
e authorization server removing the need to re-authenticate, and provide a =
familiar user-agent user experience and functionality. =C2=A0The end-user=
=0A may also rely on extensions or add-ons to assist with authentication (e=
.g. password managers or 2-factor device reader).=0A=C2=A0=C2=A0=C2=A0o =C2=
=A0Embedded user-agents may offer an improved end-user flow, as they remove=
 the need to switch context and open new windows.=C2=A0=0A=C2=A0=C2=A0=C2=
=A0o =C2=A0Embedded user-agents pose a security challenge because end-users=
 are authenticating in an unidentified window without access to the visual =
protections found on by many of the external user-agents. =C2=A0Embedded us=
er-agents educate end-user to trust unidentified=0A requests for authentica=
tion (making phishing attacks easier to execute).=0A=0AWhen choosing betwee=
n implicit and authorization code grant types, the following should be cons=
idered:=0A=0A=C2=A0=C2=A0=C2=A0o =C2=A0Native applications that use the aut=
horization code grant type flow SHOULD do so without using client password =
credentials, due to the native application=E2=80=99s inability to keep thos=
e credentials secure.=0A=C2=A0=C2=A0=C2=A0o =C2=A0When using the implicit g=
rant type flow a refresh token is not returned =C2=A0=0A=C2=A0=0A__________=
_____________________________________=0AOAuth mailing list=0AOAuth@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--0-341411841-1309311376=:66076
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


You text does not mention what will be a common use case, where the nativ=
e app uses the password grant to fetch a refresh and access token.  Wh=
ether or not an app can keep a secret, it's better to have it store the tok=
en than the username/password pair.

From: Anthony Nadalin <tonynad@m=
icrosoft.com>
To: "O=
Auth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Tuesday, June 28, 2011 6:15 PM
Subject: [OAUTH-WG] Native Applica=
tion Text

=0A=0A=0A =0A =0A=0A
=0A
9. Native=
 Applications
=0A
=0AA native application is a client which is instal=
led and executes on the end-user's device (i.e. desktop application, native=
 mobile application, etc.).  Native applications may require special c=
onsideration related to security, platform capabilities, and overall=0A end=
-user experience.  The following are examples of how native applicatio=
ns may utilize OAuth:
=0A
=0A   o  Initiate an Au=
thorization Request using an external user-agent: The native application ca=
n capture the response from the authorization server using a variety of tec=
hniques such as the use of the various methods for redirection including a =
URI identifying=0A a custom URI scheme (registered with the operating syste=
m to invoke the native application as handler), manual copy-and-paste, runn=
ing a local webserver, browser plug-ins, or by providing a redirection URI =
identifying a server-hosted resource under the native=0A application's cont=
rol, which in turn makes the response available to the native application.<=
br>=0A   o  Initiate an Authorization Request using an =
embedded user-agent:  The native application obtains the response by d=
irectly communicating with the embedded user-agent.  Techniques includ=
e monitoring state changes emitted during URL loading, monitoring http=0A h=
eaders, accessing the user-agent's cookie jar, etc.
=0A
=0AWhen choos=
ing between launching an external user-agent and an embedded user-agent, na=
tive application developers should consider the following:
=0A
=0A&nb=
sp;  o  External user-agents may improve completion rate as =
the end-user may already have an active session with the authorization serv=
er removing the need to re-authenticate, and provide a familiar user-agent =
user experience and functionality.  The end-user=0A may also rely on e=
xtensions or add-ons to assist with authentication (e.g. password managers =
or 2-factor device reader).
=0A   o  Embedded user-a=
gents may offer an improved end-user flow, as they remove the need to switc=
h context and open new windows. 
=0A   o  Embed=
ded user-agents pose a security challenge because end-users are authenticat=
ing in an unidentified window without access to the visual protections foun=
d on by many of the external user-agents.  Embedded user-agents educat=
e end-user to trust unidentified=0A requests for authentication (making phi=
shing attacks easier to execute).
=0A
=0AWhen choosing between implic=
it and authorization code grant types, the following should be considered:<=
br>=0A
=0A   o  Native applications that use the aut=
horization code grant type flow SHOULD do so without using client password =
credentials, due to the native application=E2=80=99s inability to keep thos=
e credentials secure.
=0A   o  When using the implic=
it grant type flow a refresh token is not returned  
 =0A<=
div class=3D"yiv-2009381541MsoNormal">  
 =0A
=0A =0A
___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/oauth



--0-341411841-1309311376=:66076--

From marcus@better.se  Wed Jun 29 02:58:25 2011
Return-Path: 
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 8F1459E801A for ; Wed, 29 Jun 2011 02:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6PtdZoLlLA9 for ; Wed, 29 Jun 2011 02:58:25 -0700 (PDT)
Received: from vips.better.se (vips.better.se [79.99.3.21]) by ietfa.amsl.com (Postfix) with ESMTP id D423F21F86CE for ; Wed, 29 Jun 2011 02:58:24 -0700 (PDT)
Received: from [192.168.1.180] (unknown [80.169.182.16]) by vips.better.se (Postfix) with ESMTPSA id 80A1B20EC095 for ; Wed, 29 Jun 2011 11:58:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=better.se; s=mail; t=1309341502; bh=ucecMxmmNnwHB26jDDNz2EqXIK0B1HEzgqcnQWYX0C8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JpePRt6NNdpMAnPzgxLTSIkDggV9jFHbI3kUyEtp1Ze5fsZytXWJQq6xmEd1qC1oz qhr/UvGTsDg9zSZB0MMa4R3vH+Ru/3dzTf6/S3AUJUG0vryX+NYD26/veAk2fNbWJx KHdq7FhEPSRRpONNGx7NMeL3SZp0vfOlx4BhE2Qo=
Message-ID: <4E0AF73D.7040504@better.se>
Date: Wed, 29 Jun 2011 11:58:21 +0200
From: Marcus Better 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: <4E09F785.7050007@aol.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 09:58:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-06-28 18:05, Brian Campbell wrote:
> invalid_grant seems like the appropriate error as the username and
> password are the grant in the context of the Resource Owner Password
> Credentials flow/grant type.

What should the HTTP status code be? The spec seems to indicate 400, but
I would think 401 would be appropriate?

Cheers,

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4K9zkACgkQXjXn6TzcAQmI7gCg8nKkTbb2rKFAXTEMm6WMaPL0
o3EAoKYHWKhCmqcFTZHDCcGpw65Leukz
=ocuC
-----END PGP SIGNATURE-----

From t.lodderstedt@telekom.de  Wed Jun 29 05:08:34 2011
Return-Path: 
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 1C4A511E8072 for ; Wed, 29 Jun 2011 05:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5tagPlk+eph for ; Wed, 29 Jun 2011 05:08:33 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54911E8070 for ; Wed, 29 Jun 2011 05:08:32 -0700 (PDT)
X-Mailbb-Crypt: true
Received: from he111467.emea1.cds.t-internal.com (HELO he111467) ([10.206.92.85]) by tcmail81.telekom.de with ESMTP; 29 Jun 2011 14:08:23 +0200
Received: from tcmail81.telekom.de ([192.168.84.145]) by TrustMail (Totemo SMTP Server) with SMTP ID 297; Wed, 29 Jun 2011 14:08:20 +0200 (CEST)
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail81.telekom.de with ESMTP; 29 Jun 2011 14:08:15 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Wed, 29 Jun 2011 14:08:15 +0200
Received: from QEO40072.de.t-online.corp ([169.254.1.170]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Wed, 29 Jun 2011 14:08:15 +0200
From: "Lodderstedt, Torsten" 
To: Marcus Better , "oauth@ietf.org" 
Date: Wed, 29 Jun 2011 14:08:13 +0200
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw2Q0asnKtFwxvpTkCPatJJA5sDBQAEZ8cg
Message-Id: <63366D5A116E514AA4A9872D3C53353956F9305358@QEO40072.de.t-online.corp>
References: <4E09F785.7050007@aol.com>  <4E0AF73D.7040504@better.se>
In-Reply-To: <4E0AF73D.7040504@better.se>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 12:08:34 -0000

> -----Urspr=FCngliche Nachricht-----
> Von: Marcus Better [mailto:marcus@better.se]
> Gesendet: Mittwoch, 29. Juni 2011 11:58
> An: oauth@ietf.org
> Betreff: Re: [OAUTH-WG] Resource Owner Password Credentials
> question/feedback
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 2011-06-28 18:05, Brian Campbell wrote:
> > invalid_grant seems like the appropriate error as the username and
> > password are the grant in the context of the Resource Owner Password
> > Credentials flow/grant type.
>=20
> What should the HTTP status code be? The spec seems to indicate 400,
> but
> I would think 401 would be appropriate?

401 would be the correct status code if OAuth would use HTTP authentication=
 for the authentication of the resource owner. But it doesn't. Instead HTTP=
 authentication (BASIC) is used to authenticate the OAuth client whereas th=
e resource owner's credentials are passed via request parameters.

regards,
Torsten.

>=20
> Cheers,
>=20
> Marcus
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAk4K9zkACgkQXjXn6TzcAQmI7gCg8nKkTbb2rKFAXTEMm6WMaPL0
> o3EAoKYHWKhCmqcFTZHDCcGpw65Leukz
> =3DocuC
> -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From bill@dehora.net  Wed Jun 29 06:40:48 2011
Return-Path: 
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 B41E79E803C for ; Wed, 29 Jun 2011 06:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjuX+RvpH6Pp for ; Wed, 29 Jun 2011 06:40:48 -0700 (PDT)
Received: from chilco.textdrive.com (mail.indigozen.co.uk [207.7.108.242]) by ietfa.amsl.com (Postfix) with ESMTP id 001D19E800C for ; Wed, 29 Jun 2011 06:40:47 -0700 (PDT)
Received: from [192.168.3.18] (87-198-172-217.static.ptr.magnet.ie [87.198.172.217]) by chilco.textdrive.com (Postfix) with ESMTP id 9ED81DEF99 for ; Wed, 29 Jun 2011 13:40:46 +0000 (UTC)
Message-ID: <4E0B2B5B.1040704@dehora.net>
Date: Wed, 29 Jun 2011 14:40:43 +0100
From: Bill 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: oauth@ietf.org
References: <4E1F6AAD24975D4BA5B168042967394348D04A47@TK5EX14MBXC202.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D04A47@TK5EX14MBXC202.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 13:40:48 -0000

This is a much clearer draft, thanks. I'm looking at support for this at 
the moment and are wondering is there much implementer experience to 
date with bearer tokens, and/or how stable the wg think the draft is at 
this point?

Bill

On 23/06/11 01:53, Mike Jones wrote:
> I’ve published draft 06
>  of the
> OAuth Bearer Token Specification
> . It
> contains the following changes:
>
> ·Changed parameter name bearer_tokento access_token, per working group
> consensus.
>
> ·Changed HTTP status code for invalid_requesterror code from HTTP 401
> (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP
> working group experts.
>
> It doesn’t change the use of 403 (Forbidden) to (401) Unauthorized as
> had been discussed as a possibility, also due to input from the same
> HTTP working group experts.
>
> I believe that this addresses all the bearer token specification issues
> arising from the interim working group meeting and working group
> discussions since then.
>
> The draft is available at these locations:
>
> ·http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.pdf
>
> ·http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt
>
> ·http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.xml
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will
> point to new versions as they are posted)
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point
> to new versions as they are posted)
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point
> to new versions as they are posted)
>
> ·http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point
> to new versions as they are posted)
>
> ·http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion
> repository, with html, pdf, txt, and html versions available)
>
> -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From bcampbell@pingidentity.com  Wed Jun 29 15:07:07 2011
Return-Path: 
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 2D9C911E8111 for ; Wed, 29 Jun 2011 15:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level: 
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUsaCYRXFz1D for ; Wed, 29 Jun 2011 15:07:06 -0700 (PDT)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA511E8108 for ; Wed, 29 Jun 2011 15:07:05 -0700 (PDT)
Received: from mail-qy0-f177.google.com ([209.85.216.177]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTguiCTknZByoNgJhqYnvfEJo2MdFxk4B@postini.com; Wed, 29 Jun 2011 15:07:06 PDT
Received: by mail-qy0-f177.google.com with SMTP id 7so1592717qyk.1 for ; Wed, 29 Jun 2011 15:07:05 -0700 (PDT)
Received: by 10.224.125.8 with SMTP id w8mr1086497qar.37.1309385225065; Wed, 29 Jun 2011 15:07:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.45.68 with HTTP; Wed, 29 Jun 2011 15:06:35 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Wed, 29 Jun 2011 16:06:35 -0600
Message-ID: 
To: Chuck Mortimore 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 22:07:07 -0000

Maybe this is already a known issue but it just occurred to me that
this draft probably needs to have an IANA Considerations section that
registers the parameters that it defines per registry defined in the
core OAuth spec [1] - assertion, client_assertion_type, &
client_assertion.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-11.2

On Mon, Jun 20, 2011 at 1:16 PM, Chuck Mortimore
 wrote:
>
> Thanks Thomas =96 it=92s good to hear that it=92s on the right track....t=
ook awhile to get both understanding and agreement.
>
> There was a good deal of debate on SHOULD vs MUST for client_id in sectio=
n 5.1. =A0=A0The argument for SHOULD was generally that there are use-cases=
 where the client_id provided as a parameter is enough, the client_id can b=
e implied, or the assertion format may not easily allow for it.
>
> As long as the Authorization Server can correlate the client with the key=
ing material it uses for verification of the assertion then I think SHOULD =
is enough. =A0=A0( note, I started out on the other side of this argument )=
 =A0=A0=A0The SAML and JWT profiles we expect can turn this to a MUST, but =
we want the general guidance to be a little less strict.
>
> That=92s the thinking...
>
> -cmort
>
>
> On 6/20/11 11:31 AM, "Thomas Hardjono"  wrote:
>
>
>
> Chuck,
>
> This is a good draft. Real progress. =A0I wish we had this draft before t=
he WG spent so much time in IETF-Prague arguing about the assertions text.
>
> Just a short question. =A0Section 5.1 states that the principal identity =
SHOULD be the client_id (for the OAuth client):
>
> =A0=A0=A0Principal =A0A unique identifier for the subject of the assertio=
n.
> =A0=A0=A0=A0=A0=A0When using assertions for client authentication, the Pr=
incipal
> =A0=A0=A0=A0=A0=A0SHOULD be the client_id of the OAuth client. =A0When us=
ing
> =A0=A0=A0=A0=A0=A0assertions as an authorization grant, the Principal MUS=
T identify
> =A0=A0=A0=A0=A0=A0an authorized accessor for whom the access token is bei=
ng
> =A0=A0=A0=A0=A0=A0requested (typically the resource owner, or an authoriz=
ed
> =A0=A0=A0=A0=A0=A0delegate).
>
> Why is this a "SHOULD"? =A0(I would think this is a "MUST).
>
> In Section 6.1 "The Principal MUST identify an authorized accessor". In S=
ection 6.3 =A0"The Principal MUST identify an authorized accessor...".
>
>
> PS. More broadly, I'm thinking not only of a model where the OAuth-client=
 gets an assertion from the STS/IdP server, but also of a situation in wher=
e the human-user (resource owner) specifically names the Subject (the OAuth=
 Client) in a multi-hop delegation case.
>
> More questions later.
>
> Thanks.
>
> /thomas/
>
>
> __________________________
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Chuck Mortimore
> > Sent: Saturday, June 18, 2011 3:42 PM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] New Assertion Draft for review
> >
> > A number of us in the community have been working on a general model
> > for the use of Assertions in OAuth2 for both client authentication, as
> > well as authorization grants. =A0We've reached general consensus on a d=
oc
> > that I've published as a draft:
> >
> > http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt
> >
> > Feedback and discussion welcome!
> >
> > Thanks
> >
> > -cmort
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From eran@hueniverse.com  Thu Jun 30 00:18:38 2011
Return-Path: 
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 D669611E8158 for ; Thu, 30 Jun 2011 00:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdrAOPEggvJA for ; Thu, 30 Jun 2011 00:18:30 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4605A11E816E for ; Thu, 30 Jun 2011 00:18:27 -0700 (PDT)
Received: (qmail 7129 invoked from network); 30 Jun 2011 07:18:24 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2011 07:18:24 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 30 Jun 2011 00:18:24 -0700
From: Eran Hammer-Lahav 
To: OAuth WG 
Date: Thu, 30 Jun 2011 00:18:06 -0700
Thread-Topic: Quick update
Thread-Index: Acw29Y2273n6uvUHQfywysotbP7mkg==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB1734@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_90C41DD21FB7C64BB94121FBBC2E7234475EAB1734P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Quick update
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 07:18:38 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB1734P3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've resurfaced from my project launch and will be giving the spec some att=
ention over the weekend holiday. I've got a long list of changes to make fr=
om the meeting and list. I plan to post a new draft sometimes next week, gi=
ve people a week for quick feedback, and based on the issues raised, ask fo=
r a WGLC.

If you have any feedback for -16 that was not posted on the list, please do=
 so by Friday.

EHL

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB1734P3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I’ve resur=
faced from my project launch and will be giving the spec some attention ove=
r the weekend holiday. I’ve got a long list of changes to make from t=
he meeting and list. I plan to post a new draft sometimes next week, give p=
eople a week for quick feedback, and based on the issues raised, ask for a =
WGLC.
 
If you have any feedback for -16 that was not posted on the list, p=
lease do so by Friday.
 =

EHL
=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB1734P3PW5EX1MB01E_--

From t.lodderstedt@telekom.de  Thu Jun 30 01:10:39 2011
Return-Path: 
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 CB3F421F86E4 for ; Thu, 30 Jun 2011 01:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level: 
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA8xHuFErtUc for ; Thu, 30 Jun 2011 01:10:38 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4819521F86E8 for ; Thu, 30 Jun 2011 01:10:35 -0700 (PDT)
Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail81.telekom.de with ESMTP; 30 Jun 2011 10:09:43 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP; Thu, 30 Jun 2011 10:09:41 +0200
Received: from QEO40072.de.t-online.corp ([169.254.1.170]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Thu, 30 Jun 2011 10:09:40 +0200
From: "Lodderstedt, Torsten" 
To: George Fletcher , "oauth@ietf.org" 
Date: Thu, 30 Jun 2011 10:09:39 +0200
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw1quwPvnuIfv9dS62AjLy0etrL9ABUh+Fw
Message-Id: <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp>
References: <4E09F785.7050007@aol.com>
In-Reply-To: <4E09F785.7050007@aol.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956F9305491QEO40072deton_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 08:10:39 -0000

--_000_63366D5A116E514AA4A9872D3C53353956F9305491QEO40072deton_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

No exactly the topic but also related to this grant type

There is currently no parameter the client could use to explicitly request =
a refresh token. So server-policies based on user, client and scope are the=
 only mean to decide whether a refresh token is issued or not. I consider t=
his  to limited as there might be the desire this control this per authoriz=
ation process, i.e. I client could ask the user whether he/she wants to "st=
ay connected" or "stay logged in". A parameter to pass this information to =
the authz server would be useful.

regards,
Torsten.


Von: George Fletcher [mailto:gffletch@aol.com]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

I'm working on spec'ing out a use of the Resource Owner Password Credential=
s flow and in trying to map out possible error cases, realized that there i=
s no good error for the case that the resource owner's password credentials=
 are invalid. Section 4.3 of draft 16 references section 5.2 for errors. Th=
e list of available errors in section 5.2 are...

   error

         REQUIRED.  A single error code from the following:

         invalid_request

               The request is missing a required parameter, includes an

               unsupported parameter or parameter value, repeats a

               parameter, includes multiple credentials, utilizes more

               than one mechanism for authenticating the client, or is

               otherwise malformed.

         invalid_client

               Client authentication failed (e.g. unknown client, no

               client credentials included, multiple client credentials

               included, or unsupported credentials type).  The

               authorization server MAY return an HTTP 401

               (Unauthorized) status code to indicate which HTTP

               authentication schemes are supported.  If the client

               attempted to authenticate via the "Authorization" request

               header field, the authorization server MUST respond with

               an HTTP 401 (Unauthorized) status code, and include the

               "WWW-Authenticate" response header field matching the

               authentication scheme used by the client.

         invalid_grant

               The provided authorization grant is invalid, expired,

               revoked, does not match the redirection URI used in the

               authorization request, or was issued to another client.

         unauthorized_client

               The authenticated client is not authorized to use this

               authorization grant type.

         unsupported_grant_type

               The authorization grant type is not supported by the

               authorization server.

         invalid_scope

               The requested scope is invalid, unknown, malformed, or

               exceeds the scope granted by the resource owner.


I'm wondering if others have chosen one of these values to represent the "i=
nvalid_credentials" use case.

Thanks,
George

--_000_63366D5A116E514AA4A9872D3C53353956F9305491QEO40072deton_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


No exactly the topic but also related to this grant type
 
There is currently n=
o parameter the client could use to explicitly request a refresh token. So =
server-policies based on user, client and scope are the only mean to decide=
 whether a refresh token is issued or not. I consider this  to limited=
 as there might be the desire this control this per authorization process, =
i.e. I client could ask the user whether he/she wants to “stay connec=
ted” or “stay logged in”. A parameter to pass this inform=
ation to the authz server would be useful.
 
regards,
=
Torsten.
 
 
Von: George Fletcher [mailto:gffletch@aol.com] 
Gesendet:<=
/b> Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betref=
f: [OAUTH-WG] Resource Owner Password Credentials question/feedback
 
I'm working on spec'ing out a use of the Resourc=
e Owner Password Credentials flow and in trying to map out possible error c=
ases, realized that there is no good error for the case that the resource o=
wner's password credentials are invalid. Section 4.3 of draft 16 references=
 section 5.2 for errors. The list of available errors in section 5.2 are...=

   error
 &n=
bsp;       REQUIRED.  A single error cod=
e from the following:
     &n=
bsp;   invalid_request
   &nb=
sp;           The request=
 is missing a required parameter, includes an
 &n=
bsp;            =
; unsupported parameter or parameter value, repeats a
=
            &nb=
sp;  parameter, includes multiple credentials, utilizes more
          &nb=
sp;    than one mechanism for authenticating the client, or =
is
        &nb=
sp;      otherwise malformed.
         invalid_client=

          &nbs=
p;    Client authentication failed (e.g. unknown client, no<=
o:p>
         =
      client credentials included, multiple client=
 credentials
       =
;        included, or unsupported creden=
tials type).  The
     &=
nbsp;         authorization server =
MAY return an HTTP 401
     &=
nbsp;         (Unauthorized) status=
 code to indicate which HTTP
    &=
nbsp;          authentication =
schemes are supported.  If the client
  =
;             a=
ttempted to authenticate via the "Authorization" request
          &n=
bsp;    header field, the authorization server MUST respond =
with
        &=
nbsp;      an HTTP 401 (Unauthorized) status code,=
 and include the
      &=
nbsp;        "WWW-Authenticate"=
; response header field matching the
   =
;            authent=
ication scheme used by the client.
   &=
nbsp;     invalid_grant
 &nbs=
p;             =
The provided authorization grant is invalid, expired,
=
            &nb=
sp;  revoked, does not match the redirection URI used in the
          &nb=
sp;    authorization request, or was issued to another clien=
t.
         un=
authorized_client
      =
         The authenticated client i=
s not authorized to use this
    &=
nbsp;          authorization g=
rant type.
       &=
nbsp; unsupported_grant_type
    &=
nbsp;          The authorizati=
on grant type is not supported by the
  &nbs=
p;            author=
ization server.
      &n=
bsp;  invalid_scope
     =
;          The requested scope=
 is invalid, unknown, malformed, or
   =
            exceeds =
the scope granted by the resource owner.
 
I'm wondering if others have chos=
en one of these values to represent the "invalid_credentials" use=
 case.

Thanks,
George
=

--_000_63366D5A116E514AA4A9872D3C53353956F9305491QEO40072deton_--

From eran@hueniverse.com  Thu Jun 30 01:48:27 2011
Return-Path: 
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 BB52521F872C for ; Thu, 30 Jun 2011 01:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level: 
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpq10WJbePLm for ; Thu, 30 Jun 2011 01:48:25 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D687F21F872B for ; Thu, 30 Jun 2011 01:48:19 -0700 (PDT)
Received: (qmail 13347 invoked from network); 30 Jun 2011 08:48:19 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Jun 2011 08:48:19 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 30 Jun 2011 01:48:18 -0700
From: Eran Hammer-Lahav 
To: "Lodderstedt, Torsten" , George Fletcher , "oauth@ietf.org" 
Date: Thu, 30 Jun 2011 01:47:55 -0700
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw1quwPvnuIfv9dS62AjLy0etrL9ABUh+FwAAFHVuA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB173A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E09F785.7050007@aol.com> <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp>
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_90C41DD21FB7C64BB94121FBBC2E7234475EAB173AP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 08:48:27 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB173AP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Issuing a refresh token is more a function of the access grant duration tha=
n anything else. The client can always throw away tokens when it is done of=
 if the user doesn't want to "stay connected", but issuing long term creden=
tials is not really something the client asks but the server decides (based=
 on user approval and policy).

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

No exactly the topic but also related to this grant type

There is currently no parameter the client could use to explicitly request =
a refresh token. So server-policies based on user, client and scope are the=
 only mean to decide whether a refresh token is issued or not. I consider t=
his  to limited as there might be the desire this control this per authoriz=
ation process, i.e. I client could ask the user whether he/she wants to "st=
ay connected" or "stay logged in". A parameter to pass this information to =
the authz server would be useful.

regards,
Torsten.


Von: George Fletcher [mailto:gffletch@aol.com]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

I'm working on spec'ing out a use of the Resource Owner Password Credential=
s flow and in trying to map out possible error cases, realized that there i=
s no good error for the case that the resource owner's password credentials=
 are invalid. Section 4.3 of draft 16 references section 5.2 for errors. Th=
e list of available errors in section 5.2 are...

   error

         REQUIRED.  A single error code from the following:

         invalid_request

               The request is missing a required parameter, includes an

               unsupported parameter or parameter value, repeats a

               parameter, includes multiple credentials, utilizes more

               than one mechanism for authenticating the client, or is

               otherwise malformed.

         invalid_client

               Client authentication failed (e.g. unknown client, no

               client credentials included, multiple client credentials

               included, or unsupported credentials type).  The

               authorization server MAY return an HTTP 401

               (Unauthorized) status code to indicate which HTTP

               authentication schemes are supported.  If the client

               attempted to authenticate via the "Authorization" request

               header field, the authorization server MUST respond with

               an HTTP 401 (Unauthorized) status code, and include the

               "WWW-Authenticate" response header field matching the

               authentication scheme used by the client.

         invalid_grant

               The provided authorization grant is invalid, expired,

               revoked, does not match the redirection URI used in the

               authorization request, or was issued to another client.

         unauthorized_client

               The authenticated client is not authorized to use this

               authorization grant type.

         unsupported_grant_type

               The authorization grant type is not supported by the

               authorization server.

         invalid_scope

               The requested scope is invalid, unknown, malformed, or

               exceeds the scope granted by the resource owner.


I'm wondering if others have chosen one of these values to represent the "i=
nvalid_credentials" use case.

Thanks,
George

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB173AP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Issuing a refresh token is more a function of the access grant durat=
ion than anything else. The client can always throw away tokens when it is =
done of if the user doesn’t want to “stay connected”, but=
 issuing long term credentials is not really something the client asks but =
the server decides (based on user approval and policy).
 
EHL
 =

Fr=
om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o=
rg] On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June=
 30, 2011 1:10 AM
To: George Fletcher; oauth@ietf.org
Subje=
ct: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedbac=
k
 
No exactly the topic but also related to this=
 grant type
 
There is currently no parameter t=
he client could use to explicitly request a refresh token. So server-polici=
es based on user, client and scope are the only mean to decide whether a re=
fresh token is issued or not. I consider this  to limited as there mig=
ht be the desire this control this per authorization process, i.e. I client=
 could ask the user whether he/she wants to “stay connected” or=
 “stay logged in”. A parameter to pass this information to the =
authz server would be useful.
 
regards,
Torsten.
 
 
Von: George Fletcher [mailto:gf=
fletch@aol.com] 
Gesendet: Dienstag, 28. Juni 2011 17:47
<=
b>An: oauth@ietf.org
Betref=
f: [OAUTH-WG] Resource Owner Password Credentials question/feedback
&nb=
sp;
I'm working on =
spec'ing out a use of the Resource Owner Password Credentials flow and in t=
rying to map out possible error cases, realized that there is no good error=
 for the case that the resource owner's password credentials are invalid. S=
ection 4.3 of draft 16 references section 5.2 for errors. The list of avail=
able errors in section 5.2 are...<=
/p>
   error
         REQUIRED. =
; A single error code from the following:
         invalid_request=

     =
          The request is missi=
ng a required parameter, includes an
           &nb=
sp;   unsupported parameter or parameter value, repeats a
      &n=
bsp;        parameter, includes multiple=
 credentials, utilizes more
&nb=
sp;             =
; than one mechanism for authenticating the client, or is
       &=
nbsp;       otherwise malformed.
       &=
nbsp; invalid_client
 &nbs=
p;             =
Client authentication failed (e.g. unknown client, no
        &nbs=
p;      client credentials included, multiple clie=
nt credentials
  &nbs=
p;            includ=
ed, or unsupported credentials type).  The
         &nbs=
p;     authorization server MAY return an HTTP 401=

      =
;         (Unauthorized) status cod=
e to indicate which HTTP
 =
            &nb=
sp; authentication schemes are supported.  If the client
       &n=
bsp;       attempted to authenticate via the =
"Authorization" request
            =
   header field, the authorization server MUST respond with<=
/o:p>
      =
         an HTTP 401 (Unauthorized)=
 status code, and include the
&=
nbsp;           &nbs=
p;  "WWW-Authenticate" response header field matching the
     &nb=
sp;         authentication scheme u=
sed by the client.
  =
       invalid_grant
<=
pre>         &=
nbsp;     The provided authorization grant is invalid, =
expired,
   &nbs=
p;           revoked, doe=
s not match the redirection URI used in the
          &n=
bsp;    authorization request, or was issued to another clie=
nt.
    &nb=
sp;    unauthorized_client
          &nbs=
p;    The authenticated client is not authorized to use this=

     =
          authorization grant =
type.
    &=
nbsp;    unsupported_grant_type
=
          &nbs=
p;    The authorization grant type is not supported by =
the
    &nb=
sp;          authorization ser=
ver.
    &n=
bsp;    invalid_scope
           &nb=
sp;   The requested scope is invalid, unknown, malformed, or=

      =
;         exceeds the scope granted=
 by the resource owner.
&n=
bsp;
=
I'm wonderin=
g if others have chosen one of these values to represent the "invalid_=
credentials" use case.

Thanks,
George=

=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB173AP3PW5EX1MB01E_--

From t.lodderstedt@telekom.de  Thu Jun 30 06:38:46 2011
Return-Path: 
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 E3A8D11E8148 for ; Thu, 30 Jun 2011 06:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKTv2Y4jpbfz for ; Thu, 30 Jun 2011 06:38:44 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4062F11E8124 for ; Thu, 30 Jun 2011 06:38:43 -0700 (PDT)
Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail51.telekom.de with ESMTP; 30 Jun 2011 15:38:27 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 30 Jun 2011 15:38:27 +0200
Received: from QEO40072.de.t-online.corp ([169.254.1.170]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Thu, 30 Jun 2011 15:38:25 +0200
From: "Lodderstedt, Torsten" 
To: Eran Hammer-Lahav , George Fletcher , "oauth@ietf.org" 
Date: Thu, 30 Jun 2011 15:38:25 +0200
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw1quwPvnuIfv9dS62AjLy0etrL9ABUh+FwAAFHVuAAAG16QA==
Message-Id: <63366D5A116E514AA4A9872D3C53353956F9305578@QEO40072.de.t-online.corp>
References: <4E09F785.7050007@aol.com> <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E7234475EAB173A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475EAB173A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956F9305578QEO40072deton_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 13:38:47 -0000

--_000_63366D5A116E514AA4A9872D3C53353956F9305578QEO40072deton_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>Issuing a refresh token is more a function of the access grant duration th=
an anything else.

Agreed. How shall the user influence this duration? There is no direct inte=
raction between authz server and end-user.

>The client can always throw away tokens when it is done of if the user doe=
sn't want to "stay connected", but issuing long term credentials is not >re=
ally something the client asks but the server decides (based on user approv=
al and policy).

This is a waste of resources. Moreover, how do you explain the end-user if =
a long-term authorization shows up in his service providers account managem=
ent screen for a certain client he never explicitly authorized for long-ter=
m access?

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

Issuing a refresh token is more a function of the access grant duration tha=
n anything else. The client can always throw away tokens when it is done of=
 if the user doesn't want to "stay connected", but issuing long term creden=
tials is not really something the client asks but the server decides (based=
 on user approval and policy).

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
odderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

No exactly the topic but also related to this grant type

There is currently no parameter the client could use to explicitly request =
a refresh token. So server-policies based on user, client and scope are the=
 only mean to decide whether a refresh token is issued or not. I consider t=
his  to limited as there might be the desire this control this per authoriz=
ation process, i.e. I client could ask the user whether he/she wants to "st=
ay connected" or "stay logged in". A parameter to pass this information to =
the authz server would be useful.

regards,
Torsten.


Von: George Fletcher [mailto:gffletch@aol.com]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

I'm working on spec'ing out a use of the Resource Owner Password Credential=
s flow and in trying to map out possible error cases, realized that there i=
s no good error for the case that the resource owner's password credentials=
 are invalid. Section 4.3 of draft 16 references section 5.2 for errors. Th=
e list of available errors in section 5.2 are...

   error

         REQUIRED.  A single error code from the following:

         invalid_request

               The request is missing a required parameter, includes an

               unsupported parameter or parameter value, repeats a

               parameter, includes multiple credentials, utilizes more

               than one mechanism for authenticating the client, or is

               otherwise malformed.

         invalid_client

               Client authentication failed (e.g. unknown client, no

               client credentials included, multiple client credentials

               included, or unsupported credentials type).  The

               authorization server MAY return an HTTP 401

               (Unauthorized) status code to indicate which HTTP

               authentication schemes are supported.  If the client

               attempted to authenticate via the "Authorization" request

               header field, the authorization server MUST respond with

               an HTTP 401 (Unauthorized) status code, and include the

               "WWW-Authenticate" response header field matching the

               authentication scheme used by the client.

         invalid_grant

               The provided authorization grant is invalid, expired,

               revoked, does not match the redirection URI used in the

               authorization request, or was issued to another client.

         unauthorized_client

               The authenticated client is not authorized to use this

               authorization grant type.

         unsupported_grant_type

               The authorization grant type is not supported by the

               authorization server.

         invalid_scope

               The requested scope is invalid, unknown, malformed, or

               exceeds the scope granted by the resource owner.


I'm wondering if others have chosen one of these values to represent the "i=
nvalid_credentials" use case.

Thanks,
George

--_000_63366D5A116E514AA4A9872D3C53353956F9305578QEO40072deton_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


>Issuing a refresh token is more a function of the acce=
ss grant duration than anything else.
 
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'>Agreed. How shall the user influence this duration? Ther=
e is no direct interaction between authz server and end-user. 
 <=
/p>
>The client can always throw=
 away tokens when it is done of if the user doesn’t want to “st=
ay connected”, but issuing long term credentials is not >really so=
mething the client asks but the server decides (based on user approval and =
policy).
 
This is a =
waste of resources. Moreover, how do you explain the end-user if a long-ter=
m authorization shows up in his service providers account management screen=
 for a certain client he never explicitly authorized for long-term access? =

 <=
/o:p>
regards,
<=
p class=3DMsoNormal>Torsten. 
 
Von: Eran Hammer-Lahav [mailto:eran@h=
ueniverse.com] 
Gesendet: Donnerstag, 30. Juni 2011 10:48
A=
n: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff:=
 RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback
 
<=
p class=3DMsoNormal>Issuing a refresh token is more a f=
unction of the access grant duration than anything else. The client can alw=
ays throw away tokens when it is done of if the user doesn’t want to =
“stay connected”, but issuing long term credentials is not real=
ly something the client asks but the server decides (based on user approval=
 and policy).
 
EHL<=
o:p>
 
From: oauth-bounces@ietf.org [mailt=
o:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Torsten
Se=
nt: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; oaut=
h@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password Creden=
tials question/feedback
 
No exactly the topic but also related to this grant type
 
There is currently no=
 parameter the client could use to explicitly request a refresh token. So s=
erver-policies based on user, client and scope are the only mean to decide =
whether a refresh token is issued or not. I consider this  to limited =
as there might be the desire this control this per authorization process, i=
.e. I client could ask the user whether he/she wants to “stay connect=
ed” or “stay logged in”. A parameter to pass this informa=
tion to the authz server would be useful.
 
regards,
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'>Torsten.
 
 =

Von: George Fletcher [mailto:gffletch@aol.com] 
Gesendet: Dienstag, 28. Juni 2011=
 17:47
An: oauth@ietf.orgBetreff: [OAUTH-WG] Resource Owner Password Credentials question/f=
eedback
 
I'm working on spec'ing out a use of =
the Resource Owner Password Credentials flow and in trying to map out possi=
ble error cases, realized that there is no good error for the case that the=
 resource owner's password credentials are invalid. Section 4.3 of draft 16=
 references section 5.2 for errors. The list of available errors in section=
 5.2 are...
   error
   &nbs=
p;     REQUIRED.  A single error code from the fol=
lowing:
         invali=
d_request
         =
;      The request is missing a required parameter=
, includes an
        &=
nbsp;      unsupported parameter or parameter valu=
e, repeats a
        &n=
bsp;      parameter, includes multiple credentials=
, utilizes more
        =
;       than one mechanism for authenticating=
 the client, or is
       &n=
bsp;       otherwise malformed.
&=
nbsp;        invalid_client
=
            &nb=
sp;  Client authentication failed (e.g. unknown client, no<=
/span>
            &n=
bsp;  client credentials included, multiple client credentials
           &nbs=
p;   included, or unsupported credentials type).  The
           &nb=
sp;   authorization server MAY return an HTTP 401
&nb=
sp;            =
  (Unauthorized) status code to indicate which HTTP<=
/pre>
 =
            &nb=
sp; authentication schemes are supported.  If the client
&=
nbsp;           &nbs=
p;  attempted to authenticate via the "Authorization" reques=
t
          &=
nbsp;    header field, the authorization server MUST respond=
 with
         &nb=
sp;     an HTTP 401 (Unauthorized) status code, and inc=
lude the
         =
      "WWW-Authenticate" response header=
 field matching the
       &=
nbsp;       authentication scheme used by the=
 client.
         inval=
id_grant
         =
      The provided authorization grant is invalid,=
 expired,
         =
;      revoked, does not match the redirection URI=
 used in the
        &n=
bsp;      authorization request, or was issued to =
another client.
        =
; unauthorized_client
       =
;        The authenticated client is not=
 authorized to use this
      &nb=
sp;        authorization grant type.
         unsupported_grant=
_type
          &n=
bsp;    The authorization grant type is not supported b=
y the
         &nb=
sp;     authorization server.
  &=
nbsp;      invalid_scope
  &=
nbsp;            The=
 requested scope is invalid, unknown, malformed, or=

  =
;             e=
xceeds the scope granted by the resource owner.
 
I'm wondering if others have c=
hosen one of these values to represent the "invalid_credentials" =
use case.

Thanks,
George
<=
/div>=

--_000_63366D5A116E514AA4A9872D3C53353956F9305578QEO40072deton_--

From eran@hueniverse.com  Thu Jun 30 09:40:06 2011
Return-Path: 
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 2564011E8247 for ; Thu, 30 Jun 2011 09:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7-91iJP+6Ve for ; Thu, 30 Jun 2011 09:40:03 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4305711E8085 for ; Thu, 30 Jun 2011 09:40:03 -0700 (PDT)
Received: (qmail 1071 invoked from network); 30 Jun 2011 16:40:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2011 16:40:02 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 30 Jun 2011 09:39:53 -0700
From: Eran Hammer-Lahav 
To: "Lodderstedt, Torsten" , George Fletcher , "oauth@ietf.org" 
Date: Thu, 30 Jun 2011 09:39:30 -0700
Thread-Topic: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Thread-Index: Acw1quwPvnuIfv9dS62AjLy0etrL9ABUh+FwAAFHVuAAAG16QAAQAjhA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475EAB17DF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E09F785.7050007@aol.com> <63366D5A116E514AA4A9872D3C53353956F9305491@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E7234475EAB173A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956F9305578@QEO40072.de.t-online.corp>
In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F9305578@QEO40072.de.t-online.corp>
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_90C41DD21FB7C64BB94121FBBC2E7234475EAB17DFP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 16:40:06 -0000

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB17DFP3PW5EX1MB01E_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This debate has been going on for 3 years. In OAuth 1.0 it was called token=
 attributes. Someone just need to write a proposal. Last time I tried, no o=
ne wanted to implement any such mechanism.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thursday, June 30, 2011 6:38 AM
To: Eran Hammer-Lahav; George Fletcher; oauth@ietf.org
Subject: AW: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

>Issuing a refresh token is more a function of the access grant duration th=
an anything else.

Agreed. How shall the user influence this duration? There is no direct inte=
raction between authz server and end-user.

>The client can always throw away tokens when it is done of if the user doe=
sn't want to "stay connected", but issuing long term credentials is not >re=
ally something the client asks but the server decides (based on user approv=
al and policy).

This is a waste of resources. Moreover, how do you explain the end-user if =
a long-term authorization shows up in his service providers account managem=
ent screen for a certain client he never explicitly authorized for long-ter=
m access?

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

Issuing a refresh token is more a function of the access grant duration tha=
n anything else. The client can always throw away tokens when it is done of=
 if the user doesn't want to "stay connected", but issuing long term creden=
tials is not really something the client asks but the server decides (based=
 on user approval and policy).

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Lodde=
rstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedba=
ck

No exactly the topic but also related to this grant type

There is currently no parameter the client could use to explicitly request =
a refresh token. So server-policies based on user, client and scope are the=
 only mean to decide whether a refresh token is issued or not. I consider t=
his  to limited as there might be the desire this control this per authoriz=
ation process, i.e. I client could ask the user whether he/she wants to "st=
ay connected" or "stay logged in". A parameter to pass this information to =
the authz server would be useful.

regards,
Torsten.


Von: George Fletcher [mailto:gffletch@aol.com]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

I'm working on spec'ing out a use of the Resource Owner Password Credential=
s flow and in trying to map out possible error cases, realized that there i=
s no good error for the case that the resource owner's password credentials=
 are invalid. Section 4.3 of draft 16 references section 5.2 for errors. Th=
e list of available errors in section 5.2 are...

   error

         REQUIRED.  A single error code from the following:

         invalid_request

               The request is missing a required parameter, includes an

               unsupported parameter or parameter value, repeats a

               parameter, includes multiple credentials, utilizes more

               than one mechanism for authenticating the client, or is

               otherwise malformed.

         invalid_client

               Client authentication failed (e.g. unknown client, no

               client credentials included, multiple client credentials

               included, or unsupported credentials type).  The

               authorization server MAY return an HTTP 401

               (Unauthorized) status code to indicate which HTTP

               authentication schemes are supported.  If the client

               attempted to authenticate via the "Authorization" request

               header field, the authorization server MUST respond with

               an HTTP 401 (Unauthorized) status code, and include the

               "WWW-Authenticate" response header field matching the

               authentication scheme used by the client.

         invalid_grant

               The provided authorization grant is invalid, expired,

               revoked, does not match the redirection URI used in the

               authorization request, or was issued to another client.

         unauthorized_client

               The authenticated client is not authorized to use this

               authorization grant type.

         unsupported_grant_type

               The authorization grant type is not supported by the

               authorization server.

         invalid_scope

               The requested scope is invalid, unknown, malformed, or

               exceeds the scope granted by the resource owner.


I'm wondering if others have chosen one of these values to represent the "i=
nvalid_credentials" use case.

Thanks,
George

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB17DFP3PW5EX1MB01E_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
This debate has been going on for 3 years. In OAuth 1.0 it was calle=
d token attributes. Someone just need to write a proposal. Last time I trie=
d, no one wanted to implement any such mechanism.
 
EHL
 =

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] 
=
Sent: Thursday, June 30, 2011 6:38 AM
To: Eran Hammer-Laha=
v; George Fletcher; oauth@ietf.org
Subject: AW: [OAUTH-WG] Resour=
ce Owner Password Credentials question/feedback
=

 
>Issuing a refresh token is more a function of the access grant duratio=
n than anything else.
 
Agreed. How shall the u=
ser influence this duration? There is no direct interaction between authz s=
erver and end-user. 
 
>The client can alwa=
ys throw away tokens when it is done of if the user doesn’t want to &=
#8220;stay connected”, but issuing long term credentials is not >r=
eally something the client asks but the server decides (based on user appro=
val and policy).
&nbs=
p;
This is a waste of resources=
. Moreover, how do you explain the end-user if a long-term authorization sh=
ows up in his service providers account management screen for a certain cli=
ent he never explicitly authorized for long-term access? =

 
regards,
<=
span lang=3DDE style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"=
;color:#1F497D'>Torsten. 
 
Von: Eran Hammer-L=
ahav [mailto:eran@huenivers=
e.com] 
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff: RE: [OAUTH-WG] Resource Owner Passwo=
rd Credentials question/feedback
 
Issuing a refresh token is more a function of the access grant du=
ration than anything else. The client can always throw away tokens when it =
is done of if the user doesn’t want to “stay connected”, =
but issuing long term credentials is not really something the client asks b=
ut the server decides (based on user approval and policy).
 
EHL
&nb=
sp;
F=
rom: oauth-bo=
unces@ietf.org [mail=
to:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Torsten
=
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher;=
 oauth@ietf.org
Subject: Re=
: [OAUTH-WG] Resource Owner Password Credentials question/feedback
 
No exactly the topic but also related to this grant typ=
e
 =

There is currently no parameter the client =
could use to explicitly request a refresh token. So server-policies based o=
n user, client and scope are the only mean to decide whether a refresh toke=
n is issued or not. I consider this  to limited as there might be the =
desire this control this per authorization process, i.e. I client could ask=
 the user whether he/she wants to “stay connected” or “st=
ay logged in”. A parameter to pass this information to the authz serv=
er would be useful.
 
regards,
Torsten.
 
 
Von: G=
eorge Fletcher [mailto:gffletc=
h@aol.com] 
Gesendet: Dienstag, 28. Juni 2011 17:47
An:=
 oauth@ietf.org
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback
 
I'm working on spec'=
ing out a use of the Resource Owner Password Credentials flow and in trying=
 to map out possible error cases, realized that there is no good error for =
the case that the resource owner's password credentials are invalid. Sectio=
n 4.3 of draft 16 references section 5.2 for errors. The list of available =
errors in section 5.2 are...
&nb=
sp;  error
      &=
nbsp;  REQUIRED.  A single error code from the following:
         invalid_req=
uest
        =
       The request is missing a required para=
meter, includes an
     &nbs=
p;         unsupported parameter or=
 parameter value, repeats a
    &=
nbsp;          parameter, incl=
udes multiple credentials, utilizes more
  =
             th=
an one mechanism for authenticating the client, or is
            &n=
bsp;  otherwise malformed.
   &nb=
sp;     invalid_client
 &nbs=
p;             =
Client authentication failed (e.g. unknown client, no
            &n=
bsp;  client credentials included, multiple client credentials
          =
     included, or unsupported credentials type).  =
The
        &=
nbsp;      authorization server MAY return an HTTP=
 401
        =
       (Unauthorized) status code to indicate=
 which HTTP
       =
;        authentication schemes are supp=
orted.  If the client
    &n=
bsp;          attempted to aut=
henticate via the "Authorization" request
=

&=
nbsp;           &nbs=
p;  header field, the authorization server MUST respond with
          &n=
bsp;    an HTTP 401 (Unauthorized) status code, and include =
the
        &=
nbsp;      "WWW-Authenticate" response h=
eader field matching the
    &nb=
sp;          authentication sc=
heme used by the client.
    &nb=
sp;    invalid_grant
  &nbs=
p;            The pr=
ovided authorization grant is invalid, expired,
 =
;            &n=
bsp; revoked, does not match the redirection URI used in the
           &=
nbsp;   authorization request, or was issued to another client.
         unaut=
horized_client
      &n=
bsp;        The authenticated client is =
not authorized to use this
    &n=
bsp;          authorization gr=
ant type.
       &=
nbsp; unsupported_grant_type
    =
           The authorizat=
ion grant type is not supported by the
  &n=
bsp;            auth=
orization server.
      =
;   invalid_scope
    &=
nbsp;          The requested s=
cope is invalid, unknown, malformed, or
  &=
nbsp;            exc=
eeds the scope granted by the resource owner.
<=
span lang=3DDE style=3D'font-size:10.0pt;font-family:"Courier New"'>&n=
bsp;
=
I'm wonderin=
g if others have chosen one of these values to represent the "invalid_=
credentials" use case.

Thanks,
George=

=

--_000_90C41DD21FB7C64BB94121FBBC2E7234475EAB17DFP3PW5EX1MB01E_--

From d.tangren@gmail.com  Thu Jun 30 12:45:49 2011
Return-Path: 
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 9DAC911E80CF for ; Thu, 30 Jun 2011 12:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYvsJgCGdZXN for ; Thu, 30 Jun 2011 12:45:49 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B81FA11E80C5 for ; Thu, 30 Jun 2011 12:45:43 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2827864iwn.31 for ; Thu, 30 Jun 2011 12:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=TZwOxvUO0lMzhQ//D2YPbxLcyPk7BVLzoc1Kj3h/lyA=; b=GUfylt+HiYVo7p0o23QZka+iBBC6Amcsc8zXnP0YfQvqF/p3SoqTk69+Svf6VYqU8k FdNuJW+2gLejWEclkIQUSLsJQoZoGKvqrZ3tBZhJwtE6gYfsHTk4voQXNBve4P1fQXC8 TOuYNlIOeF61nzIJW1mq/TYoO/U/R6GNHBvYg=
Received: by 10.43.130.134 with SMTP id hm6mr2527511icc.517.1309463143063; Thu, 30 Jun 2011 12:45:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.190.209 with HTTP; Thu, 30 Jun 2011 12:45:23 -0700 (PDT)
From: Doug Tangren 
Date: Thu, 30 Jun 2011 15:45:23 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=20cf307d01d07d1f1504a6f32553
Subject: [OAUTH-WG] best practices for storing access token for implicit clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 19:45:49 -0000

--20cf307d01d07d1f1504a6f32553
Content-Type: text/plain; charset=UTF-8

What is the current recommended practice of storing an implicit client's
access_tokens? LocalStorage, im mem and re-request auth on every browser
refresh?

-Doug Tangren
http://lessis.me

--20cf307d01d07d1f1504a6f32553
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What is the current recommended practice of storing an implicit client'=
s access_tokens? LocalStorage, im mem and re-request auth on every browser =
refresh?

-Doug Tangren
http://lessis.me




--20cf307d01d07d1f1504a6f32553--

From barryleiba.mailing.lists@gmail.com  Thu Jun 30 13:39:11 2011
Return-Path: 
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 468C911E80DE for ; Thu, 30 Jun 2011 13:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.227
X-Spam-Level: 
X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTAQiE5qDvby for ; Thu, 30 Jun 2011 13:39:10 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36B11E80A7 for ; Thu, 30 Jun 2011 13:39:10 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1332411ywp.31 for ; Thu, 30 Jun 2011 13:39:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ln/XAj7oU7YkY9C4Sc6ILilfpiupt+8sAU8h8TQjtx4=; b=twXtyKvtDzSjSA1sMK/DpJeTg3XlzEboBQ3vbDjAHaPMZxXweL9wtPQXFzZc+4ANPk Ttj02VJPYwmMzEyLeJmjE3ea3JBR5o65YRHFW2o85BSaHSCSkNuYTf47NG9YCKW0bUBE /GDiAf0XlBmcRHBL1q+kHccPKZrHqTMQtAwc4=
MIME-Version: 1.0
Received: by 10.151.24.10 with SMTP id b10mr2325903ybj.93.1309466350037; Thu, 30 Jun 2011 13:39:10 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.125.20 with HTTP; Thu, 30 Jun 2011 13:39:10 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 30 Jun 2011 16:39:10 -0400
X-Google-Sender-Auth: kPS-AAzBOjgE7LFszbJbUQuvp1Y
Message-ID: 
From: Barry Leiba 
To: OAuth WG 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 20:39:11 -0000

Chuck Mortimore wrote:
> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as we=
ll
> as authorization grants.  We=92ve reached general consensus on a doc
> that I=92ve published as a draft

This document is intended to replace the SAML and Bearer Token
documents, and those two will then be "profiles", defining specific
assertion mechanisms.  We would like to have them submit the
restructured doc as a working-group document before the 4 July
deadline, so we'd like to get any objections to this approach heard by
3 July.  I'm sorry for the very short notice, and you can blame that
solely on the chairs.  Chuck posted the draft about two weeks ago.

See http://tools.ietf.org/html/draft-mortimore-oauth-assertions

The editors can answer any questions you have about how the document
restructuring is being done.  We will approve
draft-ietf-oauth-assertions for submission as a working-group draft,
pending consideration of objections.  Again, please have a quick look
(it's short), and post objections by 3 July.  Thanks.

Barry, as chair

From bcampbell@pingidentity.com  Thu Jun 30 14:11:51 2011
Return-Path: 
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 77DAE11E80AA for ; Thu, 30 Jun 2011 14:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.827
X-Spam-Level: 
X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqD-wyBgcLPM for ; Thu, 30 Jun 2011 14:11:50 -0700 (PDT)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6396911E8080 for ; Thu, 30 Jun 2011 14:11:41 -0700 (PDT)
Received: from mail-qy0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTgzmjS+nNn9Ezbn4jJueiouT5VKd88HM@postini.com; Thu, 30 Jun 2011 14:11:42 PDT
Received: by mail-qy0-f174.google.com with SMTP id 29so315571qyk.12 for ; Thu, 30 Jun 2011 14:11:41 -0700 (PDT)
Received: by 10.224.76.5 with SMTP id a5mr1858301qak.337.1309468300074; Thu, 30 Jun 2011 14:11:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.45.68 with HTTP; Thu, 30 Jun 2011 14:11:10 -0700 (PDT)
In-Reply-To: 
References:    
From: Brian Campbell 
Date: Thu, 30 Jun 2011 15:11:10 -0600
Message-ID: 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 21:11:51 -0000

On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba  wrot=
e:
>
> This document is intended to replace the SAML and Bearer Token
> documents, and those two will then be "profiles", defining specific
> assertion mechanisms.

Just a couple points of clarification

This doc is not related to the Bearer Token document
(draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this
series of docs is about assertions for grants (and now client
authentication).

This doc doesn't replace anything so much as it pulls common elements
out of the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT
assertion (draft-jones-oauth-jwt-bearer) documents.  Those docs (and
possibly others) then become profiles of this doc and get to reuse the
common pieces it provides.

This doc also reintroduces the abstract concept of client assertions
for client authentication using http parameters (client_assertion_type
and client_assertion).  Presumably the SAML and JWT assertion docs
will also be reworked to account for that.

> =A0We would like to have them submit the
> restructured doc as a working-group document before the 4 July
> deadline, so we'd like to get any objections to this approach heard by
> 3 July.

Barry, which docs to you need submitted by the 4th?  Just
draft-ietf-oauth-assertions?  Or draft-ietf-oauth-saml2-bearer and
draft-jones-oauth-jwt-bearer as well?

> I'm sorry for the very short notice, and you can blame that
> solely on the chairs. =A0Chuck posted the draft about two weeks ago.
>
> See http://tools.ietf.org/html/draft-mortimore-oauth-assertions
>
> The editors can answer any questions you have about how the document
> restructuring is being done. =A0We will approve
> draft-ietf-oauth-assertions for submission as a working-group draft,
> pending consideration of objections. =A0Again, please have a quick look
> (it's short), and post objections by 3 July. =A0Thanks.
>
> Barry, as chair
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From Michael.Jones@microsoft.com  Thu Jun 30 14:31:33 2011
Return-Path: 
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 BC4E911E82EA for ; Thu, 30 Jun 2011 14:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+nm5mHLZ5+s for ; Thu, 30 Jun 2011 14:31:33 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58611E82E2 for ; Thu, 30 Jun 2011 14:31:31 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 30 Jun 2011 14:31:27 -0700
Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0289.008; Thu, 30 Jun 2011 14:31:26 -0700
From: Mike Jones 
To: Brian Campbell , Barry Leiba 
Thread-Topic: [OAUTH-WG] New Assertion Draft for review
Thread-Index: Acwt79ke4rdzoBgkFEiWFCePFvviCgBhrCTwAAIC/kAB2TmLgAAvPQoAAAEeGgAADgyBoA==
Date: Thu, 30 Jun 2011 21:31:26 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394348D36AEE@TK5EX14MBXC201.redmond.corp.microsoft.com>
References:     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 21:31:33 -0000

+1 on submitting this as a WG doc by the deadline on July 4th.

As background, http://www.ietf.org/meeting/cutoff-dates-2011.html:
.	2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) su=
bmission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.
.	2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT =
(00:00 UTC), upload using IETF ID Submission Tool

So because the assertions draft will be a -00 draft, it must be submitted b=
y the 4th.  A new version of the SAML doc could still be submitted until th=
e 11th, since it's not a -00 doc.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B=
rian Campbell
Sent: Thursday, June 30, 2011 2:11 PM
To: Barry Leiba
Cc: OAuth WG
Subject: Re: [OAUTH-WG] New Assertion Draft for review

On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba  wrot=
e:
>
> This document is intended to replace the SAML and Bearer Token=20
> documents, and those two will then be "profiles", defining specific=20
> assertion mechanisms.

Just a couple points of clarification

This doc is not related to the Bearer Token document
(draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this seri=
es of docs is about assertions for grants (and now client authentication).

This doc doesn't replace anything so much as it pulls common elements out o=
f the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT assertion (dra=
ft-jones-oauth-jwt-bearer) documents.  Those docs (and possibly others) the=
n become profiles of this doc and get to reuse the common pieces it provide=
s.

This doc also reintroduces the abstract concept of client assertions for cl=
ient authentication using http parameters (client_assertion_type and client=
_assertion).  Presumably the SAML and JWT assertion docs will also be rewor=
ked to account for that.

> =A0We would like to have them submit the restructured doc as a=20
> working-group document before the 4 July deadline, so we'd like to get=20
> any objections to this approach heard by
> 3 July.

Barry, which docs to you need submitted by the 4th?  Just draft-ietf-oauth-=
assertions?  Or draft-ietf-oauth-saml2-bearer and draft-jones-oauth-jwt-bea=
rer as well?

> I'm sorry for the very short notice, and you can blame that solely on=20
> the chairs. =A0Chuck posted the draft about two weeks ago.
>
> See http://tools.ietf.org/html/draft-mortimore-oauth-assertions
>
> The editors can answer any questions you have about how the document=20
> restructuring is being done. =A0We will approve=20
> draft-ietf-oauth-assertions for submission as a working-group draft,=20
> pending consideration of objections. =A0Again, please have a quick look=20
> (it's short), and post objections by 3 July. =A0Thanks.
>
> 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


From bcampbell@pingidentity.com  Thu Jun 30 14:40:33 2011
Return-Path: 
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 65F6821F875B for ; Thu, 30 Jun 2011 14:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.877
X-Spam-Level: 
X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYog73kov7oq for ; Thu, 30 Jun 2011 14:40:32 -0700 (PDT)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id E886B11E830D for ; Thu, 30 Jun 2011 14:40:30 -0700 (PDT)
Received: from mail-qy0-f175.google.com ([209.85.216.175]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTgztTtS8qdssBc+XgMF1qggOOQ477Uxx@postini.com; Thu, 30 Jun 2011 14:40:31 PDT
Received: by mail-qy0-f175.google.com with SMTP id 30so357522qyk.6 for ; Thu, 30 Jun 2011 14:40:30 -0700 (PDT)
Received: by 10.224.194.133 with SMTP id dy5mr1918586qab.237.1309470030111; Thu, 30 Jun 2011 14:40:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.45.68 with HTTP; Thu, 30 Jun 2011 14:40:00 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394348D36AEE@TK5EX14MBXC201.redmond.corp.microsoft.com>
References:      <4E1F6AAD24975D4BA5B168042967394348D36AEE@TK5EX14MBXC201.redmond.corp.microsoft.com>
From: Brian Campbell 
Date: Thu, 30 Jun 2011 15:40:00 -0600
Message-ID: 
To: Mike Jones 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Barry Leiba , OAuth WG 
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 21:40:33 -0000

+1 from me as well on submitting this as a WG doc.  And thanks, Mike,
for clarifying the dates.

On Thu, Jun 30, 2011 at 3:31 PM, Mike Jones  w=
rote:
> +1 on submitting this as a WG doc by the deadline on July 4th.
>
> As background, http://www.ietf.org/meeting/cutoff-dates-2011.html:
> . =A0 =A0 =A0 2011-07-04 (Monday): Internet Draft Cut-off for initial doc=
ument (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submis=
sion Tool.
> . =A0 =A0 =A0 2011-07-11 (Monday): Internet Draft final submission cut-of=
f by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool
>
> So because the assertions draft will be a -00 draft, it must be submitted=
 by the 4th. =A0A new version of the SAML doc could still be submitted unti=
l the 11th, since it's not a -00 doc.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Brian Campbell
> Sent: Thursday, June 30, 2011 2:11 PM
> To: Barry Leiba
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] New Assertion Draft for review
>
> On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba  wr=
ote:
>>
>> This document is intended to replace the SAML and Bearer Token
>> documents, and those two will then be "profiles", defining specific
>> assertion mechanisms.
>
> Just a couple points of clarification
>
> This doc is not related to the Bearer Token document
> (draft-ietf-oauth-v2-bearer-04) - that is about access tokens and this se=
ries of docs is about assertions for grants (and now client authentication)=
.
>
> This doc doesn't replace anything so much as it pulls common elements out=
 of the SAML assertion (draft-ietf-oauth-saml2-bearer) and JWT assertion (d=
raft-jones-oauth-jwt-bearer) documents. =A0Those docs (and possibly others)=
 then become profiles of this doc and get to reuse the common pieces it pro=
vides.
>
> This doc also reintroduces the abstract concept of client assertions for =
client authentication using http parameters (client_assertion_type and clie=
nt_assertion). =A0Presumably the SAML and JWT assertion docs will also be r=
eworked to account for that.
>
>> =A0We would like to have them submit the restructured doc as a
>> working-group document before the 4 July deadline, so we'd like to get
>> any objections to this approach heard by
>> 3 July.
>
> Barry, which docs to you need submitted by the 4th? =A0Just draft-ietf-oa=
uth-assertions? =A0Or draft-ietf-oauth-saml2-bearer and draft-jones-oauth-j=
wt-bearer as well?
>
>> I'm sorry for the very short notice, and you can blame that solely on
>> the chairs. =A0Chuck posted the draft about two weeks ago.
>>
>> See http://tools.ietf.org/html/draft-mortimore-oauth-assertions
>>
>> The editors can answer any questions you have about how the document
>> restructuring is being done. =A0We will approve
>> draft-ietf-oauth-assertions for submission as a working-group draft,
>> pending consideration of objections. =A0Again, please have a quick look
>> (it's short), and post objections by 3 July. =A0Thanks.
>>
>> 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
>
>

From barryleiba@gmail.com  Thu Jun 30 15:34:03 2011
Return-Path: 
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 6555211E822B for ; Thu, 30 Jun 2011 15:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.177
X-Spam-Level: 
X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVVQJM9kVRj5 for ; Thu, 30 Jun 2011 15:34:03 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 007EA11E807E for ; Thu, 30 Jun 2011 15:34:02 -0700 (PDT)
Received: by gyd5 with SMTP id 5so998481gyd.31 for ; Thu, 30 Jun 2011 15:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P5dG1f3zmkR5Elc9mHF7fZBJ+Z5HEnx2GRyd86es3ig=; b=IoNlr7L22PURTd1Gsi3sFT7+oGeGgRH/X6uP3wJb5/8vpPBkFwPmGF1ZvkRzrOKt1V 8ItFzPtZXiH0p8sMDg4hKsjWyd4NRLRKdr9vYYSHBoJwO+/0+wLLhNcj3nsKfBcRmEGL V1PGGfU5BZFk+Ulx4vXdSwB4A7SlAuGWmsgXQ=
MIME-Version: 1.0
Received: by 10.236.113.164 with SMTP id a24mr2363115yhh.130.1309473242301; Thu, 30 Jun 2011 15:34:02 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.236.107.166 with HTTP; Thu, 30 Jun 2011 15:34:02 -0700 (PDT)
In-Reply-To: 
References:     
Date: Thu, 30 Jun 2011 18:34:02 -0400
X-Google-Sender-Auth: xi1a1ImLDpOJwRMNgd149BA4Nrw
Message-ID: 
From: Barry Leiba 
To: Brian Campbell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] New Assertion Draft for review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 22:34:03 -0000

> Just a couple points of clarification

Yes, thanks, Brian, for correcting the stuff I mischaracterized, in
writing my note too quickly.

Barry

From d.tangren@gmail.com  Thu Jun 30 18:54:32 2011
Return-Path: 
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 0444411E825D for ; Thu, 30 Jun 2011 18:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pXX7-kfH1gO for ; Thu, 30 Jun 2011 18:54:31 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF4F11E8245 for ; Thu, 30 Jun 2011 18:54:31 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3069351iwn.31 for ; Thu, 30 Jun 2011 18:54:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=G1gAEpT46AVeypzo8KJFQ06ogqRVOC7USqwEWNpomlk=; b=FFdgGxnvh4kiC8cBQ7Q4+YQS18ITmPjkaxVFk4BI1dIkCdzHoVQ+alcyFFQby3nsPu r3TleU8fr4IH2ucEMO3JhjEGrSswILWr3R8L4DNsxD7o0+bDd3uqKOl3cvA11j9iYG4C NmP5lVFVQt2covEDTWWusbG9EpUZwaXKei9tY=
Received: by 10.231.44.65 with SMTP id z1mr2288608ibe.95.1309485271111; Thu, 30 Jun 2011 18:54:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.190.209 with HTTP; Thu, 30 Jun 2011 18:54:11 -0700 (PDT)
From: Doug Tangren 
Date: Thu, 30 Jun 2011 21:54:11 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=0015176f0ae46c584904a6f84cef
Subject: [OAUTH-WG] best practices for storing access token for implicit clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2011 01:54:32 -0000

--0015176f0ae46c584904a6f84cef
Content-Type: text/plain; charset=UTF-8

What is the current recommended practice of storing an implicit client's
access_tokens? LocalStorage, im mem and re-request auth on every browser
refresh?

-Doug Tangren
http://lessis.me

--0015176f0ae46c584904a6f84cef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What is the current=
 recommended practice of storing an implicit client's access_tokens? Lo=
calStorage, im mem and re-request auth on every browser refresh?


-Doug Tangren
h=
ttp://lessis.me




--0015176f0ae46c584904a6f84cef--