From hardjono@mit.edu Mon May 2 10:04: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 52DB6E071E for ; Mon, 2 May 2011 10:04: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=[AWL=-1.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 gIu+H6I9EXd9 for ; Mon, 2 May 2011 10:04:37 -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 A9DD6E0659 for ; Mon, 2 May 2011 10:04:37 -0700 (PDT) X-AuditID: 12074425-b7c8cae00000429f-76-4dbee43c6ba0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FB.B1.17055.C34EEBD4; Mon, 2 May 2011 13:05:00 -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 p42H4ZTk026844 for ; Mon, 2 May 2011 13:04:35 -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 p42H4XVD004833 for ; Mon, 2 May 2011 13:04:35 -0400 Received: from w92exhub8.exchange.mit.edu (18.7.73.14) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 2 May 2011 13:03:13 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub8.exchange.mit.edu ([18.7.73.14]) with mapi; Mon, 2 May 2011 13:04:33 -0400 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" Date: Mon, 2 May 2011 13:04:31 -0400 Thread-Topic: I-D Action:draft-oauth-dyn-reg-v1-02.txt Thread-Index: AQD42VEWs34D4+z9B0tpDAs9zVMEAZYgIoMg Message-ID: References: <20110502160002.29594.25481.idtracker@ietfa.amsl.com> In-Reply-To: <20110502160002.29594.25481.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_DADD7EAD88AB484D8CCC328D40214CCD07F84886D9EXPO10exchang_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Ta0hTYRjHec+2s+PyxNlpc4+zPri0wpqmafjBRKsPSQildMHAOrqTG21T dqapH8RuaFqaNyilvGRBdtGyxBIlZmUqmVIZSkjqgrxGGqQo0jmeLf32e97///k/7wPvS0jo NlxLmKx21mZlzDpcIaU91Fv1Ec6O2N0ts2Hh3TOTeBQ6VF+/iB1BCYoIA2s2ZbC2oMgzCuPi zTlZ2n115vj4GMpFLXQB8iCACoULvY2YyF7QP9KIFyAFQVMdCF43rMjE4jOCqrIfSCx+Irj+ th8Ti+cImuueuIpiBIOLtRIhDKd2QN9Su1xgFaWHh3PXV1lCbYPm4XyZwFLKDwrna/hYgthE hcHHgXjRvheuOYeRyCFwr/qzVGCSOgLzgy9Wz2kqGi7OL6/e24PaD8UVS7jAiN/hb88jTByl gWFntWs3FYwO9OLuPVdejbr8aviW17h6BQllgtzfJ8RRSui+5ZTeQFC5LqlyzVW5ziVadkFN 2xwu8k64XzslETkGriy8cXlCYObDbZenFcG76TCRfaG8cFQuciS8cjzG3P6Gtho+R8HzSwTV 30tk6xtqENmAthgs2XoLYzJzbLKeS2asVtamDw+0mOyBrCH9GRLeiPygfyu64dA5EEUgnScp 7+qIpWVMBpdlcSBvAtOpyaBx/mhjUqohy8hwxtO2dDPLORAQEp2KzEniNdLAZGWztlS35ENI dRqy2nt7LE2lMHb2HMumsTa3upkgdEDOjfGNShubwmaeNZntazJGeAjhnny4nzCY5NIYC2dK EfUe5KvVkCpBoATBmG793+t+85NIw6+yiZwQRnjyP+J/9yQfjPHBTZJ2IdjOrEnaXJS3oAxB CXHn4/NHNMf7gkrp8sfnHvwZ+pJ4zNQ8szwdnXb4KFnk9Z7aWBqXozypLnh6tyy/virU/9TV RPxr3YRcmbnHa2g2u+/SSlPU5Tv7hnya1VhReGGXNmCqqqVzy6VeuiS1NTNQllwxFPFJM8Ks bOj8lVce7KzMiGk/cGhfu07KGZngAImNY/4BETU7+s4DAAA= Subject: [OAUTH-WG] FW: I-D Action:draft-oauth-dyn-reg-v1-02.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: Mon, 02 May 2011 17:04:38 -0000 --_003_DADD7EAD88AB484D8CCC328D40214CCD07F84886D9EXPO10exchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Folks, This is an update of the Dynamic Client Registration Protocol draft. The pr= evious version (draft-01) expired in Feb. Thanks. /thomas/ ________________________________ -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Monday, May 02, 2011 12:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-oauth-dyn-reg-v1-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : OAuth Dynamic Client Registration Protocol Author(s) : T. Hardjono, et al. Filename : draft-oauth-dyn-reg-v1-02.txt Pages : 20 Date : 2011-05-02 This specification proposes an OAuth Dynamic Client Registration protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oauth-dyn-reg-v1-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_003_DADD7EAD88AB484D8CCC328D40214CCD07F84886D9EXPO10exchang_ Content-Type: message/external-body; name="draft-oauth-dyn-reg-v1-02.txt" Content-Description: draft-oauth-dyn-reg-v1-02.txt Content-Disposition: attachment; filename="draft-oauth-dyn-reg-v1-02.txt"; size=73; creation-date="Mon, 02 May 2011 13:04:32 GMT"; modification-date="Mon, 02 May 2011 13:04:32 GMT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAxMS0wNS0wMjA4NTU1NC5J LURAaWV0Zi5vcmc+DQoNCg== --_003_DADD7EAD88AB484D8CCC328D40214CCD07F84886D9EXPO10exchang_ Content-Type: text/plain; name="Untitled attachment 00033.txt" Content-Description: Untitled attachment 00033.txt Content-Disposition: attachment; filename="Untitled attachment 00033.txt"; size=258; creation-date="Mon, 02 May 2011 13:04:32 GMT"; modification-date="Mon, 02 May 2011 13:04:32 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_DADD7EAD88AB484D8CCC328D40214CCD07F84886D9EXPO10exchang_-- From beaton@google.com Mon May 2 11:32: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 408C1E0729 for ; Mon, 2 May 2011 11:32: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 gKDaAYvBvabZ for ; Mon, 2 May 2011 11:32:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C6B65E06FA for ; Mon, 2 May 2011 11:32:50 -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 p42IWnuT025072 for ; Mon, 2 May 2011 11:32:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304361169; bh=HyxP5zfq4wyNjNKaVwEuLOan4Zc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=SfSR0L8O6fN8tArFIXYiXkCDbh0OnQzMPhcHiAmQ8yAyaaftYhwoWodiIjbxHqSRN EvMJIgVotDmt/OUdCbafw== Received: from pxi9 (pxi9.prod.google.com [10.243.27.9]) by wpaz37.hot.corp.google.com with ESMTP id p42IWlN8002785 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 11:32:47 -0700 Received: by pxi9 with SMTP id 9so2379674pxi.14 for ; Mon, 02 May 2011 11:32: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:date :message-id:subject:from:to:cc:content-type; bh=8/S3V9DFmWsl1UbB1jj2++uHmXflSYf70QJOeDfNdO4=; b=nk6IM9tYBcKCBStYw7y7uUIMHoj2VPRfhpa4/ym4Rxk3oykOCprxmzb7qyMv2kg6lm YiAMuobvm54G1+gb8Eng== 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=PuuVgtq1rUpNqr3Wfz30+sZKcudJprnXzzQDrcHm10FNy3OLyuAYvBohKA7S9MicoM PbQNBIm465fctJUfIAHg== MIME-Version: 1.0 Received: by 10.142.171.17 with SMTP id t17mr3218354wfe.209.1304361166504; Mon, 02 May 2011 11:32:46 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Mon, 2 May 2011 11:32:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 May 2011 11:32:46 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: multipart/alternative; boundary=000e0cd1876afd066304a24f3f95 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 1.0 2-legged scenario X-BeenThere: oauth@ietf.org X-Mailman-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, 02 May 2011 18:32:52 -0000 --000e0cd1876afd066304a24f3f95 Content-Type: text/plain; charset=ISO-8859-1 Hey Andrew - Two-legged OAuth is a very confusing term. I've tried to stop using it, because it means so many different things to different people. I'm not 100% sure what your use case is... The current OAuth2 draft handles traditional client-server authentication with the client credentials flow: client_id + client_secret => access_token There is another flow that I think got dropped from the draft(?) but that various people have implemented: client_assertion => access_token That flow has better security than the client_secret flow, since it can use public key authentication instead of password authentication. But I wouldn't recommend that desktop side-bar gadgets (your use case) use either of those flows, since as you point out they can't keep secrets. We're handling gadgets using OAuth2 as small-view web applications. They use the user-agent flow with auto-approval of tokens after the user's first consent ("immediate mode"). For example: - iframe redirects to google's authentication service - google's authentication service checks that the callback URL of the iframe belongs to an app the user trusts - google redirects back to iframe with a short-lived (one hour) access token - iframe makes RPCs back to google through various channels. All of the RPCs are authenticated with the access token Does that sound like what you're getting at? Cheers, Brian On Sat, Apr 30, 2011 at 8:50 PM, Andrew Arnott wrote: > Does this docaccurately describe what the community generally refers to as "two-legged > OAuth"? If so, I have a couple questions... > > What about this is "*two* legged"? I count zero legs. The consumer > already has a key and secret, and uses them to access resources. Not a > single one of the 3 legs in standard OAuth's "unauthorized request token, > authorize, exchange for access token" flow are present in the above linked > spec by my reading of it. > > I expected two-legged OAuth to be more like this: > > 1. The client presumably already has a consumer key, but perhaps no > secret since these clients can rarely keep secrets. I'm imagining clients > that are desktop sidebar gadgets, perhaps. > 2. Upon first run, this app performs these two legs: > 1. Obtains a request token using the standard OAuth 1.0 flow. This > would traditionally be an unauthorized request token. But in 2-legged OAuth > this request token is implicitly auto-authorized, for access to a new, empty > account on the service provider. > 2. Exchanges the request token for an access token, again using the > standard OAuth 1.0 flow for that step. > 3. At this point, the client has a consumer key, perhaps a consumer > secret, and an access token and token secret. The token represents an empty > account, but may be filled and later queried by that client. The fact that > the client has no consumer secret is of little consequence because the > access token secret is unique for this particularly installation of the > client and therefore the data is protected. > > So... which one is right? And does the "wrong" one have any validity? > > Thanks. > -- > 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 > > --000e0cd1876afd066304a24f3f95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Andrew -

Two-legged OAuth is a very confusing term. = =A0I've tried to stop using it, because it means so many different thin= gs to different people. =A0I'm not 100% sure what your use case is...

The current OAuth2 draft handles traditional client-ser= ver authentication with the client credentials flow:

=A0 =A0client_id + client_secret =3D> access_token

There is another flow that I think got dropped from the draft(?) but t= hat various people have implemented:

=A0 =A0client= _assertion =3D> access_token

That flow has bett= er security than the client_secret flow, since it can use public key authen= tication instead of password authentication.

But I wouldn't recommend that desktop side-bar gadg= ets (your use case) use either of those flows, since as you point out they = can't keep secrets.

We're handling gadgets= using OAuth2 as small-view web applications. =A0They use the user-agent fl= ow with auto-approval of tokens after the user's first consent ("i= mmediate mode"). =A0For example:

- iframe redirects to google's authentication servi= ce
- google's authentication service checks that the callback= URL of the iframe belongs to an app the user trusts
- google red= irects back to iframe with a short-lived (one hour) access token
- iframe makes RPCs back to google through various channels. =A0All of= the RPCs are authenticated with the access token

= Does that sound like what you're getting at?

Cheers,
Brian

On Sat, Ap= r 30, 2011 at 8:50 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
Does this doc accurately descr= ibe what the community generally refers to as "two-legged OAuth"?= =A0 If so, I have a couple questions...
=A0
What about this is "two legged"?=A0 I= count=A0zero legs.=A0=A0The consumer already has a key and secret, and use= s them to access resources.=A0 Not a single one of the 3 legs in standard O= Auth's "unauthorized request token, authorize, exchange for access= token" flow are present in the above linked spec by my reading of it.=
=A0
I expected two-legged OAuth to be more like this:
<= ol>
  • The client presumably already has a consumer key, but perhaps no sec= ret since these clients can rarely keep secrets.=A0 I'm imagining clien= ts that are desktop sidebar gadgets, perhaps.
  • Upon first run, this app performs these two legs:
    1. Obtains a= request token using the standard OAuth 1.0 flow.=A0 This would traditional= ly be an unauthorized request token.=A0 But in 2-legged OAuth this request = token is implicitly auto-authorized, for access to a new, empty account on = the service provider.
    2. Exchanges the request token for an access token, again using the standa= rd OAuth 1.0 flow for that step.=A0
  • At this point, the client= has a consumer key, perhaps a consumer secret, and an access token and tok= en secret.=A0 The token represents an empty account, but may be filled and = later queried by that client.=A0 The fact that the client has no consumer s= ecret is of little consequence because the access token secret is unique fo= r this particularly installation of the client and therefore the data is pr= otected.
    • So... which one is right?=A0 And does the "wrong" one h= ave any validity?
    =A0
    Thanks.
    --
    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
    =A0

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth


    --000e0cd1876afd066304a24f3f95-- From tim.freeman@hp.com Mon May 2 11:34: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 E0CBDE06FA for ; Mon, 2 May 2011 11:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 l5BamIfBLDvA for ; Mon, 2 May 2011 11:34:41 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18FE06E6 for ; Mon, 2 May 2011 11:34:41 -0700 (PDT) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 0E4DF38508 for ; Mon, 2 May 2011 18:34:40 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 2 May 2011 18:33:19 +0000 Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Mon, 2 May 2011 18:33:18 +0000 From: "Freeman, Tim" To: "oauth@ietf.org" Date: Mon, 2 May 2011 18:33:16 +0000 Thread-Topic: [OAUTH-WG] requirement of redirect_uri in access token requests Thread-Index: AcwHfbavTY9JB/rmQF28aGavrZ23jABdMjGA Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8@GVW0432EXB.americas.hpqcorp.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_59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8GVW0432EXBame_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 02 May 2011 18:34:43 -0000 --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8GVW0432EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The issues around redirect_uri seem muddled to me. Here's what I know righ= t now: Brian Eaton apparently said: >This provides a defense against authorization codes which have leaked due = to open redirectors. I looked for "redirector" in http://tools.ietf.org/html//draft-lodderstedt-oauth-security-01 which is apparently the latest draft of the security considerations documen= t. The only mention is in section 4.2.4 under "Threat: Open redirector", w= hich I can quote in full: An attacker could use the end-user authorization endpoint and the redirect_uri parameter to abuse the authorization server as redirector. Impact? Countermeasure o don't redirect to redirect_uri, if client identity or redirect_uri could not be verified I don't know what this means. The word "abuse" is vague, and the "Impact" = section is blank. At least in the bearer token version of the protocol, I = believe we do all of our redirecting before verifying the client identity, = so I don't see how we can know whether the client identity can be verified = when we're deciding whether to redirect. It would help to have a specific= sequence of events that is undesired. I can't tell if this only mention o= f "redirector" in Torsten Lodderstedt's document matches what Brian was tal= king about. I talked some about whether we need the redirect_uri at: http://www.ietf.org/mail-archive/web/oauth/current/msg05733.html Judging by the "Next by thread" link on that page, nobody replied to this. = I do not think the failure scenario I described involves an open redirecto= r, so I think the problem I described (if the redirect_uri is not checked) = is different from Brian's. I haven't read the security considerations docu= ment carefully enough to know whether the failure scenario I described appe= ars in it. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Saturday, April 30, 2011 2:29 PM To: Doug Tangren Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token request= s On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren > wrote: Is this required or not? In the example http://tools.ietf.org/html/draft-ie= tf-oauth-v2-15#section-3.1 it's listed in the example but not itemized as o= ptional or required. It's not in the example for refreshing tokens http://t= ools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that section lin= ks back to section 3.1 which does use a redirect_uri in the example. Should the redirect_uri be a requirement for client authentication or is it= optional? It should be required when exchanging an authorization code for a refresh t= oken. This provides a defense against authorization codes which have leake= d due to open redirectors. It should not be present under other circumstances. --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8GVW0432EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The issues aroun= d redirect_uri seem muddled to me.  Here's what I know right now:=

     

    Br= ian Eaton apparently said:

    >This prov= ides a defense against authorization codes which have leaked due to open re= directors.

     

    I looked for "redirector" in

     

       http://tools.ietf.org/html//draft= -lodderstedt-oauth-security-01

     

    which is appar= ently the latest draft of the security considerations document.  The o= nly mention is in section 4.2.4 under "Threat: Open redirector", = which I can quote in full:

     

       An attacker could use the en= d-user authorization endpoint and the

      = ; redirect_uri parameter to abuse the authorization server as

       redirector.

     =

       Impact?

    &= nbsp;

       Countermeasure

       o  don't redirect to redirect_uri, if client identi= ty or redirect_uri

         = could not be verified

     

    I don't know what this means.  The word = "abuse" is vague, and the "Impact" section is blank.&nb= sp; At least in the bearer token version of the protocol, I believe we do a= ll of our redirecting before verifying the client identity, so I don't see = how we can know whether the client identity can be verified when we're deci= ding whether to redirect.   It would help to have a specific sequ= ence of events that is undesired.  I can't tell if this only mention o= f "redirector" in Torsten Lodderstedt's document matches what Bri= an was talking about.

     

    I talked some about wh= ether we need the redirect_uri at:

     

     &nbs= p; http://www.ietf.org/mail-archive/web/oauth/current/msg05733.html

     

    Judging by the "Next by thread" link on th= at page, nobody replied to this.  I do not think the failure scenario = I described involves an open redirector, so I think the problem I described= (if the redirect_uri is not checked) is different from Brian's.  I ha= ven't read the security considerations document carefully enough to know wh= ether the failure scenario I described appears in it.

    =

     

    From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Eaton
    Sent: Saturday, April 30, 2011 2:29 = PM
    To: Doug Tangren
    Cc: oauth@ietf.org
    Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests=

     

    On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren <d.tangren@gmail.com> wrote:

    Is this required or not? In the example http://tools.= ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed in the exa= mple but not itemized as optional or required. It's not in the example for = refreshing tokens http://tools.ietf.org/html/draft-ietf-oaut= h-v2-15#section-6 though that section links back to section 3.1 which d= oes use a redirect_uri in the example.

    Should the redirect_uri be a= requirement for client authentication or is it optional?

     

    It should be required when exchanging an authorization code f= or a refresh token.  This provides a defense against authorization cod= es which have leaked due to open redirectors.

     

    It sh= ould not be present under other circumstances.

    = --_000_59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8GVW0432EXBame_-- From beaton@google.com Mon May 2 11:52: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 B4AECE06CB for ; Mon, 2 May 2011 11:52:45 -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 lKkKzwMMY9gU for ; Mon, 2 May 2011 11:52:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 77F39E0713 for ; Mon, 2 May 2011 11:52:34 -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 p42IqXSs029870 for ; Mon, 2 May 2011 11:52:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304362353; bh=WEeeqB/QdRS2Kkvvc7qjG5mY4gY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CwGfNohoR8ux2hX5DyqaU4nIj22FSSfqVXo7iAja0Jsa/1G+gR9LVKSJT3c8zaDhn o/M5x2UKAo6rsNADkUgiA== Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq6.eem.corp.google.com with ESMTP id p42IptOa008932 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 11:52:32 -0700 Received: by pwi5 with SMTP id 5so3516685pwi.31 for ; Mon, 02 May 2011 11:52: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=WDX9whO7d9yIE8a+Yb+UUTXeO7Y6yfHbXIYMGDCBXPc=; b=weU+W9Cdpc0Gcv7XRZOdvHRUjT+o0/XNWf0KHpujJ5qf4KLiaz6DPWxse7Sb+ZvWtj M6/ruNdByvCLNAwpbAeg== 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=YdxQ2AP2HT8cdTl9vw4srYqtBro/aS8xDE/Nsk8UncPUuSD0hbBoirKlg0hCvmbcIE 9/Cz2WTR02o3/qBWl5AA== MIME-Version: 1.0 Received: by 10.142.250.42 with SMTP id x42mr3256430wfh.95.1304362351988; Mon, 02 May 2011 11:52:31 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Mon, 2 May 2011 11:52:31 -0700 (PDT) In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8@GVW0432EXB.americas.hpqcorp.net> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8@GVW0432EXB.americas.hpqcorp.net> Date: Mon, 2 May 2011 11:52:31 -0700 Message-ID: From: Brian Eaton To: "Freeman, Tim" Content-Type: multipart/alternative; boundary=001636ed66f0a6108b04a24f8628 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 02 May 2011 18:52:45 -0000 --001636ed66f0a6108b04a24f8628 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 2, 2011 at 11:33 AM, Freeman, Tim wrote: > The issues around redirect_uri seem muddled to me. > Yeah. =/ It's unfortunate. I think the problem is that implementers disagree on what type of redirect uri validation to do, so the spec has papered over the inconsistencies with muddled language. Avoiding open redirectors on the authorization server is worth doing, but open redirectors on the relying party side are a very serious risk. Here is a concrete example of an attack that implementations need to prevent. User visits evil.com. evil.com redirects with client_id of "good.com" and a callback URL of " https://good.com/bounce?continue=https://evil.com" Authorization server generates either an access token and sends redirect to "https://good.com/bounce?continue=https://evil.com#token=<tim.freeman@hp.com> wrote:
    =

    The issues around redirect_uri seem muddled to me.=A0


    Yeah. =3D/ =A0It's unfortunate. =A0I thi= nk the problem is that implementers disagree on what type of redirect uri v= alidation to do, so the spec has papered over the inconsistencies with mudd= led language.

    Avoiding open redirectors on the authorization server i= s worth doing, but open redirectors on the relying party side are a very se= rious risk.

    Here is a concrete example of an attac= k that implementations need to prevent.

    User visits evil.com.
    evil.com redirects with client_id = of "good.com" and a callback URL = of "ht= tps://good.com/bounce?continue=3Dhttps://evil.com"
    Authorization server generates either an access token and sends redire= ct to "https://good.com/bounce?continue=3Dhttps://evil.com#token=3D&= lt;token"
    good.com redirects to evil.com with token in URL.
    evil.com walks off with token.

    The righ= t way to fix that is with fairly strict matching between client-ids and cal= lback URLs. =A0This is the approach that the SAML spec took for this proble= m. =A0It's also the approach used by Google's OAuth2 implementation= .

    There are several other approaches that have been discu= ssed that don't actually work to defend against that attack.
    = - you can't prevent this by requiring HMACs on data access requests
    =A0 =A0The evil server can replay the victim's access token to the= good server. =A0The good server will then use it's own HMAC key to mak= e data access requests using the victim's token. =A0The victim's da= ta is then returned to the attacker.

    - you can't prevent this by using https for callbac= k URLs.
    =A0 =A0Redirects are an application level leak. =A0The br= owser is sending the token directly to the evil server.

    - you can't prevent this by telling good.co= m not to host any pages that redirect to third-party sites.
    = =A0 =A0good.com, like most other web sites,= will have a need to host redirectors. =A0Most sites ignore them. =A0A few = go to great lengths to close them, but the most common techniques for closi= ng redirectors don't defend against this attack.

    Referer leaks are a related problem. =A0The exploitatio= n is a bit different, but the same mitigation (strict callback URL matching= ) still works.

    Cheers,
    Brian
    --001636ed66f0a6108b04a24f8628-- From ecestari@gmail.com Tue May 3 01:34: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 E43F1E06F9 for ; Tue, 3 May 2011 01:34:43 -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 HW45Moo5d7lB for ; Tue, 3 May 2011 01:34:43 -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 0B05FE06E1 for ; Tue, 3 May 2011 01:34:42 -0700 (PDT) Received: by bwz13 with SMTP id 13so6318461bwz.31 for ; Tue, 03 May 2011 01:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=pkmNnHb6sZiKDDmpBtQoTMHvF+o3IQxOCXIbFnF5Ih0=; b=EPVKSi4l0tBqhF+XZ3uMyB6s4PbUMFuPbsb7lWR69kkhENH3j+3ef3q6ahkiJw5jej dnrulD7tmgsS7YY5e+PpKjIYUCGbwsuL9CBY6ZotyKatYs4+RUKGyJengsYBIVJ7VvXW FaFzxSLI/53kykOEqYUJs09RUPQ/K6v815N7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=RkQEQHX1jTcqC9uTI41QglBvmH90UGl+PwhsMGIo/UlOp9nPubUILlcwpswM6KJdsZ 2PN+HHkfxI54sDuCes2qCLRPcHHhblTD7knXAdaSzQrOm0kuOciXQR9wg7XruFfyxzHo 3CBWPACmrtLq0X7S25nFJmzzVUh4mQhnCfN20= Received: by 10.204.139.199 with SMTP id f7mr7671253bku.23.1304411681872; Tue, 03 May 2011 01:34:41 -0700 (PDT) Received: from [192.168.0.30] (243.226.20-93.rev.gaoland.net [93.20.226.243]) by mx.google.com with ESMTPS id z2sm876538faj.1.2011.05.03.01.34.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 01:34:41 -0700 (PDT) From: Eric Cestari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 10:34:38 +0200 Message-Id: To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 03 May 2011 08:34:44 -0000 Hi, I am currently implementing OAuth v2, and I have a couple questions: - when a client requests an access token, with grant type "password" for = example, can the authorization server resend the same refresh token from = the last time the same client/resource owner combination requested an = access token ? That would prevent the auth database from being flooded = with refresh tokens (which do not expire automatically) from badly = behaving client, reusing the "password" grant type repeatedly. Or did I overlook some security considerations? - More about obtaining an access token: is it possible to send = additional (and optional) parameters along when the client requests an = access token ? The draft states "the authorization server SHOULD ignore = unrecognized request parameters.", so I am thinking "yes". Am I correct = ? Thanks! Cheers, Eric Cestari From alexey.melnikov@isode.com Tue May 3 04: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 71E52E07F9 for ; Tue, 3 May 2011 04:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 B8Bp+JYBOgM9 for ; Tue, 3 May 2011 04:17:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id CE114E07FE for ; Tue, 3 May 2011 04:17:07 -0700 (PDT) Received: from [188.28.73.38] (188.28.73.38.threembb.co.uk [188.28.73.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 3 May 2011 12:17:06 +0100 Message-ID: <4DBFE422.5090105@isode.com> Date: Tue, 03 May 2011 12:16:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Barry Leiba References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 03 May 2011 11:17:10 -0000 Hi Barry, Barry Leiba wrote: >There are three issues in the tracker that are just looking for >consensus on text that's in the document -- Eran had flagged them as >"pending consensus" in the -15 version. Let's look at closing those >issues now. The issues are > >#8 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code >http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 > >#9 5.2, text for non-400 & 401 error conditions >http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 > > These look fine to me. >#10 8.4. Defining Additional Error Codes >http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 > > This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC 6075), the OID vendor names, or DNS names can be recommended for the prefix (to satisfy the "SHOULD be prefixed by an identifying name when possible" requirement)? Best Regards, Alexey -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov From t.lodderstedt@telekom.de Tue May 3 05:49: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 B20E5E0808 for ; Tue, 3 May 2011 05:49:07 -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 hD3-RacEGcdu for ; Tue, 3 May 2011 05:49:05 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id AD473E080B for ; Tue, 3 May 2011 05:49:04 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail71.telekom.de with ESMTP; 03 May 2011 14:48:53 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Tue, 3 May 2011 14:48:52 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Tue, 3 May 2011 14:48:52 +0200 From: "Lodderstedt, Torsten" To: 'Eric Cestari' , "oauth@ietf.org" Date: Tue, 3 May 2011 14:48:51 +0200 Thread-Topic: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization Thread-Index: AcwJkHQdR0NJaG9OQ0CEn6I98/gSDg== Message-Id: <63366D5A116E514AA4A9872D3C5335395649616D15@QEO40072.de.t-online.corp> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 03 May 2011 12:49:08 -0000 Hi Eric, >- when a client requests an access token, with grant type "password" for >= example, can the authorization server resend the same refresh token from >t= he last time the same client/resource owner combination requested an >acces= s token ? That would prevent the auth database from being flooded with >ref= resh tokens (which do not expire automatically) from badly behaving >client= , reusing the "password" grant type repeatedly. >Or did I overlook some security considerations? Your authorization server could provide the client with the same refresh to= ken again. The question is whether the authorization server must ensure it = is the same client _instance_ again. Otherwise, this might cause unintended= impacts on other instances of the same client used by the same user on oth= er devices.=20 The spec does not prevent your authorization server from automatically expi= ring refresh tokens (e.g. after some idle time). >- More about obtaining an access token: is it possible to send additional = >(and optional) parameters along when the client requests an access token ?= >The draft states "the authorization server SHOULD ignore unrecognized >re= quest parameters.", so I am thinking "yes". Am I correct ? Doesn't section 8.2 answer this question? Regards, Torsten. Thanks! Cheers, Eric Cestari _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From ecestari@gmail.com Tue May 3 06:01: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 3B56BE082C for ; Tue, 3 May 2011 06:01: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 y+6Gqtkgi9iB for ; Tue, 3 May 2011 06:01:07 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6117CE082A for ; Tue, 3 May 2011 06:01:07 -0700 (PDT) Received: by wwk4 with SMTP id 4so3255716wwk.1 for ; Tue, 03 May 2011 06:01:06 -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=qIb/oy+seeJVmpx+Zfg2PoYL+iKyM1BRfGb5eW84xqg=; b=w7n+D51GShkmqWWobhBDT/bSnOXAtMQmmTgN2kF/HrK06EJfbiMY8ibA4Yc8WfWmAo 2QpWZUo9SkYgz3xkPQuJI4IP3gBEsHVlm6NxF2lVjkB+JSDs3btmsUET51CfBjcO5pvC xZ20EmFYWhz8obyxFzA5tpcK3alCoSyBDB1bw= 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=YUPOxI1zn3b18syfUHtbIKuztWvKOIGY3egPGUdzlDZPBMbXmU44zLcBf5u1Y9rjRd F+Pc8bEOYMPfzKbFC445AQbpi7aNTTNEQqA6CTWq6ksjVVcF/+QSOhZ7yGVgoYIS7fZd qC8ASY32k/XDZzKytkuyfar5AvJFxFw72vKVw= Received: by 10.216.134.66 with SMTP id r44mr3608708wei.92.1304427506446; Tue, 03 May 2011 05:58:26 -0700 (PDT) Received: from [192.168.0.30] (243.226.20-93.rev.gaoland.net [93.20.226.243]) by mx.google.com with ESMTPS id f52sm33017wes.35.2011.05.03.05.58.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 05:58:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Eric Cestari In-Reply-To: <63366D5A116E514AA4A9872D3C5335395649616D15@QEO40072.de.t-online.corp> Date: Tue, 3 May 2011 14:58:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63366D5A116E514AA4A9872D3C5335395649616D15@QEO40072.de.t-online.corp> To: "Lodderstedt, Torsten" X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reusing refresh tokens and additional parameters when granting authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 03 May 2011 13:01:08 -0000 Thorsten, Justin, Thank you for your answers, I know the spec would not address some of = the points I raised, but I was pretty sure you had some best pratices in = mind. Le 3 mai 2011 =E0 14:48, Lodderstedt, Torsten a =E9crit : >> - More about obtaining an access token: is it possible to send = additional >(and optional) parameters along when the client requests an = access token ? >The draft states "the authorization server SHOULD ignore = unrecognized >request parameters.", so I am thinking "yes". Am I correct = ? >=20 > Doesn't section 8.2 answer this question? Indeed, massive overlook from my part, thank you! Eric From tonynad@microsoft.com Tue May 3 11:44: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 ECD42E088B for ; Tue, 3 May 2011 11:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 duMUvMlHysSc for ; Tue, 3 May 2011 11:44:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 67B57E0883 for ; Tue, 3 May 2011 11:44:40 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 3 May 2011 11:44:40 -0700 Received: from AM1EHSOBE001.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 3 May 2011 11:44:39 -0700 Received: from mail48-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 May 2011 18:44:38 +0000 Received: from mail48-am1 (localhost.localdomain [127.0.0.1]) by mail48-am1-R.bigfish.com (Postfix) with ESMTP id 0CFF77E825A for ; Tue, 3 May 2011 18:44:38 +0000 (UTC) X-SpamScore: -49 X-BigFish: PS-49(zz9371Oc3f8W542MzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT001.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=CH1PRD0302HT001.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail48-am1 (localhost.localdomain [127.0.0.1]) by mail48-am1 (MessageSwitch) id 1304448277851300_31848; Tue, 3 May 2011 18:44:37 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.251]) by mail48-am1.bigfish.com (Postfix) with ESMTP id CCC3511B804B; Tue, 3 May 2011 18:44:37 +0000 (UTC) Received: from CH1PRD0302HT001.namprd03.prod.outlook.com (157.55.61.146) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 3 May 2011 18:44:37 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.185]) by CH1PRD0302HT001.namprd03.prod.outlook.com ([10.28.28.143]) with mapi id 14.01.0225.045; Tue, 3 May 2011 18:44:35 +0000 From: Anthony Nadalin To: Barry Leiba , OAuth WG Thread-Topic: [OAUTH-WG] Closing a few issues Thread-Index: AQHMBpgUBI/4huqV/0umxSz36sp5ZZR7dkVg Date: Tue, 3 May 2011 18:44:34 +0000 Message-ID: References: In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 03 May 2011 18:44:41 -0000 I propose that we close issue #12 (Restore WWW-Authenticate response to the= framework specification) with no action, that is each extension would hand= le as they are doing now. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= arry Leiba Sent: Friday, April 29, 2011 11:05 AM To: OAuth WG Subject: [OAUTH-WG] Closing a few issues There are three issues in the tracker that are just looking for consensus o= n text that's in the document -- Eran had flagged them as "pending consensu= s" in the -15 version. Let's look at closing those issues now. The issues= are #8 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 #9 5.2, text for non-400 & 401 error conditions http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 #10 8.4. Defining Additional Error Codes http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 I think these are non-controversial. I'm aware of some conversation about = perhaps tweaking the text to make sure it's clear what layer the status cod= es go into (for the redirects, it should be clear, but a slight text change= might help). Everyone, please review these. They are short, and should be easy to confi= rm consensus on. Please post any objection you have to closing these issue= s. If you do have an objection, it would help if you could post alternativ= e text that you'd be happy with. Please post also if you think they're OK = and ready to close. I will close these issues next Friday, 6 May, if there are no unresolved ob= jections. Barry, as chair _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Tue May 3 19:51: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 55C3FE0679 for ; Tue, 3 May 2011 19:51:36 -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=[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 WhcolXS3ZJgs for ; Tue, 3 May 2011 19:51:34 -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 E1662E0618 for ; Tue, 3 May 2011 19:51:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,312,1301839200"; d="scan'208";a="32458390" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 04 May 2011 12:51:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6335"; a="25064001" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 04 May 2011 12:51:30 +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, 4 May 2011 12:51:30 +1000 From: "Manger, James H" To: oauth Date: Wed, 4 May 2011 12:51:28 +1000 Thread-Topic: I-D Action:draft-oauth-dyn-reg-v1-02.txt Thread-Index: AQD42VEWs34D4+z9B0tpDAs9zVMEAZYgIoMggACSgaA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11283C3737F@WSMSG3153V.srv.dir.telstra.com> References: <20110502160002.29594.25481.idtracker@ietfa.amsl.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 Subject: Re: [OAUTH-WG] I-D Action:draft-oauth-dyn-reg-v1-02.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: Wed, 04 May 2011 02:51:36 -0000 Comments on the OAuth Dynamic Client Registration Protocol [draft-oauth-dyn= -reg-v1-02]: I found it hard to gleam from this draft where any trust in the client info= rmation being registered comes from. Sources could be: self-asserted; PKI w= ith well-known roots; or DNS. OpenID and WebID are two existing approaches for authenticating to a server= you have never met before. A client logging in to an authorization server = (AS) using one of these techniques then accessing a specific page could be = treated as a registration. [A variant of OpenID suitable for apps, as opposed to users, is sorely need= ed.] Section 6: "Client Registration with Pushed Metadata" The draft talks about an authorization server "verifying information receiv= ed from the client" [6.2] but with no clues as to what is verified or how. = Checks that client_name doesn't contain control characters, client_uri is s= yntactically correct, or that client_uri returns "200 OK" and text/html con= tent are possible, but almost meaningless. They don't tell the AS that the = values are appropriate for the client that it is talking to. Section 7: " Client Registration with Pushed URL and Pulled Metadata" Pushing a URL appears insecure. A malicious app POSTs another apps client_u= rl (7.1) and gets a client_id and client_secret for that app in return. Per= haps signing the POSTed client_url helps (the draft says a client MAY do th= is), but it isn't obvious to me how the AS checks the signer is the right e= ntity. Must the same certificate (or same key, or same cert subject...) be = used to sign the POST and to serve the metadata the AS subsequently gets fr= om https://.../.well-known/host-meta? Section 6.2: "Client Registration Response" [and 6.3 and 7.3 and 7.4] This looks like another version of an OAuth2 token response [draft-ietf-oau= th-v2-15#section-5.1]. It conveys similar data (dynamically-issued credenti= als), but makes up another format. It doesn't tell the client how or where = to use the credentials (ie which authentication mechanisms, and which serve= rs). This draft and OAuth2 would be helped if we defined an explicit media type = for credentials: eg application/credentials+json. This draft could use it t= o return client credentials. OAuth2 could use it to return credentials repr= esenting a user's delegation to a client etc. It could cover the common nee= ds: id, auth mechanism, where it is safe to use, lifetime, renewal, multipl= e credentials, errors.... -- James Manger From marcus@better.se Wed May 4 05:25: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 8646EE0773 for ; Wed, 4 May 2011 05:25:48 -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 G7EcCUps1F1A for ; Wed, 4 May 2011 05:25:48 -0700 (PDT) Received: from vips.better.se (vips.better.se [79.99.3.21]) by ietfa.amsl.com (Postfix) with ESMTP id A40B9E071A for ; Wed, 4 May 2011 05:25:47 -0700 (PDT) Received: from [192.168.1.20] (unknown [80.169.182.16]) by vips.better.se (Postfix) with ESMTPSA id C096820EC096 for ; Wed, 4 May 2011 14:25:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=better.se; s=mail; t=1304511943; bh=3X+ZV+dZkKMB+RO2k73D1HmlkaLtrakjL3NsFQa/WPQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=DooHySYMTuYbQEwJ8UIgsmJqU8+eEFu+nbAOLBmOQlj4Gek+D33bYroTRZ5uoghkp M3y94/uhgSqvpb9/r9lCrnd5Otmg7/iiOEzstbV41AIWUiLwoFFXbYyKKYJBZRpja2 9Y7bNU1W2x1t7LxFXr6JnF5YfiHG6HGTjxo/1MGo= Message-ID: <4DC145C2.1050806@better.se> Date: Wed, 04 May 2011 14:25:38 +0200 From: Marcus Better User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: oauth@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] delegated authentication with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 May 2011 12:25:48 -0000 Hi, we are implementing a service that will allow users sign in using their account on an external OAuth 2.0 provider (a certain well-known social network). But there is a twist: my service consists of a mobile app and a web service. The mobile app needs to authenticate its user to the app server, so it can access our service API and user data. So we have the following parties: * Mobile App - used by end users * App Server - provides services to the Mobile App * Provider - OAuth 2.0 provider where users have accounts * End User holding accounts on both the Provider and App Server. The requirements are: (A) Authenticate the Mobile App to the App Server (on behalf of the end user) to access the user data on the App Server. To simplify for end users, they should log in using their Provider account (without separate credentials for the App Sever). (B) Allow the Mobile App to access the user's protected resources at the Provider. (Of course we do not consider the bad solution of asking for the user's Provider credentials, but want to use OAuth instead.) Point (B) is covered by standard OAuth 2.0. Point (A), however, is surprisingly tricky (to me at least). I do not know of a published OAuth flow that solves it. Is there a standard way to do this? So we figured out several ways to solve this, but I'm not sure if any of them are ideal. I'll list a few here. * Let the Mobile App authenticate with the Provider with the OAuth dance, and then send the access token to the App Server. The App Server will validate the access token, use it to identify the authenticating user, and return a token (the same or a new one) that is authorized to access its protected resources. This essentially means the App Server should be an OAuth provider itself (or some simplified version of it). The exchange of a Provider token for an App Server token would be accomplished with a special grant type. The only tricky point is how the App Server can validate the Provider token. It seems it will have to access the Provider using the token, and check that it succeeds. I don't like this much, because an attacker could send lots of authentication requests to the App Server with faked "Provider" access tokens, and the App Server would have to perform a transaction with the Provider each time to verify the token, which could be expensive. It would be preferable if the access token could be validated off-line. But I don't see that OAuth provides this capability. * Another variation would start an OAuth dance from the client, but use an authorization endpoint on the App Server, which would immediately redirect to the Provider's authorization endpoint with the redirect_url pointing back to the App Server, and finally redirect back to the client. In this way the App Server inserts itself into the redirect chain, and proxies the authentication request. It gets the access token and passes it on to the client, along with any app-specific extra parameters. From the Mobile App point of view, it uses a regular OAuth flow with some special endpoints and parameters. There are other variations on this using different redirect sequences. Or maybe there is an entirely different solution? Cheers, Marcus From bittercoder@gmail.com Wed May 4 06:17: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 6B9C3E0682 for ; Wed, 4 May 2011 06:17:56 -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 WR3bGIJfJpGQ for ; Wed, 4 May 2011 06:17:55 -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 C9C5FE0794 for ; Wed, 4 May 2011 06:17:54 -0700 (PDT) Received: by bwz13 with SMTP id 13so1111623bwz.31 for ; Wed, 04 May 2011 06:17:53 -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=LtsT6NXN8JSXrPZm0NKfj3IGr+bgA5wpIsZZptfRGc0=; b=VDpE7PKwCFCsVw8MXGusUREH04YE/K1yMYSnbWd8GDTzC3722smO4y1HzhXiQpMJT7 c9q4t80NtE1MCb+hMvS3/evfJz7OqBcv8L8rS7VFKP1tYEAkl8cXS8sg4ceHv0oAsicJ Nwj1kF3dx/+4yOwUvCoVdAnrjA2RNjA0M7I+g= 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=ZgUQqn0WeMnvnbE7/fS3vpvpngfVfqYV984Jqz8eEaHtGTu1oqGzFqiNMaqCi453iy z9g1M3KHFp1a7KXClW81PjOPFGGKSorGyJ1ubeMncVqsAhkUTOmFWtNm3aKuUawIzeZY dqR3fMyK3wn5EepRmz/3/hVh3qiN+4DhzJdEE= MIME-Version: 1.0 Received: by 10.205.33.194 with SMTP id sp2mr1146817bkb.27.1304515073562; Wed, 04 May 2011 06:17:53 -0700 (PDT) Received: by 10.204.75.195 with HTTP; Wed, 4 May 2011 06:17:53 -0700 (PDT) In-Reply-To: <4DC145C2.1050806@better.se> References: <4DC145C2.1050806@better.se> Date: Thu, 5 May 2011 01:17:53 +1200 Message-ID: From: Alex Henderson To: Marcus Better Content-Type: multipart/alternative; boundary=bcaec51b16e990577404a2731513 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 May 2011 13:17:56 -0000 --bcaec51b16e990577404a2731513 Content-Type: text/plain; charset=ISO-8859-1 Though not OAuth 2.0 - the scenario you're describing sounds very close to that of an OpenSocial gadgets implementation - where by the open social container (which would be Analogous to your App Server) can handle relaying requests to a 3rd party API secured via OAuth - in which case it is both an OAuth provider and OAuth consumer. Might pay to check out the OpenSocial spec, might give you some food for thought. Cheers, Alex On Thu, May 5, 2011 at 12:25 AM, Marcus Better wrote: > Hi, > > we are implementing a service that will allow users sign in using their > account on an external OAuth 2.0 provider (a certain well-known social > network). But there is a twist: my service consists of a mobile app and > a web service. The mobile app needs to authenticate its user to the app > server, so it can access our service API and user data. > > So we have the following parties: > * Mobile App - used by end users > * App Server - provides services to the Mobile App > * Provider - OAuth 2.0 provider where users have accounts > * End User holding accounts on both the Provider and App Server. > > The requirements are: > (A) Authenticate the Mobile App to the App Server (on behalf of the end > user) to access the user data on the App Server. To simplify for end > users, they should log in using their Provider account (without separate > credentials for the App Sever). > > (B) Allow the Mobile App to access the user's protected resources at the > Provider. > > (Of course we do not consider the bad solution of asking for the user's > Provider credentials, but want to use OAuth instead.) > > Point (B) is covered by standard OAuth 2.0. > > Point (A), however, is surprisingly tricky (to me at least). I do not > know of a published OAuth flow that solves it. Is there a standard way > to do this? > > So we figured out several ways to solve this, but I'm not sure if any of > them are ideal. I'll list a few here. > > * Let the Mobile App authenticate with the Provider with the OAuth > dance, and then send the access token to the App Server. The App Server > will validate the access token, use it to identify the authenticating > user, and return a token (the same or a new one) that is authorized to > access its protected resources. > > This essentially means the App Server should be an OAuth provider itself > (or some simplified version of it). The exchange of a Provider token for > an App Server token would be accomplished with a special grant type. > > The only tricky point is how the App Server can validate the Provider > token. It seems it will have to access the Provider using the token, and > check that it succeeds. I don't like this much, because an attacker > could send lots of authentication requests to the App Server with faked > "Provider" access tokens, and the App Server would have to perform a > transaction with the Provider each time to verify the token, which could > be expensive. It would be preferable if the access token could be > validated off-line. But I don't see that OAuth provides this capability. > > * Another variation would start an OAuth dance from the client, but use > an authorization endpoint on the App Server, which would immediately > redirect to the Provider's authorization endpoint with the redirect_url > pointing back to the App Server, and finally redirect back to the > client. In this way the App Server inserts itself into the redirect > chain, and proxies the authentication request. It gets the access token > and passes it on to the client, along with any app-specific extra > parameters. From the Mobile App point of view, it uses a regular OAuth > flow with some special endpoints and parameters. > > There are other variations on this using different redirect sequences. > > Or maybe there is an entirely different solution? > > Cheers, > > Marcus > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --bcaec51b16e990577404a2731513 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Though not OAuth 2.0 - the scenario you're describing sounds very close= to that of an OpenSocial gadgets implementation - where by the open social= container (which would be=A0Analogous=A0to your App Server) can handle rel= aying requests to a 3rd party API secured via OAuth - in which case it is b= oth an OAuth provider and OAuth consumer.

    Might pay to check out the OpenSocial spec, might give you some food fo= r thought.

    Cheers,

    Alex

    On Thu, May 5, 2011 at 12:25 AM, Marcus Better <marcus@better.se> wr= ote:
    Hi,

    we are implementing a service that will allow users sign in using their
    account on an external OAuth 2.0 provider (a certain well-known social
    network). But there is a twist: my service consists of a mobile app and
    a web service. The mobile app needs to authenticate its user to the app
    server, so it can access our service API and user data.

    So we have the following parties:
    * Mobile App - used by end users
    * App Server - provides services to the Mobile App
    * Provider - OAuth 2.0 provider where users have accounts
    * End User holding accounts on both the Provider and App Server.

    The requirements are:
    (A) Authenticate the Mobile App to the App Server (on behalf of the end
    user) to access the user data on the App Server. To simplify for end
    users, they should log in using their Provider account (without separate credentials for the App Sever).

    (B) Allow the Mobile App to access the user's protected resources at th= e
    Provider.

    (Of course we do not consider the bad solution of asking for the user's=
    Provider credentials, but want to use OAuth instead.)

    Point (B) is covered by standard OAuth 2.0.

    Point (A), however, is surprisingly tricky (to me at least). I do not
    know of a published OAuth flow that solves it. Is there a standard way
    to do this?

    So we figured out several ways to solve this, but I'm not sure if any o= f
    them are ideal. I'll list a few here.

    * Let the Mobile App authenticate with the Provider with the OAuth
    dance, and then send the access token to the App Server. The App Server
    will validate the access token, use it to identify the authenticating
    user, and return a token (the same or a new one) that is authorized to
    access its protected resources.

    This essentially means the App Server should be an OAuth provider itself (or some simplified version of it). The exchange of a Provider token for an App Server token would be accomplished with a special grant type.

    The only tricky point is how the App Server can validate the Provider
    token. It seems it will have to access the Provider using the token, and check that it succeeds. I don't like this much, because an attacker
    could send lots of authentication requests to the App Server with faked
    "Provider" access tokens, and the App Server would have to perfor= m a
    transaction with the Provider each time to verify the token, which could be expensive. It would be preferable if the access token could be
    validated off-line. But I don't see that OAuth provides this capability= .

    * Another variation would start an OAuth dance from the client, but use
    an authorization endpoint on the App Server, which would immediately
    redirect to the Provider's authorization endpoint with the redirect_url=
    pointing back to the App Server, and finally redirect back to the
    client. In this way the App Server inserts itself into the redirect
    chain, and proxies the authentication request. It gets the access token
    and passes it on to the client, along with any app-specific extra
    parameters. From the Mobile App point of view, it uses a regular OAuth
    flow with some special endpoints and parameters.

    There are other variations on this using different redirect sequences.

    Or maybe there is an entirely different solution?

    Cheers,

    Marcus
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    --bcaec51b16e990577404a2731513-- From prvs=110588c3f2=hardjono@mit.edu Wed May 4 07:34: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 A58D6E0719 for ; Wed, 4 May 2011 07:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 kvZt3qxAXFSm for ; Wed, 4 May 2011 07:34:24 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id B2002E070C for ; Wed, 4 May 2011 07:34:23 -0700 (PDT) X-AuditID: 12074422-b7b87ae000005e02-37-4dc163f04b94 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 86.17.24066.0F361CD4; Wed, 4 May 2011 10:34:24 -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 p44EYLG9007123 for ; Wed, 4 May 2011 10:34:22 -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 p44EYLRA017895 for ; Wed, 4 May 2011 10:34:21 -0400 Received: from w92exhub9.exchange.mit.edu (18.7.73.17) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 4 May 2011 10:32:26 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub9.exchange.mit.edu ([18.7.73.17]) with mapi; Wed, 4 May 2011 10:34:20 -0400 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" Date: Wed, 4 May 2011 10:34:19 -0400 Thread-Topic: I-D Action:draft-oauth-dyn-reg-v1-02.txt Thread-Index: AQD42VEWs34D4+z9B0tpDAs9zVMEAZYgIoMggAL7GXA= Message-ID: References: <20110502160002.29594.25481.idtracker@ietfa.amsl.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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsUixG6novsh+aCvQWsHm8XJt6/YHBg9liz5 yRTAGMVtk5RYUhacmZ6nb5fAnXHuvGNBg3DFqonbWRoYF/B3MXJySAiYSBx7PYkVwhaTuHBv PVsXIxeHkMA+Ronpj2cxQzhXGCWerD/BCOG8ZJT4+LKRBcLZwihx7MxEVginn1Hi7dL5LCDD 2AQ0JM793ssOYosI6Eqs/tQLZrMIqEh0PzjCCGILC5hKHN49A6rGTKLnyS1GCNtKYsL1GUwg Nq9AgETrlB1QqzsYJbourAdr4BQIlDi08wEbiM0IdPn3U2vAGpgFxCVuPZnPBPGRoMSi2XuY Yb77t+shVL2oxJ329YwQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExglZiEZOwtJyywkLbOQ tCxgZFnFKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokRHHUuSjsYfx5UOsQowMGo xMP7LumgrxBrYllxZe4hRkkOJiVR3tVxQCG+pPyUyozE4oz4otKc1OJDjBIczEoivE0WQDne lMTKqtSifJiUNAeLkjjvHEl1XyGB9MSS1OzU1ILUIpisDAeHkgSvNzC5CAkWpaanVqRl5pQg pJk4OEEEF8gGHqANdYkgG4oLEnOLM9Mhik4xKkqJ8/4EuVQAJJFRmgc3AJYeXzGKA/0jzKsF socHmFrhul8BDWYCGuzVfABkcEkiQkqqgbHD1+fizI58YZ51hZ2fTW3DA7etYd7w6lhq/5me 98+Cry29zs29i+PPWatf2XZBdj2fBd/3z83P0eEy1d3n+He9/9wVjLnLljooKQu/+rf+/HX5 XTOlHGWL1igHfn/z3ol35Z+DLtqxPk/WajeU3ntwdf9mSc0P8q2yvI+DfX686LRkLE9Y1KXE UpyRaKjFXFScCACQl+G+agMAAA== Subject: Re: [OAUTH-WG] I-D Action:draft-oauth-dyn-reg-v1-02.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: Wed, 04 May 2011 14:34:24 -0000 FYI folks, I renamed the draft to draft-hardjono-oauth-dynreg-00.txt for consistency w= ith IETF naming of drafts. /thomas/ _________________________ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : OAuth Dynamic Client Registration Protocol Author(s) : T. Hardjono, et al. Filename : draft-hardjono-oauth-dynreg-00.txt Pages : 20 Date : 2011-05-03 This specification proposes an OAuth Dynamic Client Registration protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-dynreg-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft __________________________________________ > -----Original Message----- > From: Thomas Hardjono > Sent: Monday, May 02, 2011 1:05 PM > To: oauth (oauth@ietf.org) > Cc: Thomas Hardjono > Subject: FW: I-D Action:draft-oauth-dyn-reg-v1-02.txt >=20 > FYI Folks, >=20 > This is an update of the Dynamic Client Registration Protocol draft. > The previous version (draft-01) expired in Feb. >=20 > Thanks. >=20 > /thomas/ >=20 > ________________________________ >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, May 02, 2011 12:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-oauth-dyn-reg-v1-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : OAuth Dynamic Client Registration Protocol > Author(s) : T. Hardjono, et al. > Filename : draft-oauth-dyn-reg-v1-02.txt > Pages : 20 > Date : 2011-05-02 >=20 > This specification proposes an OAuth Dynamic Client Registration > protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-oauth-dyn-reg-v1-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From eran@hueniverse.com Wed May 4 07: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 91B50E0762 for ; Wed, 4 May 2011 07:46:21 -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=[AWL=-0.000, 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 JYKqpd6NZYxN for ; Wed, 4 May 2011 07:46: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 8730BE0754 for ; Wed, 4 May 2011 07:46:20 -0700 (PDT) Received: (qmail 3531 invoked from network); 4 May 2011 14:46:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 May 2011 14:46:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 4 May 2011 07:46:11 -0700 From: Eran Hammer-Lahav To: Alex Henderson , Marcus Better Date: Wed, 4 May 2011 07:45:38 -0700 Thread-Topic: [OAUTH-WG] delegated authentication with OAuth 2.0 Thread-Index: AcwKXhnXIHohtHwfTvCUl0VvBESgqwAC2xGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344757F91A46@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DC145C2.1050806@better.se> 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_90C41DD21FB7C64BB94121FBBC2E72344757F91A46P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 May 2011 14:46:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72344757F91A46P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The way we do it is by having the user authenticate through the mobile app = with the app server (using an embedded browser). The app server presents th= e Facebook/Twitter/Yahoo login buttons and handles the authentication. Afte= r that, the app server issues the mobile app its own access token and saves= the social network access token on the server. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= lex Henderson Sent: Wednesday, May 04, 2011 6:18 AM To: Marcus Better Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0 Though not OAuth 2.0 - the scenario you're describing sounds very close to = that of an OpenSocial gadgets implementation - where by the open social con= tainer (which would be Analogous to your App Server) can handle relaying re= quests to a 3rd party API secured via OAuth - in which case it is both an O= Auth provider and OAuth consumer. Might pay to check out the OpenSocial spec, might give you some food for th= ought. Cheers, Alex On Thu, May 5, 2011 at 12:25 AM, Marcus Better > wrote: Hi, we are implementing a service that will allow users sign in using their account on an external OAuth 2.0 provider (a certain well-known social network). But there is a twist: my service consists of a mobile app and a web service. The mobile app needs to authenticate its user to the app server, so it can access our service API and user data. So we have the following parties: * Mobile App - used by end users * App Server - provides services to the Mobile App * Provider - OAuth 2.0 provider where users have accounts * End User holding accounts on both the Provider and App Server. The requirements are: (A) Authenticate the Mobile App to the App Server (on behalf of the end user) to access the user data on the App Server. To simplify for end users, they should log in using their Provider account (without separate credentials for the App Sever). (B) Allow the Mobile App to access the user's protected resources at the Provider. (Of course we do not consider the bad solution of asking for the user's Provider credentials, but want to use OAuth instead.) Point (B) is covered by standard OAuth 2.0. Point (A), however, is surprisingly tricky (to me at least). I do not know of a published OAuth flow that solves it. Is there a standard way to do this? So we figured out several ways to solve this, but I'm not sure if any of them are ideal. I'll list a few here. * Let the Mobile App authenticate with the Provider with the OAuth dance, and then send the access token to the App Server. The App Server will validate the access token, use it to identify the authenticating user, and return a token (the same or a new one) that is authorized to access its protected resources. This essentially means the App Server should be an OAuth provider itself (or some simplified version of it). The exchange of a Provider token for an App Server token would be accomplished with a special grant type. The only tricky point is how the App Server can validate the Provider token. It seems it will have to access the Provider using the token, and check that it succeeds. I don't like this much, because an attacker could send lots of authentication requests to the App Server with faked "Provider" access tokens, and the App Server would have to perform a transaction with the Provider each time to verify the token, which could be expensive. It would be preferable if the access token could be validated off-line. But I don't see that OAuth provides this capability. * Another variation would start an OAuth dance from the client, but use an authorization endpoint on the App Server, which would immediately redirect to the Provider's authorization endpoint with the redirect_url pointing back to the App Server, and finally redirect back to the client. In this way the App Server inserts itself into the redirect chain, and proxies the authentication request. It gets the access token and passes it on to the client, along with any app-specific extra parameters. From the Mobile App point of view, it uses a regular OAuth flow with some special endpoints and parameters. There are other variations on this using different redirect sequences. Or maybe there is an entirely different solution? Cheers, Marcus _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72344757F91A46P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The way w= e do it is by having the user authenticate through the mobile app with the = app server (using an embedded browser). The app server presents the Faceboo= k/Twitter/Yahoo login buttons and handles the authentication. After that, t= he app server issues the mobile app its own access token and saves the soci= al network access token on the server.

     

    EHL<= o:p>

     

    From: oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] On Behalf Of Alex Henderson
    Sent:<= /b> Wednesday, May 04, 2011 6:18 AM
    To: Marcus Better
    Cc: oauth@ietf.org
    Subject: Re: [OAUTH-WG] delegated authenticatio= n with OAuth 2.0

     

    Though not OAuth 2.0 - the scenario y= ou're describing sounds very close to that of an OpenSocial gadgets impleme= ntation - where by the open social container (which would be Analogous=  to your App Server) can handle relaying requests to a 3rd party API s= ecured via OAuth - in which case it is both an OAuth provider and OAuth con= sumer.

    Might pay to check out the OpenSocial spec, might give you so= me food for thought.

    Cheers,

     

    Alex

     

    On = Thu, May 5, 2011 at 12:25 AM, Marcus Better <marcus@better.se> wrote:

    Hi,

    we are implementing a service that will allow users sign in usi= ng their
    account on an external OAuth 2.0 provider (a certain well-known= social
    network). But there is a twist: my service consists of a mobile = app and
    a web service. The mobile app needs to authenticate its user to = the app
    server, so it can access our service API and user data.

    S= o we have the following parties:
    * Mobile App - used by end users
    * A= pp Server - provides services to the Mobile App
    * Provider - OAuth 2.0 p= rovider where users have accounts
    * End User holding accounts on both th= e Provider and App Server.

    The requirements are:
    (A) Authenticate= the Mobile App to the App Server (on behalf of the end
    user) to access = the user data on the App Server. To simplify for end
    users, they should = log in using their Provider account (without separate
    credentials for th= e App Sever).

    (B) Allow the Mobile App to access the user's protecte= d resources at the
    Provider.

    (Of course we do not consider the ba= d solution of asking for the user's
    Provider credentials, but want to us= e OAuth instead.)

    Point (B) is covered by standard OAuth 2.0.
    Point (A), however, is surprisingly tricky (to me at least). I do not
    k= now of a published OAuth flow that solves it. Is there a standard way
    to= do this?

    So we figured out several ways to solve this, but I'm not = sure if any of
    them are ideal. I'll list a few here.

    * Let the Mo= bile App authenticate with the Provider with the OAuth
    dance, and then s= end the access token to the App Server. The App Server
    will validate the= access token, use it to identify the authenticating
    user, and return a = token (the same or a new one) that is authorized to
    access its protected= resources.

    This essentially means the App Server should be an OAuth= provider itself
    (or some simplified version of it). The exchange of a P= rovider token for
    an App Server token would be accomplished with a speci= al grant type.

    The only tricky point is how the App Server can valid= ate the Provider
    token. It seems it will have to access the Provider usi= ng the token, and
    check that it succeeds. I don't like this much, becaus= e an attacker
    could send lots of authentication requests to the App Serv= er with faked
    "Provider" access tokens, and the App Server wou= ld have to perform a
    transaction with the Provider each time to verify t= he token, which could
    be expensive. It would be preferable if the access= token could be
    validated off-line. But I don't see that OAuth provides = this capability.

    * Another variation would start an OAuth dance from= the client, but use
    an authorization endpoint on the App Server, which = would immediately
    redirect to the Provider's authorization endpoint with= the redirect_url
    pointing back to the App Server, and finally redirect = back to the
    client. In this way the App Server inserts itself into the r= edirect
    chain, and proxies the authentication request. It gets the acces= s token
    and passes it on to the client, along with any app-specific extr= a
    parameters. From the Mobile App point of view, it uses a regular OAuth=
    flow with some special endpoints and parameters.

    There are other= variations on this using different redirect sequences.

    Or maybe the= re is an entirely different solution?

    Cheers,

    Marcus
    _____= __________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailma= n/listinfo/oauth

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72344757F91A46P3PW5EX1MB01E_-- From jhart@photobucket.com Wed May 4 09:09: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 CE591E0686 for ; Wed, 4 May 2011 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 PnfrX77Aai0G for ; Wed, 4 May 2011 09:09:31 -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 84C61E0684 for ; Wed, 4 May 2011 09:09:30 -0700 (PDT) Received: by iyn15 with SMTP id 15so1336268iyn.31 for ; Wed, 04 May 2011 09:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=photobucket.com; s=google; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=szXnxCDGKUqRgOjCwOhJbbGK1tmfXs5ziRA6T+3kbaM=; b=S38WJRTfIYGAurIJC34xyPTdZ8BQLo5Dfp2NTN7HNUrWX/SmaO7zllLZ8KI+DGHONj RDV3zwvRnb0Pif+jl5Id9Tfpmdg130dEP62BOqHP85Z1pFji2VSLW2VFK8eZPEDkK/zv FeQoF9i6yaY+jFyyXqwhOtqoJsVPDkuJfCSo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=photobucket.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=EDorR6F7JxIleHq2uoGFsSOWp83Wv81h6414Pl5d3eo7WRHYG45iKliJZ2sBxnrE9z OahN+Z0CAcfBVFuWCj1sayGHvtqTQzLBHU9B+Y/OPgTrarbL7qZBk+lARu54Vl3tvXeh 4CAsp3NMCuvrJdkJ9w1ixFMj01AuuqeAUqspI= Received: by 10.42.133.66 with SMTP id g2mr1680473ict.388.1304525369805; Wed, 04 May 2011 09:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.77 with HTTP; Wed, 4 May 2011 09:09:09 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344757F91A46@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DC145C2.1050806@better.se> <90C41DD21FB7C64BB94121FBBC2E72344757F91A46@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Justin Hart Date: Wed, 4 May 2011 10:09:09 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba6e85ac448c0104a2757bb3 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 May 2011 16:09:32 -0000 --90e6ba6e85ac448c0104a2757bb3 Content-Type: text/plain; charset=ISO-8859-1 Photobucket does this with both OAuth1 (twitter) and OAuth2/WRAP (facebook, msn messenger) services. In the mobile app, user auth's with Photobucket. To connect to the external provider service, user is redirected to Photobucket to start up a session, then to the provider service to authorize Photobucket's access. The callback here is Photobucket's servers again, where Photobucket stores the tokens, and then redirects again back to the app (url handling) to signal completion. The app can then use an api to check on the status of those services on Photobucket. You can see this in action in the new Snapbucket (Android) app, and in the existing Photobucket mobile apps on both iPhone and Android. The new Twitter oauth screens work a lot better on mobile than they used to. There's a more complicated two-app, two-server (4 legged delegation) situation that gets yet more complicated, but I've got a draft I need to update and submit for that :-) ---- Justin Hart jhart@photobucket.com On Wed, May 4, 2011 at 8:45 AM, Eran Hammer-Lahav wrote: > The way we do it is by having the user authenticate through the mobile app > with the app server (using an embedded browser). The app server presents the > Facebook/Twitter/Yahoo login buttons and handles the authentication. After > that, the app server issues the mobile app its own access token and saves > the social network access token on the server. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Alex Henderson > *Sent:* Wednesday, May 04, 2011 6:18 AM > *To:* Marcus Better > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] delegated authentication with OAuth 2.0 > > > > Though not OAuth 2.0 - the scenario you're describing sounds very close to > that of an OpenSocial gadgets implementation - where by the open social > container (which would be Analogous to your App Server) can handle relaying > requests to a 3rd party API secured via OAuth - in which case it is both an > OAuth provider and OAuth consumer. > > Might pay to check out the OpenSocial spec, might give you some food for > thought. > > Cheers, > > > > Alex > > > > On Thu, May 5, 2011 at 12:25 AM, Marcus Better wrote: > > Hi, > > we are implementing a service that will allow users sign in using their > account on an external OAuth 2.0 provider (a certain well-known social > network). But there is a twist: my service consists of a mobile app and > a web service. The mobile app needs to authenticate its user to the app > server, so it can access our service API and user data. > > So we have the following parties: > * Mobile App - used by end users > * App Server - provides services to the Mobile App > * Provider - OAuth 2.0 provider where users have accounts > * End User holding accounts on both the Provider and App Server. > > The requirements are: > (A) Authenticate the Mobile App to the App Server (on behalf of the end > user) to access the user data on the App Server. To simplify for end > users, they should log in using their Provider account (without separate > credentials for the App Sever). > > (B) Allow the Mobile App to access the user's protected resources at the > Provider. > > (Of course we do not consider the bad solution of asking for the user's > Provider credentials, but want to use OAuth instead.) > > Point (B) is covered by standard OAuth 2.0. > > Point (A), however, is surprisingly tricky (to me at least). I do not > know of a published OAuth flow that solves it. Is there a standard way > to do this? > > So we figured out several ways to solve this, but I'm not sure if any of > them are ideal. I'll list a few here. > > * Let the Mobile App authenticate with the Provider with the OAuth > dance, and then send the access token to the App Server. The App Server > will validate the access token, use it to identify the authenticating > user, and return a token (the same or a new one) that is authorized to > access its protected resources. > > This essentially means the App Server should be an OAuth provider itself > (or some simplified version of it). The exchange of a Provider token for > an App Server token would be accomplished with a special grant type. > > The only tricky point is how the App Server can validate the Provider > token. It seems it will have to access the Provider using the token, and > check that it succeeds. I don't like this much, because an attacker > could send lots of authentication requests to the App Server with faked > "Provider" access tokens, and the App Server would have to perform a > transaction with the Provider each time to verify the token, which could > be expensive. It would be preferable if the access token could be > validated off-line. But I don't see that OAuth provides this capability. > > * Another variation would start an OAuth dance from the client, but use > an authorization endpoint on the App Server, which would immediately > redirect to the Provider's authorization endpoint with the redirect_url > pointing back to the App Server, and finally redirect back to the > client. In this way the App Server inserts itself into the redirect > chain, and proxies the authentication request. It gets the access token > and passes it on to the client, along with any app-specific extra > parameters. From the Mobile App point of view, it uses a regular OAuth > flow with some special endpoints and parameters. > > There are other variations on this using different redirect sequences. > > Or maybe there is an entirely different solution? > > Cheers, > > Marcus > _______________________________________________ > 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 > > --90e6ba6e85ac448c0104a2757bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Photobucket does this with both OAuth1 (twitter) and OAuth2/WRAP (facebook,= msn messenger) services. =A0

    In the mobile app, user au= th's with Photobucket. =A0To connect to the external provider service, = user is redirected to Photobucket to start up a session, then to the provid= er service to authorize Photobucket's access. =A0The callback here is P= hotobucket's servers again, where Photobucket stores the tokens, and th= en redirects again back to the app (url handling) to signal completion. =A0= The app can then use an api to check on the status of those services on Pho= tobucket. =A0You can see this in action in the new Snapbucket (Android) app= , and in the existing Photobucket mobile apps on both iPhone and Android. = =A0The new Twitter oauth screens work a lot better on mobile than they used= to.

    There's a more complicated two-app, two-server (4 l= egged delegation) situation that gets yet more complicated, but I've go= t a draft I need to update and submit for that :-)
    ---- Justin Hart



    On Wed, May 4, 2011 at 8:45 AM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:

    The way we do it is by h= aving the user authenticate through the mobile app with the app server (usi= ng an embedded browser). The app server presents the Facebook/Twitter/Yahoo= login buttons and handles the authentication. After that, the app server i= ssues the mobile app its own access token and saves the social network acce= ss token on the server.

    =A0

    EHL

    =A0

    From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of Alex Henderson
    Sent: Wednesday, May 04, 2011 6:18 AM
    To: Marcus BetterCc: oauth@ietf.= org
    Subject: Re: [OAUTH-WG] delegated authentication with OAu= th 2.0

    =A0

    Though not OAuth 2.0 - the scenario you're desc= ribing sounds very close to that of an OpenSocial gadgets implementation - = where by the open social container (which would be=A0Analogous=A0to your Ap= p Server) can handle relaying requests to a 3rd party API secured via OAuth= - in which case it is both an OAuth provider and OAuth consumer.

    Might pay to check out the OpenSocial spec, might give you some food fo= r thought.

    Cheers,

    =A0

    =

    Alex

    =A0

    On Thu, May 5, 2011 at 12:25 AM, Marcus Better <marcus@better.se> wrote:

    Hi,

    we are implementing a service that will allow use= rs sign in using their
    account on an external OAuth 2.0 provider (a certain well-known social
    n= etwork). But there is a twist: my service consists of a mobile app and
    a= web service. The mobile app needs to authenticate its user to the app
    server, so it can access our service API and user data.

    So we have t= he following parties:
    * Mobile App - used by end users
    * App Server -= provides services to the Mobile App
    * Provider - OAuth 2.0 provider whe= re users have accounts
    * End User holding accounts on both the Provider and App Server.

    The= requirements are:
    (A) Authenticate the Mobile App to the App Server (on= behalf of the end
    user) to access the user data on the App Server. To s= implify for end
    users, they should log in using their Provider account (without separatecredentials for the App Sever).

    (B) Allow the Mobile App to access = the user's protected resources at the
    Provider.

    (Of course we= do not consider the bad solution of asking for the user's
    Provider credentials, but want to use OAuth instead.)

    Point (B) is c= overed by standard OAuth 2.0.

    Point (A), however, is surprisingly tr= icky (to me at least). I do not
    know of a published OAuth flow that solv= es it. Is there a standard way
    to do this?

    So we figured out several ways to solve this, but I'= m not sure if any of
    them are ideal. I'll list a few here.

    * = Let the Mobile App authenticate with the Provider with the OAuth
    dance, = and then send the access token to the App Server. The App Server
    will validate the access token, use it to identify the authenticating
    us= er, and return a token (the same or a new one) that is authorized to
    acc= ess its protected resources.

    This essentially means the App Server s= hould be an OAuth provider itself
    (or some simplified version of it). The exchange of a Provider token foran App Server token would be accomplished with a special grant type.
    The only tricky point is how the App Server can validate the Provider
    token. It seems it will have to access the Provider using the token, andcheck that it succeeds. I don't like this much, because an attackercould send lots of authentication requests to the App Server with faked "Provider" access tokens, and the App Server would have to perfor= m a
    transaction with the Provider each time to verify the token, which c= ould
    be expensive. It would be preferable if the access token could be validated off-line. But I don't see that OAuth provides this capability= .

    * Another variation would start an OAuth dance from the client, bu= t use
    an authorization endpoint on the App Server, which would immediate= ly
    redirect to the Provider's authorization endpoint with the redirect_url=
    pointing back to the App Server, and finally redirect back to the
    cl= ient. In this way the App Server inserts itself into the redirect
    chain,= and proxies the authentication request. It gets the access token
    and passes it on to the client, along with any app-specific extra
    parame= ters. From the Mobile App point of view, it uses a regular OAuth
    flow wi= th some special endpoints and parameters.

    There are other variations= on this using different redirect sequences.

    Or maybe there is an entirely different solution?

    Cheers,
    Marcus
    _______________________________________________
    OAuth mailing= list
    OAuth@ietf.org=
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    =A0


    ______________________________= _________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth


    --90e6ba6e85ac448c0104a2757bb3-- From marcus@better.se Wed May 4 11:36: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 E4772E0795 for ; Wed, 4 May 2011 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=1.110, 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 EdztB-J7-i96 for ; Wed, 4 May 2011 11:36:37 -0700 (PDT) Received: from vips.better.se (vips.better.se [79.99.3.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2770CE0700 for ; Wed, 4 May 2011 11:36:36 -0700 (PDT) Received: from [192.168.100.11] (109.58.105.29.bredband.tre.se [109.58.105.29]) by vips.better.se (Postfix) with ESMTPSA id E6FD420EC096; Wed, 4 May 2011 20:36:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=better.se; s=mail; t=1304534192; bh=SOUI1E0UnzRYI4ZaewGsTgsOy8nB3GHVeFg+j7U1l+I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HoA6HZN3LpRwGPUBZOO+HPRKaYBKDsZWGG7GesmNteA4FvHYzWnBF7unAvelh1AJl 0We/D39JsTbo85PMoCVMtxy9477F/xZUDmmQTzGUa2zPerW3ZMbBQQ3wbXbb6mXnbG BhXvDVkwp/y+ipG0R2TMjskq7DGtTTo/kYKE7u7A= Message-ID: <4DC19CAB.3080805@better.se> Date: Wed, 04 May 2011 20:36:27 +0200 From: Marcus Better User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: Justin Hart References: <4DC145C2.1050806@better.se> <90C41DD21FB7C64BB94121FBBC2E72344757F91A46@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 May 2011 18:36:38 -0000 Thank you all for your advice, that was very helpful. The general pattern seems to be similar to what I had in mind. It would really help to have this documented properly. I would think it is an increasingly common scenario. Cheers, Marcus From peter.wolanin@acquia.com Wed May 4 20:53: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 6D8E7E0681 for ; Wed, 4 May 2011 20:53:58 -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 dZapguzkGHcT for ; Wed, 4 May 2011 20:53:57 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with SMTP id B528AE0618 for ; Wed, 4 May 2011 20:53:55 -0700 (PDT) Received: from mail-ww0-f45.google.com ([74.125.82.45]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcIfU6GCi7YDWuDjQwSMOFUJmatSKcx2@postini.com; Wed, 04 May 2011 20:53:56 PDT Received: by wwi36 with SMTP id 36so1644622wwi.26 for ; Wed, 04 May 2011 20:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.64.139 with SMTP id c11mr5784367wed.46.1304567633766; Wed, 04 May 2011 20:53:53 -0700 (PDT) Received: by 10.216.20.212 with HTTP; Wed, 4 May 2011 20:53:53 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344656743AB6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743AB6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 4 May 2011 23:53:53 -0400 Message-ID: From: Peter Wolanin To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth v2 Mac token 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, 05 May 2011 03:53:58 -0000 Can you give an example of a setup where the hash cannot be calculated? I think to be secure, the question of whether or not the body hash must be included in the request should be specified in 2. Issuing MAC Credentials For example, as an added aspect of the algorithm, or a separate parameter. Essentially something like bodyhash: required, versus bodyhash: optional? Obviously it should be omitted if there is no body (e.g. for a GET request). By including it in #2, it's certainly clear that some clients that cannot generate the body hash could not authenticate with any servers that require it, but at least this would be known in advance. As a side note, we currently interact with or maintain several services which use HMAC auth and in one case (a spam blocking service) the inclusion of the message content in the HMAC (similar to using the body hash) is omitted in favor of simply doing a HMAC over the URL nonce and time since the consequence of a MITM attack is relatively unimportant. -Peter On Mon, Apr 11, 2011 at 7:21 PM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: Peter Wolanin [mailto:peter.wolanin@acquia.com] >> Sent: Sunday, February 27, 2011 6:59 AM > >> I was a little unclear in the spec whether the client can choose not to = include >> the body hash in the signature. =C2=A0I'd hope that the spec ends up cle= arly >> requiring the client to always send it even if a given server may or may= not >> validate the body hash. =C2=A0Our current implementations include the bo= dy >> directly in the HMAC calculation, but considering your current draft I >> appreciate the extra flexibility provided by signing over the body hash = rather >> than the body itself. > > Yes, we need to figure out when the client is required to include it. The= issue is that in some deployments, it is not possible for the client to ca= lculate this value at the point where the header is set. > >> A downside to the MAC spec for OAuth2 is, as far as I can see, you have = to >> send your client secret in the request if you ever need to refresh your = OAuth >> token? =C2=A0I see in some recent messages liek http://www.ietf.org/mail= - >> archive/web/oauth/current/msg05214.html=C2=A0 some discussion that sugge= sts >> I'm mistaken? > > Nope. Refresh does not require the access token or its secret. Just the r= efresh code. > >> Also, as stated in section 7.3, there seems to be no provision for ensur= ing >> response authenticity except relying on SSL. We have been using protocol= s >> that include in the response an HMAC of the response body calculated to >> include the client-supplied nonce. =C2=A0Obviously one could add such a = response >> header without breaking the protocol, but I'd like to see an option in t= he >> MAC credentials an added field that specifies whether the server is expe= cted >> to provide such a response HMAC and a standardized name and construction >> for such a response header. > > I will add this later, once the current bits are stable. > > EHL > --=20 Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac= quia. Inc. peter.wolanin@acquia.com : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" From barryleiba.mailing.lists@gmail.com Fri May 6 07:22: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 A23EEE06D4 for ; Fri, 6 May 2011 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 wvuH-CTE-NbA for ; Fri, 6 May 2011 07:22:39 -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 E1DB7E06BA for ; Fri, 6 May 2011 07:22:38 -0700 (PDT) Received: by yic13 with SMTP id 13so1439350yic.31 for ; Fri, 06 May 2011 07:22:38 -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=xoS9quVBzek08reLVyrdf4p488g3ZLfEgEIOW+Dk4jc=; b=FqdDanF1KcGKC7HX7rSLko2eaQCZ2yDjIJPKhtvn0w0AnzbpRZEhzR4nNOklMTlxUC /V+Px1G+M1h0rZHz4ePeJd8xq0ZG7V1RiSzrLAf1FeIBxyo4HaXQqucayRbo+47f6OLE PcGeRN4NJ5hvb4WQRB/LLc/bRLaRDoMX0SSA0= 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=FB0abFUz+oNc1dZBiREoUcjBEqb4wYGVgjJw/G49tw+zcn0BCixfG9db2c8cE5QxCy 5ps+fGX4btJ6SvbbBxjfW2X57NHUTbyMDt0fmh+X7bM1gYhjesAwCgR+4mmNOOSV/cTF 2m8Skwf2Y0xJkLmnFtnBEDa//6Hgb9tBzaNkc= MIME-Version: 1.0 Received: by 10.236.154.199 with SMTP id h47mr4940542yhk.149.1304691757643; Fri, 06 May 2011 07:22:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Fri, 6 May 2011 07:22:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2011 10:22:37 -0400 X-Google-Sender-Auth: gWYGw864uUSwiePikKjW_QPjrag 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] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 06 May 2011 14:22:39 -0000 > #8 =A0 =A0 =A04.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code > http://trac.tools.ietf.org/wg/oauth/trac/ticket/8 > > #9 =A0 =A0 =A05.2, text for non-400 & 401 error conditions > http://trac.tools.ietf.org/wg/oauth/trac/ticket/9 I will close these later today, as I said in my original note: http://www.ietf.org/mail-archive/web/oauth/current/msg06211.html There have been no objections, nor other comments. > #10 =A0 =A0 8.4. Defining Additional Error Codes > http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 I will leave this open for the moment, and consider closing after there's some response to Alexey's comment: http://www.ietf.org/mail-archive/web/oauth/current/msg06225.html Eran, do you have any comment on what Alexey suggests (I agree, as a participant, with the suggestion to use the ACAP vendor registry)? > #12 Restore WWW-Authenticate response to the framework > specification > http://trac.tools.ietf.org/wg/oauth/trac/ticket/12 Tony has suggested closing this: http://www.ietf.org/mail-archive/web/oauth/current/msg06228.html As he and Mike were the chief supporters of this, with their objection removed it should be ready to close as well. I'll leave it open for a few more days, and close it early next week if there are no objections by then. Barry, as chair From trac+oauth@trac.tools.ietf.org Fri May 6 07:24: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 DD558E06EF for ; Fri, 6 May 2011 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 eYcBR8XmY-wo for ; Fri, 6 May 2011 07:24:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 57473E06BA for ; Fri, 6 May 2011 07:24:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QILwz-0002qF-Tf; Fri, 06 May 2011 07:24:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Fri, 06 May 2011 14:24:13 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/oauth/trac/ticket/10#comment:3 Message-ID: <066.7292736827211fb5d01a05d3852ee0cf@trac.tools.ietf.org> References: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <057.27a13fb0813ce1eff49107833d51ba4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:24:17 -0000 #10: 8.4. Defining Additional Error Codes Comment(by barryleiba@…): Comment from Alexey: I am wondering if the ACAP vendor name registry (RFC 6075), the OID vendor names, or DNS names can be recommended for the prefix (to satisfy the "SHOULD be prefixed by an identifying name when possible" requirement)? -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: oauth From eran@hueniverse.com Fri May 6 07:42: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 A9A37E06EA for ; Fri, 6 May 2011 07:42:24 -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.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 Fy5Xyf194nVp for ; Fri, 6 May 2011 07:42:24 -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 2D274E06DD for ; Fri, 6 May 2011 07:42:24 -0700 (PDT) Received: (qmail 19013 invoked from network); 6 May 2011 14:42:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 May 2011 14:42:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 6 May 2011 07:42:17 -0700 From: Eran Hammer-Lahav To: Alexey Melnikov , Barry Leiba Date: Fri, 6 May 2011 07:41:40 -0700 Thread-Topic: [OAUTH-WG] Closing a few issues Thread-Index: AcwJg8Yl5YAoFXN7SqSdzppysqZf2ACdukUQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DBFE422.5090105@isode.com> In-Reply-To: <4DBFE422.5090105@isode.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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 06 May 2011 14:42:24 -0000 Hi Alexey, > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Alexey Melnikov > Sent: Tuesday, May 03, 2011 4:17 AM > >#10 8.4. Defining Additional Error Codes > >http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 > > > > > This is mostly fine, but I am wondering if the ACAP vendor name registry = (RFC > 6075), the OID vendor names, or DNS names can be recommended for the > prefix (to satisfy the "SHOULD be prefixed by an identifying name when > possible" requirement)? I don't find this particularly helpful. The main reason for allowing this kind of extensibility is to align the pro= tocol with common practice which is to add vendor specific parameters witho= ut registration. Expecting vendors (and there are going to be hundreds of t= hem, unlike the handful of companies in the ACAP registry) to follow anothe= r registry (especially one like ACAP) is just not practical for this partic= ular use case. Also, given that we are talking about URI query parameters which tend to be= short, using DNS names is unlikely to win much adoption. Reality is, there= are already plenty of such parameters deployed with OAuth 1.0 and 2.0 draf= ts. I think we have a good balance now between promoting interoperability and s= haring of ideas (new parameters) and allowing vendors to quickly deploy pra= ctical solutions that reflect how they do business today. It took us a whil= e to get to this balance. I would like to ask the chairs to close this issue with no additional chang= es. EHL From barryleiba@gmail.com Fri May 6 08:08: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 3B59FE072B for ; Fri, 6 May 2011 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 woPke155o1tB for ; Fri, 6 May 2011 08:08: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 A03C2E0707 for ; Fri, 6 May 2011 08:08:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so1506780gxk.31 for ; Fri, 06 May 2011 08:08:22 -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; bh=ioZtW7gFS+QqZbeTVuVavYsbCXrSL1bZjPlcqubpZ7o=; b=mPsQ2BOvrexqBs53wmLec5ob3dHGfiw23TzZFSY6YYNx+U/CcZ862tiKOysbdY6euN P6hgutvNlg5VpLk/4OdpHKJUyT5jWbTe6qMf6eW1bAiEV/CTrtC7KpCvTKrzjFbaqanV asxk1qqqLs4GvF7IFkcYz3uRiRBvFKmTJK3qs= 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; b=jGWw3WYwdQ45dgWZgw8BWtA3S0UwXJSsBlLZoIMCSIPi3W+Wu1Md0pOd4Y9wwea2uB vWhrGbZbHAMidDM0dc/Ncc3rkODGcWTxnXVmDNlcTbYRzvbwlNK5oelMLWtTuHRghLJO dDSvPCIHjnNVK+HhsDW+bUo1JcfM9nxHbH0zE= MIME-Version: 1.0 Received: by 10.236.119.212 with SMTP id n60mr4592385yhh.263.1304694502070; Fri, 06 May 2011 08:08:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.110.140 with HTTP; Fri, 6 May 2011 08:08:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DBFE422.5090105@isode.com> <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 6 May 2011 11:08:21 -0400 X-Google-Sender-Auth: SHPr3_8HOnCGDjwCSJJvRfn62n0 Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 06 May 2011 15:08:23 -0000 >> This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC >> 6075), the OID vendor names, or DNS names can be recommended for the >> prefix (to satisfy the "SHOULD be prefixed by an identifying name when >> possible" requirement)? ... > The main reason for allowing this kind of extensibility is to align the protocol > with common practice which is to add vendor specific parameters without > registration. Expecting vendors (and there are going to be hundreds of > them, unlike the handful of companies in the ACAP registry) to follow > another registry (especially one like ACAP) is just not practical for this > particular use case. > > Also, given that we are talking about URI query parameters which tend > to be short, using DNS names is unlikely to win much adoption. Reality > is, there are already plenty of such parameters deployed with OAuth > 1.0 and 2.0 drafts. Makes sense. > I would like to ask the chairs to close this issue with no additional changes. I think that's right. Alexey, any further objection or comment? Barry, as chair From alexey.melnikov@isode.com Sat May 7 03:15: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 3513EE06C8 for ; Sat, 7 May 2011 03:15:07 -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 df5XvONN8Lm0 for ; Sat, 7 May 2011 03:15:06 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2E243E067C for ; Sat, 7 May 2011 03:15:06 -0700 (PDT) Received: from [188.29.43.244] (188.29.43.244.threembb.co.uk [188.29.43.244]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 7 May 2011 11:15:03 +0100 Message-ID: <4DC51B9B.2030005@isode.com> Date: Sat, 07 May 2011 11:14:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eran Hammer-Lahav References: <4DBFE422.5090105@isode.com> <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 07 May 2011 10:15:07 -0000 Eran Hammer-Lahav wrote: >Hi Alexey, > > >>-----Original Message----- >>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>Of Alexey Melnikov >>Sent: Tuesday, May 03, 2011 4:17 AM >> >> >>>#10 8.4. Defining Additional Error Codes >>>http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 >>> >>> >>This is mostly fine, but I am wondering if the ACAP vendor name registry (RFC >>6075), the OID vendor names, or DNS names can be recommended for the >>prefix (to satisfy the "SHOULD be prefixed by an identifying name when >>possible" requirement)? >> >> >I don't find this particularly helpful. > >The main reason for allowing this kind of extensibility is to align the protocol with common practice which is to add vendor specific parameters without registration. Expecting vendors (and there are going to be hundreds of them, unlike the handful of companies in the ACAP registry) to follow another registry (especially one like ACAP) is just not practical for this particular use case. > Sorry, I don't find your argument to be convincing at all. Both the ACAP vendor registry (really, the name is historic, it is used for other things now and is independent of ACAP) and the PEN (Private Enterprise Numbers in OIDs) are first come first serve, so a registration only requires sending an email asking for a new value. >Also, given that we are talking about URI query parameters which tend to be short, using DNS names is unlikely to win much adoption. Reality is, there are already plenty of such parameters deployed with OAuth 1.0 and 2.0 drafts. > > I can possibly agree with this point. >I think we have a good balance now between promoting interoperability and sharing of ideas (new parameters) and allowing vendors to quickly deploy practical solutions that reflect how they do business today. It took us a while to get to this balance. > > If you say that prefixes should be used and don't state how this can be achieved, than what is the point of saying that prefixes should be used? Surely prefixes should be unique and any sort of registry is going to guaranty uniqueness. >I would like to ask the chairs to close this issue with no additional changes. > > From eran@hueniverse.com Sat May 7 09:44: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 6B11BE06FA for ; Sat, 7 May 2011 09:44:57 -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.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 XkvC2sKbPM7d for ; Sat, 7 May 2011 09:44:56 -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 813B1E0682 for ; Sat, 7 May 2011 09:44:56 -0700 (PDT) Received: (qmail 32355 invoked from network); 7 May 2011 16:38:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 May 2011 16:38:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 7 May 2011 09:38:13 -0700 From: Eran Hammer-Lahav To: Alexey Melnikov Date: Sat, 7 May 2011 09:37:35 -0700 Thread-Topic: [OAUTH-WG] Closing a few issues Thread-Index: AcwMn6OvIMiBRkEnQYW3ihln41tRmgANHrsQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA677@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DBFE422.5090105@isode.com> <90C41DD21FB7C64BB94121FBBC2E72344757F91F28@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC51B9B.2030005@isode.com> In-Reply-To: <4DC51B9B.2030005@isode.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 Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] Closing a few issues X-BeenThere: oauth@ietf.org X-Mailman-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, 07 May 2011 16:44:57 -0000 Collision between vendor-specific parameters is not a concern or something = we want to address. All we want to avoid is collision between a vendor-spec= ific parameter and a future registered extension parameter. This is why we = recommend a vendor-specific prefix. As long as there is a prefix, we've avo= ided the issue. An endpoint should never have more than one vendor-specific= extensions since then it is no longer vendor-specific and should be regist= ered without a prefix. As for the ease of getting a registration, you still need to go and read an= other RFC about how to make the request, send an email to a list, and follo= w up on that. And all that for adding parameters to an endpoint you control= , and do not have to interoperate with anyone else other than your own clie= nts. So I don't see a point in adding such a requirement. EHL > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Saturday, May 07, 2011 3:15 AM > To: Eran Hammer-Lahav > Cc: Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] Closing a few issues >=20 > Eran Hammer-Lahav wrote: >=20 > >Hi Alexey, > > > > > >>-----Original Message----- > >>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >>Of Alexey Melnikov > >>Sent: Tuesday, May 03, 2011 4:17 AM > >> > >> > >>>#10 8.4. Defining Additional Error Codes > >>>http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 > >>> > >>> > >>This is mostly fine, but I am wondering if the ACAP vendor name > >>registry (RFC 6075), the OID vendor names, or DNS names can be > >>recommended for the prefix (to satisfy the "SHOULD be prefixed by an > >>identifying name when possible" requirement)? > >> > >> > >I don't find this particularly helpful. > > > >The main reason for allowing this kind of extensibility is to align the = protocol > with common practice which is to add vendor specific parameters without > registration. Expecting vendors (and there are going to be hundreds of th= em, > unlike the handful of companies in the ACAP registry) to follow another > registry (especially one like ACAP) is just not practical for this partic= ular use > case. > > > Sorry, I don't find your argument to be convincing at all. >=20 > Both the ACAP vendor registry (really, the name is historic, it is used f= or other > things now and is independent of ACAP) and the PEN (Private Enterprise > Numbers in OIDs) are first come first serve, so a registration only requi= res > sending an email asking for a new value. >=20 > >Also, given that we are talking about URI query parameters which tend to > be short, using DNS names is unlikely to win much adoption. Reality is, t= here > are already plenty of such parameters deployed with OAuth 1.0 and 2.0 > drafts. > > > > > I can possibly agree with this point. >=20 > >I think we have a good balance now between promoting interoperability > and sharing of ideas (new parameters) and allowing vendors to quickly > deploy practical solutions that reflect how they do business today. It to= ok us > a while to get to this balance. > > > > > If you say that prefixes should be used and don't state how this can be > achieved, than what is the point of saying that prefixes should be used? > Surely prefixes should be unique and any sort of registry is going to gua= ranty > uniqueness. >=20 > >I would like to ask the chairs to close this issue with no additional ch= anges. > > > > From barryleiba.mailing.lists@gmail.com Sun May 8 15:57: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 7A721E07AA for ; Sun, 8 May 2011 15:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.321 X-Spam-Level: X-Spam-Status: No, score=-103.321 tagged_above=-999 required=5 tests=[AWL=-0.344, 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 Dd1pYx9621GZ for ; Sun, 8 May 2011 15:57:26 -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 A7E21E0684 for ; Sun, 8 May 2011 15:57:26 -0700 (PDT) Received: by gyf3 with SMTP id 3so2077903gyf.31 for ; Sun, 08 May 2011 15:57:25 -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; bh=Jso36ILA2Sap7726R+t/2k4uQHPFMGGSjyi0cKlpFiM=; b=h2yEKYFzBTVm712ju19/+JyyJDlLWIIcwnlPJs1u2VEnbotik8u4wMfs4pPq/ySL0x Rpn7wX1JV4t28REpzmDs66bxvUpiGPwwe0AgeQQOypvh3nOoxSATedjZ7f+TbCNwoo7H eYqbtDbVSKErx87eWKQLOzQzs2lLv3HJF+kjw= 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; b=WYp/MRx5FWsquTR3jjV/GCqHdJq3NZRvWQAcj5uMk/WuYv/VwqnVZTceLqmy96//e4 jIw6gXZ729XQ3Boczqcrjmw8c3ByKXuwaI/tEcwT3R/OtZCg2Wiryukc8N1MLdvvXh8J lUFYhZbnVs/qalQ/YX0/tcvTAW2BZ1C0P9tNE= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr6833789yhn.15.1304895063156; Sun, 08 May 2011 15:51:03 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Sun, 8 May 2011 15:51:03 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 May 2011 18:51:03 -0400 X-Google-Sender-Auth: ErAYmZuVp4pzEHx6b_YcosuRNJc Message-ID: From: Barry Leiba To: oauth@ietf.org Content-Type: multipart/mixed; boundary=20cf303f6496b5694104a2cb8ed3 Cc: oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 08 May 2011 22:57:27 -0000 --20cf303f6496b5694104a2cb8ed3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've had a week and a half for comment, and there've been no significant suggestions for changes to the charter proposal, so I'm going to ask the ADs to take the attached charter to the IESG for approval. Igor suggested a change here, making it "supports" instead of "consists of"= : > OAuth consists of > * a mechanism for a user to authorize issuance of credentials that > =A0a third party can use to access resources on the user's behalf and > * a mechanism for using the issued credentials to authenticate > =A0HTTP requests. That doesn't strike me as right, but I see why "consists of" might not read quite right. I think "encompasses" gets the sense that these two mechanisms are part of OAuth (a sense that "supports" doesn't give), while allowing it to be more than that ("consists of" feels like it says that OAuth is exactly those two things, and nothing more). So the attached version uses "encompasses" here. Igor also suggested adding the use-cases document to the charter. I suggest we proceed with the charter as it is, and include the use cases immediately after, as the first output of subsequent rechartering. Barry, as chair --20cf303f6496b5694104a2cb8ed3 Content-Type: text/plain; charset=US-ASCII; name="oauth-charter-new-v4.txt" Content-Disposition: attachment; filename="oauth-charter-new-v4.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gngktbf10 RGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cAoKVGhlIE9wZW4gV2ViIEF1dGhlbnRpY2F0aW9u IChPQXV0aCkgcHJvdG9jb2wgYWxsb3dzIGEgdXNlciB0byBncmFudAphIHRoaXJkLXBhcnR5IFdl YiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0aGUgdXNlcidzIHByb3RlY3RlZApyZXNv dXJjZXMsIHdpdGhvdXQgbmVjZXNzYXJpbHkgcmV2ZWFsaW5nIHRoZWlyIGxvbmctdGVybSBjcmVk ZW50aWFscywKb3IgZXZlbiB0aGVpciBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEgcGhvdG8tc2hh cmluZyBzaXRlIHRoYXQgc3VwcG9ydHMKT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVz ZSBhIHRoaXJkLXBhcnR5IHByaW50aW5nIFdlYiBzaXRlIHRvCnByaW50IHRoZWlyIHByaXZhdGUg cGljdHVyZXMsIHdpdGhvdXQgYWxsb3dpbmcgdGhlIHByaW50aW5nIHNpdGUgdG8KZ2FpbiBmdWxs IGNvbnRyb2wgb2YgdGhlIHVzZXIncyBhY2NvdW50LgoKT0F1dGggZW5jb21wYXNzZXMKKiBhIG1l Y2hhbmlzbSBmb3IgYSB1c2VyIHRvIGF1dGhvcml6ZSBpc3N1YW5jZSBvZiBjcmVkZW50aWFscyB0 aGF0CiAgYSB0aGlyZCBwYXJ0eSBjYW4gdXNlIHRvIGFjY2VzcyByZXNvdXJjZXMgb24gdGhlIHVz ZXIncyBiZWhhbGYgYW5kCiogYSBtZWNoYW5pc20gZm9yIHVzaW5nIHRoZSBpc3N1ZWQgY3JlZGVu dGlhbHMgdG8gYXV0aGVudGljYXRlCiAgSFRUUCByZXF1ZXN0cy4KCkluIEFwcmlsIDIwMTAgdGhl IE9BdXRoIDEuMCBzcGVjaWZjYXRpb24sIGRvY3VtZW50aW5nIHByZS1JRVRGIHdvcmssCndhcyBw dWJsaXNoZWQgYXMgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCAoUkZDIDU4NDkpLiBUaGUgd29y a2luZwpncm91cCBoYXMgc2luY2UgYmVlbiBkZXZlbG9waW5nIE9BdXRoIDIuMCwgYSBzdGFuZGFy ZHMtdHJhY2sgdmVyc2lvbgp0aGF0IHdpbGwgcmVmbGVjdCBJRVRGIGNvbnNlbnN1cy4gIFZlcnNp b24gMi4wIHdpbGwgY29uc2lkZXIgdGhlCmltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugd2l0aCB2 ZXJzaW9uIDEuMCwgYW5kIHdpbGwKKiBpbXByb3ZlIHRoZSB0ZXJtaW5vbG9neSB1c2VkLAoqIGNv bnNpZGVyIGJyb2FkZXIgdXNlIGNhc2VzLAoqIGVtYm9keSBnb29kIHNlY3VyaXR5IHByYWN0aWNl cywKKiBpbXByb3ZlIGludGVyb3BlcmFiaWxpdHksIGFuZAoqIHByb3ZpZGUgZ3VpZGVsaW5lcyBm b3IgZXh0ZW5zaWJpbGl0eS4KClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGV2ZWxvcCBhdXRoZW50 aWNhdGlvbiBzY2hlbWVzIGZvcgpwZWVycy9zZXJ2ZXJzIHRha2luZyBwYXJ0IGluIE9BdXRoIChh Y2Nlc3NpbmcgcHJvdGVjdGVkIHJlc291cmNlcykuIApUaGlzIGluY2x1ZGVzCgoqIGFuIEhNQUMt YmFzZWQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIFt0byB0aGUgZXh0ZW50IHRoYXQgdGhlIApP QXV0aCB3ZyBwcm9kdWNlcyBzcGVjaWZpY2F0aW9ucyB0aGF0IGNvdWxkIGJlIHVzZWQgbW9yZSBn ZW5lcmFsbHkgCmZvciBIVFRQIGF1dGhlbnRpY2F0aW9uLCB0aGUgV0cgd2lsbCB3b3JrIHdpdGgg dGhlIHNlY3VyaXR5IGFuZCAKYXBwbGljYXRpb25zIGFyZWEgZGlyZWN0b3JzIHRvIGVuc3VyZSB0 aGF0IHRoaXMgd29yayBnZXRzIGFwcHJvcHJpYXRlIApyZXZpZXcsIGUuZy4gdmlhIGFkZGl0aW9u YWwgbGFzdCBjYWxscyBpbiBvdGhlciByZWxldmFudCB3b3JraW5nIGdyb3VwcyAKc3VjaCBhcyBo dHRwYmlzXSwKCiogYSBzcGVjaWZpY2F0aW9uIGZvciBhY2Nlc3MgcHJvdGVjdGVkIGJ5IFRyYW5z cG9ydCBMYXllciBTZWN1cml0eSAKKGJlYXJlciB0b2tlbnMpLAoKKiBhbiBleHRlbnNpb24gdG8g T0F1dGggMi4wIHRvIGFsbG93IGFjY2VzcyB0b2tlbnMgdG8gYmUKICByZXF1ZXN0ZWQgd2hlbiBh IGNsaWVudCBpcyBpbiBwb3NzZXNzaW9uIG9mIGEgU0FNTCBhc3NlcnRpb24uCgpBIHNlcGFyYXRl IGluZm9ybWF0aW9uYWwgZGVzY3JpcHRpb24gd2lsbCBiZSBwcm9kdWNlZCB0byBwcm92aWRlCmFk ZGl0aW9uYWwgc2VjdXJpdHkgYW5hbHlzaXMgZm9yIGF1ZGllbmNlcyBiZXlvbmQgdGhlIGNvbW11 bml0eQpwcm90b2NvbCBpbXBsZW1lbnRlcnMuCgpNaWxlc3RvbmVzIHdpbGwgYmUgYWRkZWQgZm9y IHRoZSBsYXRlciBpdGVtcyBhZnRlciB0aGUgbmVhci10ZXJtIHdvcmsKaGFzIGJlZW4gY29tcGxl dGVkLgoKR29hbHMgYW5kIE1pbGVzdG9uZXMKTWF5IDIwMTEgICAgU3VibWl0ICdIVFRQIEF1dGhl bnRpY2F0aW9uOiBNQUMgQXV0aGVudGljYXRpb24nIGFzIGEKd29ya2luZyBncm91cCBpdGVtCgpN YXkgMjAxMSAgICBTdWJtaXQgJ09BdXRoIDIuMCBUaHJlYXQgTW9kZWwgYW5kIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zJwphcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbQoKSnVsIDIwMTEgICAgU3VibWl0 ICdUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gUHJvdG9jb2wnIHRvIHRoZQpJRVNHIGZvciBj b25zaWRlcmF0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQKCkp1bCAyMDExICAgIFN1Ym1pdCAn SFRUUCBBdXRoZW50aWNhdGlvbjogTUFDIEF1dGhlbnRpY2F0aW9uJyB0byB0aGUKSUVTRyBmb3Ig Y29uc2lkZXJhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkCgpBdWcgMjAxMSAgICBTdWJtaXQg J1RoZSBPQXV0aCAyLjAgUHJvdG9jb2w6IEJlYXJlciBUb2tlbnMnIHRvIHRoZQpJRVNHIGZvciBj b25zaWRlcmF0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQKCk9jdCAyMDExICAgIFN1Ym1pdCAn U0FNTCAyLjAgQmVhcmVyIEFzc2VydGlvbiBHcmFudCBUeXBlIFByb2ZpbGUgZm9yCk9BdXRoIDIu MCcgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZAoK Tm92IDIwMTEgICAgUHJlcGFyZSByZS1jaGFydGVyaW5nCg== --20cf303f6496b5694104a2cb8ed3-- From igor.faynberg@alcatel-lucent.com Sun May 8 23:06: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 52E1DE06C7 for ; Sun, 8 May 2011 23:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 xLwkFYFQKwFU for ; Sun, 8 May 2011 23:06:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6E189E068E for ; Sun, 8 May 2011 23:06:55 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p4966qLw015487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 01:06:52 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4966p4F020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2011 01:06:51 -0500 Received: from [135.244.33.85] (faynberg.lra.lucent.com [135.244.33.85]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4966nEV004001; Mon, 9 May 2011 01:06:50 -0500 (CDT) Message-ID: <4DC78477.6020800@alcatel-lucent.com> Date: Mon, 09 May 2011 02:06:47 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Barry Leiba 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter 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, 09 May 2011 06:06:56 -0000 Barry, Thanks for considering my proposals. I am happy with the "encompasses," and I agree that it is better than "supports." I think I don't understand the reason why the use cases are not going to be part of the new charter (or maybe I misunderstood what "subsequent rechartering" means). The idea of establishing a set of OAuth use cases was brought up by Peter at the first OAuth meeting. I liked it very much, because use cases make it a clear way to describe the features, which otherwise are hard or impossible to discern looking at the protocol spec. Furthermore, when a new feature is proposed, starting with a use case sets a good discipline for following up with both the design and testing. (Sure enough, almost every thread dedicated to one ore another OAuth feature includes a question "What is the use case for this?" in at least one posting.) So, we did not exactly do things top-down in OAuth 2.0, even though I personally believe that the present use case spec is ready to be published as Informational, but why would we want to repeat this for the next version of the protocol? With thanks, Igor Barry Leiba wrote: > We've had a week and a half for comment, and there've been no > significant suggestions for changes to the charter proposal, so I'm > going to ask the ADs to take the attached charter to the IESG for > approval. > > Igor suggested a change here, making it "supports" instead of "consists of": > > >> OAuth consists of >> * 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. >> > > That doesn't strike me as right, but I see why "consists of" might not > read quite right. I think "encompasses" gets the sense that these two > mechanisms are part of OAuth (a sense that "supports" doesn't give), > while allowing it to be more than that ("consists of" feels like it > says that OAuth is exactly those two things, and nothing more). So > the attached version uses "encompasses" here. > > Igor also suggested adding the use-cases document to the charter. I > suggest we proceed with the charter as it is, and include the use > cases immediately after, as the first output of subsequent > rechartering. > > Barry, as chair > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Mon May 9 00:58:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB3E07A1 for ; Mon, 9 May 2011 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=3.822, 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 C6xF2xkKF0+P for ; Mon, 9 May 2011 00:58:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 90565E07AC for ; Mon, 9 May 2011 00:58:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p497vqF2003570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 09:57:52 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p497vjRD017307; Mon, 9 May 2011 09:57:50 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 09:57:45 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 11:01:47 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D285991@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Revised Charter thread-index: AcwN01WB5/6ZaZoRRYigF+NcQsSONAAS4MNw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Barry Leiba" , X-OriginalArrivalTime: 09 May 2011 07:57:45.0238 (UTC) FILETIME=[C7E4F360:01CC0E1E] Cc: oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 07:58:14 -0000 Hi Barry,=20 I agree with your points below.=20 As said earlier this charter update is a quick short-term update to have = the webpage updated with information about what we are currently working = on. As requested by Stephen at the last IETF meeting we will recharter = again after we shipped the main specifications (core + bearer/MAC specs) = to the IESG.=20 Ciao Hannes =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of ext Barry Leiba > Sent: Monday, May 09, 2011 1:51 AM > To: oauth@ietf.org > Cc: oauth-ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 > We've had a week and a half for comment, and there've been no > significant suggestions for changes to the charter proposal, so I'm > going to ask the ADs to take the attached charter to the IESG for > approval. >=20 > Igor suggested a change here, making it "supports" instead of=20 > "consists of": >=20 > > OAuth consists of > > * a mechanism for a user to authorize issuance of credentials that > > =A0a third party can use to access resources on the user's behalf = and > > * a mechanism for using the issued credentials to authenticate > > =A0HTTP requests. >=20 > That doesn't strike me as right, but I see why "consists of" might not > read quite right. I think "encompasses" gets the sense that these two > mechanisms are part of OAuth (a sense that "supports" doesn't give), > while allowing it to be more than that ("consists of" feels like it > says that OAuth is exactly those two things, and nothing more). So > the attached version uses "encompasses" here. >=20 > Igor also suggested adding the use-cases document to the charter. I > suggest we proceed with the charter as it is, and include the use > cases immediately after, as the first output of subsequent > rechartering. >=20 > Barry, as chair >=20 From recordond@gmail.com Mon May 9 01:51: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 282ADE06C4 for ; Mon, 9 May 2011 01:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=1.430, 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 eblNJ11+PQUy for ; Mon, 9 May 2011 01:51:00 -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 5FB1EE067E for ; Mon, 9 May 2011 01:51:00 -0700 (PDT) Received: by vxg33 with SMTP id 33so6755259vxg.31 for ; Mon, 09 May 2011 01:50:59 -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=VsheNjxfJc4hU97twa5BEg4bOFs87/JEK5ohvV4KRIM=; b=qm3d8yU9Zh7nFy6DvBKVt7/T8legB2JpgUGwIB7Lt46ppw1liVPVr1HQggvoQaC5Nf Xr5he3cti1nYpwl1hNEIRIVrC9xJGZ0JcPhNV7p7lRaLkBDD/dl1S67UzWT1LSfD1BOG 7DQn83mEcLE5oPu36je05NZmopNPmFYUYPVy0= 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=ChOZoGwp44V3Lv9dziHlXCnCVorwl/gsRv4ymfnf/TjktCHZIlXnZMWG6JIsTSXOLJ 1lECfUxRSrdRDPNWAJm58QBl02pmBOr69BrPP2N3SS/s47sz4yVfV8GFWKNLilH0NfYm 84bHR5K/8lGjGPmUNWCOXoezUMquInRCZ6Zc0= MIME-Version: 1.0 Received: by 10.52.76.198 with SMTP id m6mr7918062vdw.0.1304931059603; Mon, 09 May 2011 01:50:59 -0700 (PDT) Received: by 10.52.187.69 with HTTP; Mon, 9 May 2011 01:50:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2011 01:50:59 -0700 Message-ID: From: David Recordon To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 08:51:01 -0000 Hey Barry, I'm confused. This thread is full of comments. Is there an updated charter which addresses them? On Sun, May 8, 2011 at 3:51 PM, Barry Leiba wrote= : > We've had a week and a half for comment, and there've been no > significant suggestions for changes to the charter proposal, so I'm > going to ask the ADs to take the attached charter to the IESG for > approval. > > Igor suggested a change here, making it "supports" instead of "consists o= f": > >> OAuth consists of >> * a mechanism for a user to authorize issuance of credentials that >> =A0a third party can use to access resources on the user's behalf and >> * a mechanism for using the issued credentials to authenticate >> =A0HTTP requests. > > That doesn't strike me as right, but I see why "consists of" might not > read quite right. =A0I think "encompasses" gets the sense that these two > mechanisms are part of OAuth (a sense that "supports" doesn't give), > while allowing it to be more than that ("consists of" feels like it > says that OAuth is exactly those two things, and nothing more). =A0So > the attached version uses "encompasses" here. > > Igor also suggested adding the use-cases document to the charter. =A0I > suggest we proceed with the charter as it is, and include the use > cases immediately after, as the first output of subsequent > rechartering. > > Barry, as chair > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From hannes.tschofenig@gmx.net Mon May 9 04:17: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 93EFAE068D for ; Mon, 9 May 2011 04:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.369, 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 N8ne2OnrO--p for ; Mon, 9 May 2011 04:17:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 46F6DE06B5 for ; Mon, 9 May 2011 04:17:29 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2011 11:17:28 -0000 Received: from unknown (EHLO [10.255.131.59]) [192.100.123.77] by mail.gmx.net (mp056) with SMTP; 09 May 2011 13:17:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xcO9ExysxnGAK4ZHAlcQC6mWkzlwbDvj+w8sZAI fhIrNX9AF4VeEt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 14:17:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 11:17:31 -0000 On Apr 28, 2011, at 4:01 AM, Eran Hammer-Lahav wrote: >> Nov 2011 Prepare re-chartering >=20 > I would like this removed. >=20 > I would like to see this WG closed when this list is complete and if = there is further work with enough interest, a new working group can be = created. Hi Eran,=20 we already today see interest in doing additional work beyond what is on = the charter. We could remove the explicit item from the charter but we = will definitely call for rechartering after we are done with the = currently chartered items.=20 Ciao Hannes From tonynad@microsoft.com Mon May 9 04:23: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 9247DE06B5 for ; Mon, 9 May 2011 04:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RAND_6=2, 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 INixLc-+Ueq3 for ; Mon, 9 May 2011 04:23:10 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 82092E068D for ; Mon, 9 May 2011 04:23:10 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 04:20:02 -0700 Received: from TX2EHSOBE009.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 9 May 2011 04:20:01 -0700 Received: from mail45-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Mon, 9 May 2011 11:20:01 +0000 Received: from mail45-tx2 (localhost.localdomain [127.0.0.1]) by mail45-tx2-R.bigfish.com (Postfix) with ESMTP id 71E2CC88471 for ; Mon, 9 May 2011 11:19:18 +0000 (UTC) X-SpamScore: -48 X-BigFish: PS-48(zz9371O542M1418M1432N98dKzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT006.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail45-tx2 (localhost.localdomain [127.0.0.1]) by mail45-tx2 (MessageSwitch) id 1304939958179559_27734; Mon, 9 May 2011 11:19:18 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.240]) by mail45-tx2.bigfish.com (Postfix) with ESMTP id 19FA3760053; Mon, 9 May 2011 11:19:18 +0000 (UTC) Received: from CH1PRD0302HT006.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 9 May 2011 11:19:17 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.185]) by CH1PRD0302HT006.namprd03.prod.outlook.com ([10.28.29.125]) with mapi id 14.01.0225.045; Mon, 9 May 2011 11:19:16 +0000 From: Anthony Nadalin To: Hannes Tschofenig , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AQHMBSNjMdtD5WEomUem7JvFmIQRXJRydV+AgBH1roCAAABy4A== Date: Mon, 9 May 2011 11:19:16 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> In-Reply-To: <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT006.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.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 Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 11:23:11 -0000 I think that a re-charter after would be a great idea -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Monday, May 09, 2011 4:17 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org; oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter On Apr 28, 2011, at 4:01 AM, Eran Hammer-Lahav wrote: >> Nov 2011 Prepare re-chartering >=20 > I would like this removed. >=20 > I would like to see this WG closed when this list is complete and if ther= e is further work with enough interest, a new working group can be created. Hi Eran,=20 we already today see interest in doing additional work beyond what is on th= e charter. We could remove the explicit item from the charter but we will d= efinitely call for rechartering after we are done with the currently charte= red items.=20 Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon May 9 04:25: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 38D47E06A6 for ; Mon, 9 May 2011 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 WQWUbq8ZH6Wd for ; Mon, 9 May 2011 04:25:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F31A4E068D for ; Mon, 9 May 2011 04:25:35 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2011 11:25:34 -0000 Received: from unknown (EHLO [10.255.131.59]) [192.100.123.77] by mail.gmx.net (mp066) with SMTP; 09 May 2011 13:25:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lNnIsZWvliuXZHvsl0Dpyj3QafyXC9pYuz5N/9a YmS4QpB8FrJuNO From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 14:25:29 +0300 Message-Id: <037D141A-A81D-44D0-AC58-060DA45ACF98@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Revised OAuth Charter 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: Mon, 09 May 2011 11:25:37 -0000 I did a few minor updates; I believe Barry had missed a few comments in = the version he sent out earlier today.=20 ----=20 Web Authorization Protocol Working Group 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=20 vulnerability (session fixation attack), the use cases and=20 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).=20 This includes * an HMAC-based authentication mechanism This document aims to provide a general purpose MAC authentication=20 scheme that can be used both with OAuth 2.0 but also with other use = case.=20 The WG will work with the security and applications area directors to=20 ensure that this work gets appropriate review, e.g. via additional last=20= calls in other relevant working groups such as HTTPBIS], * a specification for access protected by Transport Layer Security=20 (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested=20 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 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 barryleiba.mailing.lists@gmail.com Mon May 9 07: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 21C6AE0785 for ; Mon, 9 May 2011 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.311 X-Spam-Level: X-Spam-Status: No, score=-103.311 tagged_above=-999 required=5 tests=[AWL=-0.334, 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 EBqpOgxDQvH4 for ; Mon, 9 May 2011 07:29:34 -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 2BFCBE0781 for ; Mon, 9 May 2011 07:29:33 -0700 (PDT) Received: by vxg33 with SMTP id 33so135138vxg.31 for ; Mon, 09 May 2011 07:29:33 -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; bh=h91QHXuP6t1kA6xajbW4+1xz9HjHk3krepmvvCGj3vA=; b=J1oXAkOEacgnjgsYiauEblgEAdFpw6OMsXpARV/LbIcciP4w3n7h9UIw3gAgaamZAa R2Jfj4VWIGg4gTwpbx8lSIpgUVle7zbwbGD80pkD+vGPAwt93eAr8ZGqHI03NLjyDFZm nCEhs+ShxF2j1P0Gh+Krf4MdCHhpof1dTG7ow= 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; b=cb2YQj+9z6vUeNyG3Q+zfSo9IAc2fW8RNgO1bOwhh73OBWZM1MTcV7KIUlHAsg6T3K +t0r5OkWzjTFYbFDSdfNwfhloFXhBd0BCogjgT9YhyrJyswoZWfuJfVM37LQ0vMedbOB h6VlqgFbnlSj1Hh0FGpGzYUbbpyduAMbxmycA= MIME-Version: 1.0 Received: by 10.52.0.236 with SMTP id 12mr2949516vdh.223.1304951373231; Mon, 09 May 2011 07:29:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.106.202 with HTTP; Mon, 9 May 2011 07:29:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2011 10:29:33 -0400 X-Google-Sender-Auth: x3crv3At4uYAsTeAU3TuxdzD3yM Message-ID: From: Barry Leiba To: David Recordon , igor.faynberg@alcatel-lucent.com Content-Type: multipart/mixed; boundary=20cf304347020d02ef04a2d8ab15 Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 14:29:35 -0000 --20cf304347020d02ef04a2d8ab15 Content-Type: text/plain; charset=ISO-8859-1 David says... > Hey Barry, I'm confused. This thread is full of comments. Is there an > updated charter which addresses them? Well, your earlier message doesn't suggest any changes, nor does Dick's. Thomas's does, but he retracted them after he understood the purpose of this rechartering (see below). So there aren't as many comments in this thread as you think. I did, however miss Eran's comments (so sorry!), but I think Hannes picked those up in his update, posted after mine. Igor, on the use cases: The point of this rechartering is to focus tightly on getting the base protocol done Very Soon. I agree with you that a use-cases document would be great to publish, and if that's kept current with any new discussions here it should be easy to pop it out right away after the next recharter. But we (and the ADs) don't want to have any distractions from getting OAuth 2.0 out. I don't think this will really be an issue. If "use cases" is about ready to go, then it will go out very quickly afterward, and all will be well. For the ADs, I'm attaching Hannes's updated version of the charter for you to proceed with. Barry, as chair --20cf304347020d02ef04a2d8ab15 Content-Type: text/plain; charset=US-ASCII; name="oauth-charter-new-v5.txt" Content-Disposition: attachment; filename="oauth-charter-new-v5.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gnhicff50 V2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cAoKRGVzY3JpcHRpb24gb2Yg V29ya2luZyBHcm91cAoKVGhlIFdlYiBBdXRob3JpemF0aW9uIChPQXV0aCkgcHJvdG9jb2wgYWxs b3dzIGEgdXNlciB0byBncmFudAphIHRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9u IGFjY2VzcyB0byB0aGUgdXNlcidzIHByb3RlY3RlZApyZXNvdXJjZXMsIHdpdGhvdXQgbmVjZXNz YXJpbHkgcmV2ZWFsaW5nIHRoZWlyIGxvbmctdGVybSBjcmVkZW50aWFscywKb3IgZXZlbiB0aGVp ciBpZGVudGl0eS4gRm9yIGV4YW1wbGUsIGEgcGhvdG8tc2hhcmluZyBzaXRlIHRoYXQgc3VwcG9y dHMKT0F1dGggY291bGQgYWxsb3cgaXRzIHVzZXJzIHRvIHVzZSBhIHRoaXJkLXBhcnR5IHByaW50 aW5nIFdlYiBzaXRlIHRvCnByaW50IHRoZWlyIHByaXZhdGUgcGljdHVyZXMsIHdpdGhvdXQgYWxs b3dpbmcgdGhlIHByaW50aW5nIHNpdGUgdG8KZ2FpbiBmdWxsIGNvbnRyb2wgb2YgdGhlIHVzZXIn cyBhY2NvdW50LgoKT0F1dGggZW5jb21wYXNzZXMKKiBhIG1lY2hhbmlzbSBmb3IgYSB1c2VyIHRv IGF1dGhvcml6ZSBpc3N1YW5jZSBvZiBjcmVkZW50aWFscyB0aGF0CiBhIHRoaXJkIHBhcnR5IGNh biB1c2UgdG8gYWNjZXNzIHJlc291cmNlcyBvbiB0aGUgdXNlcidzIGJlaGFsZiBhbmQKKiBhIG1l Y2hhbmlzbSBmb3IgdXNpbmcgdGhlIGlzc3VlZCBjcmVkZW50aWFscyB0byBhdXRoZW50aWNhdGUK IEhUVFAgcmVxdWVzdHMuCgpJbiBBcHJpbCAyMDEwIHRoZSBPQXV0aCAxLjAgc3BlY2lmaWNhdGlv biwgZG9jdW1lbnRpbmcgcHJlLUlFVEYgd29yaywKd2FzIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1h dGlvbmFsIGRvY3VtZW50IChSRkMgNTg0OSkuIFRoZSB3b3JraW5nCmdyb3VwIGhhcyBzaW5jZSBi ZWVuIGRldmVsb3BpbmcgT0F1dGggMi4wLCBhIHN0YW5kYXJkcy10cmFjayB2ZXJzaW9uCnRoYXQg d2lsbCByZWZsZWN0IElFVEYgY29uc2Vuc3VzLiAgVmVyc2lvbiAyLjAgd2lsbCBjb25zaWRlciB0 aGUKaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB3aXRoIHZlcnNpb24gMS4wLCBhIGRpc2NvdmVy ZWQgc2VjdXJpdHkKdnVsbmVyYWJpbGl0eSAoc2Vzc2lvbiBmaXhhdGlvbiBhdHRhY2spLCB0aGUg dXNlIGNhc2VzIGFuZApmdW5jdGlvbmFsaXR5IHByb3Bvc2VkIHdpdGggT0F1dGggV1JBUCBbZHJh ZnQtaGFyZHQtb2F1dGgtMDFdIGFuZCB3aWxsCiogaW1wcm92ZSB0aGUgdGVybWlub2xvZ3kgdXNl ZCwKKiBjb25zaWRlciBicm9hZGVyIHVzZSBjYXNlcywKKiBlbWJvZHkgZ29vZCBzZWN1cml0eSBw cmFjdGljZXMsCiogaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5LCBhbmQKKiBwcm92aWRlIGd1aWRl bGluZXMgZm9yIGV4dGVuc2liaWxpdHkuCgpUaGUgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Ag YXV0aGVudGljYXRpb24gc2NoZW1lcyBmb3IKcGVlcnMvc2VydmVycyB0YWtpbmcgcGFydCBpbiBP QXV0aCAoYWNjZXNzaW5nIHByb3RlY3RlZCByZXNvdXJjZXMpLgpUaGlzIGluY2x1ZGVzCgoqIGFu IEhNQUMtYmFzZWQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtCgpUaGlzIGRvY3VtZW50IGFpbXMg dG8gcHJvdmlkZSBhIGdlbmVyYWwgcHVycG9zZSBNQUMgYXV0aGVudGljYXRpb24Kc2NoZW1lIHRo YXQgY2FuIGJlIHVzZWQgYm90aCB3aXRoIE9BdXRoIDIuMCBidXQgYWxzbyB3aXRoIG90aGVyIHVz ZSBjYXNlLgpUaGUgV0cgd2lsbCB3b3JrIHdpdGggdGhlIHNlY3VyaXR5IGFuZCBhcHBsaWNhdGlv bnMgYXJlYSBkaXJlY3RvcnMgdG8KZW5zdXJlIHRoYXQgdGhpcyB3b3JrIGdldHMgYXBwcm9wcmlh dGUgcmV2aWV3LCBlLmcuIHZpYSBhZGRpdGlvbmFsIGxhc3QKY2FsbHMgaW4gb3RoZXIgcmVsZXZh bnQgd29ya2luZyBncm91cHMgc3VjaCBhcyBIVFRQQklTXSwKCiogYSBzcGVjaWZpY2F0aW9uIGZv ciBhY2Nlc3MgcHJvdGVjdGVkIGJ5IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQooYmVhcmVyIHRv a2VucyksCgoqIGFuIGV4dGVuc2lvbiB0byBPQXV0aCAyLjAgdG8gYWxsb3cgYWNjZXNzIHRva2Vu cyB0byBiZSByZXF1ZXN0ZWQKd2hlbiBhIGNsaWVudCBpcyBpbiBwb3NzZXNzaW9uIG9mIGEgU0FN TCBhc3NlcnRpb24uCgpBIHNlcGFyYXRlIGluZm9ybWF0aW9uYWwgZGVzY3JpcHRpb24gd2lsbCBi ZSBwcm9kdWNlZCB0byBwcm92aWRlCmFkZGl0aW9uYWwgc2VjdXJpdHkgYW5hbHlzaXMgZm9yIGF1 ZGllbmNlcyBiZXlvbmQgdGhlIGNvbW11bml0eQpwcm90b2NvbCBpbXBsZW1lbnRlcnMuCgpNaWxl c3RvbmVzIHdpbGwgYmUgYWRkZWQgZm9yIHRoZSBsYXRlciBpdGVtcyBhZnRlciB0aGUgbmVhci10 ZXJtIHdvcmsKaGFzIGJlZW4gY29tcGxldGVkLgoKR29hbHMgYW5kIE1pbGVzdG9uZXMKTWF5IDIw MTEgICAgU3VibWl0ICdIVFRQIEF1dGhlbnRpY2F0aW9uOiBNQUMgQXV0aGVudGljYXRpb24nIGFz IGEKd29ya2luZyBncm91cCBpdGVtCgpNYXkgMjAxMSAgICBTdWJtaXQgJ09BdXRoIDIuMCBUaHJl YXQgTW9kZWwgYW5kIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zJwphcyBhIHdvcmtpbmcgZ3JvdXAg aXRlbQoKSnVsIDIwMTEgICAgU3VibWl0ICdUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gUHJv dG9jb2wnIHRvIHRoZQpJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQKCkp1bCAyMDExICAgIFN1Ym1pdCAnVGhlIE9BdXRoIDIuMCBQcm90b2NvbDogQmVhcmVyIFRv a2VucycgdG8gdGhlCklFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFy ZAoKQXVnIDIwMTEgICAgU3VibWl0ICdIVFRQIEF1dGhlbnRpY2F0aW9uOiBNQUMgQXV0aGVudGlj YXRpb24nIHRvIHRoZQpJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQKCk9jdCAyMDExICAgIFN1Ym1pdCAnU0FNTCAyLjAgQmVhcmVyIEFzc2VydGlvbiBHcmFudCBU eXBlIFByb2ZpbGUgZm9yCk9BdXRoIDIuMCcgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24g YXMgYSBQcm9wb3NlZCBTdGFuZGFyZAoKT2N0IDIwMTEgICAgUmUtY2hhcnRlcmluZyB3b3JraW5n IGdyb3VwCg== --20cf304347020d02ef04a2d8ab15-- From stephen.farrell@cs.tcd.ie Mon May 9 08:45: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 09A04E07CB for ; Mon, 9 May 2011 08:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 XANcFM+YBHhV for ; Mon, 9 May 2011 08:45:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 856CDE0703 for ; Mon, 9 May 2011 08:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7CBAF171C3A; Mon, 9 May 2011 16:45:15 +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=1304955915; bh=sscMAvXud4nmSK 1rWCLBlwYGrmz+pd3SjjdCiI2EO6U=; b=nEFPMbpz1ARiQjSLjaSS3mKB+Hdy1K mOVTFDP3i9gT8c3UIikvAiONq9CsH+IP49ggIwYQ9+yGpeQvwyOCPKlZCFlkfLSM umX7dhgiEyNioH3umsHcGCF5JCtiHBEkm4MzJa0cYXhC41DAH3P51Z4Gbf9fEY8+ QklzLpubAdA/I0E/3VixgRjpU5L0sgvhIQOg707B0eugqNMi6iUxtdzk0OOrFwWh yvEroiI5a76CFFz+oURwystDLhkocWBrnE89VdElG0V5MgT81r17TXMUthJu4nYx 49nNOnbTI5HoGkt1Josh0idBtUHxsfUiDplBHXMPETzD6XNav7UK6HtA== 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 jl8LuSiI90D5; Mon, 9 May 2011 16:45:15 +0100 (IST) Received: from [192.168.240.54] (145.Red-88-3-208.staticIP.rima-tde.net [88.3.208.145]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BE998171C1C; Mon, 9 May 2011 16:45:13 +0100 (IST) Message-ID: <4DC80C07.8080909@cs.tcd.ie> Date: Mon, 09 May 2011 16:45:11 +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: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 15:45:22 -0000 Thanks folks for your work in updating the charter. I'll take a peek at this and get back about getting it put in place in the next few days. S. On 09/05/11 15:29, Barry Leiba wrote: > David says... >> Hey Barry, I'm confused. This thread is full of comments. Is there an >> updated charter which addresses them? > > Well, your earlier message doesn't suggest any changes, nor does > Dick's. Thomas's does, but he retracted them after he understood the > purpose of this rechartering (see below). So there aren't as many > comments in this thread as you think. I did, however miss Eran's > comments (so sorry!), but I think Hannes picked those up in his > update, posted after mine. > > Igor, on the use cases: The point of this rechartering is to focus > tightly on getting the base protocol done Very Soon. I agree with you > that a use-cases document would be great to publish, and if that's > kept current with any new discussions here it should be easy to pop it > out right away after the next recharter. But we (and the ADs) don't > want to have any distractions from getting OAuth 2.0 out. > > I don't think this will really be an issue. If "use cases" is about > ready to go, then it will go out very quickly afterward, and all will > be well. > > For the ADs, I'm attaching Hannes's updated version of the charter for > you to proceed with. > > Barry, as chair > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon May 9 09:30: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 298C6E08E7 for ; Mon, 9 May 2011 09:30:29 -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.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 VmEkeJXuK+bK for ; Mon, 9 May 2011 09:30: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 3EFCDE08C1 for ; Mon, 9 May 2011 09:30:23 -0700 (PDT) Received: (qmail 25946 invoked from network); 9 May 2011 16:30:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2011 16:30:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 9 May 2011 09:30:19 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig Date: Mon, 9 May 2011 09:30:15 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwOO56YWB+//HB1Q6qji+mfIqKc2wAKVrsQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> In-Reply-To: <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.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 Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 16:30:29 -0000 Sure, there are plenty of things, each with a few people showing interest. = But I have yet to see any proposal with enough interest to justify a workin= g group. 5 items, each with 5 people showing interest doesn't make it a 25 = people working group. It makes it 5 individual submissions with negligible = support. Keeping this text in the charter implies that we already have consensus for= re-chartering. We don't. EHL =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, May 09, 2011 4:17 AM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; Blaine Cook; oauth@ietf.org; oauth- > ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 >=20 > On Apr 28, 2011, at 4:01 AM, Eran Hammer-Lahav wrote: >=20 > >> Nov 2011 Prepare re-chartering > > > > I would like this removed. > > > > I would like to see this WG closed when this list is complete and if th= ere is > further work with enough interest, a new working group can be created. >=20 > Hi Eran, >=20 > we already today see interest in doing additional work beyond what is on = the > charter. We could remove the explicit item from the charter but we will > definitely call for rechartering after we are done with the currently cha= rtered > items. >=20 > Ciao > Hannes From eran@hueniverse.com Mon May 9 09: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 84B48E0740 for ; Mon, 9 May 2011 09:50:59 -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_FWDLOOK=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 aXtvdTFp5qiW for ; Mon, 9 May 2011 09:50: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 B6240E0703 for ; Mon, 9 May 2011 09:49:55 -0700 (PDT) Received: (qmail 31180 invoked from network); 9 May 2011 16:49:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2011 16:49:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 May 2011 09:49:49 -0700 From: Eran Hammer-Lahav To: HTTP Working Group Date: Mon, 9 May 2011 09:49:45 -0700 Thread-Topic: BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG) Thread-Index: AcwOaRnsMmXgbq0NTxOIDUHXPFJ82g== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA816@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 Cc: OAuth WG Subject: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG) X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 16:50:59 -0000 The OAuth working group has defined an authorization protocol [1] for deleg= ating access to protected resources. Once access has been authorized, the c= lient is issued a set of token credentials which are uses to make authentic= ated HTTP requests. To accomplish that, the OAuth working group has propose= d two new HTTP authentication schemes: Bearer [2] and MAC [3]. The working group has been debating the issue of what's the best current pr= actice for returning an error status in an HTTP authentication scheme. The = Basic and Digest schemes do not specify the error condition and simply retu= rn a 401 response with a new challenge. The MAC proposal follows this patte= rn. The Bearer scheme proposal is taking a more active approach, defining an 'e= rror' response attribute for use with the WWW-Authenticate header and an er= ror code registry to go along. The parameter and registry (especially the r= egistry) are meant for reuse by other HTTP authentication schemes. At the m= oment, the three error conditions proposed by the Bearer draft are: invalid= request, invalid token, and insufficient scope (which arguably is better s= uited using a 403 response with or without a new challenge). While these error codes arguably do not provide an immediate actionable val= ue (pending the help of future discovery specifications), the attribute and= registry propose a forward-looking solution for when clients will be able = to automatically resolve such issues (with the help of future discovery spe= cifications). The OAuth WG is seeking guidance on the following questions: 1. Should the WG define a general purpose method for returning errors with = a 401 WWW-Authenticate headers, including a cross-scheme error code registr= y? If you answered yes to #1: 2. Should the WG apply this to all new HTTP authentication schemes (current= ly, MAC, but potentially more)? 3. Should this new error attribute and registry be part of the main OAuth 2= .0 specification, part of one of the upcoming schemes (for use with other s= chemes), or standalone? If you answered no to #1: 4. Should the Bearer draft retain the attribute and registry for its own sc= heme-specific needs? EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 [3] http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-03 From eran@hueniverse.com Mon May 9 10:01: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 EAE34E083C for ; Mon, 9 May 2011 10:01:52 -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 WbziLA9dvdNT for ; Mon, 9 May 2011 10:01: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 4CB56E06C3 for ; Mon, 9 May 2011 10:01:51 -0700 (PDT) Received: (qmail 21649 invoked from network); 9 May 2011 17:01:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2011 17:01:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 9 May 2011 10:01:30 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , "oauth@ietf.org WG" Date: Mon, 9 May 2011 10:01:26 -0700 Thread-Topic: [OAUTH-WG] Revised OAuth Charter Text Thread-Index: AcwOO9UupKdvu5mzTCOoKWmcnq8UzQALY77g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA82A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <037D141A-A81D-44D0-AC58-060DA45ACF98@gmx.net> In-Reply-To: <037D141A-A81D-44D0-AC58-060DA45ACF98@gmx.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 Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] Revised OAuth Charter 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: Mon, 09 May 2011 17:01:53 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Monday, May 09, 2011 4:25 AM > Goals and Milestones > May 2011 Submit 'HTTP Authentication: MAC Authentication' as a > working group item I am still not convinced this is the right working group for this document.= This is an active document with a pending -04 version coming this week. Ou= t of 26 pages, only 1 discusses OAuth 2.0 (and 2 more pages handle the regi= stration requirements). My two co-authors, Adam Barth and Ben Adida are not= members of this working group. In addition, this working group have shown = little to no interest this document to date, offering very limited feedback= . I much rather keep this document as an individual submission discussed on a= pps-discuss, and make sure it includes the HTTPbis, HTTP-State, and OAuth w= orking groups in its last call process. I would like to hear what the Stephen (security AD) and Peter (application = AD) think about the right venue for this draft. EHL From phil.hunt@oracle.com Mon May 9 10:47: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 C89C8E069F for ; Mon, 9 May 2011 10:47:17 -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 DnUcAD1-bcoe for ; Mon, 9 May 2011 10:47:16 -0700 (PDT) Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by ietfa.amsl.com (Postfix) with ESMTP id BEBCBE0698 for ; Mon, 9 May 2011 10:47:16 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by rcsinet14.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p49HlGxc004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 May 2011 17:47:16 GMT Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p49HlCQE016160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 17:47:14 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p49HlBsB005851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 17:47:12 GMT Received: from abhmt017.oracle.com (abhmt017.oracle.com [141.146.116.26]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p49Hl5GE009329; Mon, 9 May 2011 12:47:05 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 May 2011 10:47:05 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 10:47:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4DC828A2.0219:SCFSTAT5015188,ss=1,fgs=0 Cc: oauth WG , oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 17:47:17 -0000 There are several things being held back to allow the core specification = to complete. For example, I would expect more expanded work on tokens. = There is also several items in the status pages (e.g. my chain = proposal), revocation etc, that will also need to be discussed. You did mention the MAC spec should probably be in an another WG. The = outcome of this decision will likely impact future re-chartering, since = other "token" formats should follow the same path. Suffice to say a re-chartering will be needed again. Phil phil.hunt@oracle.com On 2011-05-09, at 9:30 AM, Eran Hammer-Lahav wrote: > Sure, there are plenty of things, each with a few people showing = interest. But I have yet to see any proposal with enough interest to = justify a working group. 5 items, each with 5 people showing interest = doesn't make it a 25 people working group. It makes it 5 individual = submissions with negligible support. >=20 > Keeping this text in the charter implies that we already have = consensus for re-chartering. We don't. >=20 > EHL >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Monday, May 09, 2011 4:17 AM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; Blaine Cook; oauth@ietf.org; oauth- >> ads@tools.ietf.org >> Subject: Re: [OAUTH-WG] Revised Charter >>=20 >>=20 >> On Apr 28, 2011, at 4:01 AM, Eran Hammer-Lahav wrote: >>=20 >>>> Nov 2011 Prepare re-chartering >>>=20 >>> I would like this removed. >>>=20 >>> I would like to see this WG closed when this list is complete and if = there is >> further work with enough interest, a new working group can be = created. >>=20 >> Hi Eran, >>=20 >> we already today see interest in doing additional work beyond what is = on the >> charter. We could remove the explicit item from the charter but we = will >> definitely call for rechartering after we are done with the currently = chartered >> items. >>=20 >> Ciao >> Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon May 9 10:54: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 6F64AE0917 for ; Mon, 9 May 2011 10:54: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 yp7CATANCNaB for ; Mon, 9 May 2011 10:54: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 BC8DFE06EC for ; Mon, 9 May 2011 10:54:02 -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 p49HWhjQ022529 for ; Mon, 9 May 2011 10:32:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304962364; bh=CqVy3uzqtEpT58tSnvRvSIphSJI=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=sOYM/FVNdt0rnHgLZb0QTGWHT5ghd8snzUwDcOPA8+gEfySYZYKe8yTCUfN8vE5hv 2sWc85f4mf52sedmBhbiQ== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by kpbe15.cbf.corp.google.com with ESMTP id p49HVv2B007105 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 9 May 2011 10:32:42 -0700 Received: by gxk22 with SMTP id 22so2175010gxk.30 for ; Mon, 09 May 2011 10:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to:cc :content-type; bh=rDwWEdryO8M+KJxZF9KXm1kgN7Tart2fNyIuaGwYYLQ=; b=TWi3JWi7VXpVwNK4XRxRIEPWni8eqi9uD8aB8XlXJo16vRg/64b/S3x8x3f8K7xe27 tD9M0dQkUsb2XQ4+qzMA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=ZTvIle7PiupfRJpxB6f6xiCA0wB0km8bes/at0mE7ylLMJs/7qdczb6MTbkIYO/N/Q 1p2V7GEMZw6vtS+xyWmQ== Received: by 10.101.19.8 with SMTP id w8mr4344384ani.57.1304962362209; Mon, 09 May 2011 10:32:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.46.20 with HTTP; Mon, 9 May 2011 10:32:22 -0700 (PDT) From: Marius Scurtescu Date: Mon, 9 May 2011 10:32:22 -0700 Message-ID: To: OAuth WG , Mike Jones Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 17:54:04 -0000 I am working through version 04 of the Bearer Token draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 Not sure how to interpret the authorization header grammar described in section 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, "Bearer", there is a required whitespace followed by the actual token. The token is represented by a sequence of printable characters, no escaping. No spaces or other elements are allowed after the token. Is that correct? RWS is not defined, I assume it is the "required whitespace" from section 1.2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 There is a reference to RFC2617, but not sure why. That seems to imply that a list of values can be specified, which is not the case. The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example: Bearer token=dfgh76dfghdfg or Bearer token="dfgh76dfghdfg" The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at least clean up the references. Marius From eran@hueniverse.com Mon May 9 11:38: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 8AD1AE06F0 for ; Mon, 9 May 2011 11:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 9CCwKct0sYdv for ; Mon, 9 May 2011 11:38:02 -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 CB348E06DD for ; Mon, 9 May 2011 11:38:02 -0700 (PDT) Received: (qmail 15175 invoked from network); 9 May 2011 18:38:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 18:38:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 May 2011 11:37:47 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 9 May 2011 11:37:44 -0700 Thread-Topic: Return status codes in draft-ietf-oauth-v2-bearer-04 Thread-Index: AcwOdvN8w6bMi04OR/WaqdHtzQRGgw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA8A4@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_90C41DD21FB7C64BB94121FBBC2E723447581DA8A4P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Return status codes in draft-ietf-oauth-v2-bearer-04 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 18:38:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8A4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2.4.1 conflicts with HTTP. Both invalid_request and invalid_token should be used with a 401 response. = 400 is not about poorly formatted authorization header, but about a bad pro= tected resource request. The way HTTP authentication works is that first the server authenticates th= e client. If *for any reason* authentication fails, it returns a 401. The e= rror code can reflect the exact reason (for example, differentiating betwee= n a bad header format and expired token). If the credentials are valid, but do not provide sufficient scope, a 403 is= returned. 403 means that the authentication was successful, but that that = client is not allowed to execute the request. If the credentials are valid, have sufficient scope, but the request itself= is invalid, a 400 is returned. This text and the text it originally derived from are incorrect in their us= e of 400 to indicate an invalid authorization header. This section needs to be edited to reflect the three states: 401: Invalid authentication (both invalid_request and invalid_token) 403: Valid authentication, insufficient scope - since no discovery provided= , including a new WWW-Authenticate doesn't help much, even with the scope p= arameter 400: Valid authentication, sufficient scope, invalid protected resource req= uest Arguable, specifying anything other than the 401 response and its errors ex= ceeds the scope of this document and steps over HTTP. I would recommend dro= pping all responses other than 401 since they are just how HTTP works and e= xplicitly defining them give the impression that other HTTP status codes ar= e not allowed. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8A4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Section 2.4.1 co= nflicts with HTTP.

     

    =

    Both invalid_request and invalid_token should be used = with a 401 response. 400 is not about poorly formatted authorization header= , but about a bad protected resource request.

     

    The way HTTP authentication= works is that first the server authenticates the client. If *for any re= ason* authentication fails, it returns a 401. The error code can reflec= t the exact reason (for example, differentiating between a bad header forma= t and expired token).

     <= /p>

    If the credentials are valid, but do not provide su= fficient scope, a 403 is returned. 403 means that the authentication was su= ccessful, but that that client is not allowed to execute the request.<= /o:p>

     

    If = the credentials are valid, have sufficient scope, but the request itself is= invalid, a 400 is returned.

     =

    This text and the text it originally derived= from are incorrect in their use of 400 to indicate an invalid authorizatio= n header.

     

    This section needs to be edited to reflect the three states:

     

    401: Invalid authentication (both invalid_request and invalid_token= )

    403: Valid authentication, insu= fficient scope – since no discovery provided, including a new WWW-Aut= henticate doesn’t help much, even with the scope parameter=

    400: Valid authentication, sufficient scope= , invalid protected resource request

     

    Arguable, specifying anything other = than the 401 response and its errors exceeds the scope of this document and= steps over HTTP. I would recommend dropping all responses other than 401 s= ince they are just how HTTP works and explicitly defining them give the imp= ression that other HTTP status codes are not allowed.

     

    EHL

    <= p class=3DMsoListParagraph> 

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8A4P3PW5EX1MB01E_-- From igor.faynberg@alcatel-lucent.com Mon May 9 12:18: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 D6667E0747 for ; Mon, 9 May 2011 12:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 CVcnc3YCaPUH for ; Mon, 9 May 2011 12:18:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBABE073D for ; Mon, 9 May 2011 12:18:27 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p49JINKe019062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 14:18:23 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p49JINNx004677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2011 14:18:23 -0500 Received: from [135.244.36.26] (faynberg.lra.lucent.com [135.244.36.26]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p49JIM3C009810; Mon, 9 May 2011 14:18:22 -0500 (CDT) Message-ID: <4DC83DFD.4020003@alcatel-lucent.com> Date: Mon, 09 May 2011 15:18:21 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Barry Leiba 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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth@ietf.org, oauth-ads@tools.ietf.org Subject: Re: [OAUTH-WG] Revised Charter 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, 09 May 2011 19:18:28 -0000 Barry, I agree. Indeed, after ascertaining that the next rechartering is scheduled for October, I personally see no problem with deferring the use cases. (I thought that the current rechartering was already post-2.0, which is what had confused me.) With thanks for thorough follow-ups, Igor Barry Leiba wrote: > ... > > Igor, on the use cases: The point of this rechartering is to focus > tightly on getting the base protocol done Very Soon. I agree with you > that a use-cases document would be great to publish, and if that's > kept current with any new discussions here it should be easy to pop it > out right away after the next recharter. But we (and the ADs) don't > want to have any distractions from getting OAuth 2.0 out. > > . > From eran@hueniverse.com Mon May 9 12:22: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 C855BE0792 for ; Mon, 9 May 2011 12:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 SAlEf6lrm2gJ for ; Mon, 9 May 2011 12:22:36 -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 D4B56E0795 for ; Mon, 9 May 2011 12:22:36 -0700 (PDT) Received: (qmail 24965 invoked from network); 9 May 2011 19:22:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 19:22:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 May 2011 12:22:27 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Mon, 9 May 2011 12:22:23 -0700 Thread-Topic: HTTP MAC Authentication Scheme Thread-Index: AcwOfmxmPIi74XcpSTyynQcwm/I2bw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@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_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , "http-state@ietf.org" , OAuth WG , "'Adam Barth \(adam@adambarth.com\)'" , HTTP Working Group Subject: [OAUTH-WG] 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, 09 May 2011 19:22:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Please discuss this draft on the Apps-Discuss mail= ing 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 reque= sts (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 H= MAC for authenticating an HTTP request with partial cryptographic protectio= n 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 "abus= ed" for simple client-server authentication (the poorly named 'two-legged' = use case). This functionality has been separated from OAuth 2.0 and has bee= n reintroduced as a standalone, generally applicable HTTP authentication sc= heme called MAC. Comments and feedback is greatly appreciated. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    (Please discuss = this draft on the Apps-Discuss <apps-discuss@ietf.org> mailing list)<= o:p>

     

    ht= tp://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token

    =

     

    The draft in= cludes:

     

    * An HTTP authentication scheme using a MAC algorithm to authenti= cate requests (via a pre-arranged MAC key).

    * An extension to the Set-Cookie header, providing a method for associa= ting 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 authenticati= on scheme using HMAC for authenticating an HTTP request with partial crypto= graphic protection of the HTTP request (namely, the request URI, host, and = port). The OAuth 1.0 scheme was designed for delegation-based use cases, bu= t is widely “abused” for simple client-server authentication (t= he poorly named ‘two-legged’ use case). This functionality has = been separated from OAuth 2.0 and has been reintroduced as a standalone, ge= nerally applicable HTTP authentication scheme called MAC.

     

    Comments and fe= edback is greatly appreciated.

    &nbs= p;

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_-- From eran@hueniverse.com Mon May 9 12:25: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 ACA88E06DB for ; Mon, 9 May 2011 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 56mtdz4hneAw for ; Mon, 9 May 2011 12:25:45 -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 D3B56E0713 for ; Mon, 9 May 2011 12:25:45 -0700 (PDT) Received: (qmail 491 invoked from network); 9 May 2011 19:25:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 19:25:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 May 2011 12:25:34 -0700 From: Eran Hammer-Lahav To: "igor.faynberg@alcatel-lucent.com" , Barry Leiba Date: Mon, 9 May 2011 12:25:31 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwOfeT4+/OOGYXMTvSNdbQFKt0lVgAAKAeg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4DC83DFD.4020003@alcatel-lucent.com> In-Reply-To: <4DC83DFD.4020003@alcatel-lucent.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 Cc: "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 19:25:46 -0000 I don't see why we can't just publish this document as an informational RFC= now. I sure hope we are not going to accommodate any new use cases... Also, since this is not a normative document, the WG value here is minimal.= I think Igor can move forward with publishing this as an individual submis= sion, but will also be supportive of making it a working group item and qui= ckly moving to final WG LC and off to the IESG. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Igor Faynberg > Sent: Monday, May 09, 2011 12:18 PM > To: Barry Leiba > Cc: oauth@ietf.org; oauth-ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 > Barry, >=20 > I agree. Indeed, after ascertaining that the next rechartering is schedul= ed for > October, I personally see no problem with deferring the use cases. (I tho= ught > that the current rechartering was already post-2.0, which is what had > confused me.) >=20 > With thanks for thorough follow-ups, >=20 > Igor >=20 > Barry Leiba wrote: > > ... > > > > Igor, on the use cases: The point of this rechartering is to focus > > tightly on getting the base protocol done Very Soon. I agree with you > > that a use-cases document would be great to publish, and if that's > > kept current with any new discussions here it should be easy to pop it > > out right away after the next recharter. But we (and the ADs) don't > > want to have any distractions from getting OAuth 2.0 out. > > > > . > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon May 9 12:31: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 D394AE06EC for ; Mon, 9 May 2011 12:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_14=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 d0usKV91F0mG for ; Mon, 9 May 2011 12:31:51 -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 2BDF8E069C for ; Mon, 9 May 2011 12:31:50 -0700 (PDT) Received: (qmail 16791 invoked from network); 9 May 2011 19:05:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 19:05:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 9 May 2011 12:05:02 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Mon, 9 May 2011 12:04:58 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwOcSoYQcu/mifrQJqHqMHCsCFyewACZD9w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@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 , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 19:31:51 -0000 A good example is the discussion going on about the http-state working grou= p. The WG finished their work on cleaning the cookie specification. Some pe= ople want to continue work on cookies v.next. It is far from clear if the s= ame working group will be re-chartered, or a new working group created, or = none. The problem with re-chartering is that it usually leads to weaker review of= the need to form a working group. The test should be whether the items you= mentioned would merit the creation of a working group if this one was clos= ed. I highly doubt it. I want to see this working group reach its end when this charter is fulfill= ed. At that point, a new working group can be requested to work on other it= ems. The new working group can continue using this list which I assume will= remain open. EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Monday, May 09, 2011 10:47 AM > To: Eran Hammer-Lahav > Cc: oauth WG; oauth-ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 > There are several things being held back to allow the core specification = to > complete. For example, I would expect more expanded work on tokens. > There is also several items in the status pages (e.g. my chain proposal), > revocation etc, that will also need to be discussed. >=20 > You did mention the MAC spec should probably be in an another WG. The > outcome of this decision will likely impact future re-chartering, since o= ther > "token" formats should follow the same path. >=20 > Suffice to say a re-chartering will be needed again. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-05-09, at 9:30 AM, Eran Hammer-Lahav wrote: >=20 > > Sure, there are plenty of things, each with a few people showing intere= st. > But I have yet to see any proposal with enough interest to justify a work= ing > group. 5 items, each with 5 people showing interest doesn't make it a 25 > people working group. It makes it 5 individual submissions with negligibl= e > support. > > > > Keeping this text in the charter implies that we already have consensus= for > re-chartering. We don't. > > > > EHL > > > > > > > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > >> Sent: Monday, May 09, 2011 4:17 AM > >> To: Eran Hammer-Lahav > >> Cc: Hannes Tschofenig; Blaine Cook; oauth@ietf.org; oauth- > >> ads@tools.ietf.org > >> Subject: Re: [OAUTH-WG] Revised Charter > >> > >> > >> On Apr 28, 2011, at 4:01 AM, Eran Hammer-Lahav wrote: > >> > >>>> Nov 2011 Prepare re-chartering > >>> > >>> I would like this removed. > >>> > >>> I would like to see this WG closed when this list is complete and if > >>> there is > >> further work with enough interest, a new working group can be created. > >> > >> Hi Eran, > >> > >> we already today see interest in doing additional work beyond what is > >> on the charter. We could remove the explicit item from the charter > >> but we will definitely call for rechartering after we are done with > >> the currently chartered items. > >> > >> Ciao > >> Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon May 9 12: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 96313E0787 for ; Mon, 9 May 2011 12:40:07 -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 S7R1QzVp+rkm for ; Mon, 9 May 2011 12:40:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE2E077B for ; Mon, 9 May 2011 12:40:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E16FD21B1411; Mon, 9 May 2011 15:34:47 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D9AFB21B1946; Mon, 9 May 2011 15:34:47 -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, 9 May 2011 15:34:47 -0400 Message-ID: <4DC841D7.60504@mitre.org> Date: Mon, 9 May 2011 15:34:47 -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: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------050702070706010402050502" Cc: Ben Adida , OAuth WG , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] 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, 09 May 2011 19:40:07 -0000 --------------050702070706010402050502 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit I would still like to see a binding of this to use query or form parameters. I have a direct use case for handing out signed URLs to the client, for which we're using the OAuth 1.0 signing mechanism without tokens today. I'd love to switch to something that we could bind to OAuth2, but the restriction of using the Auth header puts the MAC token out of reach for my immediate usecase. -- Justin On 5/9/2011 3:22 PM, 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 > --------------050702070706010402050502 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit I would still like to see a binding of this to use query or form parameters. I have a direct use case for handing out signed URLs to the client, for which we're using the OAuth 1.0 signing mechanism without tokens today. I'd love to switch to something that we could bind to OAuth2, but the restriction of using the Auth header puts the MAC token out of reach for my immediate usecase.

     -- Justin

    On 5/9/2011 3:22 PM, Eran Hammer-Lahav wrote:

    (Please discuss this draft on the Apps-Discuss <apps-discuss@ietf.org> 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


    --------------050702070706010402050502-- From igor.faynberg@alcatel-lucent.com Mon May 9 12:49: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 EEAE7E065A for ; Mon, 9 May 2011 12:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 6z5JapJxdrT7 for ; Mon, 9 May 2011 12:49:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF41E074C for ; Mon, 9 May 2011 12:49:50 -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 p49Ji818019352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 14:44:08 -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 p49Ji8gF002140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2011 14:44:08 -0500 Received: from [135.244.36.26] (faynberg.lra.lucent.com [135.244.36.26]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p49Ji6oX001622; Mon, 9 May 2011 14:44:07 -0500 (CDT) Message-ID: <4DC84406.5060505@alcatel-lucent.com> Date: Mon, 09 May 2011 15:44:06 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4DC83DFD.4020003@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447581DA8EE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: Barry Leiba , "oauth@ietf.org" , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter 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, 09 May 2011 19:50:00 -0000 Actually, I am NOT an author of use cases; I am just a proponent of this work. The decision of whether and when to move to publishing belongs to the authors: George, Torsten, and Zachary. Of course, if the authors choose to do so, the draft can go to the RFC Editor as an Independent (or AD-sponsored) submission, but I see two drawbacks here: 1) This would break the connection of the use cases to the protocol work and thus counter their/* *//*raison d'être*/ and 2) this may take very, very long. (As a former WG chair and an author of a few RFCs, one of which was AD-sponsored and another Independent, I have learned all of this the hard way...) This is why my inclination has been, and still is, toward Eran's second option. Igor Eran Hammer-Lahav wrote: > I don't see why we can't just publish this document as an informational RFC now. I sure hope we are not going to accommodate any new use cases... > > Also, since this is not a normative document, the WG value here is minimal. I think Igor can move forward with publishing this as an individual submission, but will also be supportive of making it a working group item and quickly moving to final WG LC and off to the IESG. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Igor Faynberg >> Sent: Monday, May 09, 2011 12:18 PM >> To: Barry Leiba >> Cc: oauth@ietf.org; oauth-ads@tools.ietf.org >> Subject: Re: [OAUTH-WG] Revised Charter >> >> Barry, >> >> I agree. Indeed, after ascertaining that the next rechartering is scheduled for >> October, I personally see no problem with deferring the use cases. (I thought >> that the current rechartering was already post-2.0, which is what had >> confused me.) >> >> With thanks for thorough follow-ups, >> >> Igor >> >> Barry Leiba wrote: >> >>> ... >>> >>> Igor, on the use cases: The point of this rechartering is to focus >>> tightly on getting the base protocol done Very Soon. I agree with you >>> that a use-cases document would be great to publish, and if that's >>> kept current with any new discussions here it should be easy to pop it >>> out right away after the next recharter. But we (and the ADs) don't >>> want to have any distractions from getting OAuth 2.0 out. >>> >>> . >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From eran@hueniverse.com Mon May 9 13:18: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 D0A44E0786 for ; Mon, 9 May 2011 13:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.302, 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 vwOkWCUhKxaJ for ; Mon, 9 May 2011 13:18: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 EB4C6E07F3 for ; Mon, 9 May 2011 13:18:57 -0700 (PDT) Received: (qmail 25737 invoked from network); 9 May 2011 19:37:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2011 19:37:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 May 2011 12:36:46 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 9 May 2011 12:36:43 -0700 Thread-Topic: draft-hammer-oauth-v2-mac-token-04 Thread-Index: AcwOfxBTppiOpPg7S7Szd7NPSkSyFw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA902@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 Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-04 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 May 2011 20:18:58 -0000 (Please discuss this draft on the Apps-Discuss mail= ing list) http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token While this document has moved to the Apps-Discuss mailing list for the time= being, I wanted to give a quick update to those who have been following th= is draft which originated on this list. The major changes since -02 are: * Removed OAuth terminology and association. The draft is now a general pur= pose HTTP authentication scheme. It does include an OAuth 2.0 binding which= is described in less than a page. One suggestion would be to move section = 5.1 into the OAuth specification and drop all the OAuth 2.0 text from the M= AC draft. * Added 'Set-Cookie' extension for using MAC with session cookies. * Removed request URI query normalization. The new draft uses the raw reque= st URI unchanged. * Replaced timestamps with credentials age to remove the need for clock syn= c. * Added a placeholder for extension, allowing random text to be included in= the request and MAC. * Added issuer attribute for identifying the source of the credentials as a= n additional protection. Draft -04 is not compatible with previous drafts. EHL From peter.wolanin@acquia.com Mon May 9 19:15: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 00BFEE06F1 for ; Mon, 9 May 2011 19:15:53 -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 wKazOcf5OUKL for ; Mon, 9 May 2011 19:15:51 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with SMTP id B4CAAE06B7 for ; Mon, 9 May 2011 19:15:50 -0700 (PDT) Received: from mail-wy0-f180.google.com ([74.125.82.180]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTcif1RVOXHVlLkEzanAgiwh9hWAZe72L@postini.com; Mon, 09 May 2011 19:15:50 PDT Received: by wyj26 with SMTP id 26so6347047wyj.11 for ; Mon, 09 May 2011 19:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.232.41 with SMTP id m41mr5236662weq.31.1304993748054; Mon, 09 May 2011 19:15:48 -0700 (PDT) Received: by 10.216.20.212 with HTTP; Mon, 9 May 2011 19:15:47 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 22:15:47 -0400 Message-ID: From: Peter Wolanin To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters) X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 02:15:53 -0000 I think it's perfectly reasonably - if inside the service you need to rewrite the URI, it's not hard to preserve the original as an extra header or ENV. We have a HMAC-sha1 implementation in production where the load balancer (nginx) may rewrite the URI before passing it to a java app that authenticates the request, so the original URI is set as a new header and used to calculate the HMAC in java. -Peter On Mon, Apr 18, 2011 at 3:26 PM, Eran Hammer-Lahav wr= ote: > I would like to drop all the request URI parameters normalization logic a= nd > just use the raw request URI instead. A year ago during the discussion on= my > Token authentication scheme (which had that behavior specified), some peo= ple > raised the issue that access to the raw request URI isn=E2=80=99t always = possible on > the client or server. This feels like a limitation that is no longer a re= al > problem for any modern web development environment. > > > > If you know of actual deployment issues with using the raw request URI > instead of the parameter parsing and sorting voodoo, please let me know. > Otherwise, the next draft will drop that entire section. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac= quia. Inc. peter.wolanin@acquia.com : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" From peter.wolanin@acquia.com Mon May 9 19:16: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 6B03DE06F1 for ; Mon, 9 May 2011 19:16:55 -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 jOx4pxSH+5Bw for ; Mon, 9 May 2011 19:16:54 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with SMTP id BECB7E06B7 for ; Mon, 9 May 2011 19:16:52 -0700 (PDT) Received: from mail-wy0-f176.google.com ([74.125.82.176]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTcigFJn8ddBH8V0uEJzmdktZ3IreZpVI@postini.com; Mon, 09 May 2011 19:16:53 PDT Received: by wyb40 with SMTP id 40so6625687wyb.35 for ; Mon, 09 May 2011 19:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.4.11 with SMTP id t11mr543277wes.46.1304993465267; Mon, 09 May 2011 19:11:05 -0700 (PDT) Received: by 10.216.20.212 with HTTP; Mon, 9 May 2011 19:11:05 -0700 (PDT) In-Reply-To: <4DC841D7.60504@mitre.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC841D7.60504@mitre.org> Date: Mon, 9 May 2011 22:11:05 -0400 Message-ID: From: Peter Wolanin To: Justin Richer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ben Adida , "Adam Barth \(adam@adambarth.com\)" , OAuth WG Subject: Re: [OAUTH-WG] 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, 10 May 2011 02:16:55 -0000 What about using the cookie header? We have a sha1-HMAC authentication scheme where we are passing the HMAC, nonce, timestamp as parts of the cookie header since scripting languages that cannot access arbitrary headers still usually can access this header. -Peter On Mon, May 9, 2011 at 3:34 PM, Justin Richer wrote: > I would still like to see a binding of this to use query or form paramete= rs. > I have a direct use case for handing out signed URLs to the client, for > which we're using the OAuth 1.0 signing mechanism without tokens today. I= 'd > love to switch to something that we could bind to OAuth2, but the > restriction of using the Auth header puts the MAC token out of reach for = my > immediate usecase. > > =C2=A0-- Justin > > On 5/9/2011 3:22 PM, 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 associati= ng > a MAC key with a session cookie. > > * An OAuth 2.0 binding, providing a method of returning MAC credentials a= s > 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 =E2=80=9Cabused=E2=80=9D for simple client-server authentication (= the poorly named > =E2=80=98two-legged=E2=80=99 use case). This functionality has been separ= ated 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac= quia. Inc. peter.wolanin@acquia.com : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" From trac+oauth@trac.tools.ietf.org Mon May 9 19:28: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 0FA2AE0849 for ; Mon, 9 May 2011 19:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Hr9-eo93J-HP for ; Mon, 9 May 2011 19:28:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 97BFCE06DC for ; Mon, 9 May 2011 19:28:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QJcgN-0004lJ-OU; Mon, 09 May 2011 19:28:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Tue, 10 May 2011 02:28:19 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/8#comment:3 Message-ID: <066.43a57ce1caa090719e68314747705e81@trac.tools.ietf.org> References: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <057.9a63990a1cb32cd95c16da6d299242c5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:28:23 -0000 #8: 4.1.2.1 and 4.2.2.1, text for 4xx or 5xx HTTP status code Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Mon May 9 19:28: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 A1013E06DC for ; Mon, 9 May 2011 19:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 EQW0Jff0hOZO for ; Mon, 9 May 2011 19:28:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7DE08CF for ; Mon, 9 May 2011 19:28:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QJcgW-0004pF-GT; Mon, 09 May 2011 19:28:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Tue, 10 May 2011 02:28:28 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/9#comment:2 Message-ID: <066.53dc2fe66b6b9262e5dd819dce4958c2@trac.tools.ietf.org> References: <057.80f2953d4a1049111596933a3f8cff2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <057.80f2953d4a1049111596933a3f8cff2e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #9: 5.2, text for non-400 & 401 error conditions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:28:29 -0000 #9: 5.2, text for non-400 & 401 error conditions Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: Eran Hammer-Lahav | Owner: Type: suggested change | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Mon May 9 19:28: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 D3B45E0902 for ; Mon, 9 May 2011 19:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 M-WlxmcX5RBq for ; Mon, 9 May 2011 19:28:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 549A9E08EC for ; Mon, 9 May 2011 19:28:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QJcgd-0004sa-4j; Mon, 09 May 2011 19:28:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Tue, 10 May 2011 02:28:35 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/12#comment:1 Message-ID: <059.2ba192f3a8c58dbfd10718073c01a581@trac.tools.ietf.org> References: <050.5a45fca9b64c743145764baea0d685c6@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <050.5a45fca9b64c743145764baea0d685c6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #12: Restore WWW-Authenticate response to the framework specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:28:35 -0000 #12: Restore WWW-Authenticate response to the framework specification Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------------------------- Reporter: Mike Jones | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Mon May 9 19:39: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 1FCDBE0849 for ; Mon, 9 May 2011 19:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 5uCRXZcWxRrS for ; Mon, 9 May 2011 19:39:35 -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 F1B53E06DC for ; Mon, 9 May 2011 19:39:34 -0700 (PDT) Received: by gyf3 with SMTP id 3so2540116gyf.31 for ; Mon, 09 May 2011 19:39:34 -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; bh=Um9w1rYnE6K8BQO78svT1cb52eIloC+vCQRn4GUGyU0=; b=DzjnpAcK5CucqM+TgC1mVG2gHFL0S1v2kOdXsVqzam1oPrU4Ds92qwcZA/tgUAmc0M fbdylt24kEdrXsAkjQ33C6g0QGJ8IjZD/7TmiapiM0qawIAmy7nKw7ZBvWfP/Es61TcR T0knVH7yp2KfAF88+4MVBRJmp+ULfNNgj7E6A= 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; b=or7QTrMYmym5Cq6edDwbKDwlytJ3mCWLXsgVK47Fo2JItJN/IW18cVZtPUyuTYWgWB nGtwy+2e+pMECwxqA43T4/Q/x40uCqYTgH+gHdU+ZdBlzkQCVK1DJZWYGTSgFUZp4P8W 40noHJoIfNjy0NlOZdjRjddiWDnh6OA1uUaxc= MIME-Version: 1.0 Received: by 10.151.99.10 with SMTP id b10mr6687741ybm.49.1304994842753; Mon, 09 May 2011 19:34:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Mon, 9 May 2011 19:34:02 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 22:34:02 -0400 X-Google-Sender-Auth: hH4g-LVLMm2Ft17R6__pBGQb_7U Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth WG Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 02:39:39 -0000 > The problem with re-chartering is that it usually leads to weaker review of > the need to form a working group. When it comes time to deal with the charter item of rechartering, we'll see where the consensus of the working group and the guidance of the ADs go at that time. The consensus may be to recharter, or it may be to close the working group. Having the item on this charter sets a time-frame for the decision. Please don't waste any more time bashing this one. Barry, as chair From hannes.tschofenig@gmx.net Mon May 9 19:46: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 77A74E096B for ; Mon, 9 May 2011 19:46:51 -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 cTF0Gl0BFHwg for ; Mon, 9 May 2011 19:46:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 33925E0849 for ; Mon, 9 May 2011 19:46:49 -0700 (PDT) Received: (qmail invoked by alias); 10 May 2011 02:46:47 -0000 Received: from unknown (EHLO [10.10.172.105]) [212.213.198.101] by mail.gmx.net (mp072) with SMTP; 10 May 2011 04:46:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/S6ihCIi/SFnNx3fcCwgYhL3ZsaDitr5Qg8hz085 Qi5/LfC/X61TSA Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 10 May 2011 05:46:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <06A3914F-0A0A-4046-9ABF-A43E946317A9@gmx.net> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth-ads@tools.ietf.org" , oauth WG Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 02:46:51 -0000 On May 9, 2011, at 10:04 PM, Eran Hammer-Lahav wrote: > I want to see this working group reach its end when this charter is = fulfilled. At that point, a new working group can be requested to work = on other items. The new working group can continue using this list which = I assume will remain open. Eran, it is typically that people find their own work most useful and = relevant. That's great. However, just because you do not want to do = further work (for example because you have moved on to new topics) does = not mean that everyone else shouldn't do anything else either. Please = keep in mind that other folks have higher expectations regarding OAuth = interoperability beyond just having the core specification.=20 Ciao Hannes From eran@hueniverse.com Mon May 9 22:14: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 ACD6AE074D for ; Mon, 9 May 2011 22:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 Rw-YydOszK2h for ; Mon, 9 May 2011 22:14:08 -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 CC043E0696 for ; Mon, 9 May 2011 22:14:08 -0700 (PDT) Received: (qmail 15443 invoked from network); 10 May 2011 05:14:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 05:14:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 May 2011 22:14:08 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig Date: Mon, 9 May 2011 22:14:03 -0700 Thread-Topic: [OAUTH-WG] Revised Charter Thread-Index: AcwOvINt1IPopMzEQXWyLJld/m+CqAAEo61w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA9E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447537EA69E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <397C2659-928A-4FAF-8EC9-100A3691ACE7@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA7F6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA8C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06A3914F-0A0A-4046-9ABF-A43E946317A9@gmx.net> In-Reply-To: <06A3914F-0A0A-4046-9ABF-A43E946317A9@gmx.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 Cc: oauth WG , "oauth-ads@tools.ietf.org" Subject: Re: [OAUTH-WG] Revised Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 05:14:10 -0000 This reply was just uncalled for. I resent the suggestions that my motives here are based on 'moving on to ne= w topics', implying that if I don't want to continue working on OAuth, no o= ne should. My views are based solely on what I believe is in the best interest of this= protocol and the concern that what is now a simple and useful protocol wil= l turn into a goo of premature, designed-by-committee, anti-web extensions.= Most of what I've seen suggested so far falls right into this category. Ex= cuse me if the personal investment I have made in this work (far exceeding = anyone else's) makes me protective of it. EHL > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, May 09, 2011 7:47 PM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; Phil Hunt; oauth WG; oauth-ads@tools.ietf.org > Subject: Re: [OAUTH-WG] Revised Charter >=20 >=20 > On May 9, 2011, at 10:04 PM, Eran Hammer-Lahav wrote: >=20 > > I want to see this working group reach its end when this charter is ful= filled. > At that point, a new working group can be requested to work on other item= s. > The new working group can continue using this list which I assume will re= main > open. >=20 >=20 > Eran, it is typically that people find their own work most useful and rel= evant. > That's great. However, just because you do not want to do further work (f= or > example because you have moved on to new topics) does not mean that > everyone else shouldn't do anything else either. Please keep in mind that > other folks have higher expectations regarding OAuth interoperability > beyond just having the core specification. >=20 > Ciao > Hannes From recordond@gmail.com Mon May 9 23: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 9C0EBE0692 for ; Mon, 9 May 2011 23:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 W63hBSPhfBJ6 for ; Mon, 9 May 2011 23:59:41 -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 72E60E065A for ; Mon, 9 May 2011 23:59:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so5161671wyb.31 for ; Mon, 09 May 2011 23:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=iPpIT0gjsg8wJxRold3ijHjzTHfkqtLHzr3TQKtgIRI=; b=SARS/qM6hjDas3j3i854O7MXxvI0Ba2akcdy8nT79qoRruUj7cV+R26MQ0Z6Zzn4Us IXwW0L0qzJXoGS/Cpx+ex/zb+QWvvCBSbWNgdndMno+qY0vJdK1KuWQdayxzMtCeGI8x C3Pt1mOJk23n6XKLHICi9aEGURZCN6U7okZ9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=liBKHAz2c66T+YzUU/izCFJBO1jBmiloQqIgZiS8+/Z4xWw+CuJagq0qdz8qLXiFkY u+KbHj4Cjl1lwEad60r0HoucjVHMLd+gBldV6HT/IBRQikAHUmS5dI2loOvFGw99Jkja SWrKJnfFbmylf0iM/NGBp+kF8466GkChxEnpw= Received: by 10.227.55.10 with SMTP id s10mr6167034wbg.87.1305010778848; Mon, 09 May 2011 23:59:38 -0700 (PDT) Received: from [10.199.0.98] (vlan5.gw1.ush2.tnib.de [86.110.65.1]) by mx.google.com with ESMTPS id w12sm4192000wby.58.2011.05.09.23.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 23:59:36 -0700 (PDT) References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> X-Mailer: iPad Mail (8H7) From: David Recordon Date: Tue, 10 May 2011 00:00:04 -0700 To: "barryleiba@computer.org" Cc: OAuth WG , Barry Leiba Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 06:59:42 -0000 Haven't seen any followup here but am running into people telling me that th= ey're coming to Facebook. I'm still happy to host, just unclear since I have= n't heard anything. On Apr 22, 2011, at 5:30 PM, Eran Hammer-Lahav wrote: > +1 for Facebook. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of David Recordon >> Sent: Friday, April 22, 2011 2:26 PM >> To: Melinda Shore >> Cc: Barry Leiba; OAuth WG >> Subject: Re: [OAUTH-WG] OAuth Interim Meeting >>=20 >> I can setup audio and video conferencing if it's at Facebook. >>=20 >> On Fri, Apr 22, 2011 at 12:13 PM, Melinda Shore = >> wrote: >>> I'm unable to attend in person but I'm hoping that remote >>> participation will be an option - any hope of that? >>>=20 >>> Thanks, >>>=20 >>> Melinda >>> _______________________________________________ >>> 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 stephen.farrell@cs.tcd.ie Tue May 10 03:24: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 B2DA8E075E for ; Tue, 10 May 2011 03:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 Jpm51mzT9hxa for ; Tue, 10 May 2011 03:24:58 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8BEE0721 for ; Tue, 10 May 2011 03:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C603C153571; Tue, 10 May 2011 11:24:56 +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=1305023096; bh=AoFoa/XuSD4HQP i44Z/MUHkFmDOSskR0w0HpephRDSU=; b=qKPzd97TtyM2oKEIEnANYW2da+epM0 i4Mu3E6kJdka5eCee9y+CNr5OKfPFyCqfem5jIo1IwkSSomw995M/GMgFywlSnVY 8xr6Gc96L0k/wNw8CxzCndx4KjRdMlJE1Yqj8bYcvj9qtz2AK0jRF62C1CBKvZES JECsdme2vnTr70CRITwSDgFy4rSKpVIdluhAe78HwH1cFrA9ZWtc8koRWC3Scnm5 err2MjdwLDhBXtseEEK7UCptYHoUfvubdW97vtAU03obswG8qJJqaYV9okeYpWf5 8f5w0vdtdWA3bMzpT2an1+TXjPX1Z5Jo//rpzDKlTD7vO4dultsCAGWw== 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 OsgSc2Ki5Ej3; Tue, 10 May 2011 11:24:56 +0100 (IST) Received: from [192.168.240.54] (145.Red-88-3-208.staticIP.rima-tde.net [88.3.208.145]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3BB6E171BFA; Tue, 10 May 2011 11:24:51 +0100 (IST) Message-ID: <4DC91273.8010407@cs.tcd.ie> Date: Tue, 10 May 2011 11:24:51 +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: <037D141A-A81D-44D0-AC58-060DA45ACF98@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA82A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA82A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Adam Barth \(adam@adambarth.com\)'" , Ben Adida , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Revised OAuth Charter 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: Tue, 10 May 2011 10:24:59 -0000 Hi Eran, all, On 09/05/11 18:01, Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Hannes Tschofenig >> Sent: Monday, May 09, 2011 4:25 AM > >> Goals and Milestones >> May 2011 Submit 'HTTP Authentication: MAC Authentication' as a >> working group item > > I am still not convinced this is the right working group for this document. This is an active document with a pending -04 version coming this week. Out of 26 pages, only 1 discusses OAuth 2.0 (and 2 more pages handle the registration requirements). My two co-authors, Adam Barth and Ben Adida are not members of this working group. In addition, this working group have shown little to no interest this document to date, offering very limited feedback. > > I much rather keep this document as an individual submission discussed on apps-discuss, and make sure it includes the HTTPbis, HTTP-State, and OAuth working groups in its last call process. > > I would like to hear what the Stephen (security AD) and Peter (application AD) think about the right venue for this draft. I chatted briefly with Peter and think that we're both happy that the mac draft be done in oauth with additional last call(s) in other relevant places, particularly httpbis. Figuring out which places can be done just before wglc here. Part of the logic for doing it here is that without the mac draft, oauth2.0 would appear to be less secure than oauth1.0 which is not an outcome I want to see. Taking the mac draft via some other route would therefore likely result in delay in getting the mac draft done, and hence delay in terms of getting an RFC for oauth2.0. If I think the oauth2.0 spec (or set of specs) sent to me as AD is less secure than oauth1.0 then I'll almost certainly send it back to the wg to fix that. In terms of rechartering this wg - as Barry said the time to discuss that is *after* the current work is done, not now. I'm sure there'll be the usual full and frank discussion on the list at that point:-) Proposing that the wg close at that point is fine and the chairs will I'm sure do a good job of establishing the rough consensus on that then. And finally, as to the use-cases document, the only, but significant, reason to hold it for now, is so it doesn't get in the way of the main work. Even the most innocuous and well-written draft can cause plenty of mail and delay so let's just shelve that draft for a few months and get done with the main goals of the wg. I guess given the spurt of mail I'll wait a few days before pushing the charter onwards in case the chairs want to tweak something. S. From d.tangren@gmail.com Tue May 10 06:25: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 64A68E07C5 for ; Tue, 10 May 2011 06:25:37 -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 MzKBVnFBjq2W for ; Tue, 10 May 2011 06:25:36 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C547E07AD for ; Tue, 10 May 2011 06:25:36 -0700 (PDT) Received: by gwb20 with SMTP id 20so2690766gwb.31 for ; Tue, 10 May 2011 06:25:35 -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=8STGaowndU+iEuQTa6rfsUOeW60ohzewyazuyCkT5+M=; b=dEz5ShoUJs3XJ4LTtdDjKH5GAVKw8NuxmqcyLM8qeGc9X65/HmAnd9NrqBC1tkJL+V 3EBkS5i9AG1jof1kCUBP8iQuZchql9u9sHFQP1xYFXhIBW+IDX/76ZHPsWVPAaJXGrOO KMw7cCNs3tg23Qb+LLApc9uCvggZkV8vOrlVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=vvPbEWe+bbiftaj0GYpFV1RcP7vs3Pd6zqTBnlUSRgTrMvPAKu4iqcPT1YZ/nHjJ3W u6QA8F0bAHeF6Oa9qtUVZumbxMhOSl8M78bfyux4Wd1Z1WnNGAe+2qZk8AZp/hsJ7LGj 2pcVwdz6CstxvwPRhXKZy0HBfRW7pRpg5X6U8= Received: by 10.91.201.18 with SMTP id d18mr6857781agq.31.1305033935130; Tue, 10 May 2011 06:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Tue, 10 May 2011 06:25:15 -0700 (PDT) From: Doug Tangren Date: Tue, 10 May 2011 09:25:15 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636af007d1f8f6c04a2ebe428 Subject: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 13:25:37 -0000 --001636af007d1f8f6c04a2ebe428 Content-Type: text/plain; charset=UTF-8 Hi, I'm implementing an authorization and resource server at worked based on the oauth2 draft 15. A question arose about the user experience of users of an implicit client flow. I've set a one hour expiry on access tokens but now the question is should the client be forced to re-prompt the user for authorization when their receive an error response from the resource server or when they refresh the page? I realize that some implementation details like this are mentioned as being beyond the scope of the spec but I wanted to get a general sense of what the authors and implementors thoughts about how it would actually be used and what is the expected user experience. I also realize that from a server's perspective, without a client secret, authorization code, or other prior evidence of who a request is coming from that there is little way for a server to be permissive about allowing for the refreshing of an access token in an implicit flow. Has there been any conversation around possible alternatives that would permit users of the implicit flow to have the same user experience as the authorization code flow? Thanks -Doug Tangren http://lessis.me --001636af007d1f8f6c04a2ebe428 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

    I'm implementing an authorization and resource server at wor= ked based on the oauth2 draft 15. A question arose about the user experienc= e of users of an implicit client flow.=C2=A0 I've set a one hour expiry= on access tokens but now the question is should the client be forced to re= -prompt the user for authorization when their receive an error response fro= m the resource server or when they refresh the page?

    I realize that some implementation details like this are mentioned as b= eing beyond the scope of the spec but I wanted to get a general sense of wh= at the authors and implementors thoughts about how it would actually be use= d and what is the expected user experience.

    I also realize that from a server's perspective, without a client s= ecret, authorization code, or other prior evidence of who a request is comi= ng from that there is little way for a server to be permissive about allowi= ng for the refreshing of an access token in an implicit flow. Has there bee= n any conversation around possible alternatives that would permit users of = the implicit flow to have the same user experience as the authorization cod= e flow?

    Thanks

    -Doug Tangren
    http://lessis.me
    --001636af007d1f8f6c04a2ebe428-- From eran@hueniverse.com Tue May 10 07:29: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 A449AE07B6 for ; Tue, 10 May 2011 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 P4BuxbiHMVxL for ; Tue, 10 May 2011 07:29: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 88909E0748 for ; Tue, 10 May 2011 07:29:45 -0700 (PDT) Received: (qmail 4338 invoked from network); 10 May 2011 14:29:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 14:29:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 10 May 2011 07:29:38 -0700 From: Eran Hammer-Lahav To: Stephen Farrell Date: Tue, 10 May 2011 07:29:33 -0700 Thread-Topic: [OAUTH-WG] Revised OAuth Charter Text Thread-Index: AcwO/IrJWN3S2P8qS6KProYhFAoARwAIhdVA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DAA4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <037D141A-A81D-44D0-AC58-060DA45ACF98@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447581DA82A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC91273.8010407@cs.tcd.ie> In-Reply-To: <4DC91273.8010407@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: "'Adam Barth \(adam@adambarth.com\)'" , Ben Adida , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Revised OAuth Charter 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: Tue, 10 May 2011 14:29:46 -0000 I can work with that. Thanks. EHL > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, May 10, 2011 3:25 AM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; oauth@ietf.org WG; Peter Saint-Andre > (stpeter@stpeter.im); 'Adam Barth (adam@adambarth.com)'; Ben Adida > Subject: Re: [OAUTH-WG] Revised OAuth Charter Text >=20 >=20 > Hi Eran, all, >=20 > On 09/05/11 18:01, Eran Hammer-Lahav wrote: > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Hannes Tschofenig > >> Sent: Monday, May 09, 2011 4:25 AM > > > >> Goals and Milestones > >> May 2011 Submit 'HTTP Authentication: MAC Authentication' as a > >> working group item > > > > I am still not convinced this is the right working group for this docum= ent. > This is an active document with a pending -04 version coming this week. O= ut > of 26 pages, only 1 discusses OAuth 2.0 (and 2 more pages handle the > registration requirements). My two co-authors, Adam Barth and Ben Adida > are not members of this working group. In addition, this working group ha= ve > shown little to no interest this document to date, offering very limited > feedback. > > > > I much rather keep this document as an individual submission discussed = on > apps-discuss, and make sure it includes the HTTPbis, HTTP-State, and OAut= h > working groups in its last call process. > > > > I would like to hear what the Stephen (security AD) and Peter (applicat= ion > AD) think about the right venue for this draft. >=20 > I chatted briefly with Peter and think that we're both happy that the mac > draft be done in oauth with additional last call(s) in other relevant pla= ces, > particularly httpbis. Figuring out which places can be done just before w= glc > here. >=20 > Part of the logic for doing it here is that without the mac draft, > oauth2.0 would appear to be less secure than oauth1.0 which is not an > outcome I want to see. Taking the mac draft via some other route would > therefore likely result in delay in getting the mac draft done, and hence= delay > in terms of getting an RFC for oauth2.0. > If I think the oauth2.0 spec (or set of specs) sent to me as AD is less s= ecure > than oauth1.0 then I'll almost certainly send it back to the wg to fix th= at. >=20 > In terms of rechartering this wg - as Barry said the time to discuss that= is > *after* the current work is done, not now. I'm sure there'll be the usual= full > and frank discussion on the list at that point:-) Proposing that the wg c= lose at > that point is fine and the chairs will I'm sure do a good job of establis= hing the > rough consensus on that then. >=20 > And finally, as to the use-cases document, the only, but significant, rea= son to > hold it for now, is so it doesn't get in the way of the main work. Even t= he > most innocuous and well-written draft can cause plenty of mail and delay = so > let's just shelve that draft for a few months and get done with the main = goals > of the wg. >=20 > I guess given the spurt of mail I'll wait a few days before pushing the c= harter > onwards in case the chairs want to tweak something. >=20 > S. >=20 From recordond@gmail.com Tue May 10 07:34: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 C0E68E0659 for ; Tue, 10 May 2011 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 g--Fkr1TneKE for ; Tue, 10 May 2011 07:34:40 -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 10D88E072B for ; Tue, 10 May 2011 07:34:39 -0700 (PDT) Received: by fxm15 with SMTP id 15so5125347fxm.31 for ; Tue, 10 May 2011 07:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:content-type:x-mailer:message-id :date:to:content-transfer-encoding:mime-version; bh=/Hf8JO1g415gIlRy9dbAYa4Y4VkJtNApssNgLFdON90=; b=rntRo+BsBIE7HoEhjS1XxRvIs7a7MnBFes0z4rD9dVuWESNBk6oN/VApNNh6Ba+KpI GJ2/1ULxedF3YzN4rDq23GXkXLQAzL41yrNreHZhrY3MeyYjEFSg8EbdS8QCET1/tRle xN5cUY/MISXU0dg+w3m1qmAzlEd9a6Up6lTzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; b=mdUUNkWEO4q/QJ5qnd7NX5//E3Qfw+Dn+l/qv6xP8RC8hExVAubAF18C3U72SVipCz tUX4lyDZA4baRz5wNTjUtwCVh5xrkDIjLDUuqjC0TIoW/38wn+AoRwxXXNpJ6fhO1mu7 r0S/dHRpkhUvPJqjgPkEObGfrd80MJIcYQfRI= Received: by 10.223.121.96 with SMTP id g32mr1523747far.0.1305038078887; Tue, 10 May 2011 07:34:38 -0700 (PDT) Received: from [10.199.0.98] (vlan5.gw1.ush2.tnib.de [86.110.65.1]) by mx.google.com with ESMTPS id l3sm2410499fap.12.2011.05.10.07.34.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 07:34:38 -0700 (PDT) From: David Recordon Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8H7) Message-Id: <5EE856B3-32F0-4229-A575-54283B214267@gmail.com> Date: Tue, 10 May 2011 07:34:58 -0700 To: OAuth WG Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPad Mail 8H7) Subject: [OAUTH-WG] IETF 81 and OSCON X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 14:34:41 -0000 Anyone else noticed that they overlap each other this year? :-/ From jricher@mitre.org Tue May 10 07:41: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 07E8DE06E5 for ; Tue, 10 May 2011 07:41:35 -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 ga4t5Tn6V0BJ for ; Tue, 10 May 2011 07:41:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1DE0659 for ; Tue, 10 May 2011 07:41:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1814021B2019; Tue, 10 May 2011 10:41:32 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 100F021B0F9A; Tue, 10 May 2011 10:41:32 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.159.2; Tue, 10 May 2011 10:41:32 -0400 From: Justin Richer To: Peter Wolanin In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC841D7.60504@mitre.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 May 2011 10:40:10 -0400 Message-ID: <1305038410.4808.7.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: Ben Adida , "Adam Barth \(adam@adambarth.com\)" , OAuth WG Subject: Re: [OAUTH-WG] 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, 10 May 2011 14:41:35 -0000 But that's so much work. :-P The ease of using a throwaway signed URL as a self-contained information unit shouldn't be ignored. It requires exactly zero client-side code and can survive all kinds of HTML repackaging and transit easily. -- Justin On Mon, 2011-05-09 at 22:11 -0400, Peter Wolanin wrote: > What about using the cookie header? > > We have a sha1-HMAC authentication scheme where we are passing the > HMAC, nonce, timestamp as parts of the cookie header since scripting > languages that cannot access arbitrary headers still usually can > access this header. > > -Peter > > On Mon, May 9, 2011 at 3:34 PM, Justin Richer wrote: > > I would still like to see a binding of this to use query or form parameters. > > I have a direct use case for handing out signed URLs to the client, for > > which we're using the OAuth 1.0 signing mechanism without tokens today. I'd > > love to switch to something that we could bind to OAuth2, but the > > restriction of using the Auth header puts the MAC token out of reach for my > > immediate usecase. > > > > -- Justin > > > > On 5/9/2011 3:22 PM, 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 > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > From eran@hueniverse.com Tue May 10 08:05: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 98F7FE0767 for ; Tue, 10 May 2011 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-0.223, 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 gJ5HD14m2CfR for ; Tue, 10 May 2011 08:05:37 -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 3E7E8E0781 for ; Tue, 10 May 2011 08:05:37 -0700 (PDT) Received: (qmail 7122 invoked from network); 10 May 2011 15:05:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 15:05:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 10 May 2011 08:05:21 -0700 From: Eran Hammer-Lahav To: Justin Richer , Peter Wolanin Date: Tue, 10 May 2011 08:05:16 -0700 Thread-Topic: [OAUTH-WG] HTTP MAC Authentication Scheme Thread-Index: AcwPIGeGCL9kXtU+TAmKD0eqQgTVRQAAxpTA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DAA75@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC841D7.60504@mitre.org> <1305038410.4808.7.camel@ground> In-Reply-To: <1305038410.4808.7.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: Ben Adida , OAuth WG , "Adam Barth \(adam@adambarth.com\)" Subject: Re: [OAUTH-WG] 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, 10 May 2011 15:05:38 -0000 SXQgaXMgYSBjb21wZWxsaW5nIHVzZSBjYXNlLCBidXQgb25lIHRoYXQgSSBkbyBub3QgaW50ZW5k IG9uIHNvbHZpbmcgd2l0aGluIHRoZSBNQUMgZHJhZnQgZm9yIG5vdy4gR2V0dGluZyBNQUMgY29v a2llcyBhZG9wdGlvbiBpcyBtdWNoIGhpZ2hlciBvbiBteSBsaXN0IGFuZCBhbnl0aGluZyB0aGF0 IG1ha2VzIHRoZSBzcGVjaWZpY2F0aW9uIGxvbmdlciBhbmQgbW9yZSBjb21wbGV4IHN0YW5kcyBp biB0aGF0IHdheS4NCg0KSG93ZXZlciwgZmVlbCBmcmVlIHRvIHByb3Bvc2UgYSBtZWNoYW5pc20g YW5kIHdlIGNhbiBkaXNjdXNzIHRoYXQuDQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10N Cj4gU2VudDogVHVlc2RheSwgTWF5IDEwLCAyMDExIDc6NDAgQU0NCj4gVG86IFBldGVyIFdvbGFu aW4NCj4gQ2M6IEVyYW4gSGFtbWVyLUxhaGF2OyBCZW4gQWRpZGE7IE9BdXRoIFdHOyBBZGFtIEJh cnRoDQo+IChhZGFtQGFkYW1iYXJ0aC5jb20pDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEhU VFAgTUFDIEF1dGhlbnRpY2F0aW9uIFNjaGVtZQ0KPiANCj4gQnV0IHRoYXQncyBzbyBtdWNoIHdv cmsuIDotUA0KPiANCj4gVGhlIGVhc2Ugb2YgdXNpbmcgYSB0aHJvd2F3YXkgc2lnbmVkIFVSTCBh cyBhIHNlbGYtY29udGFpbmVkIGluZm9ybWF0aW9uDQo+IHVuaXQgc2hvdWxkbid0IGJlIGlnbm9y ZWQuIEl0IHJlcXVpcmVzIGV4YWN0bHkgemVybyBjbGllbnQtc2lkZSBjb2RlIGFuZCBjYW4NCj4g c3Vydml2ZSBhbGwga2luZHMgb2YgSFRNTCByZXBhY2thZ2luZyBhbmQgdHJhbnNpdCBlYXNpbHku DQo+IA0KPiAgLS0gSnVzdGluDQo+IA0KPiBPbiBNb24sIDIwMTEtMDUtMDkgYXQgMjI6MTEgLTA0 MDAsIFBldGVyIFdvbGFuaW4gd3JvdGU6DQo+ID4gV2hhdCBhYm91dCB1c2luZyB0aGUgY29va2ll IGhlYWRlcj8NCj4gPg0KPiA+IFdlIGhhdmUgYSBzaGExLUhNQUMgYXV0aGVudGljYXRpb24gc2No ZW1lIHdoZXJlIHdlIGFyZSBwYXNzaW5nIHRoZQ0KPiA+IEhNQUMsIG5vbmNlLCB0aW1lc3RhbXAg YXMgcGFydHMgb2YgdGhlIGNvb2tpZSBoZWFkZXIgc2luY2Ugc2NyaXB0aW5nDQo+ID4gbGFuZ3Vh Z2VzIHRoYXQgY2Fubm90IGFjY2VzcyBhcmJpdHJhcnkgaGVhZGVycyBzdGlsbCB1c3VhbGx5IGNh bg0KPiA+IGFjY2VzcyB0aGlzIGhlYWRlci4NCj4gPg0KPiA+IC1QZXRlcg0KPiA+DQo+ID4gT24g TW9uLCBNYXkgOSwgMjAxMSBhdCAzOjM0IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJl Lm9yZz4gd3JvdGU6DQo+ID4gPiBJIHdvdWxkIHN0aWxsIGxpa2UgdG8gc2VlIGEgYmluZGluZyBv ZiB0aGlzIHRvIHVzZSBxdWVyeSBvciBmb3JtIHBhcmFtZXRlcnMuDQo+ID4gPiBJIGhhdmUgYSBk aXJlY3QgdXNlIGNhc2UgZm9yIGhhbmRpbmcgb3V0IHNpZ25lZCBVUkxzIHRvIHRoZSBjbGllbnQs DQo+ID4gPiBmb3Igd2hpY2ggd2UncmUgdXNpbmcgdGhlIE9BdXRoIDEuMCBzaWduaW5nIG1lY2hh bmlzbSB3aXRob3V0IHRva2Vucw0KPiA+ID4gdG9kYXkuIEknZCBsb3ZlIHRvIHN3aXRjaCB0byBz b21ldGhpbmcgdGhhdCB3ZSBjb3VsZCBiaW5kIHRvIE9BdXRoMiwNCj4gPiA+IGJ1dCB0aGUgcmVz dHJpY3Rpb24gb2YgdXNpbmcgdGhlIEF1dGggaGVhZGVyIHB1dHMgdGhlIE1BQyB0b2tlbiBvdXQN Cj4gPiA+IG9mIHJlYWNoIGZvciBteSBpbW1lZGlhdGUgdXNlY2FzZS4NCj4gPiA+DQo+ID4gPiAg LS0gSnVzdGluDQo+ID4gPg0KPiA+ID4gT24gNS85LzIwMTEgMzoyMiBQTSwgRXJhbiBIYW1tZXIt TGFoYXYgd3JvdGU6DQo+ID4gPg0KPiA+ID4gKFBsZWFzZSBkaXNjdXNzIHRoaXMgZHJhZnQgb24g dGhlIEFwcHMtRGlzY3Vzcw0KPiA+ID4gPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gbWFpbGluZyBs aXN0KQ0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaGFtbWVyLW9hdXRoLXYyLW1hYy10b2tlbg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K PiA+ID4gVGhlIGRyYWZ0IGluY2x1ZGVzOg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gKiBB biBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB1c2luZyBhIE1BQyBhbGdvcml0aG0gdG8NCj4g PiA+IGF1dGhlbnRpY2F0ZSByZXF1ZXN0cyAodmlhIGEgcHJlLWFycmFuZ2VkIE1BQyBrZXkpLg0K PiA+ID4NCj4gPiA+ICogQW4gZXh0ZW5zaW9uIHRvIHRoZSBTZXQtQ29va2llIGhlYWRlciwgcHJv dmlkaW5nIGEgbWV0aG9kIGZvcg0KPiA+ID4gYXNzb2NpYXRpbmcgYSBNQUMga2V5IHdpdGggYSBz ZXNzaW9uIGNvb2tpZS4NCj4gPiA+DQo+ID4gPiAqIEFuIE9BdXRoIDIuMCBiaW5kaW5nLCBwcm92 aWRpbmcgYSBtZXRob2Qgb2YgcmV0dXJuaW5nIE1BQw0KPiA+ID4gY3JlZGVudGlhbHMgYXMgYW4g YWNjZXNzIHRva2VuLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gU29tZSBiYWNrZ3JvdW5k OiBPQXV0aCAxLjAgaW50cm9kdWNlZCBhbiBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZQ0KPiA+ ID4gdXNpbmcgSE1BQyBmb3IgYXV0aGVudGljYXRpbmcgYW4gSFRUUCByZXF1ZXN0IHdpdGggcGFy dGlhbA0KPiA+ID4gY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9uIG9mIHRoZSBIVFRQIHJlcXVlc3Qg KG5hbWVseSwgdGhlIHJlcXVlc3QgVVJJLA0KPiBob3N0LCBhbmQgcG9ydCkuDQo+ID4gPiBUaGUg T0F1dGggMS4wIHNjaGVtZSB3YXMgZGVzaWduZWQgZm9yIGRlbGVnYXRpb24tYmFzZWQgdXNlIGNh c2VzLA0KPiA+ID4gYnV0IGlzIHdpZGVseSDigJxhYnVzZWTigJ0gZm9yIHNpbXBsZSBjbGllbnQt c2VydmVyIGF1dGhlbnRpY2F0aW9uICh0aGUNCj4gPiA+IHBvb3JseSBuYW1lZCDigJh0d28tbGVn Z2Vk4oCZIHVzZSBjYXNlKS4gVGhpcyBmdW5jdGlvbmFsaXR5IGhhcyBiZWVuDQo+ID4gPiBzZXBh cmF0ZWQgZnJvbSBPQXV0aCAyLjAgYW5kIGhhcyBiZWVuIHJlaW50cm9kdWNlZCBhcyBhIHN0YW5k YWxvbmUsDQo+ID4gPiBnZW5lcmFsbHkgYXBwbGljYWJsZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNj aGVtZSBjYWxsZWQgTUFDLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQ29tbWVudHMgYW5k IGZlZWRiYWNrIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ ID4gPiBFSEwNCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRm Lm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K PiA+ID4NCj4gPiA+DQo+ID4NCj4gPg0KPiA+DQo+IA0KDQo= From jricher@mitre.org Tue May 10 09:00: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 79A9EE083E for ; Tue, 10 May 2011 09:00:07 -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 BJsFtGb0BRin for ; Tue, 10 May 2011 09:00:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 25951E06CC for ; Tue, 10 May 2011 09:00:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE5B621B020E; Tue, 10 May 2011 11:50:53 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B7EC221B01A8; Tue, 10 May 2011 11:50:53 -0400 (EDT) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.159.2; Tue, 10 May 2011 11:50:53 -0400 From: Justin Richer To: Peter Wolanin In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447535BB59D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 May 2011 11:49:31 -0400 Message-ID: <1305042571.4808.21.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC request URI normalization (query parameters) X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 16:00:07 -0000 These could be solved and the whole normalization process thrown out by just restating the string that you signed. It's then up to the server to decide if they want to reparse and validate the request or not, but it gets around url rewriter problems, which I've had definite trouble with in my deployments. Most of the signature problems I've seen in OAuth1.0 stem from the fact that the client and the server effectively have to guess the base string that the other signed by rebuilding it based on the best information that they have. This is all well and good when you've got a custom internet-facing endpoint and you have complete control over the whole stack, but URL rewriters (for example) wreak havoc with these assumptions. For instance, in my Elgg implementation of OAuth, I had to put in workaround code to tell it to ignore some extra input variables that Elgg sets on all requests. By the time it gets to my code, I have no way of telling if the system injected them or if they're in the original URI request at all, so I have to make my best guess and go with that. Yes, it inflates the request size to copy the base string over explicitly, but that's a particular cost I'd be willing to pay for such explicit clarity. -- Justin On Mon, 2011-05-09 at 22:15 -0400, Peter Wolanin wrote: > I think it's perfectly reasonably - if inside the service you need to > rewrite the URI, it's not hard to preserve the original as an extra > header or ENV. > > We have a HMAC-sha1 implementation in production where the load > balancer (nginx) may rewrite the URI before passing it to a java app > that authenticates the request, so the original URI is set as a new > header and used to calculate the HMAC in java. > > -Peter > > On Mon, Apr 18, 2011 at 3:26 PM, Eran Hammer-Lahav wrote: > > I would like to drop all the request URI parameters normalization logic and > > just use the raw request URI instead. A year ago during the discussion on my > > Token authentication scheme (which had that behavior specified), some people > > raised the issue that access to the raw request URI isn’t always possible on > > the client or server. This feels like a limitation that is no longer a real > > problem for any modern web development environment. > > > > > > > > If you know of actual deployment issues with using the raw request URI > > instead of the parameter parsing and sorting voodoo, please let me know. > > Otherwise, the next draft will drop that entire section. > > > > > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > From stpeter@stpeter.im Tue May 10 09:36: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 466F6E0693 for ; Tue, 10 May 2011 09:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 5+Q1gwWNcF6C for ; Tue, 10 May 2011 09:36:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 472FAE0828 for ; Tue, 10 May 2011 09:35:42 -0700 (PDT) Received: from dhcp-64-101-72-221.cisco.com (dhcp-64-101-72-221.cisco.com [64.101.72.221]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AC3C540046 for ; Tue, 10 May 2011 10:35:40 -0600 (MDT) Message-ID: <4DC9695C.9000302@stpeter.im> Date: Tue, 10 May 2011 10:35:40 -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@ietf.org References: <5EE856B3-32F0-4229-A575-54283B214267@gmail.com> In-Reply-To: <5EE856B3-32F0-4229-A575-54283B214267@gmail.com> 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="------------ms020002040905030003040403" Subject: Re: [OAUTH-WG] IETF 81 and OSCON X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 16:36:06 -0000 This is a cryptographically signed message in MIME format. --------------ms020002040905030003040403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/10/11 8:34 AM, David Recordon wrote: > Anyone else noticed that they overlap each other this year? :-/ Yeah, it's a bummer. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020002040905030003040403 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx MDE2MzU0MFowIwYJKoZIhvcNAQkEMRYEFK7oyB2PCvqpSR/s0PY0cU8iJTe9MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCw2KnQ4bZ/uqtqMcUFshab8tm+M7k6UHx8cvxZRb/KSpQ8xfva6lhKsXdy 3E2FEkvXOEBT9FavwopZN0+MMSLG3mKECkDnmA7VEaLFhkM+3aqWbjly0GLFKg77c/ckXygo 1ZPXpU/8dLKsekh8a/GnptzgtQ5ybvrl1Qk3lrIHNWcrv+yrgulhw1uNn0V9rzDHuTaWeOof pt5I30LOIXHhTDQP5h0wOY8Mbamyi/zXZyHD0Hg103/UD1uE9iub55CLuioLRLXOMLEyiK9g eJcJt2srszZblDISWoHe7+Wy9SHZg4NpSxZABrXlgxTuzTnIjqoHKEPFNtM5ZVh+EjM6AAAA AAAA --------------ms020002040905030003040403-- From ietf@adambarth.com Tue May 10 12:18: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 E311DE0878 for ; Tue, 10 May 2011 12:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.408 X-Spam-Level: X-Spam-Status: No, score=-4.408 tagged_above=-999 required=5 tests=[AWL=-1.431, 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 JiG+A8sy44ti for ; Tue, 10 May 2011 12:18:13 -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 06200E0874 for ; Tue, 10 May 2011 12:18:12 -0700 (PDT) Received: by vws12 with SMTP id 12so926375vws.31 for ; Tue, 10 May 2011 12:18:12 -0700 (PDT) Received: by 10.52.76.166 with SMTP id l6mr5296246vdw.102.1305055091768; Tue, 10 May 2011 12:18:11 -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 b24sm2770527vby.7.2011.05.10.12.18.09 (version=SSLv3 cipher=OTHER); Tue, 10 May 2011 12:18:11 -0700 (PDT) Received: by ywi6 with SMTP id 6so2844344ywi.31 for ; Tue, 10 May 2011 12:18:09 -0700 (PDT) Received: by 10.90.21.27 with SMTP id 27mr6935893agu.6.1305055089108; Tue, 10 May 2011 12:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.65.18 with HTTP; Tue, 10 May 2011 12:17:39 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DC841D7.60504@mitre.org> From: Adam Barth Date: Tue, 10 May 2011 12:17:39 -0700 Message-ID: To: Peter Wolanin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Ben Adida , OAuth WG Subject: Re: [OAUTH-WG] 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, 10 May 2011 19:18:14 -0000 On Mon, May 9, 2011 at 7:11 PM, Peter Wolanin wr= ote: > What about using the cookie header? > > We have a sha1-HMAC authentication scheme where we are passing the > HMAC, nonce, timestamp as parts of the cookie header since scripting > languages that cannot access arbitrary headers still usually can > access this header. The Cookie header is extreme fragile. Browser vendors (me included) are reticent to touch it. Additionally, using the Authorization header lets us use the same mechanism for both cookies and OAuth, which means an easier path to adoption for servers. Adam > On Mon, May 9, 2011 at 3:34 PM, Justin Richer wrote: >> I would still like to see a binding of this to use query or form paramet= ers. >> I have a direct use case for handing out signed URLs to the client, for >> which we're using the OAuth 1.0 signing mechanism without tokens today. = I'd >> love to switch to something that we could bind to OAuth2, but the >> restriction of using the Auth header puts the MAC token out of reach for= my >> immediate usecase. >> >> =A0-- Justin >> >> On 5/9/2011 3:22 PM, 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 associat= ing >> 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 usin= g >> 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 =93abused=94 for simple client-server authentication (the poorly = named >> =91two-legged=92 use case). This functionality has been separated from O= Auth 2.0 >> and has been reintroduced as a standalone, generally applicable HTTP >> authentication scheme called MAC. >> >> >> >> Comments and feedback is greatly appreciated. >> >> >> >> EHL >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- > Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist,=A0 Acquia. Inc. > peter.wolanin@acquia.com : 978-296-5247 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" > From mscurtescu@google.com Tue May 10 12:25: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 50543E06C4 for ; Tue, 10 May 2011 12:25:55 -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 Z1hUXhXWlZVN for ; Tue, 10 May 2011 12:25: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 92D0BE069F for ; Tue, 10 May 2011 12:25:54 -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 p4AJFNQI020412 for ; Tue, 10 May 2011 12:15:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305054925; bh=+NtpKVLgoxFJ6ORbQv/vN02aWNI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=J02wU2efUc190l07NXZHAgbx3kYDxHhfd47ftHVD3swL+cOVoONJmjqbFOzEQ4Cme JyAwvexiwEfBJEEY2CUHQ== Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by hpaq14.eem.corp.google.com with ESMTP id p4AJFAvT023926 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 May 2011 12:15:11 -0700 Received: by ywf7 with SMTP id 7so2828173ywf.13 for ; Tue, 10 May 2011 12:15:10 -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=3E3sSS7UcnXuJkHGcPYsKjgF2pbcL5wMeA5IHoZmdnU=; b=hsbWn9QsqKB/K6eEs0u/NgRhNZHXMBz4KhUI26MRXPWqz9scCgoicepABkJuhqKjCX 9dqg2DJeTIWCNLPXaeQg== 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=WvK60sqPDDtrIW2y+b1yy9IdUdIxCcFhWbwgzOo3tMoxsVRWm6r3bfdSu3cYUeXWYa BJZDVUmn3sBkOHx+AbzQ== Received: by 10.100.201.3 with SMTP id y3mr5361337anf.13.1305054910242; Tue, 10 May 2011 12:15:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.46.20 with HTTP; Tue, 10 May 2011 12:14:50 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 10 May 2011 12:14:50 -0700 Message-ID: To: Doug Tangren 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] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 19:25:55 -0000 On Tue, May 10, 2011 at 6:25 AM, Doug Tangren wrote: > Hi, > > I'm implementing an authorization and resource server at worked based on = the > oauth2 draft 15. A question arose about the user experience of users of a= n > implicit client flow.=A0 I've set a one hour expiry on access tokens but = now > the question is should the client be forced to re-prompt the user for > authorization when their receive an error response from the resource serv= er > or when they refresh the page? > > I realize that some implementation details like this are mentioned as bei= ng > beyond the scope of the spec but I wanted to get a general sense of what = the > authors and implementors thoughts about how it would actually be used and > what is the expected user experience. > > I also realize that from a server's perspective, without a client secret, > authorization code, or other prior evidence of who a request is coming fr= om > that there is little way for a server to be permissive about allowing for > the refreshing of an access token in an implicit flow. Has there been any > conversation around possible alternatives that would permit users of the > implicit flow to have the same user experience as the authorization code > flow? This question was raised a few times on this list. The only solution I am aware of is for the authorization server to support auto-approvals and an immediate mode, Auto-approval means that the server will not show the approval page if the same user/scopes/client have already been approved. So as long as the user has an active session the client can get new access tokens in a hidden iframe. If the user session times out then the request in the iframe will hang, the frame will be redirected to a login page. To prevent this the client must be able to tell authorization server that it wants an immediate type request, no UI whatsoever should be shown and if auto-approval is not possible, or not active session, then just return an error. The client then can popup a window and start a regular request, so the user can login and/or approve. Auto-approvals are up to the server to support, no support from the protocol is required. You probably want to support this only for the implicit flow. Immediate mode needs a special request parameter and also a special error code. There is no extension that defines these, the suggestion was that this should go into the OpenID Connect spec, together with a username hint parameter. Hope this helps, Marius From drobin1437@gmail.com Tue May 10 13:37: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 BF02FE07FF for ; Tue, 10 May 2011 13:37:18 -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 S82oLIG61etV for ; Tue, 10 May 2011 13:37:17 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A865AE0663 for ; Tue, 10 May 2011 13:37:17 -0700 (PDT) Received: by gwb20 with SMTP id 20so2871606gwb.31 for ; Tue, 10 May 2011 13:37:17 -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=pdxQJuYZpv73QdAdG9wn9QbWyhDT1aUFeHFaCL8yNHU=; b=uFl5A0tuONvhCT2MvC4+r5+v8Hd2fA+zlA6PKgfP5QtTXUoiUS/vlrcZs5Ifku2XP/ LIA2MydzNi+nW1WqqKQXFi2uWoIqkqWUm5XIHo0TIyVXwJoRbLoSIXhWZzQOKnNPYCay SMyxAUuZB70dsBrN+32xO7KcxdmdChQrLt4tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rhUGu9Ig5XLCBflleSh+RFA2LbEJItFOZU/C+10PsVJ/LowRtrKrbWR+dg9GBSygLy OPHnBCoXRDVZNhzn5VzeGyNfaC/6h2qcRcqa+xCuHuKlTNQcfnzVpq41MMvcfMqtilmH Lsvzbdwa+W/BDfTM8CsXkROUAFv4mXslv43YM= MIME-Version: 1.0 Received: by 10.150.139.7 with SMTP id m7mr5716262ybd.266.1305059836834; Tue, 10 May 2011 13:37:16 -0700 (PDT) Received: by 10.151.49.5 with HTTP; Tue, 10 May 2011 13:37:16 -0700 (PDT) Date: Tue, 10 May 2011 16:37:16 -0400 Message-ID: From: David Robinson To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5bf38fc345204a2f1ebf0 Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 20:37:18 -0000 --000e0cd5bf38fc345204a2f1ebf0 Content-Type: text/plain; charset=ISO-8859-1 Have the plans for the interim meeting been nailed down - including a rough agenda ? (I heard discussion on closing the open issues...anything else that will be discussed ?) Is this still being held at Facebook, 9-6 and were the web conference/dial in numbers arranged ? --000e0cd5bf38fc345204a2f1ebf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Have the plans for the interim meeting been nailed down - including a rough= agenda ?
    (I heard discussion on closing the open issues...anything else= that will be discussed ?)

    Is this still being held at Facebook, 9-6= and were the web conference/dial in numbers arranged ?


    --000e0cd5bf38fc345204a2f1ebf0-- From barryleiba.mailing.lists@gmail.com Tue May 10 14:17: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 C53E7E08D8 for ; Tue, 10 May 2011 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=-0.358, 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 XFcZXPXNCuEH for ; Tue, 10 May 2011 14:17:51 -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 EAFCEE08D4 for ; Tue, 10 May 2011 14:17:50 -0700 (PDT) Received: by gxk19 with SMTP id 19so2927620gxk.31 for ; Tue, 10 May 2011 14:17:50 -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=MoYqbaHu93wovt1UX4ZBOnoo9WJy59O24H4ZvKfO/N8=; b=EksSP9Poi/eKbPPxMPW5TcO/2RjjrBXDSn7ExdyFqaGIvu4wb/kgWR5voY03YpLNRF UPcJh8ApSnRVx3Se6oPC8IxFa9XLiPTjBxTVU5Y1bpGkpIeCa3HZEyTV4pEor+gwHUS2 67YqGi6DZeIM6p7zk3V1B912EMs6UoRls5X18= 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=qckyaJTu1OtYriuXDGXIQJyGyXu1JWoUGm9un9RVBCWPVbL9385+6vB2a2pw0BAZKu 85wLxFMYakUuXcF8trq/3koDmKvVirlBT3gzakYxzJv+23nCUop5m7RelJmKif6oA6x1 Tjn8eocMsuvwhq5uGol5lQmb/tvlWdB4Nvxrc= MIME-Version: 1.0 Received: by 10.236.182.229 with SMTP id o65mr9623940yhm.216.1305062270144; Tue, 10 May 2011 14:17:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 14:17:50 -0700 (PDT) In-Reply-To: <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> Date: Tue, 10 May 2011 17:17:50 -0400 X-Google-Sender-Auth: BbJPmGzWvMtkTR_kh7oQMiE3lLU Message-ID: From: Barry Leiba To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 21:17:51 -0000 On Tue, May 10, 2011 at 3:00 AM, David Recordon wrote= : > Haven't seen any followup here but am running into people telling me that > they're coming to Facebook. I'm still happy to host, just unclear since I= haven't > heard anything. Yes, so sorry about that. The chairs would be delighted to accept your offer to host it at Facebook, and thanks! If you post the venue details to this thread, when you have them, I'll update the wiki: =A0 http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting And I remind everyone to PLEASE put your name on the wiki here: =A0 http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeetingAttendance ...if you plan to attend in person, so that David can have an approximate count for his local planning. It also wouldn't go amiss if you'd put your name there with "(remote)" after it, so we can plan for remote participation. On Tue, May 10, 2011 at 4:37 PM, David Robinson wrot= e: > Have the plans for the interim meeting been nailed down - including a rou= gh > agenda ? > (I heard discussion on closing the open issues...anything else that will = be > discussed ?) That is the plan: to clear up all remaining issues that we can with the documents on the (new) charter. If there's time, we can certainly spend it discussing what might come next, including things like the use cases document, the SAML document, and whatever else. Hannes will be the chair in attendance (Blaine and I can't make it -- schedule conflicts), so he'll be in charge of any detailed agenda, and will run the meeting. On Tue, May 10, 2011 at 4:37 PM, David Robinson wrot= e: > Is this still being held at Facebook, 9-6 and were the web conference/dia= l > in numbers arranged ? The other David R does plan to set things up for remote participation. I'm sure he'll post here when he's been able to make arrangements. Barry, as chair From recordond@gmail.com Tue May 10 14:22: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 AFA0CE08D4 for ; Tue, 10 May 2011 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.715, 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 XEV4gUQaTtjd for ; Tue, 10 May 2011 14:22:15 -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 4FC60E0888 for ; Tue, 10 May 2011 14:22:15 -0700 (PDT) Received: by vxg33 with SMTP id 33so1556749vxg.31 for ; Tue, 10 May 2011 14:22:14 -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=S7ECFSrc77HwwfrZ+TYXKa8jtHYgbkusU6D5KxjmKHM=; b=Xtut5j/SCxXP2p5O4B8MCsitS7tZ94A3APNGJJX5q1AtKARazxNtoBNd1Dyoa3MQE3 ghtX/DLggoGXu16DpYoB6eg5hR/p0iEtQvky4qcuL6g+pwz387/WZSvOCT6q2mnPJVd5 Qo7UpgoBRBrQo1mBScWcO9V2dnRAzNWFeHxhA= 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=f7/Lp7ElunJuISIbM3O9Xmldk8UjDRkOtiDqLAUp4XyoArc+xt3B2WLwGFppguHhld H29ajLe5sQNsyYBUBCdwVycx44BDXrQkns1gaxr/KAuI0/A/y1mQpcBYvNMrZqo1MDy5 2QYJ4nmLf0XROAhP3X1dJbD5MpRZPAlrdKnb0= MIME-Version: 1.0 Received: by 10.52.75.227 with SMTP id f3mr111365vdw.74.1305062534324; Tue, 10 May 2011 14:22:14 -0700 (PDT) Received: by 10.52.187.69 with HTTP; Tue, 10 May 2011 14:22:14 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> Date: Tue, 10 May 2011 23:22:14 +0200 Message-ID: From: David Recordon To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 21:22:16 -0000 On Tue, May 10, 2011 at 11:17 PM, Barry Leiba wro= te: > > If you post the venue details to this thread, when you have them, I'll > update the wiki: > =A0=A0 http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting Sure, it's 1050 Page Mill Road in Palo Alto and then head to the lobby of building 1. > And I remind everyone to PLEASE put your name on the wiki here: > =A0=A0 http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeetingAttend= ance > > ...if you plan to attend in person, so that David can have an > approximate count for his local planning. =A0It also wouldn't go amiss > if you'd put your name there with "(remote)" after it, so we can plan > for remote participation. This would be really useful! Trying to understand what size room we'll need as well as lunch plans. > The other David R does plan to set things up for remote participation. > =A0I'm sure he'll post here when he's been able to make arrangements. Current plan is that you'll be able to join either via Skype video or a normal conference call line. From barryleiba.mailing.lists@gmail.com Tue May 10 14:31: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 E36C8E08ED for ; Tue, 10 May 2011 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.331 X-Spam-Level: X-Spam-Status: No, score=-103.331 tagged_above=-999 required=5 tests=[AWL=-0.354, 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 fnViK46vL1LS for ; Tue, 10 May 2011 14:31:03 -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 89424E0726 for ; Tue, 10 May 2011 14:31:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so2932342gxk.31 for ; Tue, 10 May 2011 14:31:02 -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=rJ28pyZ2yck7nfmOPV9C5E3Cr4MYEjkTkv0nBTJepi8=; b=UNI6fI43m3idEVNGrfw3pmD+aDYSLFcesGp35leLp38DdYu2A2Z50+QZbApFQfg/Wr qLzzSuclkS6bJ5X7Xnr02gt1AvBmOaoUPzJZ6BYokddsIVdAJWwpxqoY264JiSzxwAwB cEcX/PrXo/bbzzhp3n4R3CxjyVfP31fJkuFzY= 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=reVpyo5veR/w5dYYT0r0MQjI5sFCmbQU7pqBHQ/+LKr1T0k2yyRDBx/Sb7unYWzMKo UkEfXOqvEVfXPXgB3Y3/4DjuBLNA5aw46zA8acDomeGIETgdHTJ4VgIUfdGeIdtXZNW2 +avkHF1lZRscu0Ea98TRg2/w9D29g0S06i86Q= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr9544311yhn.15.1305063061159; Tue, 10 May 2011 14:31:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 14:31:01 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> Date: Tue, 10 May 2011 17:31:01 -0400 X-Google-Sender-Auth: 6z2SQjHkVM80xmK4wHrM_51m5Ck 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] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 21:31:05 -0000 >> If you post the venue details to this thread, when you have them, I'll >> update the wiki: >> =A0=A0 http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting > > Sure, it's 1050 Page Mill Road in Palo Alto and then head to the lobby > of building 1. I have updated the wiki. Barry From barryleiba.mailing.lists@gmail.com Tue May 10 14:36: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 4E4D4E08F0 for ; Tue, 10 May 2011 14:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 bRFsu3mwqJDG for ; Tue, 10 May 2011 14:36:21 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C97EBE0726 for ; Tue, 10 May 2011 14:36:21 -0700 (PDT) Received: by gwb20 with SMTP id 20so2892655gwb.31 for ; Tue, 10 May 2011 14:36:21 -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; bh=eP2QVMz7FOamNkPOJ5oyN7WIqZfIm1LdMnFw44QRYEc=; b=f8qmKmdcjwtK1d+N+UxNTSzLMgGFHv3jo5mH1IDcMOsVRoaJeYgTtx0d+PZ9vs2b2Y kjnt+uCb0QHff9JJhv/0Q50zcBf5E0/gxRvOVz5dhS+JW9HuMGq7r5n9YThnC0LS46FD g9eifHVBBsHHAv34hwyYVb5DJfHVUnKl4AH9o= 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; b=LPU2asw4TR8J9PgR1Wk3/Rx/ctR7icH0MsIvpm1gaAp0NcRpDDwJPVF/i4PnNf2Tyj 2yfqQCFxXFPT2gD3Z0c1jQGqizNv3rbl4lZD616C+VQnpvbpaRDx5/eVcU082X8GgP3e ym5VtvnWkJbyv9KMx20Svg97kmpqIVgmm0arU= MIME-Version: 1.0 Received: by 10.146.114.26 with SMTP id m26mr6966836yac.30.1305063380795; Tue, 10 May 2011 14:36:20 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 14:36:20 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> Date: Tue, 10 May 2011 17:36:20 -0400 X-Google-Sender-Auth: PGi_KvRvLbeD18GcDusILJMcBM8 Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 21:36:23 -0000 >> Sure, it's 1050 Page Mill Road in Palo Alto and then head to the lobby >> of building 1. > > I have updated the wiki. Hannes has also created an Eventbrite event for people to sign up at: http://oauth-interim.eventbrite.com/ It's very important, for room planning purposes (and lunch, too) that you sign up either on the wiki or on the Eventbrite page [or both; please use the same name and we'll remove dups :-) ]. Conference rooms have limited space, and we'll need to know if we need a bigger room. Barry, as chair From t.lodderstedt@telekom.de Tue May 10 16:43: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 06972E0692 for ; Tue, 10 May 2011 16:43:45 -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 n6V+6KSAhz3K for ; Tue, 10 May 2011 16:43:44 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEEE0662 for ; Tue, 10 May 2011 16:43:41 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail71.telekom.de with ESMTP; 11 May 2011 01:43:35 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Wed, 11 May 2011 01:43:35 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Wed, 11 May 2011 01:43:35 +0200 From: "Lodderstedt, Torsten" To: Marius Scurtescu Date: Wed, 11 May 2011 01:43:32 +0200 Thread-Topic: [OAUTH-WG] oauth2 implicit flow user experience Thread-Index: AcwPSEVLVLc18PTyQO6XEqF6lZtYigAIdEvw Message-Id: <63366D5A116E514AA4A9872D3C53353956F40722D6@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" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 10 May 2011 23:43:45 -0000 Hi Marius, wrt "auto-approval": how is the authorization server supposed to validated = the client's identity in a reliable way? Otherwise another application (usi= ng the id of the legitimate client) could abuse the authorization previousl= y approved by the user as long as the session with the authorization server= is valid. The redirect_uri won't help for all kinds of clients since a nat= ive app could use the correct redirect_uri and nevertheless get access to t= he token.=20 regards, Torsten. > -----Urspr=FCngliche Nachricht----- > Von: Marius Scurtescu [mailto:mscurtescu@google.com] > Gesendet: Dienstag, 10. Mai 2011 21:15 > An: Doug Tangren > Cc: oauth@ietf.org > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience >=20 > On Tue, May 10, 2011 at 6:25 AM, Doug Tangren > wrote: > > Hi, > > > > I'm implementing an authorization and resource server at worked based > on the > > oauth2 draft 15. A question arose about the user experience of users > of an > > implicit client flow.=A0 I've set a one hour expiry on access tokens > but now > > the question is should the client be forced to re-prompt the user for > > authorization when their receive an error response from the resource > server > > or when they refresh the page? > > > > I realize that some implementation details like this are mentioned as > being > > beyond the scope of the spec but I wanted to get a general sense of > what the > > authors and implementors thoughts about how it would actually be used > and > > what is the expected user experience. > > > > I also realize that from a server's perspective, without a client > secret, > > authorization code, or other prior evidence of who a request is > coming from > > that there is little way for a server to be permissive about allowing > for > > the refreshing of an access token in an implicit flow. Has there been > any > > conversation around possible alternatives that would permit users of > the > > implicit flow to have the same user experience as the authorization > code > > flow? >=20 > This question was raised a few times on this list. The only solution I > am aware of is for the authorization server to support auto-approvals > and an immediate mode, >=20 > Auto-approval means that the server will not show the approval page if > the same user/scopes/client have already been approved. So as long as > the user has an active session the client can get new access tokens in > a hidden iframe. >=20 > If the user session times out then the request in the iframe will > hang, the frame will be redirected to a login page. To prevent this > the client must be able to tell authorization server that it wants an > immediate type request, no UI whatsoever should be shown and if > auto-approval is not possible, or not active session, then just return > an error. The client then can popup a window and start a regular > request, so the user can login and/or approve. >=20 > Auto-approvals are up to the server to support, no support from the > protocol is required. You probably want to support this only for the > implicit flow. Immediate mode needs a special request parameter and > also a special error code. There is no extension that defines these, > the suggestion was that this should go into the OpenID Connect spec, > together with a username hint parameter. >=20 > Hope this helps, > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From d.tangren@gmail.com Tue May 10 23: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 848B1E06BD for ; Tue, 10 May 2011 23:38:27 -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 eRhc+HOknCme for ; Tue, 10 May 2011 23:38:26 -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 BA3ADE06A0 for ; Tue, 10 May 2011 23:38:26 -0700 (PDT) Received: by iyn15 with SMTP id 15so104547iyn.31 for ; Tue, 10 May 2011 23:38:26 -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=UxyJqb80Hk+IOT5gezWbC3rKtOxz200ljYl1IHGFsZs=; b=khuMEimRip0OJ5LReQ4K+ouHot2Cdi1xXlU2vW9HH1Z/gtit/VFofOU2QFCRt0/Bc7 AvDNOu8N/G65K5QRVx5qNNKeKFQu06RuWaiBhbAVya/tIriIyTaZOZjY5V7f79LxR6+Q /jDS2Dv+GqwiugUR8nNnUS1oFQRCef85TPJ8Y= 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=cpTXIMw+RjpjaWUsFV3R/A9NdqqybPh59C3d0SXgsBYawuNf1LgSCdTkxstiEI6TPO q9rOK0H6abn3pEUyUaJiqq3AtRM2x7IdNg3VEkB/AIONowToeZd4zKXs4ok8Bm/wP+aV D0Rs4p+0rBYXOub7zMbS2ofwGrYAD55eAHDYI= Received: by 10.42.132.129 with SMTP id d1mr4075292ict.526.1305095906068; Tue, 10 May 2011 23:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Tue, 10 May 2011 23:38:06 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> From: Doug Tangren Date: Wed, 11 May 2011 02:38:06 -0400 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=90e6ba3fcec5e109ee04a2fa5150 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 06:38:27 -0000 --90e6ba3fcec5e109ee04a2fa5150 Content-Type: text/plain; charset=UTF-8 2 questions? 1. Would there be a conference line one could dial into remotely? (I'm in New York City) 2. Is this open to implementors of the spec in addition to it's authors? (I'm currently implementing draft 15 as developer @ meetup.com) -Doug Tangren http://lessis.me --90e6ba3fcec5e109ee04a2fa5150 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2 questions?

    1. Would there be a conference line one cou= ld dial into remotely? (I'm in New York City)

    = 2. Is this open to implementors of the spec in addition to it's authors= ? (I'm currently implementing draft 15 as developer @ meetup.com)


    -Doug Tangren
    http://lessis.me

    --90e6ba3fcec5e109ee04a2fa5150-- From recordond@gmail.com Tue May 10 23:52: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 A35EBE0769 for ; Tue, 10 May 2011 23:52: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 Zdp7HNtX+wuY for ; Tue, 10 May 2011 23:52: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 E75C3E066A for ; Tue, 10 May 2011 23:52:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so159883vxg.31 for ; Tue, 10 May 2011 23:52: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; bh=KyOPocCpW/TOdpEi1Rr6dk/mlS6BSg0LVkdjeznNbdI=; b=QrZz1OhL6NT69zW/e6J4VVFDSnc0VdS6BZoEieXjTukdtJ7dhgi5ZoSriRyMK23H01 nOfCu5wWSvtpxuHlDIHHT2aM/57sU35UlFd6zPaF8HmIiz+03NhjDkBIljEMGkTK5ZQJ GCdQiRnF1hqgwlAQttAHXvbIrvtUCxbQyTrkM= 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=qyboCBTdCfHHE+mKee7d/kRhOpczr7LYPa+qKie8KymVy9DJupTxOslno59ptEgJ7t OxrlmObtWjolwqmGBWYRbYcMkexO1VHIIFjcBZCO62rfdhIxS5YMFMeTes+VWfcmctv8 X2yDK2stF42AnLmpI+PFMPjoyjhbuOLS/cibE= MIME-Version: 1.0 Received: by 10.52.175.73 with SMTP id by9mr266135vdc.154.1305096737271; Tue, 10 May 2011 23:52:17 -0700 (PDT) Received: by 10.52.187.69 with HTTP; Tue, 10 May 2011 23:52:17 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> Date: Wed, 11 May 2011 08:52:17 +0200 Message-ID: From: David Recordon To: Doug Tangren Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 06:52:18 -0000 Yes and yes. Just please add (remote) to your name on the wiki page. On Wed, May 11, 2011 at 8:38 AM, Doug Tangren wrote: > 2 questions? > 1. Would there be a conference line one could dial into remotely? (I'm in > New York City) > 2. Is this open to implementors of the spec in addition to it's authors? > (I'm currently implementing draft 15 as developer @ meetup.com) > > -Doug Tangren > http://lessis.me > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Tue May 10 23:55: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 C26B3E077A for ; Tue, 10 May 2011 23:55:37 -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 dsoOO7J45cwM for ; Tue, 10 May 2011 23:55:37 -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 14644E0779 for ; Tue, 10 May 2011 23:55:37 -0700 (PDT) Received: (qmail 14923 invoked from network); 11 May 2011 06:55:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2011 06:55:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 10 May 2011 23:55:35 -0700 From: Eran Hammer-Lahav To: Doug Tangren , Barry Leiba Date: Tue, 10 May 2011 23:55:29 -0700 Thread-Topic: [OAUTH-WG] OAuth Interim Meeting Thread-Index: AcwPpgxqXafCaefHSjmxLKAprEaElAAAkk1Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DAC3F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.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_90C41DD21FB7C64BB94121FBBC2E723447581DAC3FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 06:55:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAC3FP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhbiBvZmZpY2lhbCBpbnRlcmltIHdvcmtpbmcgZ3JvdXAgbWVldGluZyB3aGljaCBn b2VzIGJ5IGFsbCB0aGUgbm9ybWFsIElFVEYgcnVsZXMgb2Ygc3VjaCBtZWV0aW5ncyBhbmQgaXMg b3BlbiBmb3IgYWxsLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb3VnIFRhbmdyZW4NClNl bnQ6IFR1ZXNkYXksIE1heSAxMCwgMjAxMSAxMTozOCBQTQ0KVG86IEJhcnJ5IExlaWJhDQpDYzog T0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIEludGVyaW0gTWVldGluZw0K DQoyIHF1ZXN0aW9ucz8NCg0KMS4gV291bGQgdGhlcmUgYmUgYSBjb25mZXJlbmNlIGxpbmUgb25l IGNvdWxkIGRpYWwgaW50byByZW1vdGVseT8gKEknbSBpbiBOZXcgWW9yayBDaXR5KQ0KDQoyLiBJ cyB0aGlzIG9wZW4gdG8gaW1wbGVtZW50b3JzIG9mIHRoZSBzcGVjIGluIGFkZGl0aW9uIHRvIGl0 J3MgYXV0aG9ycz8gKEknbSBjdXJyZW50bHkgaW1wbGVtZW50aW5nIGRyYWZ0IDE1IGFzIGRldmVs b3BlciBAIG1lZXR1cC5jb208aHR0cDovL21lZXR1cC5jb20+KQ0KDQoNCi1Eb3VnIFRhbmdyZW4N Cmh0dHA6Ly9sZXNzaXMubWUNCg== --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAC3FP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgaXMg YW4gb2ZmaWNpYWwgaW50ZXJpbSB3b3JraW5nIGdyb3VwIG1lZXRpbmcgd2hpY2ggZ29lcyBieSBh bGwgdGhlIG5vcm1hbCBJRVRGIHJ1bGVzIG9mIHN1Y2ggbWVldGluZ3MgYW5kIGlzIG9wZW4gZm9y IGFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4g b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZiA8L2I+RG91ZyBUYW5ncmVuPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBN YXkgMTAsIDIwMTEgMTE6MzggUE08YnI+PGI+VG86PC9iPiBCYXJyeSBMZWliYTxicj48Yj5DYzo8 L2I+IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBJbnRl cmltIE1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4yIHF1ZXN0aW9u cz88bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4xLiBXb3VsZCB0aGVyZSBiZSBhIGNv bmZlcmVuY2UgbGluZSBvbmUgY291bGQgZGlhbCBpbnRvIHJlbW90ZWx5PyAoSSdtIGluIE5ldyBZ b3JrIENpdHkpPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Mi4gSXMgdGhp cyBvcGVuIHRvIGltcGxlbWVudG9ycyBvZiB0aGUgc3BlYyBpbiBhZGRpdGlvbiB0byBpdCdzIGF1 dGhvcnM/IChJJ20gY3VycmVudGx5IGltcGxlbWVudGluZyBkcmFmdCAxNSBhcyBkZXZlbG9wZXIg QCA8YSBocmVmPSJodHRwOi8vbWVldHVwLmNvbSI+bWVldHVwLmNvbTwvYT4pPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48 YnIgY2xlYXI9YWxsPi1Eb3VnIFRhbmdyZW48YnI+PGEgaHJlZj0iaHR0cDovL2xlc3Npcy5tZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sZXNzaXMubWU8L2E+PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAC3FP3PW5EX1MB01E_-- From julian.reschke@gmx.de Wed May 11 00:35: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 6FD4FE06C1 for ; Wed, 11 May 2011 00:35:37 -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 5lGIy3t5DFZl for ; Wed, 11 May 2011 00:35:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 899C4E067B for ; Wed, 11 May 2011 00:35:36 -0700 (PDT) Received: (qmail invoked by alias); 11 May 2011 07:35:34 -0000 Received: from p508FCB45.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.203.69] by mail.gmx.net (mp051) with SMTP; 11 May 2011 09:35:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ycdEZXS1ymTatVsR3yakFliwDrPK8xNFqwoFuod OJi1/EJxayn1At Message-ID: <4DCA3C42.2090101@gmx.de> Date: Wed, 11 May 2011 09:35:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723447581DA816@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA816@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG) X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 07:35:37 -0000 On 09.05.2011 18:49, Eran Hammer-Lahav wrote: > ... > The OAuth WG is seeking guidance on the following questions: > > 1. Should the WG define a general purpose method for returning errors with a 401 WWW-Authenticate headers, including a cross-scheme error code registry? > ... Not sure. Are there error conditions servers *want* to reveal, and which also have interoperable implications for clients across authentication schemes? That is, can they really be re-used? If that's the case, a standalone document defining these parameters, with an easy way for new schemes to include these params would make sense. > ... > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 > ... That being said, here are a few comments about the aforementioned spec. error = "error" "=" quoted-string error-desc = "error_description" "=" quoted-string error-uri = "error_uri" = <"> URI-reference <"> This probably should be error = "error" "=" quoted-string error-desc = "error_description" "=" quoted-string error-uri = "error_uri" "=" DQUOT URI-reference DQUOT (missing quotes around the "=", and also please avoid prose productions). Also, you do seem to ignore I18N issues with the error_description. What's the encoding? (and, as a matter of taste, I'd prefer hyphens instead of underscores in parameter names...). Best regards, Julian From barryleiba@gmail.com Wed May 11 06:21: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 01D00E06AF for ; Wed, 11 May 2011 06:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=1.299, 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 0DzOPJcJaner for ; Wed, 11 May 2011 06:21:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75C98E067E for ; Wed, 11 May 2011 06:21:15 -0700 (PDT) Received: by gwb20 with SMTP id 20so198346gwb.31 for ; Wed, 11 May 2011 06:21:14 -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; bh=oj4log2XwpWI9pUSG/TdRq+PdCdo3yDGkcvVgiVnCAQ=; b=Fnyf2Vsfh5T6GzvmxB3VZkNi0qvXGZgRquqeBUopav+N1yHDGpL46S5WfTNqX+ps0Q /87LBz76oOAC8fgiFF3Sk3j/FWrz9G0Yt/kkCKi4xFERgx+yAkoTiLM/oK7KI+aUbjAK 0a9pwSKzNmJEAzWeXpsot+4zLflaXUlCNt5fw= 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; b=XGHGiE7rVzt++kWk5mUjQiv4+Vde0MErI3P2z0mW1HsLb55TDx0711f1HwYcrX70mT avdrzmP9q9lE1QW07dCgHE4xo5K6a0M4OxzCa+5mj+783IAMhmqOnys4i+6Ity+qDCwc eCgzYKhS+4kJ1lecCISklGLZR7/o/8ZhR3BXo= MIME-Version: 1.0 Received: by 10.236.200.135 with SMTP id z7mr9831929yhn.146.1305120073811; Wed, 11 May 2011 06:21:13 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.108.49 with HTTP; Wed, 11 May 2011 06:21:12 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DAC3F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447581DAC3F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 11 May 2011 09:21:12 -0400 X-Google-Sender-Auth: qw6lhSJIZqElnPFBX3sClPNLdes Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 13:21:17 -0000 Doug says... > 2. Is this open to implementors of the spec in addition to it's authors? > (I'm currently implementing draft 15 as developer @ meetup.com) Eran says... > This is an official interim working group meeting which goes by all the > normal IETF rules of such meetings and is open for all. Indeed, thanks, Eran, for the reminder here. Yes, this is an open meeting -- there are NO restrictions on who may attend, other than that we ask people to sign up in advance so the logistics can be properly set up. We hope to have a room full of people who want to spend the day finishing up the OAuth specs by getting the issues resolved -- negotiating and coming up with compromises where necessary. And the meeting is also covered by the IETF's "Note Well" (as is this mailing list). Anyone who needs a reminder of what that says can look here: http://www.ietf.org/about/note-well.html Barry, as chair From d.tangren@gmail.com Wed May 11 06:30: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 65A62E0680 for ; Wed, 11 May 2011 06:30:28 -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 bVB7nA0rwKFz for ; Wed, 11 May 2011 06:30:27 -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 C3B97E067E for ; Wed, 11 May 2011 06:30:27 -0700 (PDT) Received: by yic13 with SMTP id 13so202036yic.31 for ; Wed, 11 May 2011 06:30: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:from:date :message-id:subject:to:cc:content-type; bh=vJxSZ0LkSTdmetiEEUBQ9RH9Vg1tpd1kF9GkgCH0BNs=; b=hiSkxjzrDmwPXWNTLinYlwWABjKTSlAshchoIIgNcqRPsEXLzrPk6s1Mcend5Wnz9N NDJtlZnV0u+267wmjAd5mmLkJ2/wiF1JdMOrCktqX/OLhB83a2PAwIWFHNXSzu1vE3Yb 5LGur6ZMBEf9WD1bTDY0RcdI3mvmQouYjZOSU= 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=a8L6WKe0aIh35HeSboVqTG5ag2PC6DlBFtRoTYt4D+J66HVOxa4k3hirW00i2fSNy6 KhHyKnIiIDZuf/2kWd+NCDzzQ+ezUX3ZkOsZa+gztfZ3uEVCGmpMfvL52/sE6ThHd8e+ P8Zok+zGM7hn0eh1ztkL4DUGVnEgz/u2hvbMQ= Received: by 10.91.201.18 with SMTP id d18mr7958080agq.31.1305120627152; Wed, 11 May 2011 06:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Wed, 11 May 2011 06:30:07 -0700 (PDT) In-Reply-To: References: <4B4CDF58-AF92-4660-AB05-20C3CF8FCAEB@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723447535BBFAC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5D93E40C-D5BA-4E13-976F-6CEE7790686B@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447581DAC3F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Doug Tangren Date: Wed, 11 May 2011 09:30:07 -0400 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001636af007d5ed92904a300130a Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 13:30:28 -0000 --001636af007d5ed92904a300130a Content-Type: text/plain; charset=UTF-8 Thanks guys. Added my name to the list. -Doug Tangren http://lessis.me --001636af007d5ed92904a300130a Content-Type: text/html; charset=UTF-8 Thanks guys. Added my name to the list.

    -Doug Tangren
    http://lessis.me

    --001636af007d5ed92904a300130a-- From Internet-Drafts@ietf.org Wed May 11 10:00: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 E121BE0864; Wed, 11 May 2011 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 Pe51YCk-XrYq; Wed, 11 May 2011 10:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890FAE0861; Wed, 11 May 2011 10:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110511170002.9796.94333.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2011 10:00:02 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-http-mac-00.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: Wed, 11 May 2011 17:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : HTTP Authentication: MAC Access Authentication Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-http-mac-00.txt Pages : 26 Date : 2011-05-11 This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type, as well as an extension attribute to the HTTP Set-Cookie response header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-http-mac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-11094631.I-D@ietf.org> --NextPart-- From mscurtescu@google.com Wed May 11 11:28: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 352F4E086B for ; Wed, 11 May 2011 11:28:38 -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 O4R-fRNn3h+i for ; Wed, 11 May 2011 11:28:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB3EE0869 for ; Wed, 11 May 2011 11:28:37 -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 p4BISZps028444 for ; Wed, 11 May 2011 11:28:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305138516; bh=/dL6AiwGQCJFiCyOJUX92O1MHdI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ctFj48rKaMUGCTgwG2eJV9g1ZfAiJbcApEOM48Nvw1xEP34dnFNQl7b8KSEOLhsWX NOGVOI1Sl7Hlt/OKvO1GA== Received: from gya6 (gya6.prod.google.com [10.243.49.6]) by kpbe14.cbf.corp.google.com with ESMTP id p4BISJOa017963 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 May 2011 11:28:34 -0700 Received: by gya6 with SMTP id 6so368662gya.35 for ; Wed, 11 May 2011 11:28:34 -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=mGYntXVoV3Xs/eyMaW3gGLiYGUjeeeZl6sBqLw3DXT4=; b=gsNUTTv9ZJP/YzN/JSNiwV+y4wxCXSFlFpDr+yHY2tp12OAVoYL5JsthKDXTYTOLEt CgsxdStLK0zi68XSL2Vw== 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=CgIekly2KFbWDM64QK33EIQcuW48LOmz4gpJTJXU5gfeSWqHforkhF1IJhzaoEbDce T8G8pSKL7JqQ+dUs6Kgg== Received: by 10.100.201.3 with SMTP id y3mr250981anf.13.1305138514148; Wed, 11 May 2011 11:28:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.46.20 with HTTP; Wed, 11 May 2011 11:28:14 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> From: Marius Scurtescu Date: Wed, 11 May 2011 11:28:14 -0700 Message-ID: To: "Lodderstedt, Torsten" 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] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 18:28:38 -0000 On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten wrote: > Hi Marius, > > wrt "auto-approval": how is the authorization server supposed to validate= d the client's identity in a reliable way? Otherwise another application (u= sing the id of the legitimate client) could abuse the authorization previou= sly approved by the user as long as the session with the authorization serv= er is valid. The redirect_uri won't help for all kinds of clients since a n= ative app could use the correct redirect_uri and nevertheless get access to= the token. The only validation is based on the redirect URI. Native apps should not use the implicit flow, and in general there is no need for auto-approval for them. Marius From breno.demedeiros@gmail.com Wed May 11 11:32: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 19F07E0823 for ; Wed, 11 May 2011 11:32:35 -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 FV1c0SCB8VoA for ; Wed, 11 May 2011 11:32:34 -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 28737E066E for ; Wed, 11 May 2011 11:32:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so486283pzk.31 for ; Wed, 11 May 2011 11:32: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:date :message-id:subject:from:to:cc:content-type; bh=nJ1XW9yQmutqvuPpXC+KPvh0Ps99e0uej2s3OfvEueY=; b=VeZAImGIc1tCbhznngzQ7OdR0ERW9YgMAyD14MNh/lwYlzVRs1qtyI/za544vSRJTP 0xROxWoI0pfTDaIkoZOlvFkUC/aDBPqVka5p6JG5/G6g0oGvDPZoxYUvB/g2i+xZc09C Cikc8XRA/PJCYLTxtl8uVBMM/aDzi42J/LgGg= 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=hSLyoaemi00ZXfcC4u6xiexLkPZYqsLLLfgxeTQ9QtjPKf2SyEtTU4OwYqWNp/1OhK PVvBbJK/OGdVxL6x6bKWpAtYIhx4IL2J5QDgKrKx7fRwnN8Zd4RjAfGn9g0wfdVRe4f6 o2L3AnfJ+WjRacyCWmmLRsBpovZcq5cEuGydg= MIME-Version: 1.0 Received: by 10.68.60.135 with SMTP id h7mr4899817pbr.457.1305138753573; Wed, 11 May 2011 11:32:33 -0700 (PDT) Received: by 10.68.50.106 with HTTP; Wed, 11 May 2011 11:32:33 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> Date: Wed, 11 May 2011 11:32:33 -0700 Message-ID: From: Breno To: "Lodderstedt, Torsten" Content-Type: multipart/alternative; boundary=bcaec5430bd2ca152a04a3044b2b Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 18:32:35 -0000 --bcaec5430bd2ca152a04a3044b2b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten < t.lodderstedt@telekom.de> wrote: > Hi Marius, > > wrt "auto-approval": how is the authorization server supposed to validate= d > the client's identity in a reliable way? Otherwise another application > (using the id of the legitimate client) could abuse the authorization > previously approved by the user as long as the session with the > authorization server is valid. The redirect_uri won't help for all kinds = of > clients since a native app could use the correct redirect_uri and > nevertheless get access to the token. > A native app that can screen scrape the browser can probably also install a keylogger. It would be very difficult or impossible to protect against a malicious native app with access to shared OS resources. > regards, > Torsten. > > > -----Urspr=FCngliche Nachricht----- > > Von: Marius Scurtescu [mailto:mscurtescu@google.com] > > Gesendet: Dienstag, 10. Mai 2011 21:15 > > An: Doug Tangren > > Cc: oauth@ietf.org > > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience > > > > On Tue, May 10, 2011 at 6:25 AM, Doug Tangren > > wrote: > > > Hi, > > > > > > I'm implementing an authorization and resource server at worked based > > on the > > > oauth2 draft 15. A question arose about the user experience of users > > of an > > > implicit client flow. I've set a one hour expiry on access tokens > > but now > > > the question is should the client be forced to re-prompt the user for > > > authorization when their receive an error response from the resource > > server > > > or when they refresh the page? > > > > > > I realize that some implementation details like this are mentioned as > > being > > > beyond the scope of the spec but I wanted to get a general sense of > > what the > > > authors and implementors thoughts about how it would actually be used > > and > > > what is the expected user experience. > > > > > > I also realize that from a server's perspective, without a client > > secret, > > > authorization code, or other prior evidence of who a request is > > coming from > > > that there is little way for a server to be permissive about allowing > > for > > > the refreshing of an access token in an implicit flow. Has there been > > any > > > conversation around possible alternatives that would permit users of > > the > > > implicit flow to have the same user experience as the authorization > > code > > > flow? > > > > This question was raised a few times on this list. The only solution I > > am aware of is for the authorization server to support auto-approvals > > and an immediate mode, > > > > Auto-approval means that the server will not show the approval page if > > the same user/scopes/client have already been approved. So as long as > > the user has an active session the client can get new access tokens in > > a hidden iframe. > > > > If the user session times out then the request in the iframe will > > hang, the frame will be redirected to a login page. To prevent this > > the client must be able to tell authorization server that it wants an > > immediate type request, no UI whatsoever should be shown and if > > auto-approval is not possible, or not active session, then just return > > an error. The client then can popup a window and start a regular > > request, so the user can login and/or approve. > > > > Auto-approvals are up to the server to support, no support from the > > protocol is required. You probably want to support this only for the > > implicit flow. Immediate mode needs a special request parameter and > > also a special error code. There is no extension that defines these, > > the suggestion was that this should go into the OpenID Connect spec, > > together with a username hint parameter. > > > > Hope this helps, > > 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 > --=20 Breno de Medeiros --bcaec5430bd2ca152a04a3044b2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, May 10, 2011 at 4:43 PM, Lodders= tedt, Torsten <t.lodderstedt@telekom.de> wrote:
    Hi Marius,

    wrt "auto-approval": how is the authorization server supposed to = validated the client's identity in a reliable way? Otherwise another ap= plication (using the id of the legitimate client) could abuse the authoriza= tion previously approved by the user as long as the session with the author= ization server is valid. The redirect_uri won't help for all kinds of c= lients since a native app could use the correct redirect_uri and neverthele= ss get access to the token.

    A native app that can screen scrape the br= owser can probably also install a keylogger. It would be very difficult or = impossible to protect against a malicious native app with access to shared = OS resources.=A0


    regards,
    Torsten.

    > -----Urspr=FCngliche Nachricht-----
    > Von: Marius Scurtescu [mailto:mscurtescu@google.com]
    > Gesendet: Dienstag, 10. Mai 2011 21:15
    > An: Doug Tangren
    > Cc: oauth@ietf.org
    > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience
    >
    > On Tue, May 10, 2011 at 6:25 AM, Doug Tangren <d.tangren@gmail.com>
    > wrote:
    > > Hi,
    > >
    > > I'm implementing an authorization and resource server at work= ed based
    > on the
    > > oauth2 draft 15. A question arose about the user experience of us= ers
    > of an
    > > implicit client flow.=A0 I've set a one hour expiry on access= tokens
    > but now
    > > the question is should the client be forced to re-prompt the user= for
    > > authorization when their receive an error response from the resou= rce
    > server
    > > or when they refresh the page?
    > >
    > > I realize that some implementation details like this are mentione= d as
    > being
    > > beyond the scope of the spec but I wanted to get a general sense = of
    > what the
    > > authors and implementors thoughts about how it would actually be = used
    > and
    > > what is the expected user experience.
    > >
    > > I also realize that from a server's perspective, without a cl= ient
    > secret,
    > > authorization code, or other prior evidence of who a request is > coming from
    > > that there is little way for a server to be permissive about allo= wing
    > for
    > > the refreshing of an access token in an implicit flow. Has there = been
    > any
    > > conversation around possible alternatives that would permit users= of
    > the
    > > implicit flow to have the same user experience as the authorizati= on
    > code
    > > flow?
    >
    > This question was raised a few times on this list. The only solution I=
    > am aware of is for the authorization server to support auto-approvals<= br> > and an immediate mode,
    >
    > Auto-approval means that the server will not show the approval page if=
    > the same user/scopes/client have already been approved. So as long as<= br> > the user has an active session the client can get new access tokens in=
    > a hidden iframe.
    >
    > If the user session times out then the request in the iframe will
    > hang, the frame will be redirected to a login page. To prevent this > the client must be able to tell authorization server that it wants an<= br> > immediate type request, no UI whatsoever should be shown and if
    > auto-approval is not possible, or not active session, then just return=
    > an error. The client then can popup a window and start a regular
    > request, so the user can login and/or approve.
    >
    > Auto-approvals are up to the server to support, no support from the > protocol is required. You probably want to support this only for the > implicit flow. Immediate mode needs a special request parameter and > also a special error code. There is no extension that defines these, > the suggestion was that this should go into the OpenID Connect spec, > together with a username hint parameter.
    >
    > Hope this helps,
    > Marius
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth



    --
    Breno de Me= deiros

    --bcaec5430bd2ca152a04a3044b2b-- From breno.demedeiros@gmail.com Wed May 11 11:33: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 DDEFAE07F3 for ; Wed, 11 May 2011 11:33: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 1fKiQPQAypGV for ; Wed, 11 May 2011 11:33:52 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E1E066E for ; Wed, 11 May 2011 11:33:52 -0700 (PDT) Received: by pxi2 with SMTP id 2so485725pxi.38 for ; Wed, 11 May 2011 11:33:52 -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=y3bSdi+NQM05R2H0sYyKarEy78z4bjTLGXs112F8/VE=; b=TNPDVKT3RTieKwUKy6g+pekdeIQ2caMmicwrpnw8E7kRPccggV2eWhBHf0gn4/Ml25 us7fsYrh0i0mWV1oDyk97J5/t8SPMUThUbaAlQjq1DWcU6W0xqPGdBoYlsH8dXCGETPF Fdv/gS//DXsvwVOUCYtEd2gU3HPGk7v3hxbrc= 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=tAcZOCwdUF40WmBtD7sNAPvUjVtBYdHozSFYkUEcvy1673zFR7UU4Pqh2dSGoYyJrV VPYIWTxJ7VLoxO4WSXqfFcb6KDFlOZWAFdbdLWw2V4Kjm/EoLj0ByVY7PoiWxhc7I3bp Q55D93yoTC2QbOcL1BB5kQMsG4DYmzbCZIV6s= MIME-Version: 1.0 Received: by 10.68.1.170 with SMTP id 10mr13312833pbn.189.1305138832380; Wed, 11 May 2011 11:33:52 -0700 (PDT) Received: by 10.68.50.106 with HTTP; Wed, 11 May 2011 11:33:52 -0700 (PDT) In-Reply-To: References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> Date: Wed, 11 May 2011 11:33:52 -0700 Message-ID: From: Breno To: "Lodderstedt, Torsten" Content-Type: multipart/alternative; boundary=bcaec531480f7c95ce04a30450f7 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 18:33:54 -0000 --bcaec531480f7c95ce04a30450f7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 11, 2011 at 11:32 AM, Breno wrote: > > > On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten < > t.lodderstedt@telekom.de> wrote: > >> Hi Marius, >> >> wrt "auto-approval": how is the authorization server supposed to validat= ed >> the client's identity in a reliable way? Otherwise another application >> (using the id of the legitimate client) could abuse the authorization >> previously approved by the user as long as the session with the >> authorization server is valid. The redirect_uri won't help for all kinds= of >> clients since a native app could use the correct redirect_uri and >> nevertheless get access to the token. >> > > A native app that can screen scrape the browser can probably also install= a > keylogger. It would be very difficult or impossible to protect against a > malicious native app with access to shared OS resources. > By which I mean we should consider protection against apps with such capabilities a non-goal for this protocol and not an impediment to enabling of auto-approval modes. > > >> regards, >> Torsten. >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: Marius Scurtescu [mailto:mscurtescu@google.com] >> > Gesendet: Dienstag, 10. Mai 2011 21:15 >> > An: Doug Tangren >> > Cc: oauth@ietf.org >> > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience >> > >> > On Tue, May 10, 2011 at 6:25 AM, Doug Tangren >> > wrote: >> > > Hi, >> > > >> > > I'm implementing an authorization and resource server at worked base= d >> > on the >> > > oauth2 draft 15. A question arose about the user experience of users >> > of an >> > > implicit client flow. I've set a one hour expiry on access tokens >> > but now >> > > the question is should the client be forced to re-prompt the user fo= r >> > > authorization when their receive an error response from the resource >> > server >> > > or when they refresh the page? >> > > >> > > I realize that some implementation details like this are mentioned a= s >> > being >> > > beyond the scope of the spec but I wanted to get a general sense of >> > what the >> > > authors and implementors thoughts about how it would actually be use= d >> > and >> > > what is the expected user experience. >> > > >> > > I also realize that from a server's perspective, without a client >> > secret, >> > > authorization code, or other prior evidence of who a request is >> > coming from >> > > that there is little way for a server to be permissive about allowin= g >> > for >> > > the refreshing of an access token in an implicit flow. Has there bee= n >> > any >> > > conversation around possible alternatives that would permit users of >> > the >> > > implicit flow to have the same user experience as the authorization >> > code >> > > flow? >> > >> > This question was raised a few times on this list. The only solution I >> > am aware of is for the authorization server to support auto-approvals >> > and an immediate mode, >> > >> > Auto-approval means that the server will not show the approval page if >> > the same user/scopes/client have already been approved. So as long as >> > the user has an active session the client can get new access tokens in >> > a hidden iframe. >> > >> > If the user session times out then the request in the iframe will >> > hang, the frame will be redirected to a login page. To prevent this >> > the client must be able to tell authorization server that it wants an >> > immediate type request, no UI whatsoever should be shown and if >> > auto-approval is not possible, or not active session, then just return >> > an error. The client then can popup a window and start a regular >> > request, so the user can login and/or approve. >> > >> > Auto-approvals are up to the server to support, no support from the >> > protocol is required. You probably want to support this only for the >> > implicit flow. Immediate mode needs a special request parameter and >> > also a special error code. There is no extension that defines these, >> > the suggestion was that this should go into the OpenID Connect spec, >> > together with a username hint parameter. >> > >> > Hope this helps, >> > 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 >> > > > > -- > Breno de Medeiros > > --=20 Breno de Medeiros --bcaec531480f7c95ce04a30450f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, May 11, 2011 at 11:32 AM, Breno = <breno.d= emedeiros@gmail.com> wrote:
    On Tue, May 10, 2011 a= t 4:43 PM, Lodderstedt, Torsten <t.lodderstedt@telekom.de> wrote:
    Hi Marius,

    wrt "auto-approval": how is the authorization server supposed to = validated the client's identity in a reliable way? Otherwise another ap= plication (using the id of the legitimate client) could abuse the authoriza= tion previously approved by the user as long as the session with the author= ization server is valid. The redirect_uri won't help for all kinds of c= lients since a native app could use the correct redirect_uri and neverthele= ss get access to the token.

    A native app that can screen scrape = the browser can probably also install a keylogger. It would be very difficu= lt or impossible to protect against a malicious native app with access to s= hared OS resources.=A0

    By which I mean we should consider p= rotection against apps with such capabilities a non-goal for this protocol = and not an impediment to enabling of auto-approval modes.
    =A0
    =


    regards,
    Torsten.

    > -----Urspr=FCngliche Nachricht-----
    > Von: Marius Scurtescu [mailto:mscurtescu@google.com]
    > Gesendet: Dienstag, 10. Mai 2011 21:15
    > An: Doug Tangren
    > Cc: oauth@ietf.org=
    > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience
    >
    > On Tue, May 10, 2011 at 6:25 AM, Doug Tangren <d.tangren@gmail.com>
    > wrote:
    > > Hi,
    > >
    > > I'm implementing an authorization and resource server at work= ed based
    > on the
    > > oauth2 draft 15. A question arose about the user experience of us= ers
    > of an
    > > implicit client flow.=A0 I've set a one hour expiry on access= tokens
    > but now
    > > the question is should the client be forced to re-prompt the user= for
    > > authorization when their receive an error response from the resou= rce
    > server
    > > or when they refresh the page?
    > >
    > > I realize that some implementation details like this are mentione= d as
    > being
    > > beyond the scope of the spec but I wanted to get a general sense = of
    > what the
    > > authors and implementors thoughts about how it would actually be = used
    > and
    > > what is the expected user experience.
    > >
    > > I also realize that from a server's perspective, without a cl= ient
    > secret,
    > > authorization code, or other prior evidence of who a request is > coming from
    > > that there is little way for a server to be permissive about allo= wing
    > for
    > > the refreshing of an access token in an implicit flow. Has there = been
    > any
    > > conversation around possible alternatives that would permit users= of
    > the
    > > implicit flow to have the same user experience as the authorizati= on
    > code
    > > flow?
    >
    > This question was raised a few times on this list. The only solution I=
    > am aware of is for the authorization server to support auto-approvals<= br> > and an immediate mode,
    >
    > Auto-approval means that the server will not show the approval page if=
    > the same user/scopes/client have already been approved. So as long as<= br> > the user has an active session the client can get new access tokens in=
    > a hidden iframe.
    >
    > If the user session times out then the request in the iframe will
    > hang, the frame will be redirected to a login page. To prevent this > the client must be able to tell authorization server that it wants an<= br> > immediate type request, no UI whatsoever should be shown and if
    > auto-approval is not possible, or not active session, then just return=
    > an error. The client then can popup a window and start a regular
    > request, so the user can login and/or approve.
    >
    > Auto-approvals are up to the server to support, no support from the > protocol is required. You probably want to support this only for the > implicit flow. Immediate mode needs a special request parameter and > also a special error code. There is no extension that defines these, > the suggestion was that this should go into the OpenID Connect spec, > together with a username hint parameter.
    >
    > Hope this helps,
    > Marius
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org=
    > https://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth



    --
    Breno de Medeiros




    --
    Breno de Medeiro= s

    --bcaec531480f7c95ce04a30450f7-- From hannes.tschofenig@gmx.net Wed May 11 11:37: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 0D18AE084F for ; Wed, 11 May 2011 11:37:46 -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 4K4jPxel18vk for ; Wed, 11 May 2011 11:37:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 35E00E0693 for ; Wed, 11 May 2011 11:37:19 -0700 (PDT) Received: (qmail invoked by alias); 11 May 2011 18:37:15 -0000 Received: from static-141-156-107-130.res.east.verizon.net (EHLO [192.168.1.21]) [141.156.107.130] by mail.gmx.net (mp056) with SMTP; 11 May 2011 20:37:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ExdwFNj8ERZCI2c/nGkxU9bwWGbJ1uOwsLQ4bw8 x3qKPPqXLSvHdg Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Wed, 11 May 2011 21:37:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7376795F-D9DC-4A9E-8CB0-C49E8AE368D9@gmx.net> References: To: oauth WG X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Fwd: OAuth Security Consideration 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, 11 May 2011 18:37:46 -0000 Breno did a review of the security draft. Thanks a lot! Begin forwarded message: > From: Breno de Medeiros > Date: May 7, 2011 4:25:53 AM GMT+03:00 > To: Hannes Tschofenig > Subject: Re: OAuth Security Consideration Text >=20 > Hi Hannes, >=20 > I have gone through the test and I have a few edits and questions. >=20 > In the edits below, text between -- -- are supposed the be stricken > out. Example if the original is: >=20 > They quick brown fox ... >=20 > and my suggested edit is: >=20 > --They--The quick brown fox ... >=20 > it means that I am suggesting that you replace the original with >=20 > The quick brown fox ... >=20 > Now edits by section: ------------------------------------- >=20 > IN: Section 1. Definitions >=20 > Web Application .... to the OAuth protocol is--are-- stored on the > server and --is-- not accessible ... >=20 > User Agent-based Application ... they can seamlessly make use of > --it--its capabilities ... >=20 > IN: Section 2.2 Malicious Client Obtains Authorization >=20 > ... >=20 > Where the client can be --authenticate--authenticated ... >=20 > ... >=20 > It is --higly--highly RECOMMENDED that ... >=20 > IN: Section 2.9 Phishing Attacks >=20 > in which users can confirm the --authentictity--authenticity of the = site. >=20 > -----------------/edits >=20 > Now higher level comments: >=20 > On Native Apps protection of refresh token: >=20 > On section Definitions, there is a sentence in the Native Apps "It is > assumed that such applications can protect dynamically issued secrets, > such as refresh tokens, from eavesdropping by other applications > residing in the same service" >=20 > I suggest that you strike out this sentence from definitions since it > is confusing. This should be moved to section 2.4, with a specific > headed paragraph about management of refresh tokens for native > applications including specific recommendation. >=20 > E.g. of substitution paragraph: >=20 > Native Applications MUST use operating system mediated protections to > ensure that the refresh tokens are safe from unauthorized access by > other users and applications. It is highly RECOMMENDED that such > applications use OS-provided APIs to manage secrets. The applications > MUST apply appropriately restrictive access controls to any file > system or persistent memory objects where the refresh token is stored. >=20 > On Client Authentication: >=20 > "Authorization servers are encouraged to consider stronger client > authentication means" --> This is too vague to be actionable. There is > a great tradition of 'innovation' in client security that promotes no > security and hinders interoperability. I tend to believe that it is > better for servers to be conscious of the limitations of client > authentication and implement mitigation measures than to create ad-hoc > authentication mechanisms. Suggest to strike out this sentence. >=20 > "Authorization server MUST NOT issue client secrets to native or user > agent-based applications in general." -> Agreed on user-agent, however > at least in principle it is possible to issue secrets to native > applications that use hardware-based DRM modules and can hold on to > secrets. More importantly, since the OAuth2 spec no longer actually > specifies how to implement a Native App Flow end-to-end, I am not sure > how to even reason about Native App issues. Propose simply strike out > 'native or'. >=20 > On Malicious Client Obtains Authorization: >=20 > "Authorization servers MUST NOT automatically process (without user > interaction) repeated authorizations without authenticating the > client." -> Not sure what to make of this sentence. If this implies > User-Agent should not support automatic renewal of access tokens > (since user-agent apps cannot be 'authenticated'), then it is a > harmful recommendation because it ignores practical requirements. The > bad word here is 'authenticating', since what is really intended is > some assurance that it is the same client, e.g., the redirect URI > matches a registered value in the User-Agent case. Please strike out > this sentence or substitute it with one like: >=20 > "Authorization servers MUST implement measures to ensure that > automatically issued tokens (without user interaction, based on > previously recorded grant) are delivered to the same client to whom > original grant was performed. Example of suitable measures are > enforcing client authentication or enforcing that the destination of a > redirect (in case of implicit grant) matches the expected value for > the client." >=20 > On Access Tokens >=20 > "Application developers MUST NOT store access tokens in non-transient > memory." -> This is not realistic -- consider the case of a Web > Application running on distributed servers. It is quite possible that > the only distributed storage mechanism available to the application is > based on persistent storage. I suggest you strike out this sentence, > since the previous one is sufficient. >=20 > On Session Fixation >=20 > This section needs to cover XSRF protection, the measures described > within are insufficient for Web Applications or User-Agent-Based > applications. Also the current mitigation described there is better > described as a mitigation against token/code leakage. >=20 > I suggest that you create a new section: >=20 > =3D=3D > Token and Code Leakage via Referer Header and/Or Open Redirectors >=20 > Attackers can leverage inclusion of third party content (images, ads) > and/or the presence of redirectors in legitimate Web or > User-Agent-Based Applications to steal codes and/or tokens issued to > such sites. >=20 > "In order to prevent such attack ..." (move here the 2nd paragraph > that currently lives on Session Fixation) >=20 > Now for the Session Fixation section, I would recommend that you > expand it to also include 'token', since the attack is also possible > via token. >=20 > The Session fixation attack involves an attacker that forwards a link > to an unsuspecting victim. The victim clicks on the link and > subsequently approves an expected application but as a result the > attacker obtains access to the victim's data either at application or > at the authorization server. >=20 > In order to prevent such attack, a Web or User-Agent-Based application > MUST bind the state of authorization requests to the user's session > with the application. This requires that the Application generate a > strongly unguessable random number, and both include it in the 'state' > parameter of the authorization request as well as to store it in the > user's session, e.g., as an HTTP cookie, a DOM variable, or in any > other suitable storage in the user's agent. When processing the > response from the authorization server (whether in the form of a code > or token), the Application MUST verify that the returned 'state' > parameter matches the value in the user agent. >=20 >=20 >=20 > On Thu, May 5, 2011 at 14:26, Hannes Tschofenig > wrote: >> Hey Breno, >>=20 >> here is the draft I mentioned: >> = http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-= 02 >>=20 >> It would be great to get your review comments in. >>=20 >> Ciao >> Hannes >>=20 >>=20 >=20 >=20 >=20 > -- > --Breno From t.lodderstedt@telekom.de Wed May 11 11:44: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 4B3ECE0693 for ; Wed, 11 May 2011 11:44: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 3POZHOsRT6Mh for ; Wed, 11 May 2011 11:44:33 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 81FCEE066E for ; Wed, 11 May 2011 11:44:33 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail71.telekom.de with ESMTP; 11 May 2011 20:44:28 +0200 Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP; Wed, 11 May 2011 20:44:28 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Wed, 11 May 2011 20:44:28 +0200 From: "Lodderstedt, Torsten" To: Marius Scurtescu Date: Wed, 11 May 2011 20:44:27 +0200 Thread-Topic: [OAUTH-WG] oauth2 implicit flow user experience Thread-Index: AcwQCT7BrIRtoVlERUmKuAOTf0PvlgAAd51g Message-Id: <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> 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" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 18:44:34 -0000 How shall the authorization server ensure that the calling client is a user= -agent based app (i.e. a native app could impersonate an user-agent based a= pp)? In my opinion, enforcing explicit user consent is the only way to prevent t= his kind of attack. regards, Torsten. > -----Urspr=FCngliche Nachricht----- > Von: Marius Scurtescu [mailto:mscurtescu@google.com] > Gesendet: Mittwoch, 11. Mai 2011 20:28 > An: Lodderstedt, Torsten > Cc: oauth@ietf.org; Doug Tangren > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience >=20 > On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten > wrote: > > Hi Marius, > > > > wrt "auto-approval": how is the authorization server supposed to > validated the client's identity in a reliable way? Otherwise another > application (using the id of the legitimate client) could abuse the > authorization previously approved by the user as long as the session > with the authorization server is valid. The redirect_uri won't help for > all kinds of clients since a native app could use the correct > redirect_uri and nevertheless get access to the token. >=20 > The only validation is based on the redirect URI. Native apps should > not use the implicit flow, and in general there is no need for > auto-approval for them. >=20 > Marius From breno.demedeiros@gmail.com Wed May 11 12:08: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 C0279E07C2 for ; Wed, 11 May 2011 12:08:07 -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 WUZlZVAzL1jN for ; Wed, 11 May 2011 12:08:07 -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 29D23E0886 for ; Wed, 11 May 2011 12:08:07 -0700 (PDT) Received: by pvh1 with SMTP id 1so508108pvh.31 for ; Wed, 11 May 2011 12:08:07 -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=G3YAeQlBtYoEeINFswkIjoyeaGBBIcCr6bGVLSGTAks=; b=bf7dpLXMINP4duiZzosS7K5YzOJ3TTBo6CfXojbHMUINiUVeTA2MOheRfaOxnT/yUb 9bJIcQ62L+oIqEjNn2LBZoWKBaqaQB02BaTjXvaiwBkeujQLencmpRDBwNU9HFwxox5B imexf9JWhH6LnQj7lZrYtMPca+9PeAVpFzqGw= 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=xkbuLsO7X9WJW14y3bn4oABgTp8LOp+ZlgQQcGABcNaFXz4nqCbsOsEiuFhAD92j+I PFy+l4SqMYO12XN+aJ0eTXiu2+F3C8BKi/De8xuxxMAXLQYpMKG9X4KoK97I/k56Mctw TXZXasdJhWJ3wPGPlUdE7LUVAaBeaYfxk6woU= MIME-Version: 1.0 Received: by 10.68.1.170 with SMTP id 10mr13359895pbn.189.1305140886679; Wed, 11 May 2011 12:08:06 -0700 (PDT) Received: by 10.68.50.106 with HTTP; Wed, 11 May 2011 12:08:06 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> Date: Wed, 11 May 2011 12:08:06 -0700 Message-ID: From: Breno To: "Lodderstedt, Torsten" Content-Type: multipart/alternative; boundary=bcaec531480feeb2aa04a304caaf Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 19:08:07 -0000 --bcaec531480feeb2aa04a304caaf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten < t.lodderstedt@telekom.de> wrote: > How shall the authorization server ensure that the calling client is a > user-agent based app (i.e. a native app could impersonate an user-agent > based app)? > > In my opinion, enforcing explicit user consent is the only way to prevent > this kind of attack. > Native apps will require access to shared OS resources to retrieve the access token if the redirect URI is a web location registered with the proper web client. If the Native app has such access, the native app can do far more interesting things to compromise the users credentials directly. No amount of protocol sophistication can address this. > > regards, > Torsten. > > > -----Urspr=FCngliche Nachricht----- > > Von: Marius Scurtescu [mailto:mscurtescu@google.com] > > Gesendet: Mittwoch, 11. Mai 2011 20:28 > > An: Lodderstedt, Torsten > > Cc: oauth@ietf.org; Doug Tangren > > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience > > > > On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten > > wrote: > > > Hi Marius, > > > > > > wrt "auto-approval": how is the authorization server supposed to > > validated the client's identity in a reliable way? Otherwise another > > application (using the id of the legitimate client) could abuse the > > authorization previously approved by the user as long as the session > > with the authorization server is valid. The redirect_uri won't help for > > all kinds of clients since a native app could use the correct > > redirect_uri and nevertheless get access to the token. > > > > The only validation is based on the redirect URI. Native apps should > > not use the implicit flow, and in general there is no need for > > auto-approval for them. > > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Breno de Medeiros --bcaec531480feeb2aa04a304caaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, May 11, 2011 at 11:44 AM, Lodder= stedt, Torsten <t.lodderstedt@telekom.de> wrote:
    How shall the authorization server ensure that the calling client is a user= -agent based app (i.e. a native app could impersonate an user-agent based a= pp)?

    In my opinion, enforcing explicit user consent is the only way to prevent t= his kind of attack.

    Native apps will re= quire access to shared OS resources to retrieve the access token if the red= irect URI is a web location registered with the proper web client.

    If the Native app has such access, the native app can d= o far more interesting things to compromise the users credentials directly.=

    No amount of protocol sophistication can address = this.
    =A0

    regards,
    Torsten.

    > -----Urspr=FCngliche Nachricht-----
    > Von: Marius Scurtescu [mailto:mscurtescu@google.com]
    > Gesendet: Mittwoch, 11. Mai 2011 20:28
    > An: Lodderstedt, Torsten
    > Cc: oauth@ietf.org; Doug Tangren=
    > Betreff: Re: [OAUTH-WG] oauth2 implicit flow user ex= perience
    >
    > On Tue, May 10, 2011 at 4:43 P= M, Lodderstedt, Torsten
    > <t.lodderstedt@telekom.= de> wrote:
    > > Hi Marius,
    > >
    > > wrt "auto-approval": how is the authorization server su= pposed to
    > validated the client's identity in a reliable way? Otherwise anoth= er
    > application (using the id of the legitimate client) could abuse the > authorization previously approved by the user as long as the session > with the authorization server is valid. The redirect_uri won't hel= p for
    > all kinds of clients since a native app could use the correct
    > redirect_uri and nevertheless get access to the token.
    >
    > The only validation is based on the redirect URI. Native apps should > not use the implicit flow, and in general there is no need for
    > auto-approval for them.
    >
    > Marius
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth



    --
    Breno de Me= deiros

    --bcaec531480feeb2aa04a304caaf-- From mscurtescu@google.com Wed May 11 13:39: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 AEA2BE079B for ; Wed, 11 May 2011 13:39:08 -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 wtMKcaERBFRd for ; Wed, 11 May 2011 13:39:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 146E5E0674 for ; Wed, 11 May 2011 13:39:07 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p4BKd6Ww004634 for ; Wed, 11 May 2011 13:39:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305146347; bh=I93tiV9RvoT43X2hwcrJyZTnLXk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=J/A/IYtYE9YAHrpaTj47FRTZ9HUXT7K34eKTvfBsJ14j3sOdzkrNR+d8VQY7ExXrh 53bJ3cpWB23GjbVQVUQDA== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by hpaq13.eem.corp.google.com with ESMTP id p4BKbLKW013534 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 May 2011 13:39:05 -0700 Received: by yxe42 with SMTP id 42so400859yxe.2 for ; Wed, 11 May 2011 13:39: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:from:date :message-id:subject:to:cc:content-type; bh=rBmZHC1RdPOC7Dh1I84Iknw1hjHRQbSglNg7YvCBJH4=; b=Rp5xW70y994QbxD+8Apj66/Rb+l2SEoTjpXNrUaxvDmdkIlH6R+P3IkEwinl5BfHsD S2/FDGmc0VmnPoWOqRjA== 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=RMJI4vCuUnmqhjoqwbafApzCUiYJ74+amL7kg3SOjG2Wkul/XG/M5eDBFT44P3RJnz iSSvorvV6BPgj23oE6HA== Received: by 10.100.201.3 with SMTP id y3mr338439anf.13.1305146345180; Wed, 11 May 2011 13:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.46.20 with HTTP; Wed, 11 May 2011 13:38:45 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> From: Marius Scurtescu Date: Wed, 11 May 2011 13:38:45 -0700 Message-ID: To: "Lodderstedt, Torsten" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 20:39:08 -0000 On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten wrote: > How shall the authorization server ensure that the calling client is a user-agent based app (i.e. a native app could impersonate an user-agent based app)? Through registration and redirect URI validation. A native app does not have to impersonate, they can just register a user-agent client. Everything boils down to the user trusting the app. As Breno mentions, nothing the spec can do to help with that. Marius From t.lodderstedt@telekom.de Wed May 11 15:26: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 41685E0870 for ; Wed, 11 May 2011 15:26: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 1REgvnGDXAxk for ; Wed, 11 May 2011 15:26:31 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 26287E07C9 for ; Wed, 11 May 2011 15:26:30 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail51.telekom.de with ESMTP; 12 May 2011 00:26:19 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by G8DBSE01.krf01.telekom.de with ESMTP; Thu, 12 May 2011 00:26:18 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Thu, 12 May 2011 00:26:17 +0200 From: "Lodderstedt, Torsten" To: Marius Scurtescu Date: Thu, 12 May 2011 00:26:16 +0200 Thread-Topic: [OAUTH-WG] oauth2 implicit flow user experience Thread-Index: AcwQG3n2GOqFS0UpTpO9x01c/1mgNQADkMYA Message-Id: <63366D5A116E514AA4A9872D3C53353956F40724DD@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 22:26:34 -0000 >=20 > Through registration and redirect URI validation. A native app does > not have to impersonate, they can just register a user-agent client. > Everything boils down to the user trusting the app. As Breno mentions, > nothing the spec can do to help with that. It could recommend the authorization server not to automatically process re= peated authorizations without user consent if it cannot reliably authentica= te the client. >=20 > Marius From breno.demedeiros@gmail.com Wed May 11 15:46: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 BA56DE08A5 for ; Wed, 11 May 2011 15:46: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 QlDOqvOW-lgZ for ; Wed, 11 May 2011 15:46:33 -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 35C32E07F0 for ; Wed, 11 May 2011 15:46:33 -0700 (PDT) Received: by pwi5 with SMTP id 5so612641pwi.31 for ; Wed, 11 May 2011 15:46: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:date :message-id:subject:from:to:cc:content-type; bh=kYA1tvpCG6TnKilQld1/zK+5LVY4ZcK4qvLI2MiRKz0=; b=awKrmEeYjr+v3V3tFbEFd2DAi9XW6uY94cJeJ1IwecUOL9jokDrAkSLbIoKWUHKSFs J9p8zqskJPus07AZeTLtHmjOycXTq1xcaWsQoYJh4G8KUJr5YVLIq45lL1maic8KbFXs LWHFogSjlm3xnk+NTa9lMl1JPZnDAa4cql8nU= 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=bVfHGqy+3kLAXQ4PQNNYPnp2KemMzbhY98AryQKYWLqGh2Y061m8ym6ZnGw77aBKoc wumka3yK6wPd1Rvkxe0ZxgV0jOFnzVRkXYYapcOjQ6CKKM8HxaJ2pBuocVeex62sSe4j 4BG42DrQWZH+GxvgxVSyu958BHMIRVR+GCBuk= MIME-Version: 1.0 Received: by 10.68.66.163 with SMTP id g3mr4850028pbt.524.1305153992682; Wed, 11 May 2011 15:46:32 -0700 (PDT) Received: by 10.68.50.106 with HTTP; Wed, 11 May 2011 15:46:32 -0700 (PDT) In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F40724DD@QEO40072.de.t-online.corp> References: <63366D5A116E514AA4A9872D3C53353956F40722D6@QEO40072.de.t-online.corp> <63366D5A116E514AA4A9872D3C53353956F40724D7@QEO40072.de.t-online.corp> <63366D5A116E514AA4A9872D3C53353956F40724DD@QEO40072.de.t-online.corp> Date: Wed, 11 May 2011 15:46:32 -0700 Message-ID: From: Breno To: "Lodderstedt, Torsten" Content-Type: multipart/alternative; boundary=bcaec5430bd81c6e3004a307d8a1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] oauth2 implicit flow user experience X-BeenThere: oauth@ietf.org X-Mailman-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, 11 May 2011 22:46:33 -0000 --bcaec5430bd81c6e3004a307d8a1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 3:26 PM, Lodderstedt, Torsten < t.lodderstedt@telekom.de> wrote: > > > > Through registration and redirect URI validation. A native app does > > not have to impersonate, they can just register a user-agent client. > > Everything boils down to the user trusting the app. As Breno mentions, > > nothing the spec can do to help with that. > > It could recommend the authorization server not to automatically process > repeated authorizations without user consent if it cannot reliably > authenticate the client. > And, as I explained above, it would provide no additional meaningful security while at the same time eliminating the value of the user-agent profile. > > > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --bcaec5430bd81c6e3004a307d8a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, May 11, 2011 at 3:26 PM, Lodders= tedt, Torsten <t.lodderstedt@telekom.de> wrote:
    >
    > Through registration and redirect URI validation. A native app does > not have to impersonate, they can just register a user-agent client. > Everything boils down to the user trusting the app. As Breno mentions,=
    > nothing the spec can do to help with that.

    It could recommend the authorization server not to automatically proc= ess repeated authorizations without user consent if it cannot reliably auth= enticate the client.

    And, as I explaine= d above, it would provide no additional meaningful security while at the sa= me time eliminating the value of the user-agent profile.
    =A0

    >
    > Marius
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth



    --
    Breno de Me= deiros

    --bcaec5430bd81c6e3004a307d8a1-- From mnot@mnot.net Wed May 11 18:12: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 31832E07EB for ; Wed, 11 May 2011 18:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.766 X-Spam-Level: X-Spam-Status: No, score=-105.766 tagged_above=-999 required=5 tests=[AWL=-4.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 lX1jmPu9DOt4 for ; Wed, 11 May 2011 18:12:18 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 30264E07E8 for ; Wed, 11 May 2011 18:12:18 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.212.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DAC2D509D9; Wed, 11 May 2011 21:12:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA816@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 12 May 2011 11:12:08 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <85C4941D-BD2F-4C4C-8F3E-CEABF8A4927C@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA816@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 11 May 2011 18:42:11 -0700 Cc: HTTP Working Group , OAuth WG Subject: Re: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG) X-BeenThere: oauth@ietf.org X-Mailman-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, 12 May 2011 01:12:19 -0000 My .02 -=20 On 10/05/2011, at 2:49 AM, Eran Hammer-Lahav wrote: > The OAuth working group has defined an authorization protocol [1] for = delegating access to protected resources. Once access has been = authorized, the client is issued a set of token credentials which are = uses to make authenticated HTTP requests. To accomplish that, the OAuth = working group has proposed two new HTTP authentication schemes: Bearer = [2] and MAC [3]. >=20 > The working group has been debating the issue of what's the best = current practice for returning an error status in an HTTP authentication = scheme. The Basic and Digest schemes do not specify the error condition = and simply return a 401 response with a new challenge. The MAC proposal = follows this pattern. >=20 > The Bearer scheme proposal is taking a more active approach, defining = an 'error' response attribute for use with the WWW-Authenticate header = and an error code registry to go along. The parameter and registry = (especially the registry) are meant for reuse by other HTTP = authentication schemes. At the moment, the three error conditions = proposed by the Bearer draft are: invalid request, invalid token, and = insufficient scope (which arguably is better suited using a 403 response = with or without a new challenge). >=20 > While these error codes arguably do not provide an immediate = actionable value (pending the help of future discovery specifications), = the attribute and registry propose a forward-looking solution for when = clients will be able to automatically resolve such issues (with the help = of future discovery specifications). >=20 > The OAuth WG is seeking guidance on the following questions: >=20 > 1. Should the WG define a general purpose method for returning errors = with a 401 WWW-Authenticate headers, including a cross-scheme error code = registry? I don't have strong feelings about whether or not it's a good idea = overall. However, I tend to think that if it's intended for more than = one scheme, it'd make more sense to a) make it a separate header, much = like Authentication-Info for successful responses, and b) also note that = it's a good idea to put human-friendly information in the response body = (e.g., in HTML). Making it a separate header not only avoids collisions (largely = theoretical at this stage), it also doesn't put too much information = into WWW-Authenticate (which has never had the cleanest syntax), = avoiding potential parsing issues, etc. > If you answered yes to #1: >=20 > 2. Should the WG apply this to all new HTTP authentication schemes = (currently, MAC, but potentially more)? What does "apply" mean here? Do you just want to allow people to use the = same error codes with other auth schemes if they want to, knowing that = most existing software won't use it? > 3. Should this new error attribute and registry be part of the main = OAuth 2.0 specification, part of one of the upcoming schemes (for use = with other schemes), or standalone? If you really want people to use it for other schemes, it needs to be a = separate spec; no matter how much you say otherwise, folks assume that = if it's part of a bigger spec, it's inseparable. > If you answered no to #1: >=20 > 4. Should the Bearer draft retain the attribute and registry for its = own scheme-specific needs? Not sure how that's relevant here... Cheers, -- Mark Nottingham http://www.mnot.net/ From t.lodderstedt@telekom.de Wed May 11 19:23: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 2453FE06B9 for ; Wed, 11 May 2011 19:23:48 -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 Lg5xgoFWMbDx for ; Wed, 11 May 2011 19:23:47 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 88007E068D for ; Wed, 11 May 2011 19:23:46 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail31.telekom.de with ESMTP; 12 May 2011 04:23:41 +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, 12 May 2011 04:23:41 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Thu, 12 May 2011 04:23:40 +0200 From: "Lodderstedt, Torsten" To: Hannes Tschofenig , oauth WG , "breno@google.com" Date: Thu, 12 May 2011 04:23:40 +0200 Thread-Topic: [OAUTH-WG] Fwd: OAuth Security Consideration Text Thread-Index: AcwQCpWj+l0H1oZPR3qjjGv6ONOzQQAIlDRA Message-Id: <913181C5F90DDE41A1390755327E7787570DAF0A15@QEO40072.de.t-online.corp> References: <7376795F-D9DC-4A9E-8CB0-C49E8AE368D9@gmx.net> In-Reply-To: <7376795F-D9DC-4A9E-8CB0-C49E8AE368D9@gmx.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: OAuth Security Consideration 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: Thu, 12 May 2011 02:23:48 -0000 Hi Breno, thanks for the feedback. Please find my comments inline. > > > > Now higher level comments: > > > > On Native Apps protection of refresh token: > > > > On section Definitions, there is a sentence in the Native Apps "It is > > assumed that such applications can protect dynamically issued > secrets, > > such as refresh tokens, from eavesdropping by other applications > > residing in the same service" the original text says: "on the same device" > > > > I suggest that you strike out this sentence from definitions since it > > is confusing. This should be moved to section 2.4, with a specific > > headed paragraph about management of refresh tokens for native > > applications including specific recommendation. This section shall document all assumptions determining the differences bet= ween those categories, which are relevant for the security sections. Thus I= would like to keep it and probably improve it.=20 > > > > E.g. of substitution paragraph: > > > > Native Applications MUST use operating system mediated protections to > > ensure that the refresh tokens are safe from unauthorized access by > > other users and applications. It is highly RECOMMENDED that such > > applications use OS-provided APIs to manage secrets. The applications > > MUST apply appropriately restrictive access controls to any file > > system or persistent memory objects where the refresh token is > stored. > > > > On Client Authentication: > > > > "Authorization servers are encouraged to consider stronger client > > authentication means" --> This is too vague to be actionable. There > is > > a great tradition of 'innovation' in client security that promotes no > > security and hinders interoperability. I tend to believe that it is > > better for servers to be conscious of the limitations of client > > authentication and implement mitigation measures than to create ad- > hoc > > authentication mechanisms. Suggest to strike out this sentence. > > > > "Authorization server MUST NOT issue client secrets to native or user > > agent-based applications in general." -> Agreed on user-agent, > however > > at least in principle it is possible to issue secrets to native > > applications that use hardware-based DRM modules and can hold on to > > secrets.=20 A couple of comments on this: 1) This statement is intended to prohibit secrets for software packages and= not software instances. Thus the text also says "An authorization server M= AY issue a client secret for an installation of a native application on a s= pecific device.". We just want to get rid of the bad practice of using secr= ets for authenticating software packages. This practice creates a false fee= ling of security and people tend to rely on this kind of client authenticat= ion too much. They shall be adviced to utilize other means than client secr= ets. 2) The intention of the text is to give simple and clear rules instead of d= iscussing "if", "then" and "why". This discussion is subject of the securit= y threats and considerations I-D referenced by the introduction of the text= . 3) DRM modules give you a device specific authentication, they do not authe= nticate a certain software package or instance. >>> More importantly, since the OAuth2 spec no longer actually > > specifies how to implement a Native App Flow end-to-end, I am not > sure > > how to even reason about Native App issues. Propose simply strike out > > 'native or'. The description of how to implement native apps is badly missing right now = and has been requested during IETF-80. It will be re-included soon.=20 > > > > On Malicious Client Obtains Authorization: > > > > "Authorization servers MUST NOT automatically process (without user > > interaction) repeated authorizations without authenticating the > > client." -> Not sure what to make of this sentence. If this implies > > User-Agent should not support automatic renewal of access tokens > > (since user-agent apps cannot be 'authenticated'), then it is a > > harmful recommendation because it ignores practical requirements. The > > bad word here is 'authenticating', since what is really intended is > > some assurance that it is the same client, e.g., the redirect URI > > matches a registered value in the User-Agent case. Please strike out > > this sentence or substitute it with one like: > > > > "Authorization servers MUST implement measures to ensure that > > automatically issued tokens (without user interaction, based on > > previously recorded grant) are delivered to the same client to whom > > original grant was performed. Example of suitable measures are > > enforcing client authentication or enforcing that the destination of > a > > redirect (in case of implicit grant) matches the expected value for > > the client." As discussed in the other thread. I do not consider the redirect_uri enforc= ement to be a reliable way to prevent abuse of existing authorizations. > > > > On Access Tokens > > > > "Application developers MUST NOT store access tokens in non-transient > > memory." -> This is not realistic -- consider the case of a Web > > Application running on distributed servers. It is quite possible that > > the only distributed storage mechanism available to the application > is > > based on persistent storage. I suggest you strike out this sentence, > > since the previous one is sufficient. Good point, I agree. > > > > On Session Fixation > > > > This section needs to cover XSRF protection, the measures described > > within are insufficient for Web Applications or User-Agent-Based > > applications. Also the current mitigation described there is better > > described as a mitigation against token/code leakage. > > > > I suggest that you create a new section: > > > > =3D=3D > > Token and Code Leakage via Referer Header and/Or Open Redirectors > > > > Attackers can leverage inclusion of third party content (images, ads) > > and/or the presence of redirectors in legitimate Web or > > User-Agent-Based Applications to steal codes and/or tokens issued to > > such sites. > > > > "In order to prevent such attack ..." (move here the 2nd paragraph > > that currently lives on Session Fixation) > > > > Now for the Session Fixation section, I would recommend that you > > expand it to also include 'token', since the attack is also possible > > via token. > > > > The Session fixation attack involves an attacker that forwards a link > > to an unsuspecting victim. The victim clicks on the link and > > subsequently approves an expected application but as a result the > > attacker obtains access to the victim's data either at application or > > at the authorization server. > > > > In order to prevent such attack, a Web or User-Agent-Based > application > > MUST bind the state of authorization requests to the user's session > > with the application. This requires that the Application generate a > > strongly unguessable random number, and both include it in the > 'state' > > parameter of the authorization request as well as to store it in the > > user's session, e.g., as an HTTP cookie, a DOM variable, or in any > > other suitable storage in the user's agent. When processing the > > response from the authorization server (whether in the form of a code > > or token), the Application MUST verify that the returned 'state' > > parameter matches the value in the user agent. > > In my opinion, the mean you describe is complementary to the redirect_uri-b= ased approach described in the text. Both can be used to detect session fix= ation attempts. The difference is that the redirect_uri-based appraoch reli= es on the authz server to detect the attack whereas the redirect_uri-based = approach leaves the detection to the client. =20 Would you please elaborate on how the state parameter prevents XSRF? regards, Torsten. > > > > > > On Thu, May 5, 2011 at 14:26, Hannes Tschofenig > > wrote: > >> Hey Breno, > >> > >> here is the draft I mentioned: > >> http://tools.ietf.org/html/draft-lodderstedt-oauth- > securityconsiderations-02 > >> > >> It would be great to get your review comments in. > >> > >> Ciao > >> Hannes > >> > >> > > > > > > > > -- > > --Breno >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From d.tangren@gmail.com Wed May 11 22:09: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 915C2E06A4 for ; Wed, 11 May 2011 22:09:00 -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 uHq2K6FzgUxE for ; Wed, 11 May 2011 22:09:00 -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 CDACCE0689 for ; Wed, 11 May 2011 22:08:59 -0700 (PDT) Received: by gyf3 with SMTP id 3so514718gyf.31 for ; Wed, 11 May 2011 22:08:59 -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=NR6TGP23BD0QP2FxMUArEMOzgEdqwdXcRmSqFfZpJj4=; b=quhSGh+81l2ZTdUaw1AWpo/6+CRRq5EsPd0uKlvLHhObjCHbQBRZq2Sh4qrJaGRPq2 xw4uCg6gq+p4/a1L0n/Z5cTlmUkWRMWeLjJf0lswF/Tk0Dgsuw5lM4bcsYeon7H3cRjR kTZdAIFf3D02IRWraHzlhAUKUfEzuGZxaD0vI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=hzfzKLPt87uhIckZUFNR/Io+kzGmc+1Zn+ST/bwn7zQSh/30na7pMiE2cGpFCF2Ysf 3bXQjGURsotzdZyDt9Mbhr+HmR1eQn0+tW59U4F1F9qcL70tBlLa/KgeVJn6I+WT8tw0 JZgl8/WBOKkGlhTGya3ZmWQsDB1v+zs59vN9U= Received: by 10.91.201.18 with SMTP id d18mr172903agq.31.1305176939106; Wed, 11 May 2011 22:08:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Wed, 11 May 2011 22:08:39 -0700 (PDT) From: Doug Tangren Date: Thu, 12 May 2011 01:08:39 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636af007dd3112604a30d2f50 Subject: [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, 12 May 2011 05:09:00 -0000 --001636af007dd3112604a30d2f50 Content-Type: text/plain; charset=UTF-8 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 --001636af007dd3112604a30d2f50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This may have come up before so I'm sorry if I'm repeating. Why doe= s bearer token spec introduce a new name for oauth2 access tokens [1], &quo= t;bearer_token", and before that [2], "oauth_token"?=C2=A0
    I=C2=A0apologize=C2=A0if this may sound shallow but, why int= roduce a new parameter name verses sticking with what the general oauth2 sp= ec already defines, "access_token". It seems arbitrary for an aut= h server to hand a client an apple then have the client hand it off to the = resource server and call it an orange.=C2=A0

    Was this just for the sake of differentiating the param= eter name enough so that the bearer tokens may be used in other protocols w= ithout being confused with oauth2 access_tokens?


    -Doug Tangren
    http://lessis.me
    --001636af007dd3112604a30d2f50-- From eran@hueniverse.com Wed May 11 22:27: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 86E97E06AC for ; Wed, 11 May 2011 22:27:01 -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 2wtOgvJjCpxB for ; Wed, 11 May 2011 22:27:01 -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 DD11DE0689 for ; Wed, 11 May 2011 22:27:00 -0700 (PDT) Received: (qmail 19368 invoked from network); 12 May 2011 05:27:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 May 2011 05:26:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 11 May 2011 22:26:17 -0700 From: Eran Hammer-Lahav To: Doug Tangren , "oauth@ietf.org" Date: Wed, 11 May 2011 22:26:09 -0700 Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type Thread-Index: AcwQYrceSnvEGGoTQHW9LYaMzaE7MAAAjzww Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DAE8A@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_90C41DD21FB7C64BB94121FBBC2E723447581DAE8AP3PW5EX1MB01E_" 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: Thu, 12 May 2011 05:27:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAE8AP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG5hbWUgbmVlZHMgdG8gYmUgdW5pcXVlIGVub3VnaCBub3QgdG8gY29uZmxpY3Qgd2l0aCBs aWtlbHkgcGFyYW1ldGVycyBhbHJlYWR5IHVzZWQgYnkgcHJvdmlkZXJzLiBJIGRvbuKAmXQgaGF2 ZSBhbiBvcGluaW9uIHdoaWNoIG5hbWUgaXMgYmV0dGVyLCBqdXN0IHRoYXQgaXQgd2FzIG9hdXRo X3Rva2VuIGJlZm9yZSBhbmQgd2hlbiB3ZSBjaGFuZ2VkIHRoZSBzY2hlbWUgbmFtZSB0byBCZWFy ZXIsIGNoYW5nZWQgaXQgdG9vLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb3VnIFRhbmdy ZW4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDExIDEwOjA5IFBNDQpUbzogb2F1dGhAaWV0 Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gY29uc2lzdGVuY3kgb2YgdG9rZW4gcGFyYW0gbmFt ZSBpbiBiZWFyZXIgdG9rZW4gdHlwZQ0KDQpUaGlzIG1heSBoYXZlIGNvbWUgdXAgYmVmb3JlIHNv IEknbSBzb3JyeSBpZiBJJ20gcmVwZWF0aW5nLiBXaHkgZG9lcyBiZWFyZXIgdG9rZW4gc3BlYyBp bnRyb2R1Y2UgYSBuZXcgbmFtZSBmb3Igb2F1dGgyIGFjY2VzcyB0b2tlbnMgWzFdLCAiYmVhcmVy X3Rva2VuIiwgYW5kIGJlZm9yZSB0aGF0IFsyXSwgIm9hdXRoX3Rva2VuIj8NCg0KSSBhcG9sb2dp emUgaWYgdGhpcyBtYXkgc291bmQgc2hhbGxvdyBidXQsIHdoeSBpbnRyb2R1Y2UgYSBuZXcgcGFy YW1ldGVyIG5hbWUgdmVyc2VzIHN0aWNraW5nIHdpdGggd2hhdCB0aGUgZ2VuZXJhbCBvYXV0aDIg c3BlYyBhbHJlYWR5IGRlZmluZXMsICJhY2Nlc3NfdG9rZW4iLiBJdCBzZWVtcyBhcmJpdHJhcnkg Zm9yIGFuIGF1dGggc2VydmVyIHRvIGhhbmQgYSBjbGllbnQgYW4gYXBwbGUgdGhlbiBoYXZlIHRo ZSBjbGllbnQgaGFuZCBpdCBvZmYgdG8gdGhlIHJlc291cmNlIHNlcnZlciBhbmQgY2FsbCBpdCBh biBvcmFuZ2UuDQoNCldhcyB0aGlzIGp1c3QgZm9yIHRoZSBzYWtlIG9mIGRpZmZlcmVudGlhdGlu ZyB0aGUgcGFyYW1ldGVyIG5hbWUgZW5vdWdoIHNvIHRoYXQgdGhlIGJlYXJlciB0b2tlbnMgbWF5 IGJlIHVzZWQgaW4gb3RoZXIgcHJvdG9jb2xzIHdpdGhvdXQgYmVpbmcgY29uZnVzZWQgd2l0aCBv YXV0aDIgYWNjZXNzX3Rva2Vucz8NCg0KWzFdOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNCNzZWN0aW9uLTIuMg0KWzJdOiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMyNzZWN0aW9uLTIu Mg0KDQotRG91ZyBUYW5ncmVuDQpodHRwOi8vbGVzc2lzLm1lDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAE8AP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBuYW1l IG5lZWRzIHRvIGJlIHVuaXF1ZSBlbm91Z2ggbm90IHRvIGNvbmZsaWN0IHdpdGggbGlrZWx5IHBh cmFtZXRlcnMgYWxyZWFkeSB1c2VkIGJ5IHByb3ZpZGVycy4gSSBkb27igJl0IGhhdmUgYW4gb3Bp bmlvbiB3aGljaCBuYW1lIGlzIGJldHRlciwganVzdCB0aGF0IGl0IHdhcyBvYXV0aF90b2tlbiBi ZWZvcmUgYW5kIHdoZW4gd2UgY2hhbmdlZCB0aGUgc2NoZW1lIG5hbWUgdG8gQmVhcmVyLCBjaGFu Z2VkIGl0IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RG91ZyBUYW5ncmVuPGJyPjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIE1heSAxMSwgMjAxMSAxMDowOSBQTTxicj48Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIGNvbnNpc3RlbmN5IG9mIHRva2VuIHBhcmFt IG5hbWUgaW4gYmVhcmVyIHRva2VuIHR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5UaGlzIG1heSBoYXZlIGNvbWUgdXAgYmVmb3JlIHNvIEknbSBzb3JyeSBpZiBJJ20gcmVw ZWF0aW5nLiBXaHkgZG9lcyBiZWFyZXIgdG9rZW4gc3BlYyBpbnRyb2R1Y2UgYSBuZXcgbmFtZSBm b3Igb2F1dGgyIGFjY2VzcyB0b2tlbnMgWzFdLCAmcXVvdDtiZWFyZXJfdG9rZW4mcXVvdDssIGFu ZCBiZWZvcmUgdGhhdCBbMl0sICZxdW90O29hdXRoX3Rva2VuJnF1b3Q7PyZuYnNwOzxvOnA+PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkmbmJzcDthcG9sb2dpemUmbmJzcDtpZiB0aGlzIG1h eSBzb3VuZCBzaGFsbG93IGJ1dCwgd2h5IGludHJvZHVjZSBhIG5ldyBwYXJhbWV0ZXIgbmFtZSB2 ZXJzZXMgc3RpY2tpbmcgd2l0aCB3aGF0IHRoZSBnZW5lcmFsIG9hdXRoMiBzcGVjIGFscmVhZHkg ZGVmaW5lcywgJnF1b3Q7YWNjZXNzX3Rva2VuJnF1b3Q7LiBJdCBzZWVtcyBhcmJpdHJhcnkgZm9y IGFuIGF1dGggc2VydmVyIHRvIGhhbmQgYSBjbGllbnQgYW4gYXBwbGUgdGhlbiBoYXZlIHRoZSBj bGllbnQgaGFuZCBpdCBvZmYgdG8gdGhlIHJlc291cmNlIHNlcnZlciBhbmQgY2FsbCBpdCBhbiBv cmFuZ2UuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V2FzIHRo aXMganVzdCBmb3IgdGhlIHNha2Ugb2YgZGlmZmVyZW50aWF0aW5nIHRoZSBwYXJhbWV0ZXIgbmFt ZSBlbm91Z2ggc28gdGhhdCB0aGUgYmVhcmVyIHRva2VucyBtYXkgYmUgdXNlZCBpbiBvdGhlciBw cm90b2NvbHMgd2l0aG91dCBiZWluZyBjb25mdXNlZCB3aXRoIG9hdXRoMiBhY2Nlc3NfdG9rZW5z PzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlsxXTombmJzcDs8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wNCNzZWN0 aW9uLTIuMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1i ZWFyZXItMDQjc2VjdGlvbi0yLjI8L2E+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+WzJdOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAzI3NlY3Rpb24tMi4yIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMyNzZWN0aW9uLTIuMjwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tRG91ZyBUYW5ncmVuPGJyPjxhIGhy ZWY9Imh0dHA6Ly9sZXNzaXMubWUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGVzc2lzLm1lPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E723447581DAE8AP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Wed May 11 22:57: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 C53A9E06B7 for ; Wed, 11 May 2011 22:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 A882En60YXEr for ; Wed, 11 May 2011 22:57:33 -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 92A06E0689 for ; Wed, 11 May 2011 22:57:33 -0700 (PDT) Received: by pvh1 with SMTP id 1so770404pvh.31 for ; Wed, 11 May 2011 22:57:33 -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; bh=z0zVvoe1q6bBKeXOPx8U90RXgENkgvWRJBFzVW7hxNo=; b=r7sGwmNfccCoGZG5t5MXvPFUZ4DJ3JhMVwO2PaZ6F49w+CffdbCHa05Y23ldnlSPYh Dr75AqEsjtvcAIXP7kpAolhqd3GiGHSVCrm3boadc3jTGaYtaINVkYLBOENV39U3GwLN edwvmzeGEqXEx2Dd6YZHbme/Nmtq93GFbpkzU= 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; b=ZGrnpkWcP7W/NFL9R8XURVk01HFgXeCCcaqSIMBcsLt2uN4ukz5PYP45M+0IzJMpxs GrkbW3A4pfsIixCnFxWKbRovxGJuK5JKVTDjYTOMJsdnPiLJ+vTz5hQdOTDkRi975VVn 3Czk5PgiMiG1XEIjZICTAB1OjOnREpFbmKcKg= MIME-Version: 1.0 Received: by 10.68.17.163 with SMTP id p3mr14735891pbd.323.1305179852694; Wed, 11 May 2011 22:57:32 -0700 (PDT) Sender: breno.demedeiros@gmail.com Received: by 10.68.50.106 with HTTP; Wed, 11 May 2011 22:57:32 -0700 (PDT) In-Reply-To: <913181C5F90DDE41A1390755327E7787570DAF0A15@QEO40072.de.t-online.corp> References: <7376795F-D9DC-4A9E-8CB0-C49E8AE368D9@gmx.net> <913181C5F90DDE41A1390755327E7787570DAF0A15@QEO40072.de.t-online.corp> Date: Wed, 11 May 2011 22:57:32 -0700 X-Google-Sender-Auth: MWfOGZdUzHr9tD_9wjEODGXOWuk Message-ID: From: Breno To: "Lodderstedt, Torsten" Content-Type: multipart/alternative; boundary=bcaec51f8fe17ce56204a30ddd9c Cc: oauth WG Subject: Re: [OAUTH-WG] Fwd: OAuth Security Consideration 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: Thu, 12 May 2011 05:57:35 -0000 --bcaec51f8fe17ce56204a30ddd9c Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten < t.lodderstedt@telekom.de> wrote: > Hi Breno, > > thanks for the feedback. Please find my comments inline. > > > > > > > Now higher level comments: > > > > > > On Native Apps protection of refresh token: > > > > > > On section Definitions, there is a sentence in the Native Apps "It is > > > assumed that such applications can protect dynamically issued > > secrets, > > > such as refresh tokens, from eavesdropping by other applications > > > residing in the same service" > > the original text says: "on the same device" > > > > > > > I suggest that you strike out this sentence from definitions since it > > > is confusing. This should be moved to section 2.4, with a specific > > > headed paragraph about management of refresh tokens for native > > > applications including specific recommendation. > > This section shall document all assumptions determining the differences > between those categories, which are relevant for the security sections. Thus > I would like to keep it and probably improve it. > This may be a difference of opinion rather than substance, but I find that assumptions stated too far ahead of their use suffer from lack of connection. I would suggest again that the definition remain purely semantic, and the security assumptions be discussed more closely to the attending threats and mitigations. > > > > > > > E.g. of substitution paragraph: > > > > > > Native Applications MUST use operating system mediated protections to > > > ensure that the refresh tokens are safe from unauthorized access by > > > other users and applications. It is highly RECOMMENDED that such > > > applications use OS-provided APIs to manage secrets. The applications > > > MUST apply appropriately restrictive access controls to any file > > > system or persistent memory objects where the refresh token is > > stored. > > > > > > On Client Authentication: > > > > > > "Authorization servers are encouraged to consider stronger client > > > authentication means" --> This is too vague to be actionable. There > > is > > > a great tradition of 'innovation' in client security that promotes no > > > security and hinders interoperability. I tend to believe that it is > > > better for servers to be conscious of the limitations of client > > > authentication and implement mitigation measures than to create ad- > > hoc > > > authentication mechanisms. Suggest to strike out this sentence. > > > > > > "Authorization server MUST NOT issue client secrets to native or user > > > agent-based applications in general." -> Agreed on user-agent, > > however > > > at least in principle it is possible to issue secrets to native > > > applications that use hardware-based DRM modules and can hold on to > > > secrets. > > A couple of comments on this: > > 1) This statement is intended to prohibit secrets for software packages and > not software instances. Thus the text also says "An authorization server MAY > issue a client secret for an installation of a native application on a > specific device.". We just want to get rid of the bad practice of using > secrets for authenticating software packages. This practice creates a false > feeling of security and people tend to rely on this kind of client > authentication too much. They shall be adviced to utilize other means than > client secrets. > When the spec did define a Native App flow it mandated the opposite (the secret was required not optional), which led Google, for instance, to launch the OAuth2 registration for clients to include secret issuance for native apps---against the recommendation of our internal security team---for pure compliance reasons (not that we are relying on its remaining a secret, our security model does not rely on this). I welcome the change of language (even if we may take some time for Google to catch up with it), but find it a bit too strong. Possibly "It is NOT RECOMMENDED ..." followed by some description of why this is ineffective as a security measure? > 2) The intention of the text is to give simple and clear rules instead of > discussing "if", "then" and "why". This discussion is subject of the > security threats and considerations I-D referenced by the introduction of > the text. > Yes, and I am not suggesting it should -- my recommendation was to strike it out. However, what about a softened approach as above? > 3) DRM modules give you a device specific authentication, they do not > authenticate a certain software package or instance. > > >>> More importantly, since the OAuth2 spec no longer actually > > > specifies how to implement a Native App Flow end-to-end, I am not > > sure > > > how to even reason about Native App issues. Propose simply strike out > > > 'native or'. > > The description of how to implement native apps is badly missing right now > and has been requested during IETF-80. It will be re-included soon. > That's welcome news indeed. > > > > > > > On Malicious Client Obtains Authorization: > > > > > > "Authorization servers MUST NOT automatically process (without user > > > interaction) repeated authorizations without authenticating the > > > client." -> Not sure what to make of this sentence. If this implies > > > User-Agent should not support automatic renewal of access tokens > > > (since user-agent apps cannot be 'authenticated'), then it is a > > > harmful recommendation because it ignores practical requirements. The > > > bad word here is 'authenticating', since what is really intended is > > > some assurance that it is the same client, e.g., the redirect URI > > > matches a registered value in the User-Agent case. Please strike out > > > this sentence or substitute it with one like: > > > > > > "Authorization servers MUST implement measures to ensure that > > > automatically issued tokens (without user interaction, based on > > > previously recorded grant) are delivered to the same client to whom > > > original grant was performed. Example of suitable measures are > > > enforcing client authentication or enforcing that the destination of > > a > > > redirect (in case of implicit grant) matches the expected value for > > > the client." > > As discussed in the other thread. I do not consider the redirect_uri > enforcement to be a reliable way to prevent abuse of existing > authorizations. > Google's experience with threat models on this space leads us to believe that it can be effective in practice. Note that expansive variants of this practice are not safe, e.g., domain matching versus full redirect URI matching. Note that: - There is high value from the perspective of deployment flexibility to support auto-approval in flows where the client cannot authenticate (e.g., user-agent); and - There is a class of existence of effective mitigation strategies: one of these that is fully spec-compliant is full URL matching. Another is to use non-HTTP transport such as windows.postMessage() for authenticated cross-domain communication of the response. (You could consider that a case of client authentication where the user-agent is the authority). I believe that is quite important that we address this issue with a bit of finesse. I understand that there is interest in not going into too much detail into a security considerations section for a broadly applicable spec. However this is a point where abstraction can easily change the threat model/risk profile to the point where a security practitioner would reverse their recommendation on usage. Taking the easy option here to use categorical language may be counterproductive. It is perfectly appropriate to issue guidance that one expects to be widely disregarded provided that one is convinced that those ignoring the guidance will inevitably be putting their services and/or their users at risk. However, I do not think this is the case here. It is possible (or so I believe) to violate this guidance as current stated and mitigate the risks appropriately. > > > > > > > On Access Tokens > > > > > > "Application developers MUST NOT store access tokens in non-transient > > > memory." -> This is not realistic -- consider the case of a Web > > > Application running on distributed servers. It is quite possible that > > > the only distributed storage mechanism available to the application > > is > > > based on persistent storage. I suggest you strike out this sentence, > > > since the previous one is sufficient. > > Good point, I agree. > > > > > > > On Session Fixation > > > > > > This section needs to cover XSRF protection, the measures described > > > within are insufficient for Web Applications or User-Agent-Based > > > applications. Also the current mitigation described there is better > > > described as a mitigation against token/code leakage. > > > > > > I suggest that you create a new section: > > > > > > == > > > Token and Code Leakage via Referer Header and/Or Open Redirectors > > > > > > Attackers can leverage inclusion of third party content (images, ads) > > > and/or the presence of redirectors in legitimate Web or > > > User-Agent-Based Applications to steal codes and/or tokens issued to > > > such sites. > > > > > > "In order to prevent such attack ..." (move here the 2nd paragraph > > > that currently lives on Session Fixation) > > > > > > Now for the Session Fixation section, I would recommend that you > > > expand it to also include 'token', since the attack is also possible > > > via token. > > > > > > The Session fixation attack involves an attacker that forwards a link > > > to an unsuspecting victim. The victim clicks on the link and > > > subsequently approves an expected application but as a result the > > > attacker obtains access to the victim's data either at application or > > > at the authorization server. > > > > > > In order to prevent such attack, a Web or User-Agent-Based > > application > > > MUST bind the state of authorization requests to the user's session > > > with the application. This requires that the Application generate a > > > strongly unguessable random number, and both include it in the > > 'state' > > > parameter of the authorization request as well as to store it in the > > > user's session, e.g., as an HTTP cookie, a DOM variable, or in any > > > other suitable storage in the user's agent. When processing the > > > response from the authorization server (whether in the form of a code > > > or token), the Application MUST verify that the returned 'state' > > > parameter matches the value in the user agent. > > > > > In my opinion, the mean you describe is complementary to the > redirect_uri-based approach described in the text. Both can be used to > detect session fixation attempts. The difference is that the > redirect_uri-based appraoch relies on the authz server to detect the attack > whereas the redirect_uri-based approach leaves the detection to the client. > They are complementary but not in an optional way. By that I mean that _both_ types of measures must _always_ be applied. The client cannot help the user agent against exploits where the attacker abuses the inherent authority of the user agent (while acting on behalf of the user), causing it to perform actions against itself in a confused deputy-type scenario. That's the essence of an XSRF. The client is impotent to help the user agent protect itself without explicit involvement by the user agent. > > Would you please elaborate on how the state parameter prevents XSRF? > The state parameter can provide XSRF (which in turn is essential to prevent session fixation attacks) 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. Concrete example using HTTP cookies: Client issues a 302 to the user agent with a Set-Cookie header with value "XsrfToken1=$unguessable_random_number" and while simultaneously attaching to the request the state parameter "&state=XsrfToken1%3D$unguessable_random_number" When the client receives the response from the authorization server, it checks that such cookie is also visible. Now, an attacker cannot perform a session fixation attack because it cannot cause the user agent to modify its state in the same-domain-origin scope of the client (if it could it would be game over as it could cause the user agent to supply user credentials in most circumstances). Since it cannot modify the user agent state, it cannot cause the user agent to succeed in completing transactions with the client. In the case of a web server application the client is a web server. In the case of a user agent application the client is logic running within the user agent (so instead of a 302 you would most likely have a window.location reassignment and instead of a Set-Cookie header you would have a reassignment of document.cookie). The principle is the same. > > regards, > Torsten. > > > > > > > > > > On Thu, May 5, 2011 at 14:26, Hannes Tschofenig > > > wrote: > > >> Hey Breno, > > >> > > >> here is the draft I mentioned: > > >> http://tools.ietf.org/html/draft-lodderstedt-oauth- > > securityconsiderations-02 > > >> > > >> It would be great to get your review comments in. > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > > > > > > > > > > > -- > > > --Breno > > > > _______________________________________________ > > 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 > -- Breno de Medeiros --bcaec51f8fe17ce56204a30ddd9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, May 11, 2011 at 7:23 PM, Lodders= tedt, Torsten <t.lodderstedt@telekom.de> wrote:
    Hi Breno,

    thanks for the feedback. Please find my comments inline.

    > >
    > > Now higher level comments:
    > >
    > > On Native Apps protection of refresh token:
    > >
    > > On section Definitions, there is a sentence in the Native Apps &q= uot;It is
    > > assumed that such applications can protect dynamically issued
    > secrets,
    > > such as refresh tokens, from eavesdropping by other applications<= br> > > residing in the same service"

    the original text says: "on the same device"

    > >
    > > I suggest that you strike out this sentence from definitions sinc= e it
    > > is confusing. This should be moved to section 2.4, with a specifi= c
    > > headed paragraph about management of refresh tokens for native > > applications including specific recommendation.

    This section shall document all assumptions determining the differenc= es between those categories, which are relevant for the security sections. = Thus I would like to keep it and probably improve it.

    This may be a difference of opinion rather than substan= ce, but I find that assumptions stated too far ahead of their use suffer fr= om lack of connection. I would suggest again that the definition remain pur= ely semantic, and the security assumptions be discussed more closely to the= attending threats and mitigations.
    =A0

    > >
    > > E.g. of substitution paragraph:
    > >
    > > Native Applications MUST use operating system mediated protection= s to
    > > ensure that the refresh tokens are safe from unauthorized access = by
    > > other users and applications. It is highly RECOMMENDED that such<= br> > > applications use OS-provided APIs to manage secrets. The applicat= ions
    > > MUST apply appropriately restrictive access controls to any file<= br> > > system or persistent memory objects where the refresh token is > stored.
    > >
    > > On Client Authentication:
    > >
    > > "Authorization servers are encouraged to consider stronger c= lient
    > > authentication means" --> This is too vague to be actiona= ble. There
    > is
    > > a great tradition of 'innovation' in client security that= promotes no
    > > security and hinders interoperability. I tend to believe that it = is
    > > better for servers to be conscious of the limitations of client > > authentication and implement mitigation measures than to create a= d-
    > hoc
    > > authentication mechanisms. Suggest to strike out this sentence. > >
    > > "Authorization server MUST NOT issue client secrets to nativ= e or user
    > > agent-based applications in general." -> Agreed on user-a= gent,
    > however
    > > at least in principle it is possible to issue secrets to native > > applications that use hardware-based DRM modules and can hold on = to
    > > secrets.

    A couple of comments on this:

    1) This statement is intended to prohibit secrets for software packages and= not software instances. Thus the text also says "An authorization ser= ver MAY issue a client secret for an installation of a native application o= n a specific device.". We just want to get rid of the bad practice of = using secrets for authenticating software packages. This practice creates a= false feeling of security and people tend to rely on this kind of client a= uthentication too much. They shall be adviced to utilize other means than c= lient secrets.

    When the spec did define a Native App flow= it mandated the opposite (the secret was required not optional), which led= Google, for instance, to launch the OAuth2 registration for clients to inc= lude secret issuance for native apps---against the recommendation of our in= ternal security team---for pure compliance reasons (not that we are relying= on its remaining a secret, our security model does not rely on this). I we= lcome the change of language (even if we may take some time for Google to c= atch up with it), but find it a bit too strong. Possibly "It is NOT RE= COMMENDED ..." followed by some description of why this is ineffective= as a security measure?

    =A0
    2) The intention of the text is to give simple and clear rules instead of d= iscussing "if", "then" and "why". This discus= sion is subject of the security threats and considerations I-D referenced b= y the introduction of the text.

    Yes, and I am not suggesting it should -- = my recommendation was to strike it out. However, what about a softened appr= oach as above?
    =A0
    3) DRM modules give you a device specific authentication, they do not authe= nticate a certain software package or instance.

    >>> More importantly, since the OAuth2 spec no longer actually
    > > specifies how to implement a Native App Flow end-to-end, I am not=
    > sure
    > > how to even reason about Native App issues. Propose simply strike= out
    > > 'native or'.

    The description of how to implement native apps is badly missing righ= t now and has been requested during IETF-80. It will be re-included soon.

    That's welcome news indeed.
    =A0

    > >
    > > On Malicious Client Obtains Authorization:
    > >
    > > "Authorization servers MUST NOT automatically process (witho= ut user
    > > interaction) repeated authorizations without authenticating the > > client." -> Not sure what to make of this sentence. If th= is implies
    > > User-Agent should not support automatic renewal of access tokens<= br> > > (since user-agent apps cannot be 'authenticated'), then i= t is a
    > > harmful recommendation because it ignores practical requirements.= The
    > > bad word here is 'authenticating', since what is really i= ntended is
    > > some assurance that it is the same client, e.g., the redirect URI=
    > > matches a registered value in the User-Agent case. Please strike = out
    > > this sentence or substitute it with one like:
    > >
    > > "Authorization servers MUST implement measures to ensure tha= t
    > > automatically issued tokens (without user interaction, based on > > previously recorded grant) are delivered to the same client to wh= om
    > > original grant was performed. Example of suitable measures are > > enforcing client authentication or enforcing that the destination= of
    > a
    > > redirect (in case of implicit grant) matches the expected value f= or
    > > the client."

    As discussed in the other thread. I do not consider the redirect_uri = enforcement to be a reliable way to prevent abuse of existing authorization= s.

    Google's experience with threat = models on this space leads us to believe that it can be effective in practi= ce. Note that expansive variants of this practice are not safe, e.g., domai= n matching versus full redirect URI matching.

    Note that:

    - There is high val= ue from the perspective of deployment flexibility to support auto-approval = in flows where the client cannot authenticate (e.g., user-agent); =A0and
    - There is a class of existence of effective mitigation strategies: on= e of these that is fully spec-compliant is full URL matching. Another is to= use non-HTTP transport such as windows.postMessage() for authenticated cro= ss-domain communication of the response. (You could consider that a case of= client authentication where the user-agent is the authority).

    I believe that is quite important that we address this = issue with a bit of finesse. I understand that there is interest in not goi= ng into too much detail into a security considerations section for a broadl= y applicable spec. However this is a point where abstraction can easily cha= nge the threat model/risk profile to the point where a security practitione= r would reverse their recommendation on usage. Taking the easy option here = to use categorical language may be counterproductive. It is perfectly appro= priate to issue guidance that one expects to be widely disregarded provided= that one is convinced that those ignoring the guidance will inevitably be = putting their services and/or their users at risk. However, I do not think = this is the case here. It is possible (or so I believe) to violate this gui= dance as current stated and mitigate the risks appropriately.
    =A0

    > >
    > > On Access Tokens
    > >
    > > "Application developers MUST NOT store access tokens in non-= transient
    > > memory." -> This is not realistic -- consider the case of= a Web
    > > Application running on distributed servers. It is quite possible = that
    > > the only distributed storage mechanism available to the applicati= on
    > is
    > > based on persistent storage. I suggest you strike out this senten= ce,
    > > since the previous one is sufficient.

    Good point, I agree.

    > >
    > > On Session Fixation
    > >
    > > This section needs to cover XSRF protection, the measures describ= ed
    > > within are insufficient for Web Applications or User-Agent-Based<= br> > > applications. Also the current mitigation described there is bett= er
    > > described as a mitigation against token/code leakage.
    > >
    > > I suggest that you create a new section:
    > >
    > > =3D=3D
    > > Token and Code Leakage via Referer Header and/Or Open Redirectors=
    > >
    > > Attackers can leverage inclusion of third party content (images, = ads)
    > > and/or the presence of redirectors in legitimate Web or
    > > User-Agent-Based Applications to steal codes and/or tokens issued= to
    > > such sites.
    > >
    > > "In order to prevent such attack ..." (move here the 2n= d paragraph
    > > that currently lives on Session Fixation)
    > >
    > > Now for the Session Fixation section, I would recommend that you<= br> > > expand it to also include 'token', since the attack is al= so possible
    > > via token.
    > >
    > > The Session fixation attack involves an attacker that forwards a = link
    > > to an unsuspecting victim. The victim clicks on the link and
    > > subsequently approves an expected application but as a result the=
    > > attacker obtains access to the victim's data either at applic= ation or
    > > at the authorization server.
    > >
    > > In order to prevent such attack, a Web or User-Agent-Based
    > application
    > > MUST bind the state of authorization requests to the user's s= ession
    > > with the application. This requires that the Application generate= a
    > > strongly unguessable random number, and both include it in the > 'state'
    > > parameter of the authorization request as well as to store it in = the
    > > user's session, e.g., as an HTTP cookie, a DOM variable, or i= n any
    > > other suitable storage in the user's agent. When processing t= he
    > > response from the authorization server (whether in the form of a = code
    > > or token), the Application MUST verify that the returned 'sta= te'
    > > parameter matches the value in the user agent.
    > >

    In my opinion, the mean you describe is complementary to the re= direct_uri-based approach described in the text. Both can be used to detect= session fixation attempts. The difference is that the redirect_uri-based a= ppraoch relies on the authz server to detect the attack whereas the redirec= t_uri-based approach leaves the detection to the client.

    They are complementary but not in an optio= nal way. By that I mean that _both_ types of measures must _always_ be appl= ied.=A0

    The client cannot help the user agent agai= nst exploits where the attacker abuses the inherent authority of the user a= gent (while acting on behalf of the user), causing it to perform actions ag= ainst itself in a confused deputy-type scenario. That's the essence of = an XSRF. The client is impotent to help the user agent protect itself witho= ut explicit involvement by the user agent.
    =A0

    Would you please elaborate on how the state parameter prevents XSRF?

    The state parameter can provide XSRF (which i= n turn is essential to prevent session fixation attacks) as follows.

    - Client or user-agent generates a secret.
    - = The secret is stored in a location accessible only by the client or the use= r agent (i.e., protected by same-origin policy). E.g.: DOM variable (protec= ted 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 th= e client
    - When the response is received, before accepting the to= ken or code, the client consults the user agent state and rejects the respo= nse altogether if the state does not match the user agent's stored valu= e.

    Concrete example using HTTP cookies:

    Client issues a 302 to the user agent with a Set-Cookie header with = value "XsrfToken1=3D$unguessable_random_number" and while simulta= neously attaching to the request the state parameter "&state=3DXsr= fToken1%3D$unguessable_random_number"

    When the client receives the response from the authoriz= ation server, it checks that such cookie is also visible.

    Now, an attacker cannot perform a session fixation attack because i= t cannot cause the user agent to modify its state in the same-domain-origin= scope of the client (if it could it would be game over as it could cause t= he user agent to supply user credentials in most circumstances). Since it c= annot modify the user agent state, it cannot cause the user agent to succee= d in completing transactions with the client.

    In the case of a web server application the client is a= web server. In the case of a user agent application the client is logic ru= nning within the user agent (so instead of a 302 you would most likely have= a window.location reassignment and instead of a Set-Cookie header you woul= d have a reassignment of document.cookie). The principle is the same.
    =A0

    regards,
    Torsten.



    --
    Breno de Me= deiros

    --bcaec51f8fe17ce56204a30ddd9c-- From mark.mcgloin@ie.ibm.com Fri May 13 03:41: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 E7F2FE075D for ; Fri, 13 May 2011 03:41: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 giAAoqkhNoEl for ; Fri, 13 May 2011 03:41:22 -0700 (PDT) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1C695E0744 for ; Fri, 13 May 2011 03:41:21 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p4DAfKsU017904 for ; Fri, 13 May 2011 10:41:20 GMT Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4DAfCV52502846 for ; Fri, 13 May 2011 11:41:20 +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 p4DAfBlE021880 for ; Fri, 13 May 2011 11:41:12 +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 p4DAfBxj021874 for ; Fri, 13 May 2011 11:41:11 +0100 X-KeepSent: FF2EAFA9:5EE54B19-8025788F:00395A3E; type=4; name=$KeepSent To: oauth@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Fri, 13 May 2011 11:40:33 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 13/05/2011 11:40:35 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2011 10:41:23 -0000 Does anyone know of a formal security protocol analysis that has been carried out for OAuth 2.0? I could only find analysis done against 1.0a, like this one: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765 thanks Mark From fcorella@pomcor.com Fri May 13 09:58: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 29A2BE07E4 for ; Fri, 13 May 2011 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 cZ-+Hxi6RZYQ for ; Fri, 13 May 2011 09:58:06 -0700 (PDT) Received: from nm29.bullet.mail.ac4.yahoo.com (nm29.bullet.mail.ac4.yahoo.com [98.139.52.226]) by ietfa.amsl.com (Postfix) with SMTP id 7D681E073B for ; Fri, 13 May 2011 09:58:06 -0700 (PDT) Received: from [98.139.52.193] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 13 May 2011 16:58:01 -0000 Received: from [98.139.52.187] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 13 May 2011 16:58:01 -0000 Received: from [127.0.0.1] by omp1070.mail.ac4.yahoo.com with NNFMP; 13 May 2011 16:58:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 853929.20515.bm@omp1070.mail.ac4.yahoo.com Received: (qmail 42480 invoked by uid 60001); 13 May 2011 16:58:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305305881; bh=5XVPGnBfSiptipV29cnZ+igHvTLMzRKxVSb+jwSQEsk=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Bh0TuPTlGN7Xi9uMxWhFqCMdp/dJVNuGEO9uuincaPOTrZLP593x3FEOCTioF0xM5TiIl8XlJEUu9xd6XfpwMd+vIom1eowOGSBQ04gW0S+I/hw69JR5QGV9H8IGyxaeOZXGbbQVNHyeBrJOA65XQ6xC+IIELyopYT4SfLNZqb4= Message-ID: <716589.42107.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: Pb2iC1YVM1kT0pQX4Clcu5UN2QGbo4Uxtnl0ThBig29B.5Z ix9hOrjLwy2Qbw0EaOvRFQq1tmIauz7x65lxuTN5B8PejYYvesMl4XGaYit5 z4hRS02WIphOPN5PQTSsUvexLBT2Qn6tF1Udfo.v1RHGoIy5QvG9qz.bfsRp bsL5UK4X8JJDHxphT0kxSBanM1YrO.J.8tdTb2rXR1eOlY57NTF9Vcy3MnEP B9f7wNdDbVUnnQWNnl5H4KoCu.JdGCyKuVtfugooGg3qGCHpqSHVDDdfZKEe wcHhZKF9xV74pxXUJSXD7T2EW21pwDQw3dSidPYPtHgotdm9cVsNMnkQ9xan wRBZmERQt8tgyUKtUTyY2W.rX8jFUJbtKKwXFtxfOJ_2JmNtkkIpxJc3r5Yv WrplgNWZY4HVmvXhpIsXMyTgn03sHJyH0pPlJX2leeZuTrqWHBOObXEdV5Tj H_wamJhL4ioxuc7Jz9qTdh.t0cYtZDKGnlrNuJcBzgOP.VATeeaNwlrZPbWp DRmbyL9V0kr954ZQ78Vxfp9ZXeTWLsATmEuYkkfSczJ.PPZRZOXXmbNn5mRT QCi1UtO8.TdOBa9Tkw_IXArw2dQ-- Received: from [67.91.91.101] by web55806.mail.re3.yahoo.com via HTTP; Fri, 13 May 2011 09:58:01 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Fri, 13 May 2011 09:58:01 -0700 (PDT) From: Francisco Corella To: oauth@ietf.org, Mark Mcgloin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-622596522-1305305881=:42107" Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:58:07 -0000 --0-622596522-1305305881=:42107 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We wrote a security analysis of double redirection protocols that has a sec= tion on OAuth 2.0 as of draft 11.=A0 You can find it at http://pomcor.com/t= echreports/DoubleRedirection.pdf Francisco --- On Fri, 5/13/11, Mark Mcgloin wrote: From: Mark Mcgloin Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 To: oauth@ietf.org Date: Friday, May 13, 2011, 10:40 AM Does anyone know of a formal security protocol analysis that has been carried out for OAuth 2.0? I could only find analysis done against 1.0a, like this one: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5762765 thanks Mark _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-622596522-1305305881=:42107 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    We wrote a security analysis of double redire= ction protocols that has a section on OAuth 2.0 as of draft 11.  You c= an find it at http://pomcor.com/techreports/DoubleRedirection.pdf

    Francisco=

    --- On Fri, 5/13/11, Mark Mcgloin <mark.mcgloin@ie.ibm.com= > wrote:

    From: Mark Mcgloin <= mark.mcgloin@ie.ibm.com>
    Subject: [OAUTH-WG] Formal security protocol= analysis of OAuth 2.0
    To: oauth@ietf.org
    Date: Friday, May 13, 2011,= 10:40 AM


    Does anyone know of a formal = security protocol analysis that has been
    carried out for OAuth 2.0?
    <= br>I could only find analysis done against 1.0a, like this one:

    http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= mp;arnumber=3D5762765


    thanks
    Mark

    ________________= _______________________________
    OAuth mailing list
    OAuth@ietf.org<= /a>
    https://www.ietf.org/mailman/listinfo/oauth
    --0-622596522-1305305881=:42107-- From d.tangren@gmail.com Fri May 13 10:50: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 D2986E081A for ; Fri, 13 May 2011 10:50:13 -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=[AWL=-0.000, 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 Q53RE4lTbfRy for ; Fri, 13 May 2011 10:50:13 -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 CEFE1E07E1 for ; Fri, 13 May 2011 10:50:12 -0700 (PDT) Received: by gyf3 with SMTP id 3so1209067gyf.31 for ; Fri, 13 May 2011 10:50:12 -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=Q0i+nJcUza8cVnPoYhSwluhF2Y6BoJpXwtEqMPrb8R8=; b=yEU1FfX6v1h3G6+e4m8zTRkWsfrlFvoOMWk+JpHCidegUURQcaIgLxBrUnbugi5S+T 2P1aOrAq2jTUsLCOq0w6Jf5kroXvdB19VEFO3HPeQVVrR0OxNL8rNxYtveZ6Z9CdnXSs 7UZ2t0u36RUlaw439O5lDfsqvB9lwTe1b1X8Q= 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=p29PkEjtiXfHDYS42EjKkYHNEtc1uip31w1rUmHSVGHcysQF7MXrAI1ftlAWyTZqlw WUIFG6+thvbeweVI/AsuWBzb9gXMsgqhcmLjqj2MAEGuAZ4L5ogsAWkOwJhYT2jCm3LF UqcpHYRsNXtNqwv0Lg2nxhRzIb5e35A0U6H6A= Received: by 10.91.73.21 with SMTP id a21mr1560116agl.4.1305309012153; Fri, 13 May 2011 10:50:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Fri, 13 May 2011 10:49:52 -0700 (PDT) In-Reply-To: <716589.42107.qm@web55806.mail.re3.yahoo.com> References: <716589.42107.qm@web55806.mail.re3.yahoo.com> From: Doug Tangren Date: Fri, 13 May 2011 13:49:52 -0400 Message-ID: To: fcorella@pomcor.com Content-Type: multipart/alternative; boundary=001485f7ce7afdd78b04a32bef92 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2011 17:50:13 -0000 --001485f7ce7afdd78b04a32bef92 Content-Type: text/plain; charset=UTF-8 -Doug Tangren http://lessis.me On Fri, May 13, 2011 at 12:58 PM, Francisco Corella wrote: > We wrote a security analysis of double redirection protocols that has a > section on OAuth 2.0 as of draft 11. You can find it at > http://pomcor.com/techreports/DoubleRedirection.pdf > > Wow, this looks really informative. Thanks! --001485f7ce7afdd78b04a32bef92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    -Doug Tangren
    http://lessis.me


    On Fri, May 13, 2011 at 12:58 PM, Franci= sco Corella <fc= orella@pomcor.com> wrote:
    We wrote a security analysis of double = redirection protocols that has a section on OAuth 2.0 as of draft 11.=C2=A0= You can find it at http://pomcor.com/techreports/DoubleRedirection.= pdf


    Wow, this looks re= ally informative. Thanks!
    --001485f7ce7afdd78b04a32bef92-- From vss@73rus.com Fri May 13 15:22: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 C4A55E085C for ; Fri, 13 May 2011 15:22:41 -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 Hgae4HdxrXUg for ; Fri, 13 May 2011 15:22:41 -0700 (PDT) Received: from tail.lionet.info (tail.lionet.info [216.218.215.226]) by ietfa.amsl.com (Postfix) with ESMTP id F3D92E0840 for ; Fri, 13 May 2011 15:22:40 -0700 (PDT) Received: from localhost (173-228-88-32.dsl.dynamic.sonic.net [173.228.88.32]) (authenticated bits=0) by tail.lionet.info (8.13.8/8.13.6) with ESMTP id p4DMMdXM030675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 May 2011 15:22:40 -0700 (PDT) (envelope-from vss@73rus.com) Date: Fri, 13 May 2011 15:22:40 -0700 From: Vlad Skvortsov To: oauth@ietf.org Message-ID: <20110513222239.GA1543@paw.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (tail.lionet.info [216.218.215.226]); Fri, 13 May 2011 15:22:40 -0700 (PDT) Subject: [OAUTH-WG] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2011 23:00:43 -0000 Hi, a have a question regarding unauthenticated requests to a token endpoint in OAuth 2.0. The spec v2-15 section 3 says[1] that "the authorization server MAY allow unauthenticated access token requests when the client identity does not matter". Does that mean omitting "client_id" and "client_secret" parameters altogether? In our setting there are two types of clients: regular clients with proper credentials (username/password) and JavaScript clients working anonymously. The server is supposed to grant different permissions to these groups of clients based on the authentication method used. It's not clear from the spec how the anonymous access should be requested. Please advice! Thanks! [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 -- Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com From eran@hueniverse.com Fri May 13 16:15: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 22371E08FF for ; Fri, 13 May 2011 16:15:50 -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.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 DlE6Z37sMV+n for ; Fri, 13 May 2011 16:15:49 -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 86D2FE07E9 for ; Fri, 13 May 2011 16:15:49 -0700 (PDT) Received: (qmail 15393 invoked from network); 13 May 2011 23:15:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 May 2011 23:15:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 13 May 2011 16:15:25 -0700 From: Eran Hammer-Lahav To: Vlad Skvortsov Date: Fri, 13 May 2011 16:15:17 -0700 Thread-Topic: [OAUTH-WG] unauthenticated token requests Thread-Index: AcwRw6Nbr8eFXfedS7S/Ge5kDJeGAw== Message-ID: <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> References: <20110513222239.GA1543@paw.local> In-Reply-To: <20110513222239.GA1543@paw.local> 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] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 13 May 2011 23:15:50 -0000 The client_id is required. client_secret is not. EHL On May 13, 2011, at 16:00, "Vlad Skvortsov" wrote: > Hi, >=20 > a have a question regarding unauthenticated requests to a token endpoint > in OAuth 2.0. The spec v2-15 section 3 says[1] that "the authorization > server MAY allow unauthenticated access token requests when the client > identity does not matter". Does that mean omitting "client_id" and > "client_secret" parameters altogether? >=20 > In our setting there are two types of clients: regular clients with > proper credentials (username/password) and JavaScript clients working > anonymously. The server is supposed to grant different permissions to > these groups of clients based on the authentication method used. >=20 > It's not clear from the spec how the anonymous access should be > requested. Please advice! >=20 > Thanks! >=20 > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 >=20 > --=20 > Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mark.mcgloin@ie.ibm.com Sat May 14 04:10: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 BC5E5E06D4 for ; Sat, 14 May 2011 04:10:49 -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 O5Y3V0j3Kxgy for ; Sat, 14 May 2011 04:10:48 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF0EE06CB for ; Sat, 14 May 2011 04:10:47 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p4EBAjbu028203 for ; Sat, 14 May 2011 11:10:45 GMT Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4EBAUxW2527462 for ; Sat, 14 May 2011 12:10:45 +0100 Received: from d06av10.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4EBAT7H007002 for ; Sat, 14 May 2011 05:10:29 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4EBATrw006994; Sat, 14 May 2011 05:10:29 -0600 In-Reply-To: <716589.42107.qm@web55806.mail.re3.yahoo.com> References: <716589.42107.qm@web55806.mail.re3.yahoo.com> X-KeepSent: E842359D:8D8F4579-80257890:003D0B16; type=4; name=$KeepSent To: fcorella@pomcor.com X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Sat, 14 May 2011 12:09:52 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 14/05/2011 12:09:53 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 May 2011 11:10:49 -0000 Hi Francisco Yes, I have seen that report in the past and it is good and informative but is not a substitute for formal analysis. Here is another example of the type of analysis I am looking for, this one covering Oauth 1.0a from our research lab http://domino.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf Regards Mark Francisco Corella wrote on 13/05/2011 17:58:01: > Francisco Corella > 13/05/2011 17:58 > > Please respond to > fcorella@pomcor.com > > To > > oauth@ietf.org, Mark Mcgloin/Ireland/IBM@IBMIE > > cc > > Subject > > Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > > We wrote a security analysis of double redirection protocols that > has a section on OAuth 2.0 as of draft 11. You can find it at > http://pomcor.com/techreports/DoubleRedirection.pdf > > Francisco > > --- On Fri, 5/13/11, Mark Mcgloin wrote: > > From: Mark Mcgloin > Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > To: oauth@ietf.org > Date: Friday, May 13, 2011, 10:40 AM > > Does anyone know of a formal security protocol analysis that has been > carried out for OAuth 2.0? > > I could only find analysis done against 1.0a, like this one: > > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765 > > > thanks > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From fcorella@pomcor.com Sun May 15 16:19: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 C3CFDE0700 for ; Sun, 15 May 2011 16:19:42 -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 oqQyItfUfVdX for ; Sun, 15 May 2011 16:19:41 -0700 (PDT) Received: from nm30.bullet.mail.ac4.yahoo.com (nm30.bullet.mail.ac4.yahoo.com [98.139.52.227]) by ietfa.amsl.com (Postfix) with SMTP id 738BAE06D7 for ; Sun, 15 May 2011 16:19:40 -0700 (PDT) Received: from [98.139.52.197] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 15 May 2011 23:19:37 -0000 Received: from [98.139.52.186] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 15 May 2011 23:19:37 -0000 Received: from [127.0.0.1] by omp1069.mail.ac4.yahoo.com with NNFMP; 15 May 2011 23:19:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 550104.985.bm@omp1069.mail.ac4.yahoo.com Received: (qmail 93191 invoked by uid 60001); 15 May 2011 23:19:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305501577; bh=2KtDFP4oc4VrdyztSIRpB2Kq02nb6KzahHLw05Wt2IY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VEh+y/eY3evaUqlClG6Umy/mlzdcY975wSwXg9+rH8JOHm3VUGuVy86Z8l7OVPy4AvSTYrNfHOrKu83cG8AKhVXWhfbK3zvCWceIAXkWQGi6L4TmVpkcR3ACUUdDeTS9wZscsIio78F2r1dsCMgpxbp/WGGwljraqJXqyYZVvvQ= Message-ID: <415623.86964.qm@web55807.mail.re3.yahoo.com> X-YMail-OSG: AyrjwYsVM1nE5b.ZSQ2SxKSGglCN8LWhtY6hI3Tiq7AQJj1 TQoG3rkFrXHUMK8XYq1ihZLjOgTwNNwCybWEQSa0SsxRer.nfEkA37ridZ89 KdhaGMv1EK3p_eIh7h0.zs1Kh9JkAWtKKIPA6nM4wOzsW_Dt3S2qYR_S.5vr tNmQIgoDeJGWHlhqB4AN3VyIBeY8D2Tk9VLK.NWvNhT2_EaFUwIxUr7NSgwk yhyQltlPYsBfQilnhWEjCfPDP_6Bk5dPmqVR4I4OF8m_E.2UyIC5wSkn42vo eQLCSumypRsWFUTv3jRXKpEgowJLFTaR8CLPwS_EPa6vIMooeDZWvfUjWgyk meSF2z8o_0hUF91RcOL6tQlpmVjO30BaJMlXIlZynoERrigglCV1VY.R5jAn tkQ9P9W6TPpgt3xlnFjcJAU89LCqoe_i0.3muNMqQ4f6pNr16BcTJG9Vsy_F p2tfweZvbwpT9f5rFnTjbq7.wPm2qbJ8YZBJ0SRCJCrNcosgWGuZ2I9RGIyi fYw-- Received: from [174.65.103.16] by web55807.mail.re3.yahoo.com via HTTP; Sun, 15 May 2011 16:19:37 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Sun, 15 May 2011 16:19:37 -0700 (PDT) From: Francisco Corella To: Mark Mcgloin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2093832853-1305501577=:86964" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 23:19:42 -0000 --0-2093832853-1305501577=:86964 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc, You're right, the report I referred to is not a formal analysis. Thanks for the reference to the your lab's analysis of OAuth 1.0a.=A0 I had= a quick look at it, and at the Canetti tutorial on the underlying methodol= ogy that the paper refers to.=A0 It's interesting, but so complicated! It's a pity that your colleagues missed the flaw in OAuth 1.0a.=A0 In secti= on 5.4 they say "We assume that the Consumer and Service Providers have pub= lic keys (and certificates) and that the end-user communicates with theses = server entities over secure channels (SSL/TLS)".=A0 If instead of assuming = it they had checked the spec they would have seen that that's not true for = the consumer, and they would have been able to claim an important practical= result :-) Francisco --- On Sat, 5/14/11, Mark Mcgloin wrote: From: Mark Mcgloin Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 To: fcorella@pomcor.com Cc: oauth@ietf.org Date: Saturday, May 14, 2011, 11:09 AM Hi Francisco Yes, I have seen that report in the past and it is good and informative but is not a substitute for formal analysis. Here is another example of the type of analysis I am looking for, this one covering Oauth 1.0a from our research lab http://domino.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A085= 2576410043BCDD/$File/rc24856.pdf Regards Mark Francisco Corella wrote on 13/05/2011 17:58:01: > Francisco Corella > 13/05/2011 17:58 > > Please respond to > fcorella@pomcor.com > > To > > oauth@ietf.org, Mark Mcgloin/Ireland/IBM@IBMIE > > cc > > Subject > > Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > > We wrote a security analysis of double redirection protocols that > has a section on OAuth 2.0 as of draft 11.=A0 You can find it at > http://pomcor.com/techreports/DoubleRedirection.pdf > > Francisco > > --- On Fri, 5/13/11, Mark Mcgloin wrote: > > From: Mark Mcgloin > Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > To: oauth@ietf.org > Date: Friday, May 13, 2011, 10:40 AM > > Does anyone know of a formal security protocol analysis that has been > carried out for OAuth 2.0? > > I could only find analysis done against 1.0a, like this one: > > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5762765 > > > thanks > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --0-2093832853-1305501577=:86964 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi Marc,

    You're right, the report I re= ferred to is not a formal analysis.

    Thanks for the reference to the = your lab's analysis of OAuth 1.0a.  I had a quick look at it, and at t= he Canetti tutorial on the underlying methodology that the paper refers to.=   It's interesting, but so complicated!

    It's a pity that your c= olleagues missed the flaw in OAuth 1.0a.  In section 5.4 they say "We = assume that the Consumer and Service Providers have public keys (and certif= icates) and that the end-user communicates with theses server entities over= secure channels (SSL/TLS)".  If instead of assuming it they had check= ed the spec they would have seen that that's not true for the consumer, and= they would have been able to claim an important practical result :-)
    Francisco

    --- On Sat, 5/14/11, Mark Mcgloin <mark.mcgloin@ie.ibm.com> wrote:

    From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
    Subject: Re: = [OAUTH-WG] Formal security protocol analysis of OAuth 2.0
    To: fcorella@p= omcor.com
    Cc: oauth@ietf.org
    Date: Saturday, May 14, 2011, 11:09 AM
    Hi Francisco

    Yes, I have seen that re= port in the past and it is good and informative but
    is not a substitute = for formal analysis. Here is another example of the
    type of analysis I a= m looking for, this one covering Oauth 1.0a from our
    research lab
    http://domi= no.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A0852576410043B= CDD/$File/rc24856.pdf


    Regards
    Mark


    Francisco Corella <fcorella@pomcor.com> wrote on 13/05/2011 1= 7:58:01:

    > Francisco Corella <fcorella@pomcor.com= >
    > 13/05/2011 17:58
    >
    > Please respond to
    >= fcorella@pomcor.com
    >
    > To
    >
    > oauth@ietf.org, Mark Mcgloin/Ireland/IBM@IBMIE
    >
    > cc
    &= gt;
    > Subject
    >
    > Re: [OAUTH-WG] Formal security protocol= analysis of OAuth 2.0
    >
    > We wrote a security analysis of doub= le redirection protocols that
    > has a section on OAuth 2.0 as of draf= t 11.  You can find it at
    > http://pomcor.com/techreports/DoubleRedirection.pdf
    >
    >= ; Francisco
    >
    > --- On Fri, 5/13/11, Mark Mcgloin <mark.mcgloin@ie.ibm.com> wrote:
    >
    > From: Ma= rk Mcgloin <mark.mcgloin@ie.ibm.com>
    >= Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0
    >= To: oauth@ietf.org
    > Date: Friday, May 13, 2011, 10:40 AM
    =
    >
    > Does anyone know of a formal security protocol analysis th= at has been
    > carried out for OAuth 2.0?
    >
    > I could only= find analysis done against 1.0a, like this one:
    >
    > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= mp;arnumber=3D5762765
    >
    >
    > thanks
    > Mark
    &g= t;
    > _______________________________________________
    > OAuth ma= iling list
    > OAuth@ietf.org
    > https://www.ietf.org/mailma= n/listinfo/oauth

    --0-2093832853-1305501577=:86964-- From d.tangren@gmail.com Sun May 15 19:31: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 990A3E06D6 for ; Sun, 15 May 2011 19:31:41 -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 o0Z-Z6csUmvv for ; Sun, 15 May 2011 19:31:41 -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 011D4E06B9 for ; Sun, 15 May 2011 19:31:40 -0700 (PDT) Received: by yic13 with SMTP id 13so1654400yic.31 for ; Sun, 15 May 2011 19:31:40 -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=qBaDlN0iSBQ0fBDKd4+TVCtntsDWPtftbmEUyP4G/bg=; b=JpA/UuNwZYkyXuPxTqC5QWrcvMQm6FKxo4Kn65uJTE95zkyVronpzzhwg0EKq08Vss kk/mjeZCg+SEQYN7efeVDc9oQFFkfJnSZSYUQY90plqy48Ls/gnzfcjQz15V76Cj/TR0 AEYv2ZNDw4I1u4xV6b9mxSc3lLe6Su/neiIZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fzRNnai5kXeehw1ZpG1+mHmBrUsp+zb2Mjm5XfD0X/yCCYiONTFf7wX5YjihUIgJwQ 55lOCHgf8fZPJfWjoxUpvDz4Ftp7f1mT0rowrhmnGLDFOzmdkg2o8lqS6goADp7PwXaG OpNjkouAsounMHPEPt8KyNkp45SuCIYbQjJvY= Received: by 10.90.235.17 with SMTP id i17mr2997169agh.112.1305513100248; Sun, 15 May 2011 19:31:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Sun, 15 May 2011 19:31:20 -0700 (PDT) From: Doug Tangren Date: Sun, 15 May 2011 22:31:20 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00163628477e9706e804a35b748d Subject: [OAUTH-WG] purpose of client sending bodyhash in mac authorized requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 02:31:41 -0000 --00163628477e9706e804a35b748d Content-Type: text/plain; charset=UTF-8 I'm implementing a mac authorization module for request handling library [1] based on the latest mac spec. I ran into a curious implementation detail having do with the bodyhash value passed in by the client. Here [2], it says the server should recalculate the bodyhash if the client passes one in. Since it doesn't mention comparing bodyhash values, does that mean the only reason for having to pass in the value of the bodyhash is so that the server knows to include it's own bodyhashing vs an empty string in the mac hash verification? Otherwise, I don't see why the client needs to pass it in. There there an implicit requirent for the server to also validate the bodyhash before calculating the it's own mac for validation? I realize some request bodies may be empty but couldn't the server detect that on it's own and make it required that the client also includes a bodyhash in its own mac calculation. That would be one less header field server implementors have to handle different paths of executions for. [1]: https://github.com/n8han/unfiltered/#readme [2]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-4 -Doug Tangren http://lessis.me --00163628477e9706e804a35b748d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm implementing a mac authorization module for request handling librar= y [1] based on the latest mac spec. I ran into a=C2=A0curious implementatio= n detail having do with the bodyhash value passed in by the client.=C2=A0
    Here [2], it says the server should recalculate the bodyhash if = the client passes one in. Since it doesn't mention comparing bodyhash v= alues, does that mean the only reason for having to pass in the value of th= e bodyhash is so that the server knows to include it's own bodyhashing = vs an empty string in the mac hash verification? Otherwise, I don't see= why the client needs to pass it in. There there an implicit requirent for = the server to also validate the bodyhash before calculating the it's ow= n mac for validation?=C2=A0

    I realize some request bodies may be empty but couldn't = the server detect that on it's own and make it required that the client= also includes a bodyhash in its own mac calculation. That would be one les= s header field server implementors have to handle different paths of execut= ions for.

    [2]: <= a href=3D"http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#sec= tion-4">http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#secti= on-4

    -Doug Tangren
    http://lessis.me
    --00163628477e9706e804a35b748d-- From igor.faynberg@alcatel-lucent.com Mon May 16 01: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 B511DE06E9 for ; Mon, 16 May 2011 01:03: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 zvgdy+Ooa7z7 for ; Mon, 16 May 2011 01:02:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC52E062B for ; Mon, 16 May 2011 01:02:58 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4G82Re4024640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 May 2011 03:02:27 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4G82Q4K002904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 May 2011 03:02:27 -0500 Received: from [135.244.1.165] (faynberg.lra.lucent.com [135.244.1.165]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4G82PSv015107; Mon, 16 May 2011 03:02:26 -0500 (CDT) Message-ID: <4DD0DA11.5080908@alcatel-lucent.com> Date: Mon, 16 May 2011 04:02:25 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Mcgloin 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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 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, 16 May 2011 08:03:00 -0000 The approach looks right to me; the key is that the 1.0 state machine is rather simple. A priori, I don't see the 2.0 as more complex (even though it involves an additional machine), and I think it should be straight-forward to build the machine and run the reachability analysis on the system graph. The conclusions of this paper puzzle me though. There are things that I simply do not understand. For instance, what does this mean: "The current OAuth specification uses nonce, timestamps and signatures to guard against possible attacks. If the API interfaces are secure, they are not needed. On the other hand, if the API interfaces are insecure, they are not sufficient to guarantee the desired security properties." Igor Mark Mcgloin wrote: > Does anyone know of a formal security protocol analysis that has been > carried out for OAuth 2.0? > > I could only find analysis done against 1.0a, like this one: > > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765 > > > thanks > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Mon May 16 01:07: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 DCB57E070B for ; Mon, 16 May 2011 01:07:17 -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=[AWL=-0.000, 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 wvZbxzyGi7HE for ; Mon, 16 May 2011 01:07:16 -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 C3D06E06E9 for ; Mon, 16 May 2011 01:07:16 -0700 (PDT) Received: (qmail 13757 invoked from network); 16 May 2011 08:07:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 May 2011 08:07:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 16 May 2011 01:07:08 -0700 From: Eran Hammer-Lahav To: Doug Tangren , "oauth@ietf.org" Date: Mon, 16 May 2011 01:06:56 -0700 Thread-Topic: [OAUTH-WG] purpose of client sending bodyhash in mac authorized requests Thread-Index: AcwTcWdLoGlD12AET4OyNTcUrDriFwALqxUw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DB3A4@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_90C41DD21FB7C64BB94121FBBC2E723447581DB3A4P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] purpose of client sending bodyhash in mac authorized requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 08:07:18 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DB3A4P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGF0dHJpYnV0ZXMgc2VydmVzIGJvdGggYXMgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgYSBi b2R5IGhhc2ggaGFzIGJlZW4gaW5jbHVkZWQsIGJ1dCBhbHNvIHRvIGFsbG93IHZhbGlkYXRpb24g b2YgdGhlIHJlcXVlc3QgKGV4Y2x1ZGluZyB0aGUgYm9keSkgYmVmb3JlIHRoZSBib2R5IGlzIHJl Y2VpdmVkLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb3VnIFRhbmdyZW4NClNlbnQ6IFN1 bmRheSwgTWF5IDE1LCAyMDExIDc6MzEgUE0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog W09BVVRILVdHXSBwdXJwb3NlIG9mIGNsaWVudCBzZW5kaW5nIGJvZHloYXNoIGluIG1hYyBhdXRo b3JpemVkIHJlcXVlc3RzDQoNCkknbSBpbXBsZW1lbnRpbmcgYSBtYWMgYXV0aG9yaXphdGlvbiBt b2R1bGUgZm9yIHJlcXVlc3QgaGFuZGxpbmcgbGlicmFyeSBbMV0gYmFzZWQgb24gdGhlIGxhdGVz dCBtYWMgc3BlYy4gSSByYW4gaW50byBhIGN1cmlvdXMgaW1wbGVtZW50YXRpb24gZGV0YWlsIGhh dmluZyBkbyB3aXRoIHRoZSBib2R5aGFzaCB2YWx1ZSBwYXNzZWQgaW4gYnkgdGhlIGNsaWVudC4N Cg0KSGVyZSBbMl0sIGl0IHNheXMgdGhlIHNlcnZlciBzaG91bGQgcmVjYWxjdWxhdGUgdGhlIGJv ZHloYXNoIGlmIHRoZSBjbGllbnQgcGFzc2VzIG9uZSBpbi4gU2luY2UgaXQgZG9lc24ndCBtZW50 aW9uIGNvbXBhcmluZyBib2R5aGFzaCB2YWx1ZXMsIGRvZXMgdGhhdCBtZWFuIHRoZSBvbmx5IHJl YXNvbiBmb3IgaGF2aW5nIHRvIHBhc3MgaW4gdGhlIHZhbHVlIG9mIHRoZSBib2R5aGFzaCBpcyBz byB0aGF0IHRoZSBzZXJ2ZXIga25vd3MgdG8gaW5jbHVkZSBpdCdzIG93biBib2R5aGFzaGluZyB2 cyBhbiBlbXB0eSBzdHJpbmcgaW4gdGhlIG1hYyBoYXNoIHZlcmlmaWNhdGlvbj8gT3RoZXJ3aXNl LCBJIGRvbid0IHNlZSB3aHkgdGhlIGNsaWVudCBuZWVkcyB0byBwYXNzIGl0IGluLiBUaGVyZSB0 aGVyZSBhbiBpbXBsaWNpdCByZXF1aXJlbnQgZm9yIHRoZSBzZXJ2ZXIgdG8gYWxzbyB2YWxpZGF0 ZSB0aGUgYm9keWhhc2ggYmVmb3JlIGNhbGN1bGF0aW5nIHRoZSBpdCdzIG93biBtYWMgZm9yIHZh bGlkYXRpb24/DQoNCkkgcmVhbGl6ZSBzb21lIHJlcXVlc3QgYm9kaWVzIG1heSBiZSBlbXB0eSBi dXQgY291bGRuJ3QgdGhlIHNlcnZlciBkZXRlY3QgdGhhdCBvbiBpdCdzIG93biBhbmQgbWFrZSBp dCByZXF1aXJlZCB0aGF0IHRoZSBjbGllbnQgYWxzbyBpbmNsdWRlcyBhIGJvZHloYXNoIGluIGl0 cyBvd24gbWFjIGNhbGN1bGF0aW9uLiBUaGF0IHdvdWxkIGJlIG9uZSBsZXNzIGhlYWRlciBmaWVs ZCBzZXJ2ZXIgaW1wbGVtZW50b3JzIGhhdmUgdG8gaGFuZGxlIGRpZmZlcmVudCBwYXRocyBvZiBl eGVjdXRpb25zIGZvci4NCg0KWzFdOiBodHRwczovL2dpdGh1Yi5jb20vbjhoYW4vdW5maWx0ZXJl ZC8jcmVhZG1lDQpbMl06IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhbW1lci1v YXV0aC12Mi1tYWMtdG9rZW4tMDUjc2VjdGlvbi00DQoNCi1Eb3VnIFRhbmdyZW4NCmh0dHA6Ly9s ZXNzaXMubWUNCg== --_000_90C41DD21FB7C64BB94121FBBC2E723447581DB3A4P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBhdHRy aWJ1dGVzIHNlcnZlcyBib3RoIGFzIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IGEgYm9keSBoYXNo IGhhcyBiZWVuIGluY2x1ZGVkLCBidXQgYWxzbyB0byBhbGxvdyB2YWxpZGF0aW9uIG9mIHRoZSBy ZXF1ZXN0IChleGNsdWRpbmcgdGhlIGJvZHkpIGJlZm9yZSB0aGUgYm9keSBpcyByZWNlaXZlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gb2F1dGgt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZiA8L2I+RG91ZyBUYW5ncmVuPGJyPjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1heSAxNSwg MjAxMSA3OjMxIFBNPGJyPjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8 L2I+IFtPQVVUSC1XR10gcHVycG9zZSBvZiBjbGllbnQgc2VuZGluZyBib2R5aGFzaCBpbiBtYWMg YXV0aG9yaXplZCByZXF1ZXN0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkkn bSBpbXBsZW1lbnRpbmcgYSBtYWMgYXV0aG9yaXphdGlvbiBtb2R1bGUgZm9yIHJlcXVlc3QgaGFu ZGxpbmcgbGlicmFyeSBbMV0gYmFzZWQgb24gdGhlIGxhdGVzdCBtYWMgc3BlYy4gSSByYW4gaW50 byBhJm5ic3A7Y3VyaW91cyBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgaGF2aW5nIGRvIHdpdGggdGhl IGJvZHloYXNoIHZhbHVlIHBhc3NlZCBpbiBieSB0aGUgY2xpZW50LiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhlcmUgWzJdLCBpdCBzYXlzIHRoZSBzZXJ2ZXIgc2hvdWxk IHJlY2FsY3VsYXRlIHRoZSBib2R5aGFzaCBpZiB0aGUgY2xpZW50IHBhc3NlcyBvbmUgaW4uIFNp bmNlIGl0IGRvZXNuJ3QgbWVudGlvbiBjb21wYXJpbmcgYm9keWhhc2ggdmFsdWVzLCBkb2VzIHRo YXQgbWVhbiB0aGUgb25seSByZWFzb24gZm9yIGhhdmluZyB0byBwYXNzIGluIHRoZSB2YWx1ZSBv ZiB0aGUgYm9keWhhc2ggaXMgc28gdGhhdCB0aGUgc2VydmVyIGtub3dzIHRvIGluY2x1ZGUgaXQn cyBvd24gYm9keWhhc2hpbmcgdnMgYW4gZW1wdHkgc3RyaW5nIGluIHRoZSBtYWMgaGFzaCB2ZXJp ZmljYXRpb24/IE90aGVyd2lzZSwgSSBkb24ndCBzZWUgd2h5IHRoZSBjbGllbnQgbmVlZHMgdG8g cGFzcyBpdCBpbi4gVGhlcmUgdGhlcmUgYW4gaW1wbGljaXQgcmVxdWlyZW50IGZvciB0aGUgc2Vy dmVyIHRvIGFsc28gdmFsaWRhdGUgdGhlIGJvZHloYXNoIGJlZm9yZSBjYWxjdWxhdGluZyB0aGUg aXQncyBvd24gbWFjIGZvciB2YWxpZGF0aW9uPyZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkkgcmVhbGl6ZSBzb21lIHJlcXVlc3QgYm9kaWVzIG1heSBiZSBlbXB0eSBidXQg Y291bGRuJ3QgdGhlIHNlcnZlciBkZXRlY3QgdGhhdCBvbiBpdCdzIG93biBhbmQgbWFrZSBpdCBy ZXF1aXJlZCB0aGF0IHRoZSBjbGllbnQgYWxzbyBpbmNsdWRlcyBhIGJvZHloYXNoIGluIGl0cyBv d24gbWFjIGNhbGN1bGF0aW9uLiBUaGF0IHdvdWxkIGJlIG9uZSBsZXNzIGhlYWRlciBmaWVsZCBz ZXJ2ZXIgaW1wbGVtZW50b3JzIGhhdmUgdG8gaGFuZGxlIGRpZmZlcmVudCBwYXRocyBvZiBleGVj dXRpb25zIGZvci48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlsxXTombmJz cDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbjhoYW4vdW5maWx0ZXJlZC8jcmVhZG1lIj5o dHRwczovL2dpdGh1Yi5jb20vbjhoYW4vdW5maWx0ZXJlZC8jcmVhZG1lPC9hPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlsyXTogPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFtbWVyLW9hdXRoLXYyLW1hYy10b2tlbi0wNSNzZWN0 aW9uLTQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhbW1lci1vYXV0aC12Mi1t YWMtdG9rZW4tMDUjc2VjdGlvbi00PC9hPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiciBjbGVhcj1hbGw+LURvdWcgVGFuZ3Jlbjxicj48YSBocmVmPSJodHRwOi8vbGVz c2lzLm1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xlc3Npcy5tZTwvYT48bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_90C41DD21FB7C64BB94121FBBC2E723447581DB3A4P3PW5EX1MB01E_-- From igor.faynberg@alcatel-lucent.com Mon May 16 01:45: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 53947E070B for ; Mon, 16 May 2011 01:45:30 -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 CoJ+IHMcFa2A for ; Mon, 16 May 2011 01:45:29 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C58CBE06AB for ; Mon, 16 May 2011 01:45:29 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p4G8jPjg029329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 May 2011 03:45:26 -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 p4G8jPAO026157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 May 2011 03:45:25 -0500 Received: from [135.244.1.165] (faynberg.lra.lucent.com [135.244.1.165]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4G8jO87003330; Mon, 16 May 2011 03:45:24 -0500 (CDT) Message-ID: <4DD0E423.2080008@alcatel-lucent.com> Date: Mon, 16 May 2011 04:45:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Mcgloin References: <716589.42107.qm@web55806.mail.re3.yahoo.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.11 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 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, 16 May 2011 08:45:30 -0000 Mark, Many thanks for posting this. I am thinking of the next step. This paper proposes to use the Password-Based Asymmetric Key Exchange protocol. Many messages ago, I had proposed to use the Password-Based DH key exchange for the symmetric key generation. Another option is to mandate some form of PKI for all OAuth actors. I did not want to bring this discussion until 2.0 is finished and published. (I do believe that the current security analysis and considerations lead by Torsten has been comprehensive, and therefore 2.0 ought to move to conclusion.) For the future, maybe you could work with your colleagues to compare the PBAKE and PAK specifically as they apply to OAuth? You might also consider publishing PBAKE in the IETF. Igor Mark Mcgloin wrote: > ... > Here is another example of the > type of analysis I am looking for, this one covering Oauth 1.0a from our > research lab > > http://domino.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf > > > > From mark.mcgloin@ie.ibm.com Mon May 16 03:53: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 6C6E9E06EA for ; Mon, 16 May 2011 03:53:35 -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 D2YiOwdC+oBT for ; Mon, 16 May 2011 03:53:34 -0700 (PDT) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by ietfa.amsl.com (Postfix) with ESMTP id 674C2E0695 for ; Mon, 16 May 2011 03:53:33 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p4GArVJt031559 for ; Mon, 16 May 2011 10:53:31 GMT Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4GArUFT2629800 for ; Mon, 16 May 2011 11:53:30 +0100 Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4GArUIC012463 for ; Mon, 16 May 2011 04:53:30 -0600 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4GArUGg012454; Mon, 16 May 2011 04:53:30 -0600 In-Reply-To: <4DD0DA11.5080908@alcatel-lucent.com> References: <4DD0DA11.5080908@alcatel-lucent.com> X-KeepSent: 9D41ECA9:4760A688-80257892:003AFFAF; type=4; name=$KeepSent To: igor.faynberg@alcatel-lucent.com X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Mon, 16 May 2011 11:52:52 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 16/05/2011 11:52:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 10:53:35 -0000 Hi Igor, comments Inline below Igor Faynberg wrote on 16/05/2011 09:02:25: > Igor Faynberg > 16/05/2011 09:02 > > Please respond to > igor.faynberg@alcatel-lucent.com > > To > > Mark Mcgloin/Ireland/IBM@IBMIE > > cc > > oauth@ietf.org > > Subject > > Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > > The approach looks right to me; the key is that the 1.0 state machine is > rather simple. A priori, I don't see the 2.0 as more complex (even > though it involves an additional machine), and I think it should be > straight-forward to build the machine and run the reachability analysis > on the system graph. > I think the part of the 2.0 spec most people would like to scrutinise is the implicit grant flow with no secret although I suspect the conclusion may be that the user has to 100% trust the consumer povider > The conclusions of this paper puzzle me though. There are things that I > simply do not understand. For instance, what does this mean: "The > current OAuth specification uses nonce, timestamps and signatures to > guard against possible attacks. If the API interfaces are secure, they > are not needed. On the other hand, if the API interfaces are insecure, > they are not sufficient to guarantee the desired security properties." > So they claim that signing is ineffective over http! > Igor > > Mark Mcgloin wrote: > > Does anyone know of a formal security protocol analysis that has been > > carried out for OAuth 2.0? > > > > I could only find analysis done against 1.0a, like this one: > > > > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765 > > > > > > thanks > > Mark > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From mark.mcgloin@ie.ibm.com Mon May 16 03:54: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 27944E06EA for ; Mon, 16 May 2011 03:54:45 -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 CFRbUZRquMvO for ; Mon, 16 May 2011 03:54:44 -0700 (PDT) Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3221DE0657 for ; Mon, 16 May 2011 03:54:44 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p4GAscCl016062 for ; Mon, 16 May 2011 10:54:38 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 p4GAscmq2478304 for ; Mon, 16 May 2011 11:54:38 +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 p4GAscWL007551 for ; Mon, 16 May 2011 04:54:38 -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 p4GAscGf007545; Mon, 16 May 2011 04:54:38 -0600 In-Reply-To: <4DD0E423.2080008@alcatel-lucent.com> References: <716589.42107.qm@web55806.mail.re3.yahoo.com> <4DD0E423.2080008@alcatel-lucent.com> X-KeepSent: 6083F439:4261ABCA-80257892:003BD691; type=4; name=$KeepSent To: igor.faynberg@alcatel-lucent.com X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Mon, 16 May 2011 11:53:59 +0100 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 16/05/2011 11:54:02 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 10:54:45 -0000 Hi Igor, I will pass on your comments Regards Mark Igor Faynberg wrote on 16/05/2011 09:45:23: > Igor Faynberg > 16/05/2011 09:45 > > Please respond to > igor.faynberg@alcatel-lucent.com > > To > > Mark Mcgloin/Ireland/IBM@IBMIE > > cc > > fcorella@pomcor.com, oauth@ietf.org > > Subject > > Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0 > > Mark, > > Many thanks for posting this. I am thinking of the next step. > > This paper proposes to use the Password-Based Asymmetric Key Exchange > protocol. Many messages ago, I had proposed to use the Password-Based > DH key exchange for the symmetric key generation. > > Another option is to mandate some form of PKI for all OAuth actors. > > I did not want to bring this discussion until 2.0 is finished and > published. (I do believe that the current security analysis and > considerations lead by Torsten has been comprehensive, and therefore 2.0 > ought to move to conclusion.) > > For the future, maybe you could work with your colleagues to compare the > PBAKE and PAK specifically as they apply to OAuth? You might also > consider publishing PBAKE in the IETF. > > Igor > > > Mark Mcgloin wrote: > > ... > > Here is another example of the > > type of analysis I am looking for, this one covering Oauth 1.0a from our > > research lab > > > > http://domino.watson.ibm.com/library/cyberdig.nsf/papers/ > B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf > > > > > > > > From d.tangren@gmail.com Mon May 16 06:42: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 13015E0689 for ; Mon, 16 May 2011 06:42:43 -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 ypjwk4gWslll for ; Mon, 16 May 2011 06:42:42 -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 26749E0665 for ; Mon, 16 May 2011 06:42:42 -0700 (PDT) Received: by yxk30 with SMTP id 30so1932085yxk.31 for ; Mon, 16 May 2011 06:42:41 -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=/UezayNBorfTWal76UYTBhWjKQYGT10HZOYn+2Kx0cI=; b=Kq4AT+xY47O/K+6AdnVR05tD0v4M4UwbkRrvzKEza8MJTQwwRUkfLoI2D90ffKVpOz Vpx2xgOGijoQvsifzfWYTPYIWXr/MzZGjGyROt51fSRBixhOmM+BuDlWts4lg7eWHwHL bx12dT40/KZrO5ig05FEKeCBho2pmGCjfPmlI= 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=SfIju5EiAUBBrY9Mgr2YhvQtwAuxiDUo+ZzesUM47zNu5SYx5/SxXX7NTMNNJiQYm3 fQk9E/sVeUv4SexbmGv4qnPxFahQmCHf+owFdSWsM36cpS9n8F9rLSAgEtNFiFWDoZCa GBYuoi2u30Cpqr7Bg/3lwYQSl0l4unfJvjZvU= Received: by 10.90.249.27 with SMTP id w27mr3303155agh.139.1305553361100; Mon, 16 May 2011 06:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Mon, 16 May 2011 06:42:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DB3A4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DB3A4@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Doug Tangren Date: Mon, 16 May 2011 09:42:21 -0400 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016363b880452e37b04a364d484 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] purpose of client sending bodyhash in mac authorized requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 13:42:43 -0000 --0016363b880452e37b04a364d484 Content-Type: text/plain; charset=UTF-8 -Doug Tangren http://lessis.me On Mon, May 16, 2011 at 4:06 AM, Eran Hammer-Lahav wrote: > The attributes serves both as a flag to indicate that a body hash has been > included, but also to allow validation of the request (excluding the body) > before the body is received. > > Makes sense. Thanks! --0016363b880452e37b04a364d484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    -Doug Tangren
    http://lessis.me


    On Mon, May 16, 2011 at 4:06 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

    The attribute= s serves both as a flag to indicate that a body hash has been included, but= also to allow validation of the request (excluding the body) before the bo= dy is received.



    Makes sense. Thanks!
    --0016363b880452e37b04a364d484-- From vss@73rus.com Mon May 16 10:18: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 2CEE5E0787 for ; Mon, 16 May 2011 10:18:40 -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 zIaYa2ImYoYH for ; Mon, 16 May 2011 10:18:39 -0700 (PDT) Received: from tail.lionet.info (tail.lionet.info [216.218.215.226]) by ietfa.amsl.com (Postfix) with ESMTP id A8A50E06BB for ; Mon, 16 May 2011 10:18:39 -0700 (PDT) Received: from localhost (173-228-88-32.dsl.dynamic.sonic.net [173.228.88.32]) (authenticated bits=0) by tail.lionet.info (8.13.8/8.13.6) with ESMTP id p4GHIZGa001350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 May 2011 10:18:35 -0700 (PDT) (envelope-from vss@73rus.com) Date: Mon, 16 May 2011 10:18:34 -0700 From: Vlad Skvortsov To: Eran Hammer-Lahav Message-ID: <20110516171834.GE1543@paw.local> References: <20110513222239.GA1543@paw.local> <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (tail.lionet.info [216.218.215.226]); Mon, 16 May 2011 10:18:35 -0700 (PDT) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 17:18:40 -0000 On Fri, May 13, 2011 at 04:15:17PM -0700, Eran Hammer-Lahav wrote: > The client_id is required. client_secret is not. Ok, thanks! This might deserve a clarification in the spec though — not obvious. > > EHL > > On May 13, 2011, at 16:00, "Vlad Skvortsov" wrote: > > > Hi, > > > > a have a question regarding unauthenticated requests to a token endpoint > > in OAuth 2.0. The spec v2-15 section 3 says[1] that "the authorization > > server MAY allow unauthenticated access token requests when the client > > identity does not matter". Does that mean omitting "client_id" and > > "client_secret" parameters altogether? > > > > In our setting there are two types of clients: regular clients with > > proper credentials (username/password) and JavaScript clients working > > anonymously. The server is supposed to grant different permissions to > > these groups of clients based on the authentication method used. > > > > It's not clear from the spec how the anonymous access should be > > requested. Please advice! > > > > Thanks! > > > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 > > > > -- > > Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth -- Vlad Skvortsov, vss@aboutecho.com From eve@xmlgrrl.com Mon May 16 15:14: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 8CBD4E069D for ; Mon, 16 May 2011 15:14:13 -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 4+cZEoNqlc9i for ; Mon, 16 May 2011 15:14:12 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 75A78E07DD for ; Mon, 16 May 2011 15:14:12 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.4) with ESMTP id p4GHtSV9021203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 May 2011 10:55:28 -0700 From: Eve Maler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 May 2011 10:55:27 -0700 To: oauth WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [OAUTH-WG] Looking for feedback on "client-server OAuth" usage X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 22:14:13 -0000 Folks-- Sorry for the intrusion, but this seemed the community best = positioned to respond to this query. I'm interested to talk to security = architects and application architects in organizations that have = informed opinions on the "client-server" pattern of OAuth as an = enterprise web services security technique, either because: - You currently use it with full forethought - You currently see ad-hoc usage of it in your org - You are considering using it for some use cases - You have considered and rejected it Any or all of the 2.0 MAC pattern, 1.0a usage, plain old app-to-app = protection, mobile use cases, etc. are fair game. Feel free to drop me a = note at eve@xmlgrrl.com or emaler@forrester.com, or ping me on Twitter = (use the hashtag #Forr2Legs to catch my attention fastest), or write in = here if you like: http://forr.com/FORRblog_OAuth Feel free to forward this to folks you know who might be interested to = respond. Thanks in advance, Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From bcampbell@pingidentity.com Mon May 16 15:45: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 94D7EE07E6 for ; Mon, 16 May 2011 15:45:18 -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 XXbTZofHCC6w for ; Mon, 16 May 2011 15:45:18 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id AB040E06AF for ; Mon, 16 May 2011 15:45:16 -0700 (PDT) Received: from mail-qy0-f181.google.com ([209.85.216.181]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTdGo/OVa3lFNQblodFByd/WEw0wtvRdF@postini.com; Mon, 16 May 2011 15:45:17 PDT Received: by mail-qy0-f181.google.com with SMTP id 14so2910593qyg.19 for ; Mon, 16 May 2011 15:45:16 -0700 (PDT) Received: by 10.224.104.141 with SMTP id p13mr3650628qao.128.1305585915199; Mon, 16 May 2011 15:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 16 May 2011 15:44:45 -0700 (PDT) In-Reply-To: <20110516171834.GE1543@paw.local> References: <20110513222239.GA1543@paw.local> <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> <20110516171834.GE1543@paw.local> From: Brian Campbell Date: Mon, 16 May 2011 16:44:45 -0600 Message-ID: To: Vlad Skvortsov Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 22:45:18 -0000 Yeah, I had just sort of being going off the assumption that client_id is required & client_secret is not but, looking at -15 again, I agree that it's not entirely obvious.=A0 There's the text at the end of section 3 that say allows for unauthenticated clients. Then in 3.1 both client_id & client_secret are marked as required. So, while it says unauthenticated clients are allowed, it's not fully clear how they are supposed to work or what parameters they should present. Along the same lines, can an unauthenticated client use HTTP Basic as shown in section 3.2 to present only the client_id?=A0 Would that just amount to using an empty string in place of a password?=A0So something like some_client_id: would end up as the header, Authorization: Basic c29tZV9jbGllbnRfaWQ6 ? On Mon, May 16, 2011 at 11:18 AM, Vlad Skvortsov wrote: > > On Fri, May 13, 2011 at 04:15:17PM -0700, Eran Hammer-Lahav wrote: > > The client_id is required. client_secret is not. > > Ok, thanks! This might deserve a clarification in the spec though =97 not > obvious. > > > > > EHL > > > > On May 13, 2011, at 16:00, "Vlad Skvortsov" wrote: > > > > > Hi, > > > > > > a have a question regarding unauthenticated requests to a token endpo= int > > > in OAuth 2.0. The spec v2-15 section 3 says[1] that "the authorizatio= n > > > server MAY allow unauthenticated access token requests when the clien= t > > > identity does not matter". Does that mean omitting "client_id" and > > > "client_secret" parameters altogether? > > > > > > In our setting there are two types of clients: regular clients with > > > proper credentials (username/password) and JavaScript clients working > > > anonymously. The server is supposed to grant different permissions to > > > these groups of clients based on the authentication method used. > > > > > > It's not clear from the spec how the anonymous access should be > > > requested. Please advice! > > > > > > Thanks! > > > > > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 > > > > > > -- > > > Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > -- > Vlad Skvortsov, vss@aboutecho.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon May 16 15:50: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 46F17E07F6 for ; Mon, 16 May 2011 15:50:33 -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.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 U2wOTBtyTehh for ; Mon, 16 May 2011 15:50:32 -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 944C5E07F0 for ; Mon, 16 May 2011 15:50:32 -0700 (PDT) Received: (qmail 3866 invoked from network); 16 May 2011 22:50:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 May 2011 22:50:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 16 May 2011 15:50:09 -0700 From: Eran Hammer-Lahav To: Brian Campbell , Vlad Skvortsov Date: Mon, 16 May 2011 15:50:06 -0700 Thread-Topic: [OAUTH-WG] unauthenticated token requests Thread-Index: AcwUGu4/7Oek6q5yRJqZSpQ+8/axrwAAJfYQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E3DC7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110513222239.GA1543@paw.local> <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> <20110516171834.GE1543@paw.local> 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@ietf.org" Subject: Re: [OAUTH-WG] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 22:50:33 -0000 No, client_id is always required. Basic will just duplicate it (server must= check they match - that's the "basic auth binding"). I'll clarify it. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Monday, May 16, 2011 3:45 PM > To: Vlad Skvortsov > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] unauthenticated token requests >=20 > Yeah, I had just sort of being going off the assumption that client_id is > required & client_secret is not but, looking at -15 again, I agree that i= t's not > entirely obvious.=A0 There's the text at the end of section 3 that say al= lows for > unauthenticated clients. > Then in 3.1 both client_id & client_secret are marked as required. > So, while it says unauthenticated clients are allowed, it's not fully cle= ar how > they are supposed to work or what parameters they should present. >=20 > Along the same lines, can an unauthenticated client use HTTP Basic as sho= wn > in section 3.2 to present only the client_id?=A0 Would that just amount t= o using > an empty string in place of a password?=A0So something like some_client_i= d: > would end up as the header, > Authorization: Basic c29tZV9jbGllbnRfaWQ6 ? >=20 >=20 > On Mon, May 16, 2011 at 11:18 AM, Vlad Skvortsov > wrote: > > > > On Fri, May 13, 2011 at 04:15:17PM -0700, Eran Hammer-Lahav wrote: > > > The client_id is required. client_secret is not. > > > > Ok, thanks! This might deserve a clarification in the spec though - > > not obvious. > > > > > > > > EHL > > > > > > On May 13, 2011, at 16:00, "Vlad Skvortsov" > wrote: > > > > > > > Hi, > > > > > > > > a have a question regarding unauthenticated requests to a token > > > > endpoint in OAuth 2.0. The spec v2-15 section 3 says[1] that "the > > > > authorization server MAY allow unauthenticated access token > > > > requests when the client identity does not matter". Does that mean > > > > omitting "client_id" and "client_secret" parameters altogether? > > > > > > > > In our setting there are two types of clients: regular clients > > > > with proper credentials (username/password) and JavaScript clients > > > > working anonymously. The server is supposed to grant different > > > > permissions to these groups of clients based on the authentication > method used. > > > > > > > > It's not clear from the spec how the anonymous access should be > > > > requested. Please advice! > > > > > > > > Thanks! > > > > > > > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 > > > > > > > > -- > > > > Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Vlad Skvortsov, vss@aboutecho.com > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon May 16 15:57: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 812A2E07B8 for ; Mon, 16 May 2011 15:57:47 -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 5Eysg6RcoiON for ; Mon, 16 May 2011 15:57:46 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id A033CE07B6 for ; Mon, 16 May 2011 15:57:46 -0700 (PDT) Received: from mail-qw0-f43.google.com ([209.85.216.43]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTdGr6abieesS+Fdd0KHb04pt/2SyCVRL@postini.com; Mon, 16 May 2011 15:57:46 PDT Received: by mail-qw0-f43.google.com with SMTP id 6so3427453qwf.2 for ; Mon, 16 May 2011 15:57:45 -0700 (PDT) Received: by 10.224.218.72 with SMTP id hp8mr3866587qab.78.1305586665150; Mon, 16 May 2011 15:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 16 May 2011 15:57:15 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E3DC7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110513222239.GA1543@paw.local> <877FD20D-A011-4B6D-B025-20E84F2C7E24@hueniverse.com> <20110516171834.GE1543@paw.local> <90C41DD21FB7C64BB94121FBBC2E723447582E3DC7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Mon, 16 May 2011 16:57:15 -0600 Message-ID: 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] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 16 May 2011 22:57:47 -0000 Clarification would be helpful, thanks. Note that the example in 3.2 doesn't have the client_id parameter in the body of the request. On Mon, May 16, 2011 at 4:50 PM, Eran Hammer-Lahav wr= ote: > No, client_id is always required. Basic will just duplicate it (server mu= st check they match - that's the "basic auth binding"). > > I'll clarify it. > > EHL > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Monday, May 16, 2011 3:45 PM >> To: Vlad Skvortsov >> Cc: Eran Hammer-Lahav; oauth@ietf.org >> Subject: Re: [OAUTH-WG] unauthenticated token requests >> >> Yeah, I had just sort of being going off the assumption that client_id i= s >> required & client_secret is not but, looking at -15 again, I agree that = it's not >> entirely obvious.=A0 There's the text at the end of section 3 that say a= llows for >> unauthenticated clients. >> Then in 3.1 both client_id & client_secret are marked as required. >> So, while it says unauthenticated clients are allowed, it's not fully cl= ear how >> they are supposed to work or what parameters they should present. >> >> Along the same lines, can an unauthenticated client use HTTP Basic as sh= own >> in section 3.2 to present only the client_id?=A0 Would that just amount = to using >> an empty string in place of a password?=A0So something like some_client_= id: >> would end up as the header, >> Authorization: Basic c29tZV9jbGllbnRfaWQ6 ? >> >> >> On Mon, May 16, 2011 at 11:18 AM, Vlad Skvortsov >> wrote: >> > >> > On Fri, May 13, 2011 at 04:15:17PM -0700, Eran Hammer-Lahav wrote: >> > > The client_id is required. client_secret is not. >> > >> > Ok, thanks! This might deserve a clarification in the spec though - >> > not obvious. >> > >> > > >> > > EHL >> > > >> > > On May 13, 2011, at 16:00, "Vlad Skvortsov" >> wrote: >> > > >> > > > Hi, >> > > > >> > > > a have a question regarding unauthenticated requests to a token >> > > > endpoint in OAuth 2.0. The spec v2-15 section 3 says[1] that "the >> > > > authorization server MAY allow unauthenticated access token >> > > > requests when the client identity does not matter". Does that mean >> > > > omitting "client_id" and "client_secret" parameters altogether? >> > > > >> > > > In our setting there are two types of clients: regular clients >> > > > with proper credentials (username/password) and JavaScript clients >> > > > working anonymously. The server is supposed to grant different >> > > > permissions to these groups of clients based on the authentication >> method used. >> > > > >> > > > It's not clear from the spec how the anonymous access should be >> > > > requested. Please advice! >> > > > >> > > > Thanks! >> > > > >> > > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3 >> > > > >> > > > -- >> > > > Vlad Skvortsov, VP Engineering Echo, vss@aboutecho.com >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > OAuth@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > -- >> > Vlad Skvortsov, vss@aboutecho.com >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Wed May 18 09:20: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 128D3E0714 for ; Wed, 18 May 2011 09:20:37 -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=[AWL=-0.000, 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 o7wBlz0v11wZ for ; Wed, 18 May 2011 09:20:36 -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 F1600E0703 for ; Wed, 18 May 2011 09:20:35 -0700 (PDT) Received: (qmail 28871 invoked from network); 18 May 2011 16:20:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 May 2011 16:20:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 May 2011 09:20:23 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 18 May 2011 09:20:18 -0700 Thread-Topic: Language encoding in error_description Thread-Index: AcwVd1TotSXN6am4RCe726YAf5dT8w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@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_90C41DD21FB7C64BB94121FBBC2E723447582E4117P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2011 16:20:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4117P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The error_description parameter and similar parameters in the MAC and Beare= r specs do not specify the language or encoding used. This is a problem. Ca= n someone offer a solution? EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4117P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The error_descri= ption parameter and similar parameters in the MAC and Bearer specs do not s= pecify the language or encoding used. This is a problem. Can someone offer = a solution?

     

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4117P3PW5EX1MB01E_-- From eran@hueniverse.com Wed May 18 09:39: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 1536CE0756 for ; Wed, 18 May 2011 09:39:05 -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.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 lHtYg91HWa4N for ; Wed, 18 May 2011 09:39: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 3654DE073E for ; Wed, 18 May 2011 09:39:02 -0700 (PDT) Received: (qmail 1959 invoked from network); 18 May 2011 16:39:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 May 2011 16:39:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 May 2011 09:38:44 -0700 From: Eran Hammer-Lahav To: Peter Wolanin Date: Wed, 18 May 2011 09:38:39 -0700 Thread-Topic: OAuth v2 Mac token spec Thread-Index: AcwK2BeOo9+BsW8BR/6eBCEa3ZQ5pgKoco3A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4125@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743AB6@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth v2 Mac token 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, 18 May 2011 16:39:05 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgV29sYW5pbiBb bWFpbHRvOnBldGVyLndvbGFuaW5AYWNxdWlhLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkg MDQsIDIwMTEgODo1NCBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IG9hdXRoQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBPQXV0aCB2MiBNYWMgdG9rZW4gc3BlYw0KPiANCj4gQ2Fu IHlvdSBnaXZlIGFuIGV4YW1wbGUgb2YgYSBzZXR1cCB3aGVyZSB0aGUgaGFzaCBjYW5ub3QgYmUg Y2FsY3VsYXRlZD8NCg0KTGFyZ2UgZmlsZSB1cGxvYWQgd2hpY2ggaXMgcmVhZCBmcm9tIGRpc2sg YXMgaXQgaXMgYmVpbmcgdHJhbnNtaXR0ZWQuDQoNCj4gSSB0aGluayB0byBiZSBzZWN1cmUsIHRo ZSBxdWVzdGlvbiBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgYm9keSBoYXNoIG11c3QgYmUNCj4gaW5j bHVkZWQgaW4gdGhlIHJlcXVlc3Qgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiAyLiBJc3N1aW5nIE1B QyBDcmVkZW50aWFscw0KPiANCj4gRm9yIGV4YW1wbGUsIGFzIGFuIGFkZGVkIGFzcGVjdCBvZiB0 aGUgYWxnb3JpdGhtLCBvciBhIHNlcGFyYXRlIHBhcmFtZXRlci4NCj4gRXNzZW50aWFsbHkgc29t ZXRoaW5nIGxpa2UgYm9keWhhc2g6IHJlcXVpcmVkLCB2ZXJzdXMNCj4gYm9keWhhc2g6IG9wdGlv bmFsPyAgT2J2aW91c2x5IGl0IHNob3VsZCBiZSBvbWl0dGVkIGlmIHRoZXJlIGlzIG5vIGJvZHkg KGUuZy4NCj4gZm9yIGEgR0VUIHJlcXVlc3QpLiAgQnkgaW5jbHVkaW5nIGl0IGluICMyLCBpdCdz IGNlcnRhaW5seSBjbGVhciB0aGF0IHNvbWUgY2xpZW50cw0KPiB0aGF0IGNhbm5vdCBnZW5lcmF0 ZSB0aGUgYm9keSBoYXNoIGNvdWxkIG5vdCBhdXRoZW50aWNhdGUgd2l0aCBhbnkgc2VydmVycw0K PiB0aGF0IHJlcXVpcmUgaXQsIGJ1dCBhdCBsZWFzdCB0aGlzIHdvdWxkIGJlIGtub3duIGluIGFk dmFuY2UuDQoNCldlIGNhbiBhbGxvdyB0aGUgc2VydmVyIHRvIGluZGljYXRlIGl0cyByZXF1aXJl bWVudHMsIGJ1dCB0aGF0IGFkZHMgbW9yZSBjb21wbGV4aXR5IGFuZCByZXF1aXJlcyBhIHJvdW5k IHRyaXAgKHByZS1mZXRjaCBvciBmYWlsZWQpIHRvIGRldGVybWluZS4gSSBhbSBub3QgYSBmYW4g b2YgdGhpcyBhcHByb2FjaC4NCg0KRUhMDQogDQo+IEFzIGEgc2lkZSBub3RlLCB3ZSBjdXJyZW50 bHkgaW50ZXJhY3Qgd2l0aCBvciBtYWludGFpbiBzZXZlcmFsIHNlcnZpY2VzIHdoaWNoDQo+IHVz ZSBITUFDIGF1dGggYW5kIGluIG9uZSBjYXNlIChhIHNwYW0gYmxvY2tpbmcgc2VydmljZSkgdGhl IGluY2x1c2lvbiBvZiB0aGUNCj4gbWVzc2FnZSBjb250ZW50IGluIHRoZSBITUFDIChzaW1pbGFy IHRvIHVzaW5nIHRoZSBib2R5IGhhc2gpIGlzIG9taXR0ZWQgaW4NCj4gZmF2b3Igb2Ygc2ltcGx5 IGRvaW5nIGEgSE1BQyBvdmVyIHRoZSBVUkwgbm9uY2UgYW5kIHRpbWUgc2luY2UgdGhlDQo+IGNv bnNlcXVlbmNlIG9mIGEgTUlUTSBhdHRhY2sgaXMgcmVsYXRpdmVseSB1bmltcG9ydGFudC4NCj4g DQo+IC1QZXRlcg0KPiBPbiBNb24sIEFwciAxMSwgMjAxMSBhdCA3OjIxIFBNLCBFcmFuIEhhbW1l ci1MYWhhdg0KPiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBQZXRlciBXb2xhbmluIFttYWls dG86cGV0ZXIud29sYW5pbkBhY3F1aWEuY29tXQ0KPiA+PiBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5 IDI3LCAyMDExIDY6NTkgQU0NCj4gPg0KPiA+PiBJIHdhcyBhIGxpdHRsZSB1bmNsZWFyIGluIHRo ZSBzcGVjIHdoZXRoZXIgdGhlIGNsaWVudCBjYW4gY2hvb3NlIG5vdA0KPiA+PiB0byBpbmNsdWRl IHRoZSBib2R5IGhhc2ggaW4gdGhlIHNpZ25hdHVyZS4gwqBJJ2QgaG9wZSB0aGF0IHRoZSBzcGVj DQo+ID4+IGVuZHMgdXAgY2xlYXJseSByZXF1aXJpbmcgdGhlIGNsaWVudCB0byBhbHdheXMgc2Vu ZCBpdCBldmVuIGlmIGENCj4gPj4gZ2l2ZW4gc2VydmVyIG1heSBvciBtYXkgbm90IHZhbGlkYXRl IHRoZSBib2R5IGhhc2guIMKgT3VyIGN1cnJlbnQNCj4gPj4gaW1wbGVtZW50YXRpb25zIGluY2x1 ZGUgdGhlIGJvZHkgZGlyZWN0bHkgaW4gdGhlIEhNQUMgY2FsY3VsYXRpb24sDQo+ID4+IGJ1dCBj b25zaWRlcmluZyB5b3VyIGN1cnJlbnQgZHJhZnQgSSBhcHByZWNpYXRlIHRoZSBleHRyYSBmbGV4 aWJpbGl0eQ0KPiA+PiBwcm92aWRlZCBieSBzaWduaW5nIG92ZXIgdGhlIGJvZHkgaGFzaCByYXRo ZXIgdGhhbiB0aGUgYm9keSBpdHNlbGYuDQo+ID4NCj4gPiBZZXMsIHdlIG5lZWQgdG8gZmlndXJl IG91dCB3aGVuIHRoZSBjbGllbnQgaXMgcmVxdWlyZWQgdG8gaW5jbHVkZSBpdC4gVGhlDQo+IGlz c3VlIGlzIHRoYXQgaW4gc29tZSBkZXBsb3ltZW50cywgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0 aGUgY2xpZW50IHRvIGNhbGN1bGF0ZQ0KPiB0aGlzIHZhbHVlIGF0IHRoZSBwb2ludCB3aGVyZSB0 aGUgaGVhZGVyIGlzIHNldC4NCj4gPg0KPiA+PiBBIGRvd25zaWRlIHRvIHRoZSBNQUMgc3BlYyBm b3IgT0F1dGgyIGlzLCBhcyBmYXIgYXMgSSBjYW4gc2VlLCB5b3UNCj4gPj4gaGF2ZSB0byBzZW5k IHlvdXIgY2xpZW50IHNlY3JldCBpbiB0aGUgcmVxdWVzdCBpZiB5b3UgZXZlciBuZWVkIHRvDQo+ ID4+IHJlZnJlc2ggeW91ciBPQXV0aCB0b2tlbj8gwqBJIHNlZSBpbiBzb21lIHJlY2VudCBtZXNz YWdlcyBsaWVrDQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0gYXJjaGl2ZS93ZWIvb2F1 dGgvY3VycmVudC9tc2cwNTIxNC5odG1sDQo+ID4+IHNvbWUgZGlzY3Vzc2lvbiB0aGF0IHN1Z2dl c3RzIEknbSBtaXN0YWtlbj8NCj4gPg0KPiA+IE5vcGUuIFJlZnJlc2ggZG9lcyBub3QgcmVxdWly ZSB0aGUgYWNjZXNzIHRva2VuIG9yIGl0cyBzZWNyZXQuIEp1c3QgdGhlDQo+IHJlZnJlc2ggY29k ZS4NCj4gPg0KPiA+PiBBbHNvLCBhcyBzdGF0ZWQgaW4gc2VjdGlvbiA3LjMsIHRoZXJlIHNlZW1z IHRvIGJlIG5vIHByb3Zpc2lvbiBmb3INCj4gPj4gZW5zdXJpbmcgcmVzcG9uc2UgYXV0aGVudGlj aXR5IGV4Y2VwdCByZWx5aW5nIG9uIFNTTC4gV2UgaGF2ZSBiZWVuDQo+ID4+IHVzaW5nIHByb3Rv Y29scyB0aGF0IGluY2x1ZGUgaW4gdGhlIHJlc3BvbnNlIGFuIEhNQUMgb2YgdGhlIHJlc3BvbnNl DQo+ID4+IGJvZHkgY2FsY3VsYXRlZCB0byBpbmNsdWRlIHRoZSBjbGllbnQtc3VwcGxpZWQgbm9u Y2UuIMKgT2J2aW91c2x5IG9uZQ0KPiA+PiBjb3VsZCBhZGQgc3VjaCBhIHJlc3BvbnNlIGhlYWRl ciB3aXRob3V0IGJyZWFraW5nIHRoZSBwcm90b2NvbCwgYnV0DQo+ID4+IEknZCBsaWtlIHRvIHNl ZSBhbiBvcHRpb24gaW4gdGhlIE1BQyBjcmVkZW50aWFscyBhbiBhZGRlZCBmaWVsZCB0aGF0DQo+ ID4+IHNwZWNpZmllcyB3aGV0aGVyIHRoZSBzZXJ2ZXIgaXMgZXhwZWN0ZWQgdG8gcHJvdmlkZSBz dWNoIGEgcmVzcG9uc2UNCj4gPj4gSE1BQyBhbmQgYSBzdGFuZGFyZGl6ZWQgbmFtZSBhbmQgY29u c3RydWN0aW9uIGZvciBzdWNoIGEgcmVzcG9uc2UNCj4gaGVhZGVyLg0KPiA+DQo+ID4gSSB3aWxs IGFkZCB0aGlzIGxhdGVyLCBvbmNlIHRoZSBjdXJyZW50IGJpdHMgYXJlIHN0YWJsZS4NCj4gPg0K PiA+IEVITA0KPiA+DQo+IA0KPiANCj4gDQo+IC0tDQo+IFBldGVyIE0uIFdvbGFuaW4sIFBoLkQu IMKgIMKgIMKgOiBNb21lbnR1bSBTcGVjaWFsaXN0LMKgIEFjcXVpYS4gSW5jLg0KPiBwZXRlci53 b2xhbmluQGFjcXVpYS5jb20gOiA5NzgtMjk2LTUyNDcNCj4gDQo+ICJHZXQgYSBmcmVlLCBob3N0 ZWQgRHJ1cGFsIDcgc2l0ZTogaHR0cDovL3d3dy5kcnVwYWxnYXJkZW5zLmNvbSINCg== From peter.wolanin@acquia.com Wed May 18 10:11: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 A49FEE0761 for ; Wed, 18 May 2011 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wLE5U-r0EjQx for ; Wed, 18 May 2011 10:11:02 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with SMTP id 83069E0763 for ; Wed, 18 May 2011 10:11:00 -0700 (PDT) Received: from mail-ww0-f50.google.com ([74.125.82.50]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTdP9o+5gYx0TSPr1KOP8AqbBL+ff1xYf@postini.com; Wed, 18 May 2011 10:11:01 PDT Received: by mail-ww0-f50.google.com with SMTP id 33so1905672wwc.31 for ; Wed, 18 May 2011 10:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.232.41 with SMTP id m41mr2081730weq.31.1305738658331; Wed, 18 May 2011 10:10:58 -0700 (PDT) Received: by 10.216.20.212 with HTTP; Wed, 18 May 2011 10:10:58 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4125@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72344656743AB6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447582E4125@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 18 May 2011 13:10:58 -0400 Message-ID: From: Peter Wolanin To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00151750dadee63eca04a38ff824 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth v2 Mac token 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, 18 May 2011 17:11:03 -0000 --00151750dadee63eca04a38ff824 Content-Type: text/plain; charset=UTF-8 Dear Eran, I was not suggesting an extra round-trip to the server. Rather, that whether or not the server requires the body hash be part of the credentials supplied for that endpoint. Thus, a client that could not calculate a body hash would simply not be able to authenticate requests with a non-empty body, and should not attempt to do so at all. However, your use case of a file on disk does strengthen further in my mind the argument for using body hash rather than calculating the hash over the headers+body. I should be able to calculate the hash of the file on disk (e.g. using the PHP function hash_file('sha256', $filename) ), so I could then construct all the headers and stream the file to the server. -Peter On Wed, May 18, 2011 at 12:38 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: Peter Wolanin [mailto:peter.wolanin@acquia.com] > > Sent: Wednesday, May 04, 2011 8:54 PM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: Re: OAuth v2 Mac token spec > > > > Can you give an example of a setup where the hash cannot be calculated? > > Large file upload which is read from disk as it is being transmitted. > > > I think to be secure, the question of whether or not the body hash must > be > > included in the request should be specified in 2. Issuing MAC Credentials > > > > For example, as an added aspect of the algorithm, or a separate > parameter. > > Essentially something like bodyhash: required, versus > > bodyhash: optional? Obviously it should be omitted if there is no body > (e.g. > > for a GET request). By including it in #2, it's certainly clear that > some clients > > that cannot generate the body hash could not authenticate with any > servers > > that require it, but at least this would be known in advance. > > We can allow the server to indicate its requirements, but that adds more > complexity and requires a round trip (pre-fetch or failed) to determine. I > am not a fan of this approach. > > EHL > > > As a side note, we currently interact with or maintain several services > which > > use HMAC auth and in one case (a spam blocking service) the inclusion of > the > > message content in the HMAC (similar to using the body hash) is omitted > in > > favor of simply doing a HMAC over the URL nonce and time since the > > consequence of a MITM attack is relatively unimportant. > > > > -Peter > > On Mon, Apr 11, 2011 at 7:21 PM, Eran Hammer-Lahav > > wrote: > > > > > > > > >> -----Original Message----- > > >> From: Peter Wolanin [mailto:peter.wolanin@acquia.com] > > >> Sent: Sunday, February 27, 2011 6:59 AM > > > > > >> I was a little unclear in the spec whether the client can choose not > > >> to include the body hash in the signature. I'd hope that the spec > > >> ends up clearly requiring the client to always send it even if a > > >> given server may or may not validate the body hash. Our current > > >> implementations include the body directly in the HMAC calculation, > > >> but considering your current draft I appreciate the extra flexibility > > >> provided by signing over the body hash rather than the body itself. > > > > > > Yes, we need to figure out when the client is required to include it. > The > > issue is that in some deployments, it is not possible for the client to > calculate > > this value at the point where the header is set. > > > > > >> A downside to the MAC spec for OAuth2 is, as far as I can see, you > > >> have to send your client secret in the request if you ever need to > > >> refresh your OAuth token? I see in some recent messages liek > > >> http://www.ietf.org/mail- archive/web/oauth/current/msg05214.html > > >> some discussion that suggests I'm mistaken? > > > > > > Nope. Refresh does not require the access token or its secret. Just the > > refresh code. > > > > > >> Also, as stated in section 7.3, there seems to be no provision for > > >> ensuring response authenticity except relying on SSL. We have been > > >> using protocols that include in the response an HMAC of the response > > >> body calculated to include the client-supplied nonce. Obviously one > > >> could add such a response header without breaking the protocol, but > > >> I'd like to see an option in the MAC credentials an added field that > > >> specifies whether the server is expected to provide such a response > > >> HMAC and a standardized name and construction for such a response > > header. > > > > > > I will add this later, once the current bits are stable. > > > > > > EHL > > > > > > > > > > > -- > > Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. > > peter.wolanin@acquia.com : 978-296-5247 > > > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" > -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. peter.wolanin@acquia.com : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" --00151750dadee63eca04a38ff824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear Eran,

    I was not suggesting an extra round-trip to the serve= r.=C2=A0 Rather, that whether or not the server requires the body hash be p= art of the credentials supplied for that endpoint.

    Thus, a client th= at could not calculate a body hash would simply not be able to authenticate= requests with a non-empty body, and should not attempt to do so at all.
    However, your use case of a file on disk does strengthen further in my = mind the argument for using body hash rather than calculating the hash over= the headers+body.=C2=A0 I should be able to calculate the hash of the file= on disk (e.g. using the PHP function hash_file('sha256', $filename= ) ), so I could then construct all the headers and stream the file to the s= erver.

    -Peter

    On Wed, May 18, 2011 at 12:38 = PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:


    > -----Original Message-----
    > From: Peter Wolanin [mailto:peter.wolanin@acquia.com]
    > Sent: Wednesday, May 04, 2011 8:54 PM
    > To: Eran Hammer-Lahav
    > Cc: oauth@ietf.org
    > Subject: Re: OAuth v2 Mac token spec
    >
    > Can you give an example of a setup where the h= ash cannot be calculated?

    Large file upload which is read from disk as it is being transmitted.=

    > I think to be secure, the question of whether or not the body hash mus= t be
    > included in the request should be specified in 2. Issuing MAC Credenti= als
    >
    > For example, as an added aspect of the algorithm, or a separate parame= ter.
    > Essentially something like bodyhash: required, versus
    > bodyhash: optional? =C2=A0Obviously it should be omitted if there is n= o body (e.g.
    > for a GET request). =C2=A0By including it in #2, it's certainly cl= ear that some clients
    > that cannot generate the body hash could not authenticate with any ser= vers
    > that require it, but at least this would be known in advance.

    We can allow the server to indicate its requirements, but that adds m= ore complexity and requires a round trip (pre-fetch or failed) to determine= . I am not a fan of this approach.

    EHL

    > As a side note, we currently interact with or maintain several service= s which
    > use HMAC auth and in one case (a spam blocking service) the inclusion = of the
    > message content in the HMAC (similar to using the body hash) is omitte= d in
    > favor of simply doing a HMAC over the URL nonce and time since the
    > consequence of a MITM attack is relatively unimportant.
    >
    > -Peter
    > On Mon, Apr 11, 2011 at 7:21 PM, Eran Hammer-Lahav
    > <eran@hueniverse.com>= wrote:
    > >
    > >
    > >> -----Original Message-----
    > >> From: Peter Wolanin [mailto:peter.wolanin@acquia.com]
    > >> Sent: Sunday, February 27, 2011 6:59 AM
    > >
    > >> I was a little unclear in the spec whether the client can cho= ose not
    > >> to include the body hash in the signature. =C2=A0I'd hope= that the spec
    > >> ends up clearly requiring the client to always send it even i= f a
    > >> given server may or may not validate the body hash. =C2=A0Our= current
    > >> implementations include the body directly in the HMAC calcula= tion,
    > >> but considering your current draft I appreciate the extra fle= xibility
    > >> provided by signing over the body hash rather than the body i= tself.
    > >
    > > Yes, we need to figure out when the client is required to include= it. The
    > issue is that in some deployments, it is not possible for the client t= o calculate
    > this value at the point where the header is set.
    > >
    > >> A downside to the MAC spec for OAuth2 is, as far as I can see= , you
    > >> have to send your client secret in the request if you ever ne= ed to
    > >> refresh your OAuth token? =C2=A0I see in some recent messages= liek
    > >> http:= //www.ietf.org/mail- archive/web/oauth/current/msg05214.html
    > >> some discussion that suggests I'm mistaken?
    > >
    > > Nope. Refresh does not require the access token or its secret. Ju= st the
    > refresh code.
    > >
    > >> Also, as stated in section 7.3, there seems to be no provisio= n for
    > >> ensuring response authenticity except relying on SSL. We have= been
    > >> using protocols that include in the response an HMAC of the r= esponse
    > >> body calculated to include the client-supplied nonce. =C2=A0O= bviously one
    > >> could add such a response header without breaking the protoco= l, but
    > >> I'd like to see an option in the MAC credentials an added= field that
    > >> specifies whether the server is expected to provide such a re= sponse
    > >> HMAC and a standardized name and construction for such a resp= onse
    > header.
    > >
    > > I will add this later, once the current bits are stable.
    > >
    > > EHL
    > >
    >
    >
    >
    > --
    > Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2= =A0 Acquia. Inc.
    > peter.wolanin@acquia.com : 978-296-5247 >
    > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"



    --
    Peter M. Wo= lanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Acquia. Inc.<= br>peter.wola= nin@acquia.com : 978-296-5247

    "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
    --00151750dadee63eca04a38ff824-- From julian.reschke@gmx.de Wed May 18 10:17: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 DD0B1E06B9 for ; Wed, 18 May 2011 10:17:05 -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 oF3rlx7taM-h for ; Wed, 18 May 2011 10:17:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 95BA4E0665 for ; Wed, 18 May 2011 10:17:02 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2011 17:16:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.134]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 18 May 2011 19:16:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UPU5r8dEU5bsGUbBHaUj5lqYHXwz74hzG4O0PRV LPVf864KR7lPK1 Message-ID: <4DD3FF08.2000502@gmx.de> Date: Wed, 18 May 2011 19:16:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2011 17:17:06 -0000 On 2011-05-18 18:20, Eran Hammer-Lahav wrote: > The error_description parameter and similar parameters in the MAC and > Bearer specs do not specify the language or encoding used. This is a > problem. Can someone offer a solution? For parameters, you can use the encoding defined in RFCs 2231 and 5987. See, for instance, (filename-param). Best regards, Julian From kris.selden@gmail.com Wed May 18 13:26: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 9FDC0E06F5 for ; Wed, 18 May 2011 13:26:00 -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 cHIxzVwsKbr3 for ; Wed, 18 May 2011 13:26:00 -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 27B37E06BA for ; Wed, 18 May 2011 13:26:00 -0700 (PDT) Received: by pvh18 with SMTP id 18so1185270pvh.31 for ; Wed, 18 May 2011 13:25:59 -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=nRfQJjSkwx/Mv1pTUwnMZtCcJJHhPAcNMqEFm/3M5Kg=; b=aREIQip5sovmnB9TjGLGsfRr14CKXPAgP56E/mWza2puQtdDCekhN3dq3kuaJ/9TQT xAOYFs72kZg1m6FrMoDuwERb2mX3hvPo0jzWAUq3vxpLYLC8a1+M8mrb10skoqOmoX21 5DIti8U+Mz0bK79KO7iWH3gxu99U8Fx4gl8kY= 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=xeU4XPi6o1RjtzmOsOgUVntheQFVXZsVFITJYS9MafPA2Ruf0vnjYTDTpEv0b5cSTl qzd+mRB4cLQM+ibd6EHvA3pqQQOxz5+nBDth9tIDQ+tUscMt6O7x/jJBRg5Kve9lCXrd mnE/bMhAY8AlDzVlTqoi4F2auJ6HRhmTDLfCk= Received: by 10.142.212.10 with SMTP id k10mr1442990wfg.4.1305750358768; Wed, 18 May 2011 13:25:58 -0700 (PDT) Received: from [172.16.176.22] (65-122-179-162.dia.static.qwest.net [65.122.179.162]) by mx.google.com with ESMTPS id w18sm683188wfd.15.2011.05.18.13.25.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 13:25:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 18 May 2011 13:25:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2011 20:26:00 -0000 How about taking a page from URI spec since it is a query parameter = value and follow this for the value of such human readable text params: When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. http://tools.ietf.org/html/rfc3986 That is also inline with JSON as the one OAuth response type, since it = is already limited to UTF encodings. On May 18, 2011, at 9:20 AM, Eran Hammer-Lahav wrote: > The error_description parameter and similar parameters in the MAC and = Bearer specs do not specify the language or encoding used. This is a = problem. Can someone offer a solution? > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Wed May 18 13:32: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 CCAB0E06B1 for ; Wed, 18 May 2011 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 0bQ7mbT963tM for ; Wed, 18 May 2011 13:32:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7796BE06BA for ; Wed, 18 May 2011 13:32:12 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2011 20:32:09 -0000 Received: from p508F9B3C.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.155.60] by mail.gmx.net (mp001) with SMTP; 18 May 2011 22:32:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18QFSBX/G0Q3f8WySykDBybJEbTG1ZnUsV7R/6fZM 3LU8+pGyOReZSg Message-ID: <4DD42CC7.7010109@gmx.de> Date: Wed, 18 May 2011 22:32:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kris Selden References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> In-Reply-To: <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2011 20:32:15 -0000 On 2011-05-18 22:25, Kris Selden wrote: > How about taking a page from URI spec since it is a query parameter value and follow this for the value of such human readable text params: > > When a new URI scheme defines a component that represents textual > data consisting of characters from the Universal Character Set [UCS], > the data should first be encoded as octets according to the UTF-8 > character encoding [STD63]; then only those octets that do not > correspond to characters in the unreserved set should be percent- > encoded. > > http://tools.ietf.org/html/rfc3986 > ... ...which yields almost the same representation as RFC2231/5987 (except that in these, the string gets labeled with the charset name). Best regards, Julian From kris.selden@gmail.com Wed May 18 16:25: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 08D35E06DF for ; Wed, 18 May 2011 16:25:01 -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 d8LG6MKvmL1T for ; Wed, 18 May 2011 16:25:00 -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 5895BE0651 for ; Wed, 18 May 2011 16:25:00 -0700 (PDT) Received: by pvh18 with SMTP id 18so1261628pvh.31 for ; Wed, 18 May 2011 16:25:00 -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=I5X0VgMuxz1EVHzCpTcSeYhaxZADlGdGslbIkqX44Gc=; b=jLRm619y0j6NSpYZF6Nhe35qrrsg6tourBq/sx57EDkoMvvGotcOdM/YiQb6bcKq0m A8nto/dqEZWPLfMCrxL5iv4vPx1pU3iPyBNb+bJ04ypBy6ssgTaMb1/ebT6xlJOQ0P+i A26o6A7d+EwlbNnDBRNXYBiGCI0MLFWgKzD/E= 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=vTMHNlX1qO5tfoOkXjmrBLXuxrRLLrQV5auMxi215UJQW4rTFpQw2egIiqRdeR6zvZ Bu1CEJdXV5zgt7v7CO2SB4o7VgisSXRUG1W87pi6fdpA4icrVtZp/QN7C50ZCycXZV2B vwd5WLUhE1GcGKym+vcL977Fydz9swnVdwudw= Received: by 10.68.11.196 with SMTP id s4mr3604429pbb.301.1305761100002; Wed, 18 May 2011 16:25:00 -0700 (PDT) Received: from [172.16.176.22] (65-122-179-162.dia.static.qwest.net [65.122.179.162]) by mx.google.com with ESMTPS id c6sm1346848pbu.35.2011.05.18.16.24.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 16:24:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <4DD42CC7.7010109@gmx.de> Date: Wed, 18 May 2011 16:24:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 18 May 2011 23:25:01 -0000 Is there a problem with sticking to UTF-8? OAuth already mandates JSON = which is Unicode only. Would be nice to keep it simple. I'm guessing without guidance, most would convert to UTF-8 and percent = encode anyway. On May 18, 2011, at 1:32 PM, Julian Reschke wrote: > On 2011-05-18 22:25, Kris Selden wrote: >> How about taking a page from URI spec since it is a query parameter = value and follow this for the value of such human readable text params: >>=20 >> When a new URI scheme defines a component that represents textual >> data consisting of characters from the Universal Character Set = [UCS], >> the data should first be encoded as octets according to the UTF-8 >> character encoding [STD63]; then only those octets that do not >> correspond to characters in the unreserved set should be percent- >> encoded. >>=20 >> http://tools.ietf.org/html/rfc3986 >> ... >=20 > ...which yields almost the same representation as RFC2231/5987 (except = that in these, the string gets labeled with the charset name). >=20 > Best regards, Julian From eran@hueniverse.com Wed May 18 16:43: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 B851AE06AF for ; Wed, 18 May 2011 16:43:00 -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=[AWL=-0.000, 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 pd7CsfKNj0MA for ; Wed, 18 May 2011 16:43:00 -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 355A1E0651 for ; Wed, 18 May 2011 16:43:00 -0700 (PDT) Received: (qmail 21477 invoked from network); 18 May 2011 23:42:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 May 2011 23:42:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 18 May 2011 16:42:48 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 18 May 2011 16:42:43 -0700 Thread-Topic: Draft -16 Thread-Index: AcwVtDsmrA9aLwANTealmrENYE09EA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4262@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_90C41DD21FB7C64BB94121FBBC2E723447582E4262P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -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, 18 May 2011 23:43:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4262P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -16 should show up in a few minutes. This will be the last draft befo= re the meeting next week and the reference document for discussion. If you = plan to attend the meeting, this is a required reading. Changes since -15: - New security consideration section (closes issue #7) - Reintroduced native application section (closes issues #13) - Reworked section 3 (client authentication) to restore HTTP Basic= as the recommended scheme. - Removed [[ pending consensus ]] labels off error extensibility (= closes issues #10 and #11) - Added note about username and password being UTF-8 encoded - Clarified that extension grant types must use section 5 response= s - Minor language fixes, new abstract The only open issues remaining are some missing security consideration sect= ions and language encoding for error_description. I will do my best to make -17 the last working group draft before final WG = last call. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4262P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Draft -16 should= show up in a few minutes. This will be the last draft before the meeting n= ext week and the reference document for discussion. If you plan to attend t= he meeting, this is a required reading.

    =  

    Changes since -15:

    =

     

    -&nb= sp;         New security consideration section (closes issue #7= )

    = -     = ;     Re= introduced native application section (closes issues #13)

    -        =   Reworked section 3 (c= lient authentication) to restore HTTP Basic as the recommended scheme.=

    -      = ;    Removed = [[ pending consensus ]] labels off error extensibility (closes issues #10 a= nd #11)

    -    = ;      Added note about username and password being UTF-8 encoded

    -       = ;   Clarified that= extension grant types must use section 5 responses

    -         = ; Minor language fixes, new = abstract

     

    The only open issues remaining are some missing security consi= deration sections and language encoding for error_description.

     

    I will do = my best to make -17 the last working group draft before final WG last call.=

     

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4262P3PW5EX1MB01E_-- From eran@hueniverse.com Wed May 18 16:44: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 1989AE077B for ; Wed, 18 May 2011 16:44:57 -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=[AWL=-0.000, 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 Vn2Mm-hX1RX3 for ; Wed, 18 May 2011 16:44: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 796BEE0651 for ; Wed, 18 May 2011 16:44:56 -0700 (PDT) Received: (qmail 23867 invoked from network); 18 May 2011 23:44:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 May 2011 23:44:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 May 2011 16:44:49 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , OAuth WG Date: Wed, 18 May 2011 16:44:43 -0700 Thread-Topic: Draft -16 Thread-Index: AcwVtDsmrA9aLwANTealmrENYE09EAAATp0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4263@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4262@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4262@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_90C41DD21FB7C64BB94121FBBC2E723447582E4263P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -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, 18 May 2011 23:44:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4263P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I forgot to mention (the obvious) that the chairs will follow up on each op= en issue with their own notes and will do the actual determination with reg= ard to closing issues. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, May 18, 2011 4:43 PM To: OAuth WG Subject: [OAUTH-WG] Draft -16 Draft -16 should show up in a few minutes. This will be the last draft befo= re the meeting next week and the reference document for discussion. If you = plan to attend the meeting, this is a required reading. Changes since -15: - New security consideration section (closes issue #7) - Reintroduced native application section (closes issues #13) - Reworked section 3 (client authentication) to restore HTTP Basic= as the recommended scheme. - Removed [[ pending consensus ]] labels off error extensibility (= closes issues #10 and #11) - Added note about username and password being UTF-8 encoded - Clarified that extension grant types must use section 5 response= s - Minor language fixes, new abstract The only open issues remaining are some missing security consideration sect= ions and language encoding for error_description. I will do my best to make -17 the last working group draft before final WG = last call. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4263P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I forgot to mention (the obvious) that the chairs will follow= up on each open issue with their own notes and will do the actual determin= ation with regard to closing issues.

     

    EHL

     

    <= div>

    From: oauth-bounces@ietf.org [mailto:oauth-= bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
    Sent: Wed= nesday, May 18, 2011 4:43 PM
    To: OAuth WG
    Subject: [OAU= TH-WG] Draft -16

     

    Draft -16 should show up in a few min= utes. This will be the last draft before the meeting next week and the refe= rence document for discussion. If you plan to attend the meeting, this is a= required reading.

     

    =

    Changes since -15:

    =  

    -    =       New security consideration section (closes issue #7)

    -        &n= bsp; Reintroduced native app= lication section (closes issues #13)

    -          = Reworked section 3 (client authentication)= to restore HTTP Basic as the recommended scheme.

    -          <= /span>Removed [[ pending consensus = ]] labels off error extensibility (closes issues #10 and #11)

    -       &n= bsp;  Added note about = username and password being UTF-8 encoded

    -          Clarified that extension grant types = must use section 5 responses

    -&n= bsp;         Minor language fixes, new abstract

    <= p class=3DMsoNormal> 

    The only open= issues remaining are some missing security consideration sections and lang= uage encoding for error_description.

     

    I will do my best to make -17 the la= st working group draft before final WG last call.

     

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4263P3PW5EX1MB01E_-- From Internet-Drafts@ietf.org Wed May 18 16: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 8A24EE07B8; Wed, 18 May 2011 16:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 ti26Y-Mq2R8s; Wed, 18 May 2011 16:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C8E07C1; Wed, 18 May 2011 16:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110518234502.31169.73618.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 16:45:02 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-16.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: Wed, 18 May 2011 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-16.txt Pages : 55 Date : 2011-05-18 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service, or by allowing the third- party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-18163343.I-D@ietf.org> --NextPart-- From d.tangren@gmail.com Wed May 18 19:09: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 4A926E06C8 for ; Wed, 18 May 2011 19:09:55 -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=[AWL=-0.000, 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 ZC0dZ+xGUWji for ; Wed, 18 May 2011 19:09:52 -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 457EDE06C2 for ; Wed, 18 May 2011 19:09:52 -0700 (PDT) Received: by gyf3 with SMTP id 3so927867gyf.31 for ; Wed, 18 May 2011 19:09: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:from:date :message-id:subject:to:cc:content-type; bh=XpH8R3xNDmJJIqBhcxpCbeDAVmv640C39s+i8hVaxwE=; b=fxCP/bEU/b5+oNNrLukjh8BKf+vE+HxbfIdxsjO8MLR8g+638raxSc2eyGNJXEVVI0 khn/4nOYJ8Sn5q/CxCGBFtlWazd+QL8I9+73XbHz4CGy/7Dovt4JYpktH2p2bLnKxhpM xZ7hoeWcGZNGVIfVAFCqzIIi0UeM20+ulkOmg= 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=hO4Jq0+R6yka3dQrkHzit9laCra1ziTTuuBLg3XhiwG/nRp7/x/ZembPdFESor9wPn +zLx2w8VcQrbRzEkuP6loCwoagjNlDRMk0t0obAiqN8VnXs8f4ob9+o1ddprMaKNjAnL 7+UBPHGDx0R1W4qdvolW1IyHalcua0VgJPKaw= Received: by 10.91.63.40 with SMTP id q40mr2037450agk.166.1305770991192; Wed, 18 May 2011 19:09:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.57.33 with HTTP; Wed, 18 May 2011 19:09:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4263@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4262@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447582E4263@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Doug Tangren Date: Wed, 18 May 2011 22:09:31 -0400 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e6408cae168c1404a3978027 Cc: OAuth WG , "eran@sled.com" Subject: Re: [OAUTH-WG] Draft -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, 19 May 2011 02:09:55 -0000 --0016e6408cae168c1404a3978027 Content-Type: text/plain; charset=UTF-8 Followup questions from draft 16 1. On storing user password for the resource owner creds flow. If the client stores a access token along with the refresh token [1] to refresh it, there should be no need to store the users password as mentioned here [2] right? 2. What value does adding the client password to a basic auth encoded header with duplicated client_id info add? [3] 3. Is the mentioned error returned to the client on token expiration supposed to result in a 401 status? Is invalid_token_error the error identifier? I don't see that in any of the error name registries. 4. "Request and response parameters MUST NOT repeat more than once, unless noted otherwise."[5] Why let them be repeated at all? That requires the server to do extra work ensuring that anything repeated contains the consistent and identical values. 5. Utf8 denotation. [6] I noticed that the owner creds flow specifies utf8 encoding. Is there an implicit assumption that all other parameters in the protocol are also utf8 encoded or were they special cased because they are foreign data flowed into the protocol not created by the server? 6. Native modified usage of the auth code flow - "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" [7] The issue was brought up earlier that clients the implicit flow should not be issued a refresh token because there'd be no way for the server to identify the client without the client secret. Here its suggested they do just that. Does this mean there may be a step added in the implicit flow in the future that will enable the client to refresh their access token without involving the user if the user has already chosen to authorize the app? Those are some of the things that jump out at me. I'll read if a few more times so see if anything else comes up. I'm happy to see this is all coming together! This is great work. [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.3 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 [4]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-1.5 [5]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.2 [6]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2 [7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 -Doug Tangren http://lessis.me --0016e6408cae168c1404a3978027 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Followup questions from draft 16

    1. On storin= g user password for the resource owner creds flow. If the client stores a a= ccess token along with the refresh token [1] to refresh it, there should be= no need to store the users password as mentioned here [2] right?

    2. What value does adding the client password to a basi= c auth encoded header with duplicated client_id info add? [3]
    3. Is the mentioned error returned to the client on token expir= ation supposed to result in a 401 status? Is invalid_token_error the error = identifier? I don't see that in any of the error name registries.

    4. "Request and response parameters MUST NOT repeat more than once,= un= less noted otherwise."[5] Why let them be repeated at all? That requires the server to do extr= a work ensuring that anything repeated contains the consistent and identica= l values.

    5. Utf8 denotation. [6] I noticed that the owner creds = flow specifies utf8 encoding. Is there an implicit assumption that all othe= r parameters in the protocol are also utf8 encoded or were they special cas= ed because they are=C2=A0foreign=C2=A0data flowed into the protocol not cre= ated by the server?

    6. Native modified usage of the auth code flow - "= Native applicat= ions SHOULD use the authorization code grant type flow without client password credentials (due to their i= nability to keep the credentials confi= dential) to obtain short-lived access tokens, and use refresh= tokens to maintain access" [7]

    The issue was brought up earlier that clients the impli= cit flow should not be issued a refresh token because there'd be no way= for the server to identify the client without the client secret. Here its = suggested they do just that. Does this mean there may be a step added in th= e implicit flow in the future that will enable the client to refresh their = access token without involving the user if the user has already chosen to a= uthorize the app?

    Those are some of the things that jump out at me. I'= ;ll read if a few more times so see if anything else comes up.
    I'm happy to see this is all coming together! This is grea= t work.


    -Doug Tangren
    http://lessis.me


    --0016e6408cae168c1404a3978027-- From julian.reschke@gmx.de Wed May 18 22:48: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 557C4E06F6 for ; Wed, 18 May 2011 22:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=-0.615, 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 Mcq4opL9qnhi for ; Wed, 18 May 2011 22:48:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E8010E06D1 for ; Wed, 18 May 2011 22:48:30 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2011 05:48:28 -0000 Received: from p508FA1D4.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.161.212] by mail.gmx.net (mp064) with SMTP; 19 May 2011 07:48:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+EQ20P+1GEZ+oFkOV57Rt6uX6mPWDxp55danx4GK Dg0L0XJoy8dsje Message-ID: <4DD4AF2A.2060004@gmx.de> Date: Thu, 19 May 2011 07:48:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kris Selden References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 05:48:32 -0000 On 2011-05-19 01:24, Kris Selden wrote: > Is there a problem with sticking to UTF-8? OAuth already mandates JSON which is Unicode only. Well, like it or not, the default for HTTP header fields is not UTF-8. > Would be nice to keep it simple. > > I'm guessing without guidance, most would convert to UTF-8 and percent encode anyway. Without guidance, people usually do not encode at all, and we'll see different encodings on the wire. Best regards, Julian From hannes.tschofenig@gmx.net Thu May 19 00:26: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 92B36E06FC for ; Thu, 19 May 2011 00:26:28 -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 iYH4GL-gxeZa for ; Thu, 19 May 2011 00:26:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 73ADFE0681 for ; Thu, 19 May 2011 00:26:26 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2011 07:26:25 -0000 Received: from unknown (EHLO [10.255.131.237]) [192.100.123.77] by mail.gmx.net (mp066) with SMTP; 19 May 2011 09:26:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18RzshnNHkRLmxfhHY0PzbleKmYFLTGi2Dqh5kFZg InnSHEP4Uuyf15 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 10:26:21 +0300 Message-Id: <487B4CB8-B7C3-4455-856B-9D07BFFBEB34@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: Register by Today X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 07:26:28 -0000 Hey all,=20 a number of you had signed up already for the interim meeting either at = the OAuth Wiki or at the Eventbrite page: http://oauth-interim.eventbrite.com/ http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeetingAttendance =20 If you have not added your name to either one of these two lists yet = please do so by the end of today.=20 We need the info for planning purposes.=20 See you next Monday in Palo Alto! Ciao Hannes Ps: Please have a look at the working group documents.=20 From kris.selden@gmail.com Thu May 19 02:14: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 324A0E0727 for ; Thu, 19 May 2011 02:14: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 Q6aCsRICyOLA for ; Thu, 19 May 2011 02:14:36 -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 B69ADE0783 for ; Thu, 19 May 2011 02:14:36 -0700 (PDT) Received: by pwi5 with SMTP id 5so1556990pwi.31 for ; Thu, 19 May 2011 02:14:36 -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=5Ik+emkdfYA0nsF2L+FZafQrCzeNx7kReXbgx5f7JYg=; b=Hixwm8UhKDHZNmEz1a/dCRqYKxvh+gPIv9i56XfpEODvXexl8qUKRVxkjWmOdvW1ID SPhQ8HZGqsvJNOuvdC77F+RdiLswHABuL3BnO5raIVK2Yr/jMn7sHyFGnaKTTk8S01gz UcBb0pwOOm/GVTFSotlUgJL1x1/a5yKym3T1k= 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=Am5x46JdCQafWfCmqYw12igva3l5GxPoj/AdI+K2bwnQ5mrIyNUkb3c//aox4FsENM hgj++gQ/pufk2cEBr1edkrvKx2A5oi45vEEoNNM5RO5Y1A1R8ExWx8ly5qaAa1Z6EFDs l1MqXBF1CzjL15luTBSf8t3WYuOnJKDy6yCf0= Received: by 10.68.27.195 with SMTP id v3mr4220244pbg.214.1305796476013; Thu, 19 May 2011 02:14:36 -0700 (PDT) Received: from [172.16.2.2] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id n6sm1629093pbc.57.2011.05.19.02.14.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 02:14:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Kris Selden In-Reply-To: <4DD4AF2A.2060004@gmx.de> Date: Thu, 19 May 2011 02:14:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 09:14:38 -0000 > Well, like it or not, the default for HTTP header fields is not UTF-8. Encoding in HTTP header fields is not the topic, error_description is = already encoded into a URI before it is in the Location field.=20 There are 3 spots where error_description appears: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2.2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.2 In section 4.1.2.1 and 4.2.2.1 the issue is about character encoding = before application/x-www-form-urlencoded encoding (after that it is = ASCII only). In section 4.2.2.1, the parameter is encoded in the = fragment component which is only visible on the client side, and likely = to be read by a script in Javascript (which is unicode only). In section 5.2 the response type is JSON which already deals with = character encoding (http://tools.ietf.org/html/rfc4627#section-3) and is = Unicode only. So there isn't anything to solve for error_description in = section 5.2, except maybe to reference section 3 of rfc4627. =20 Proposal for sections 4.1.2.1 and 4.2.2.1: error_description OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred. The text should first be encoded as octets according to the UTF-8 character encoding before being encoded using the "application/x-www-form-urlencoded" format. Examples: HTTP/1.1 302 Found Location: = https://client.example.com/cb?error=3Daccess_denied&error_description=3DAc= c%C3%A8s+refus%C3%A9 HTTP/1.1 302 Found Location: = https://client.example.com/cb#error=3Daccess_denied&error_description=3DAc= c%C3%A8s%20refus%C3%A9 Proposal for section 5.2: error_description OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred. The text shall be encoded in Unicode as defined by [RFC4627]. Example: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error":"invalid_request", "error_description":"Acc=C3=A8s refus=C3=A9" } For query strings encoded with application/x-www-form-urlencoded the = most common default is UTF-8, while a response body encoded with = application/x-www-form-urlencoded should set a charset parameter in the = Content-Type header. Here are examples of dealing with query strings in a few languages and = app frameworks: Javascript (very relevant to section 4.2.2.1) > decodeURIComponent("Acc%C3%A8s%20refus%C3%A9") // UTF-8 'Acc=C3=A8s refus=C3=A9' http://www.ecmascript.org/docs.php > The decodeURIComponent function computes a new version of a URI in = which each escape > sequence and UTF-8 encoding of the sort that might be introduced by = the encodeURIComponent > function is replaced with the character that it represents. NodeJS node > var querystring =3D require('querystring') > = querystring.parse('error=3Daccess_denied&error_description=3DAcc%C3%A8s+re= fus%C3%A9') // UTF-8 { error: 'access_denied', error_description: 'Acc=C3=A8s refus=C3=A9' } .Net Request.QueryString // UTF-8 HttpUtility.ParseQueryString(String) // UTF-8 HttpUtility.ParseQueryString(String, Encoding) // Need to know the = encoding before the query string is parsed Ruby # Rack 3 only parses query strings as UTF-8 but older versions use = binary strings Rack::Request.params URI.decode_www_form_component(str, enc=3DEncoding::UTF_8) Python (binary string) python >>> from urlparse import parse_qs >>> = parse_qs("error=3Daccess_denied&error_description=3DAcc%C3%A8s+refus%C3%A9= ") {'error_description': ['Acc\xc3\xa8s refus\xc3\xa9'], 'error': = ['access_denied']} PHP (binary string) php -r = 'parse_str("error=3Daccess_denied&error_description=3DAcc%C3%A8s+refus%C3%= A9", $output); print_r($output);' Array ( [error] =3D> access_denied [error_description] =3D> Acc=C3=A8s refus=C3=A9 ) Java ServletRequest.getParameter(String name) // Tomcat has 2 settings which = govern query string parsing URIEncoding which defaults to ISO-8859-1 and = useBodyEncodingForURI which defaults to false URLDecoder.decode(String s, String enc) // Need to know encoding before = percent decoding On May 18, 2011, at 10:48 PM, Julian Reschke wrote: > On 2011-05-19 01:24, Kris Selden wrote: >> Is there a problem with sticking to UTF-8? OAuth already mandates = JSON which is Unicode only. >=20 >=20 >=20 >> Would be nice to keep it simple. >>=20 >> I'm guessing without guidance, most would convert to UTF-8 and = percent encode anyway. >=20 > Without guidance, people usually do not encode at all, and we'll see = different encodings on the wire. >=20 > Best regards, Julian From julian.reschke@gmx.de Thu May 19 02:55: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 E0A0FE079F for ; Thu, 19 May 2011 02:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 r-ECCMlmkZpQ for ; Thu, 19 May 2011 02:55:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B336DE079C for ; Thu, 19 May 2011 02:55:35 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2011 09:55:32 -0000 Received: from p508FA1D4.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.161.212] by mail.gmx.net (mp013) with SMTP; 19 May 2011 11:55:32 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX197NDxCA6N72EtI+8EbvPdW0992fhZpG1eOZ8HSvh mY09+LKiF3wIBc Message-ID: <4DD4E913.7070301@gmx.de> Date: Thu, 19 May 2011 11:55:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kris Selden References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> In-Reply-To: <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 09:55:37 -0000 On 2011-05-19 11:14, Kris Selden wrote: >> Well, like it or not, the default for HTTP header fields is not UTF-8. > > Encoding in HTTP header fields is not the topic, error_description is already encoded into a URI before it is in the Location field. > > There are 3 spots where error_description appears: > http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.2.1 > http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2.2.1 > http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.2 > > In section 4.1.2.1 and 4.2.2.1 the issue is about character encoding before application/x-www-form-urlencoded encoding (after that it is ASCII only). In section 4.2.2.1, the parameter is encoded in the fragment component which is only visible on the client side, and likely to be read by a script in Javascript (which is unicode only). > > In section 5.2 the response type is JSON which already deals with character encoding (http://tools.ietf.org/html/rfc4627#section-3) and is Unicode only. So there isn't anything to solve for error_description in section 5.2, except maybe to reference section 3 of rfc4627. > ... My comments applied to the proposal of returning error_description in the WWW-Authenticate header field (see ). Best regards, Julian From stephen.farrell@cs.tcd.ie Thu May 19 03:11: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 70433E07AB for ; Thu, 19 May 2011 03:11:01 -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 euwte7V9TC1U for ; Thu, 19 May 2011 03:11:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 15CADE0727 for ; Thu, 19 May 2011 03:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 33F81171D32; Thu, 19 May 2011 11:10:59 +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=1305799858; bh=X18ZSRDJTRDRlY mnEr40/zv4stqYp1oniaYgeaHSCMY=; b=yh+v8TiTtu2SUcQ3A1Q2UAw0EWTtoy jFg7jKIcJpAX5pKaCR772iYMQ+iz+ZoRnWvtoKgJnlqT+I669UlqsDo3XD4tQxmN 2leCCHE4siawQ+UbkA9UGRS7YEGNBiy0NCb0sNdP52RcHcDN/8zvVPmTHxtcX0Us bwpOG+ej0gN9MMcvsvJUm+Ww7Gy8uXp3BQkZNpo03DgyzGj+w1mZev8+hLnIP6MZ aMvOrx/zyiuJMPJPgMtNh6nUlHtZt48PHtDoEQRt8zfBzkY+vcMNy1TGjU8Psg1+ 6Jxtwm5iN5INXup27VRgZcjXANVGaR98cDVAiSNBDDZHv9npXa+0C6PQ== 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 SEOmGZzfGKvq; Thu, 19 May 2011 11:10:58 +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 B16B9171C64; Thu, 19 May 2011 11:10:58 +0100 (IST) Message-ID: <4DD4ECB2.1030508@cs.tcd.ie> Date: Thu, 19 May 2011 11:10:58 +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: Hannes Tschofenig References: <487B4CB8-B7C3-4455-856B-9D07BFFBEB34@gmx.net> In-Reply-To: <487B4CB8-B7C3-4455-856B-9D07BFFBEB34@gmx.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth WG Subject: Re: [OAUTH-WG] OAuth Interim Meeting: Register by Today X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 10:11:01 -0000 Hi All, On 19/05/11 08:26, Hannes Tschofenig wrote: > Hey all, > > a number of you had signed up already for the interim meeting either at the OAuth Wiki or at the Eventbrite page: > http://oauth-interim.eventbrite.com/ > http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeetingAttendance > > If you have not added your name to either one of these two lists yet please do so by the end of today. > We need the info for planning purposes. > > See you next Monday in Palo Alto! I'll be at some hotel in Brussels Monday and will try to get remote access to the meeting, at least for the early part. But just in case I don't get in... I'd like to thank to the the wg, the design team, and the chairs for the good progress since Prague - I still hope to get the base spec and whatever siblings it needs to the IESG before Quebec, so the wg can have that nice re-chartering discussion there - so please keep up the good work (and I'll plan to keep some AD pressure on:-) Cheers, S. PS: Where are the remote attendee instructions? Be good for me at least if those are out before I travel on Monday morning here. From torsten@lodderstedt.net Thu May 19 08:41: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 0F11FE07FE for ; Thu, 19 May 2011 08:41:44 -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 WG1WEAOavxzo for ; Thu, 19 May 2011 08:41:43 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1A1E0753 for ; Thu, 19 May 2011 08:41:42 -0700 (PDT) Received: from [79.253.37.205] (helo=[192.168.71.27]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QN5M3-0005LA-NO; Thu, 19 May 2011 17:41:39 +0200 Message-ID: <4DD53A3D.5010805@lodderstedt.net> Date: Thu, 19 May 2011 17:41:49 +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: <90C41DD21FB7C64BB94121FBBC2E723447582E4262@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447582E4263@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020106020809050904010004" X-Df-Sender: torsten@lodderstedt-online.de Cc: "eran@sled.com" , OAuth WG Subject: Re: [OAUTH-WG] Draft -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, 19 May 2011 15:41:44 -0000 This is a multi-part message in MIME format. --------------020106020809050904010004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Doug, Am 19.05.2011 04:09, schrieb Doug Tangren: > Followup questions from draft 16 > > 1. On storing user password for the resource owner creds flow. If the > client stores a access token along with the refresh token [1] to > refresh it, there should be no need to store the users password as > mentioned here [2] right? Yes. That's what meant with "It reduces the overall risk of storing username and password in the client". > > 2. What value does adding the client password to a basic auth encoded > header with duplicated client_id info add? [3] The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ. > > 6. Native modified usage of the auth code flow - "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" [7] > > The issue was brought up earlier that clients the implicit flow should > not be issued a refresh token because there'd be no way for the server > to identify the client without the client secret. Here its suggested > they do just that. Does this mean there may be a step added in the > implicit flow in the future that will enable the client to refresh > their access token without involving the user if the user has already > chosen to authorize the app? The text recommends to use the authorization code grant type not the implicit grant. regards, Torsten. > > Those are some of the things that jump out at me. I'll read if a few > more times so see if anything else comes up. > > I'm happy to see this is all coming together! This is great work. > > [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.3 > [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 > [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 > [4]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-1.5 > [5]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.2 > [6]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2 > [7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 > > -Doug Tangren > http://lessis.me > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020106020809050904010004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Doug,

    Am 19.05.2011 04:09, schrieb Doug Tangren:
    Followup questions from draft 16

    1. On storing user password for the resource owner creds flow. If the client stores a access token along with the refresh token [1] to refresh it, there should be no need to store the users password as mentioned here [2] right?

    Yes. That's what meant with "It reduces the overall risk of storing username and password in the client".


    2. What value does adding the client password to a basic auth encoded header with duplicated client_id info add? [3]

    The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ.

    <someone else should answer questions 3-5, pls.>


    6. Native modified usage of the auth code flow - "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    " [7]

    The issue was brought up earlier that clients the implicit flow should not be issued a refresh token because there'd be no way for the server to identify the client without the client secret. Here its suggested they do just that. Does this mean there may be a step added in the implicit flow in the future that will enable the client to refresh their access token without involving the user if the user has already chosen to authorize the app?

    The text recommends to use the authorization code grant type not the implicit grant.

    regards,
    Torsten.

    Those are some of the things that jump out at me. I'll read if a few more times so see if anything else comes up.

    I'm happy to see this is all coming together! This is great work.


    -Doug Tangren
    http://lessis.me


    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
    --------------020106020809050904010004-- From kris.selden@gmail.com Thu May 19 10:47:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2349DE0665 for ; Thu, 19 May 2011 10:47:14 -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 UeFSeNmwIvSy for ; Thu, 19 May 2011 10:47:13 -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 30BD6E0658 for ; Thu, 19 May 2011 10:47:13 -0700 (PDT) Received: by pwi5 with SMTP id 5so1820540pwi.31 for ; Thu, 19 May 2011 10:47:13 -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=10CIhwRswAMuoDp1R8EPZuAZi/YBiyfXbMKLqk+2e14=; b=P9vnMtw9c03otvqGFOyUuxs0Ou4ZpPr9NhVI6wiGveZrCF7j3cYdGznR8+ua6RkUSZ R8gHTWFCdN4+f6wpNHfpb4Vv+BUg+Agpw2uUx8066ZC5i1VW2bH08uZ88FENGfW3juhp eEQMuj41B7AOiOKuAynImg1BpsqhMnTpc7DrM= 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=m6JDsWjzUNdHHX5DwO+fDVmufkA9IFsxbmB0SXZYTunAK4hLjB9iyKHSU0wIJeIdHk PttgaEdzGHhFpi28m2KKpNKxrI+Sw3G1DPvn1B+UB8iBznTHGHmkocRRcCT3GAlACID9 TIyQgXfl7ElyAnCLnS8FLQH1UcTmtJjqtvYFk= Received: by 10.143.26.19 with SMTP id d19mr1943380wfj.131.1305827232886; Thu, 19 May 2011 10:47:12 -0700 (PDT) Received: from [172.16.176.22] (65-122-179-162.dia.static.qwest.net [65.122.179.162]) by mx.google.com with ESMTPS id k6sm2485232wfa.5.2011.05.19.10.47.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 10:47:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <4DD4E913.7070301@gmx.de> Date: Thu, 19 May 2011 10:47:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> <4DD4E913.7070301@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 17:47:14 -0000 I totally missed the error_description in the WWW-Authenticate header in = the bearer spec. I'm not sure why the human readable error description = is not in the response body on a 401 but I assume there is a reason. Is what you were proposing only apply to error_description when in HTTP = headers? Eran, are you looking for a solution to apply to error_description = wherever it appears? In the oauth spec it appears in a url query string, a url fragment, and = the json response body and in the bearer and mac spec it appears in a = http header. If it is possible for general guidance, I would start at the most = limited case, the url fragment which is intended to be parsed by a = client side script. Javascript cannot percent decode into a string = anything other than UTF-8. On May 19, 2011, at 2:55 AM, Julian Reschke wrote: > On 2011-05-19 11:14, Kris Selden wrote: >>> Well, like it or not, the default for HTTP header fields is not = UTF-8. >>=20 >> Encoding in HTTP header fields is not the topic, error_description is = already encoded into a URI before it is in the Location field. >>=20 >> There are 3 spots where error_description appears: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.2.1 >> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2.2.1 >> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.2 >>=20 >> In section 4.1.2.1 and 4.2.2.1 the issue is about character encoding = before application/x-www-form-urlencoded encoding (after that it is = ASCII only). In section 4.2.2.1, the parameter is encoded in the = fragment component which is only visible on the client side, and likely = to be read by a script in Javascript (which is unicode only). >>=20 >> In section 5.2 the response type is JSON which already deals with = character encoding (http://tools.ietf.org/html/rfc4627#section-3) and is = Unicode only. So there isn't anything to solve for error_description in = section 5.2, except maybe to reference section 3 of rfc4627. >> ... >=20 > My comments applied to the proposal of returning error_description in = the WWW-Authenticate header field (see = ).= >=20 > Best regards, Julian From julian.reschke@gmx.de Thu May 19 10:52: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 6B566E06B3 for ; Thu, 19 May 2011 10:52:49 -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 5LeTQk9SXDP2 for ; Thu, 19 May 2011 10:52:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 16668E0658 for ; Thu, 19 May 2011 10:52:19 -0700 (PDT) Received: (qmail invoked by alias); 19 May 2011 17:52:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 19 May 2011 19:52:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18mIQNAOvYmOZ7lKl3lxseIgaSfuOAk+0vxo+eKjy x2u2zcMq/ZoU25 Message-ID: <4DD558CD.7090800@gmx.de> Date: Thu, 19 May 2011 19:52:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kris Selden References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> <4DD4E913.7070301@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 19 May 2011 17:52:49 -0000 On 2011-05-19 19:47, Kris Selden wrote: > I totally missed the error_description in the WWW-Authenticate header in the bearer spec. I'm not sure why the human readable error description is not in the response body on a 401 but I assume there is a reason. Dunno. > Is what you were proposing only apply to error_description when in HTTP headers? Yes. >... BR, Julian From nico@cryptonector.com Fri May 20 13:24: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 C105AE0758; Fri, 20 May 2011 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 G2xdwSpYUxo9; Fri, 20 May 2011 13:24:47 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E0E80E0710; Fri, 20 May 2011 13:24:47 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 55579594062; Fri, 20 May 2011 13:24:43 -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=FQiafcjE6EoaINb7Dsj8n v+KqFhBY8X72n8fK2nfhbGqzZGubVW1S3UwIZZoH36V1/vH1BHIHQj3eeWC1Nup0 Jlg30DU1ZSXffceNHXdIVBzJbcI+hcIiD1/A8g1i+uJtvTP9OiAgl145JFvK2xTb xnB8Bj0XrApwp0kqDTQ0zE= 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=ddX2s1YSRTkvGEZDzUsZ YMot7Bc=; b=SrpcK3ylsHGwZk+G8TER0bxRPcYZHJB1ORjYiXDCitosE5zCyQx1 9pa8dEOI75yusp6GxBt21VKCkLCA9VBSvFwxzzzlfFx0+xKjOcehgm/Oe8tbk8XP l79IIqsjEhCVY8UelMDIgJT6hdLrzhOJi61zqxWtyL9iN6HzvhMODGc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 04575594058; Fri, 20 May 2011 13:24:42 -0700 (PDT) Received: by vws12 with SMTP id 12so3526669vws.31 for ; Fri, 20 May 2011 13:24:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.106 with SMTP id cp10mr56945vdc.199.1305923082438; Fri, 20 May 2011 13:24:42 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 13:24:42 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 20 May 2011 15:24:42 -0500 Message-ID: From: Nico Williams To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 20 May 2011 13:42:58 -0700 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: Fri, 20 May 2011 20:24:48 -0000 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 -- From eran@hueniverse.com Fri May 20 14:18: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 B829FE0759 for ; Fri, 20 May 2011 14:18:40 -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.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 ZTpa6yV9Vqbe for ; Fri, 20 May 2011 14:18:39 -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 C0612E0677 for ; Fri, 20 May 2011 14:18:39 -0700 (PDT) Received: (qmail 23941 invoked from network); 20 May 2011 21:18:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 May 2011 21:18:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 20 May 2011 14:18:29 -0700 From: Eran Hammer-Lahav To: Nico Williams Date: Fri, 20 May 2011 14:18:21 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: AcwXK/Tq8zux+2NhRMyGj/1LRzJuvgABvy4g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@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="utf-8" Content-Transfer-Encoding: base64 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: Fri, 20 May 2011 21:18:40 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmljbyBXaWxsaWFtcyBb bWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0NCj4gU2VudDogRnJpZGF5LCBNYXkgMjAsIDIw MTEgMToyNSBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IGFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZzsgQmVuIEFkaWRhOyBodHRwLXN0YXRlQGlldGYub3JnOyBPQXV0aCBXRzsgQWRhbQ0K PiBCYXJ0aCAoYWRhbUBhZGFtYmFydGguY29tKTsgSFRUUCBXb3JraW5nIEdyb3VwDQo+IFN1Ympl Y3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBIVFRQIE1BQyBBdXRoZW50aWNhdGlvbiBTY2hlbWUNCj4g DQo+IEFkZGl0aW9uYWwgY29tbWVudHM6DQo+IA0KPiAgLSBVc2luZyBub25jZXMgZm9yIHJlcGxh eSBwcm90ZWN0aW9uIGlzIGhlYXZ5LWR1dHkuICBJdCBpcyBkaWZmaWN1bHQgdG8NCj4gaW1wbGVt ZW50IGEgcmVsaWFibGUsIHNlY3VyZSwgaGlnaC1wZXJmb3JtYW5jZSByZXBsYXkgY2FjaGUuICAo SXQgaXMgZWFzeSB0bw0KPiBpbXBsZW1lbnQganVzdCBhIGhpZ2gtcGVyZm9ybWFuY2UgcmVwbGF5 IGNhY2hlOiB1c2UNCj4gbWVtY2FjaGUuKQ0KPiANCj4gICAgSSByZWNvbW1lbmQgYW4gb3B0aW9u IHRvIHVzZSBzZXF1ZW5jZSBudW1iZXJzIGF0IHRoZSBzZXJ2ZXIncyBjaG9pY2UsDQo+IHVuZGVy c3RhbmRpbmcsIG9mIGNvdXJzZSwgdGhhdCByZXF1ZXN0cyB3aWxsIG5vdCBiZSByZWNlaXZlZCBp biBzZXF1ZW5jZS4NCj4gVGhlIHVzZSBvZiBhIHNsaWRpbmcgc2VxdWVuY2UgbnVtYmVyIHdpbmRv dyBtYWtlcyBpdCBwb3NzaWJsZSB0byBkbyBhdA0KPiBsZWFzdCBhcyB3ZWxsIGFzIHdoZW4gdXNp bmcgbm9uY2UsIGFuZCBwcm9iYWJseSBmYXN0ZXIgd2hpbGUgc3RpbGwgYmVpbmcNCj4gc2VjdXJl Lg0KDQpXZSBzd2l0Y2hlZCB0byB1c2UgdGltZSBzaW5jZSBjcmVkZW50aWFscyB3ZXJlIGlzc3Vl ZC4gVGhpcyBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gaW1wbGVtZW50IGlmIHlvdSByZWFsbHkg bmVlZCByZXBseSBwcm90ZWN0aW9uIGJ5IHVzaW5nIGEgc21hbGwgd2luZG93IChjbG9jayBzeW5j IGlzIG5vIGxvbmdlciBhIHByb2JsZW0sIGp1c3QgdGhlIGRlbGF5IGluIGdldHRpbmcgdGhlIGNy ZWRlbnRpYWxzIHRvIHRoZSBjbGllbnQsIHdoaWNoIHNob3VsZCBiZSBhIHNtYWxsIHdpbmRvdyku DQoNCj4gIC0gSW4gYW4gb3BlbiB3aWZpIGVudmlyb25tZW50IGFjdGl2ZSBhdHRhY2tzIG1heSBu b3QgYmUgdmVyeSBkaWZmaWN1bHQsIHRodXMNCj4gYW4gb3B0aW9uIHRvIHNlY3VyZSBtb3JlIHRo YW4ganVzdCBhIGhhbmRmdWwgb2YgYml0cyBmcm9tIHRoZSByZXF1ZXN0LCB3b3VsZA0KPiBiZSBu aWNlIChhbGwgb2YgdGhlIHJlcXVlc3QgYW5kIGFsbCBvZiB0aGUgcmVzcG9uc2UsIHNheSkuICBU aGUgaGFyZCBwYXJ0IGlzIGhvdw0KPiB0byBkZWNpZGUgd2hlbiB0byB1c2Ugb25lIG9yIHRoZSBv dGhlci4gIElkZWFsbHkgYnJvd3NlcnMgY2FuIHJlcXVlc3QgbW9yZQ0KPiBwcm90ZWN0aW9uIHdo ZW4gdGhlIG5ldHdvcmsgaXMgcmVjb25maWd1cmVkIHN1Y2ggdGhhdCB0aGVyZSdzIG9uZSBvciBt b3JlDQo+IGNsZWFyIHdpZmkgaW50ZXJmYWNlcy4NCg0KVGhlcmUgaXMganVzdCBubyBlYXN5IHdh eSB0byBkbyB0aGF0LiBJZiB5b3UgbmVlZCBtb3JlLCB1c2UgVExTLg0KDQpFSEwNCg0K From nico@cryptonector.com Fri May 20 14:31: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 19F52E06CD; Fri, 20 May 2011 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 dxbVXMBeC4C3; Fri, 20 May 2011 14:31:54 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 54A13E06AD; Fri, 20 May 2011 14:31:54 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id ABE045406F; Fri, 20 May 2011 14:31: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=HbUh7udovQq+tRDqIt4xyHJwdFdJnh0hgbSUdAYXG933 +pvqZetq4T0/VBbFCbfcOPtedQem4ONpMc7iDRtrl38CSouoMAVQlBQMlHVw/2fA Al71SJDj6efTHVNQg6CFGf+E7wHK6KqYvWqXd2TrCKDd27tu+3fW+yGMtGx+guo= 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=wRXDvM0zQrr3JzT7Xuq7tUvW91Q=; b=F/55JvrnwNI 4xHL4O+WKGEwjX8NcGgriBYxgAcbReEAG/x63bbH7Q/YYnbSJNF46i/C1H3zpyM+ Dt0yhCEeKIZKmtoXifnfvxO3de1uDy3ITTp+Xe6EtYENcqq9wiwUq1uAIiZZZnVE ZyOWMqjCeeFeeSWnGJXaMMLEKRHSsCF4= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 4EDC054057; Fri, 20 May 2011 14:31:53 -0700 (PDT) Received: by vxg33 with SMTP id 33so3540948vxg.31 for ; Fri, 20 May 2011 14:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.196 with SMTP id cs4mr117174vdc.279.1305927112714; Fri, 20 May 2011 14:31:52 -0700 (PDT) Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 14:31:52 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 20 May 2011 16:31:52 -0500 Message-ID: From: Nico Williams To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 20 May 2011 21:31:55 -0000 On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav wr= ote: >> Additional comments: >> >> =C2=A0- Using nonces for replay protection is heavy-duty. =C2=A0It is di= fficult to >> implement a reliable, secure, high-performance replay cache. =C2=A0(It i= s easy to >> implement just a high-performance replay cache: use >> memcache.) >> >> =C2=A0 =C2=A0I 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. > > We switched to use time since credentials were issued. This should be pre= tty easy to implement if you really need reply protection by using a small = window (clock sync is no longer a problem, just the delay in getting the cr= edentials to the client, which should be a small window). Kerberos has had an option to use time or sequence numbers for a long time. We've learned a few things from this experience. For a memcache-type implementation, timestamps are probably best because maintaining a sequence number window in memcache, synchronized, would be a pain, if not impossible. Other replay cache implementations would likely do better using sequence numbers, especially when they have a small sequence number window per-session. And, of course, memcache isn't going to be durable (but probably it will be good enough in many cases). If you set a skew window to be tight on the future side, then you can compensate for this if you can detect loss of replay data (hmmm, not likely with memcache, eh?). One big gotcha to be aware of: - Some clocks have lousy resolution, leading to easily repeated values in high-rate environments. One fix is to add resolution on the wire and use random numbers for the unused precision bits. Another solution is to not use time. My advice is that you allow the server to select which of timestamps or sequence numbers to use. Also, I strongly recommend that you specify replay cache semantics in some detail. Think of the Kerberos V5 replay cache semantics. >> =C2=A0- In an open wifi environment active attacks may not be very diffi= cult, thus >> an option to secure more than just a handful of bits from the request, w= ould >> be nice (all of the request and all of the response, say). =C2=A0The har= d part is how >> to decide when to use one or the other. =C2=A0Ideally browsers can reque= st more >> protection when the network is reconfigured such that there's one or mor= e >> clear wifi interfaces. > > There is just no easy way to do that. If you need more, use TLS. But even then you need to know when to use TLS. TLS doesn't solve the problem when you're trying to solve problems without introducing TLS in the first place. This is a serious problem. You think you're fixing one problem (cookie theft by passive attackers on open networks) and you're very likely only making things somewhat harder for the attacker -- we need to be very careful that the attacker can't just automate active attacks and still win. Nico -- From andrew@uncorkedapps.com Fri May 20 20: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 47555E068E for ; Fri, 20 May 2011 20:41:34 -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 sDX6Huhs1vB7 for ; Fri, 20 May 2011 20:41:33 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id DE22DE068B for ; Fri, 20 May 2011 20:41:33 -0700 (PDT) Received: by pxi2 with SMTP id 2so2580203pxi.38 for ; Fri, 20 May 2011 20:41:33 -0700 (PDT) Received: by 10.142.246.15 with SMTP id t15mr77491wfh.41.1305949293312; Fri, 20 May 2011 20:41:33 -0700 (PDT) Received: from [10.0.1.3] (c-76-126-138-255.hsd1.ca.comcast.net [76.126.138.255]) by mx.google.com with ESMTPS id x12sm3783428wfd.18.2011.05.20.20.41.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2011 20:41:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Andrew Wooster In-Reply-To: <4DD558CD.7090800@gmx.de> Date: Fri, 20 May 2011 20:41:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> <4DD4E913.7070301@gmx.de> <4DD558CD.7090800@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2011 03:41:34 -0000 On May 19, 2011, at 10:52 AM, Julian Reschke wrote: > On 2011-05-19 19:47, Kris Selden wrote: >> I totally missed the error_description in the WWW-Authenticate header = in the bearer spec. I'm not sure why the human readable error = description is not in the response body on a 401 but I assume there is a = reason. >=20 > Dunno. >=20 >> Is what you were proposing only apply to error_description when in = HTTP headers? >=20 > Yes. That seems bad. Human readable text isn't something that should be put = into an HTTP header. The MAC spec has the same problem, in section 4.1. These should be brought in line with the OAuth v2 spec, which specifies = the human readable error descriptions going in the body. -Andrew= From eran@hueniverse.com Fri May 20 22:42: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 EE6AFE06EE for ; Fri, 20 May 2011 22:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 wW9tN1D13Ltd for ; Fri, 20 May 2011 22:42:58 -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 D2446E0719 for ; Fri, 20 May 2011 22:42:57 -0700 (PDT) Received: (qmail 22274 invoked from network); 21 May 2011 05:42:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 May 2011 05:42:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 20 May 2011 22:42:47 -0700 From: Eran Hammer-Lahav To: Andrew Wooster , Julian Reschke Date: Fri, 20 May 2011 22:42:38 -0700 Thread-Topic: [OAUTH-WG] Language encoding in error_description Thread-Index: AcwXaP77kplmvi9TSnenMBgaxcvALwAENx/A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4711@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4117@P3PW5EX1MB01.EX1.SECURESERVER.NET> <31C589EC-B492-4F5B-B898-C81785B442AD@gmail.com> <4DD42CC7.7010109@gmx.de> <4DD4AF2A.2060004@gmx.de> <0EA3E115-DA0D-4BE2-9301-1FA6892F040A@gmail.com> <4DD4E913.7070301@gmx.de> <4DD558CD.7090800@gmx.de> 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: Kris Selden , OAuth WG Subject: Re: [OAUTH-WG] Language encoding in error_description X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2011 05:42:59 -0000 I'm dropping it from MAC. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Andrew Wooster > Sent: Friday, May 20, 2011 8:42 PM > To: Julian Reschke > Cc: Kris Selden; OAuth WG > Subject: Re: [OAUTH-WG] Language encoding in error_description >=20 > On May 19, 2011, at 10:52 AM, Julian Reschke wrote: > > On 2011-05-19 19:47, Kris Selden wrote: > >> I totally missed the error_description in the WWW-Authenticate header = in > the bearer spec. I'm not sure why the human readable error description i= s > not in the response body on a 401 but I assume there is a reason. > > > > Dunno. > > > >> Is what you were proposing only apply to error_description when in HTT= P > headers? > > > > Yes. >=20 > That seems bad. Human readable text isn't something that should be put in= to > an HTTP header. >=20 > The MAC spec has the same problem, in section 4.1. >=20 > These should be brought in line with the OAuth v2 spec, which specifies t= he > human readable error descriptions going in the body. >=20 > -Andrew > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From denadai2@gmail.com Sat May 21 11:16: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 AC376E070C for ; Sat, 21 May 2011 11:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDjx127tbccP for ; Sat, 21 May 2011 11:16:49 -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 0A241E070F for ; Sat, 21 May 2011 11:16:48 -0700 (PDT) Received: by qwc23 with SMTP id 23so3503399qwc.31 for ; Sat, 21 May 2011 11:16: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=XmokTVafE3NjPQFRDjZbfel2p4Na9cIBTAYi9Xd/kV8=; b=o1SG3Gyjcw2axm2O89e1Qt04zhE9CUAxIK0EZUKUvyVDcSQ9f7g8ktnLwvxTvS9+nJ qT0rWEpW/9ZgYwTsCGGahexnG28QkhzKTc2DXa50Rf3ErEkg13nqT7UvFaCL9iKOSPrO 3CI778ioyWqpoc7DnhnEo+jbQ/jZ/e/XP0ymA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=CgC8Zz/+HLjjIdkr4iWMkswJWXDY3q4txge5IVqY4nBTCTG7ht6Ez1l3/HQUGUzgFB 8U+YkZ+y3J3zllJKTmDQ/O2PcK22aT7tumrhro6JZnr8FSbfOwbCkALHtqzPLjFUQtN1 wQ4MwRd0b4XJKHPYnD662atoPiwLIsvvjRHSo= Received: by 10.229.42.73 with SMTP id r9mr583574qce.189.1306001807199; Sat, 21 May 2011 11:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.187.137 with HTTP; Sat, 21 May 2011 11:16:27 -0700 (PDT) From: denadai2 Date: Sat, 21 May 2011 20:16:27 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00163683249ccb4c5c04a3cd3d85 Subject: [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: Sat, 21 May 2011 18:18:38 -0000 --00163683249ccb4c5c04a3cd3d85 Content-Type: text/plain; charset=ISO-8859-1 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 --00163683249ccb4c5c04a3cd3d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm trying to formal verify the OAuth 2.0 =A0draft 16 protocol.=A0
    =
    I want to try OAuth 2.0 with hmac token type ().
    <= br>
    In the "Authorization Code" mode i have the respons= e token as this:
    - access_token: [access_token]
    - token_type: mac
    -= mac_key: buabuabua
    - mac_algorithm: hmac-sha-256
    The a= ccess_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 /resour= ce/1 HTTP/1.1
    Authorization: MAC id =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:dj83hs92"
    =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_to= ken, secret)

    ?

    --00163683249ccb4c5c04a3cd3d85-- From internet-drafts@ietf.org Sat May 21 13:20: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 2B522E06E5; Sat, 21 May 2011 13:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 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 iUQFG9JcfJlg; Sat, 21 May 2011 13:20:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C433E0688; Sat, 21 May 2011 13:20:44 -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.54 Message-ID: <20110521202044.20765.16202.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2011 13:20:44 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-05.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: Sat, 21 May 2011 20:20:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Authentication Protocol Working = Group 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-05.txt Pages : 17 Date : 2011-05-21 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-05.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-05.txt From Michael.Jones@microsoft.com Sat May 21 14:59: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 71781E070D for ; Sat, 21 May 2011 14:59:56 -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=[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 9blSo7PptrZK for ; Sat, 21 May 2011 14:59:53 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 485B5E06B9 for ; Sat, 21 May 2011 14:59:53 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 21 May 2011 14:59:50 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0289.008; Sat, 21 May 2011 14:59:50 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification draft -05 Thread-Index: AcwYAmPJyyxwFkYjRSObwtPT/BymlA== Date: Sat, 21 May 2011 21:59:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943380E3834@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943380E3834TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -05 X-BeenThere: oauth@ietf.org X-Mailman-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, 21 May 2011 21:59:56 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943380E3834TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In preparation for the OAuth working group meeting on Monday, I've publishe= d draft 05= of the OAuth Bearer Token Specification, incorporating input received from the OAuth de= sign team. The changes in this draft are: * Removed OAuth Errors Registry, per design team input. * Changed HTTP status code for invalid_request error code from HTTP = 400 (Bad Request) to HTTP 401 (Unauthorized) to match HTTP usage [[ change = pending working group consensus ]]. * Added missing quotation marks in error-uri definition. * Added note to add language and encoding information to error_descr= iption if the core specification does. * Explicitly reference the Augmented Backus-Naur Form (ABNF) defined= in [RFC5234]. * Use auth-param instead of repeating its definition, which is ( tok= en "=3D" ( token / quoted-string ) ). * Clarify security considerations about including an audience restri= ction in the token and include a recommendation to issue scoped bearer toke= ns in the summary of recommendations. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.= pdf * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.= txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-05.= xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.pdf * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-05.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 --_000_4E1F6AAD24975D4BA5B1680429673943380E3834TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    In preparation for the OAuth working group meeting o= n Monday, I’ve published draft 05 of the OA= uth Bearer Token Specification, incorporating input received from the O= Auth design team.  The changes in this draft are:

    ·        Removed OAuth Errors Registry, per design te= am input.

    ·        Changed HTTP status code for invalid_request= error code from HTTP 400 (Bad Request) to HTTP 401 (Unauthorized) to match= HTTP usage [[ change pending working group consensus ]].

    ·        Added missing quotation marks in error-uri d= efinition.

    ·        Added note to add language and encoding info= rmation to error_description if the core specification does.

    ·        Explicitly reference the Augmented Backus-Na= ur Form (ABNF) defined in [RFC5234].

    ·        Use auth-param instead of repeating its defi= nition, which is ( token "=3D" ( token / quoted-string ) ).<= /o:p>

    ·        Clarify security considerations about includ= ing an audience restriction in the token and include a recommendation to is= sue scoped bearer tokens in the summary of recommendations.

     

    The draft is available at these locations:

    ·        http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-05.pdf

    ·        http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-05.txt

    ·        http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-05.xml

    ·        http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-05.html

    ·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-05.pdf

    ·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-05.txt

    ·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-05.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-v= 2-bearer.pdf (will point to new versions as they are posted)=

    ·        http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.txt (will point to new versions as they are posted)=

    ·        http://self-issued.info/docs/draft-ietf-oauth-v= 2-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 availab= le)

     

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

     

    --_000_4E1F6AAD24975D4BA5B1680429673943380E3834TK5EX14MBXC202r_-- From eran@hueniverse.com Sat May 21 23:24: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 C95C8E0693 for ; Sat, 21 May 2011 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 5aWAxGn79ZFN for ; Sat, 21 May 2011 23:24:24 -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 C4B5BE0618 for ; Sat, 21 May 2011 23:24:24 -0700 (PDT) Received: (qmail 8539 invoked from network); 22 May 2011 06:24:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 May 2011 06:24:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 21 May 2011 23:19:59 -0700 From: Eran Hammer-Lahav To: denadai2 , "oauth@ietf.org" Date: Sat, 21 May 2011 23:19:48 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand Thread-Index: AcwX44TN3+yw9RVXTLyAGPh5XVYz3gAZCOkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4797@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_90C41DD21FB7C64BB94121FBBC2E723447582E4797P3PW5EX1MB01E_" MIME-Version: 1.0 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: Sun, 22 May 2011 06:24:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4797P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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-bounces@ietf.org] On Behalf Of d= enadai2 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_90C41DD21FB7C64BB94121FBBC2E723447582E4797P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

    <= p class=3DMsoNormal> 

    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 a= s defined in the MAC spec (and it does not include the access token).<= /o:p>

     

    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: Saturd= ay, 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.&n= bsp;

     

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

     

    =

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

    - acc= ess_token: [access_token]

    - t= oken_type: mac

    - mac_key: bua= buabua

    - mac_algorithm: hmac-= sha-256

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

     

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

    G= ET /resource/1 HTTP/1.1

    Authorization: MAC id =3D [access_toke= n provided in the first pass]

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

              &= nbsp;                  mac =3D= "ASDDFGDFGDG"

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

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4797P3PW5EX1MB01E_-- From denadai2@gmail.com Sun May 22 08:28: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 EC3D3E0684 for ; Sun, 22 May 2011 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.759, 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 kHoXQQuLwple for ; Sun, 22 May 2011 08:28:02 -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 C74FEE065D for ; Sun, 22 May 2011 08:28:01 -0700 (PDT) Received: by qyk7 with SMTP id 7so3321555qyk.10 for ; Sun, 22 May 2011 08:28:01 -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=6gCVPnegIyAsfpYRpUQbEwtQ3FLSgZ9t4aL7G/U9YNM=; b=SLrpHVXBE3W3rG7OKUrS6Lw2cHnC57xCX1onByyZznrc43Hf+TtTUp2rj/dMeQZcSz KJ36iF5NKRD4T1OjxahFgNfbsEqHOiFUNe7KJ/Uv6zPnghoE8WB8VoRHCnr5euw0sZTC KaAR//MVpy5w3y4CV8jkR/iDo/7KFosZoVN6E= 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=luMBBB2+GiidVtCrp0t2KC4xCz/sjYfbWR2jNBUKp21baoKKoEyHtrjNpPTEPImQPW xAtR/n4edHg4eFtxoHn8sA6GCK2/SCRg5BuWURYJtUwG3jbaj98pYLBJQor581YGUt/6 9NdO5mckyfNCf7ibZZfnKJjY2LQjkPRSZO2p4= Received: by 10.229.17.210 with SMTP id t18mr1020123qca.228.1306078081120; Sun, 22 May 2011 08:28:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.187.137 with HTTP; Sun, 22 May 2011 08:27:41 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E4797@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447582E4797@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: denadai2 Date: Sun, 22 May 2011 17:27:41 +0200 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0015175df24e12f9f404a3df0099 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: Sun, 22 May 2011 15:28:03 -0000 --0015175df24e12f9f404a3df0099 Content-Type: text/plain; charset=ISO-8859-1 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). 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()) 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). 6- resource owner - > Client (without TLS) It will provide the resouce requested - Did I understand? - how would you generate a token? - Is the id field the access_token provided in the authorization response? 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 > --0015175df24e12f9f404a3df0099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Ok thank you. I will be more specific:

    1- Cli= ent -> Authorization server. (via TLS)
    =A0 =A0 I build the aut= horization request with response_type =3D "code", client_id, redi= rect_uri.

    2- Authorization server -> Client. (without TLS)
    =A0 =A0 I grant access with an authorization code generated (for exa= mple) with enc(client_id || redirect_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 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

    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 =A0= token_type =3D "mac"
    =A0 =A0 =A0 =A0mac_key=3D "..."
    =A0 =A0 =A0 =A0mac= _algorithm =3D "hmac-sha-256".=A0
    =A0 =A0 The access_to= ken is generated with sha-256(random_string())

    5- = Client -> resource owner (without TLS)
    =A0 =A0 The client request a resource with access_token obtained in st= ep 4 and=A0
    =A0 =A0 =A0 =A0Authorization header: MAC id=3D"[= access_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 =A0non= ce=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 p= rovided in step4])
    =A0 =A0 The resource owner will asks to the Au= thorization server if the access_token is valid (if it belongs to the clien= t and if it=A0
    =A0 =A0 not expired, if the scope is allowed etc).

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

    - Did I understand?
    - how would you generate a token?= =A0
    - Is the id field the access_token provided in= the authorization response?

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

    2011/5/2= 2 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.=

    =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


    --0015175df24e12f9f404a3df0099-- From recordond@gmail.com Sun May 22 10:46: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 7BD26E06EE for ; Sun, 22 May 2011 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 NQxl2zGgjbT3 for ; Sun, 22 May 2011 10:46:29 -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 91BF2E06E7 for ; Sun, 22 May 2011 10:46:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so4344553vxg.31 for ; Sun, 22 May 2011 10:46:29 -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=bUlr8qOw3c4STGjGApJb0TO4BjU8Yi2JoHW+lSWjvQc=; b=mLjdG59flf9JADskCL9klZO9AohkQd0GZ4wxc0TZCfGp0ItASGfDWmHEF4RW4hw3Pe x0Lkxilw8h0ebGVyXexGC54+OSwY7HqP3Ul2QWKHbzN/30N/rZ/2o3U5UePUvdzID9Ly QoeEu9taIJDOZxG/EcjdJABsKlPEnERP/BsLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=htjLyKHV/ipsLywx8/CFMg3koLZIEfwLTRRoldevykxMCmZ5DkyL6P7eUfJvvW7+uK UNU3Ka92a8Vp+0RpFswhhIi+6mu5c1TQvYLpjmiSrPcd0NpDSefCvmSFVr9E/ddstoyg keWkI+0W3nYyan4Un5wWjk9zR956Jp3jD0SC4= MIME-Version: 1.0 Received: by 10.52.75.227 with SMTP id f3mr2237549vdw.74.1306086000873; Sun, 22 May 2011 10:40:00 -0700 (PDT) Received: by 10.52.158.202 with HTTP; Sun, 22 May 2011 10:40:00 -0700 (PDT) Date: Sun, 22 May 2011 10:40:00 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 22 May 2011 17:46:30 -0000 If you're planning to attend in person then you'll want to head to 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind the building so feel free to park anywhere in that lot. You'll then want to head to the lobby of building 1 which is the largest; the lobby is on the Page Mill side. When you get there ask for either me or the OAuth meeting. There's plenty of snack food and breakfast will still be going on until 10. If you're joining remotely, you can do so either via video or audio conference. To join, goto http://bluejeans.com/davidrecordon/ and choose the OAuth meeting. Anything I missed? --David From eran@hueniverse.com Sun May 22 11:41: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 3102CE06BF for ; Sun, 22 May 2011 11:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-1.547, 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 HYST4GZnsRlL for ; Sun, 22 May 2011 11:41: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 EB6ADE0696 for ; Sun, 22 May 2011 11:41:47 -0700 (PDT) Received: (qmail 1072 invoked from network); 22 May 2011 16:55:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 May 2011 16:55:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 22 May 2011 09:54:49 -0700 From: Eran Hammer-Lahav To: denadai2 Date: Sun, 22 May 2011 09:54:40 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0-16 + mactoken draft 6. I don't undestand Thread-Index: AcwYoPWhznPDIjdtQOG++6DJ7YnSCw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9FE8D70132B1eranhueniversecom_" 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: Sun, 22 May 2011 18:41:49 -0000 --_000_C9FE8D70132B1eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_C9FE8D70132B1eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


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

    Ok thank you. I will be more specific= :

    1- Client -> Authorization server. (via TLS)<= /div>
        I build the authorization request with response_typ= e =3D "code", client_id, redirect_uri.

    2- Authoriz= ation server -> Client. (without TLS)
        I grant ac= cess 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 diffi= e-hellman secret shared with the Client in a previous step.

    <= /div>
    3- Client -> Authorization server. (without TLS)
        I request the access token with grant_type =3D "authorizati= on_code", client_id, code =3D "[authorization code of step 2]",
    &= nbsp;   redirect_uri =3D [redirect_uri of step 2].
      &n= bsp; The Authorization server now will check that the authorization code wa= s issued to that client and will verify that the uri       m= atches the redirection URI with: dec(authorization_code, secret). 

    TLS Required

    =

    4- Authorization server -> Client. (witho= ut TLS)
        Authorization code will return the access_t= oken: 
           access_token =3D "..."
           token_type =3D "mac"
      &nb= sp;    mac_key=3D "..."
           mac_= algorithm =3D "hmac-sha-256". 
        The access_toke= n is generated with sha-256(random_string())
    =
    TLS Required


    <= div>5- Client -> resource owner (without TLS)
        Th= e client request a resource with access_token obtained in step 4 and <= /div>
           Authorization header: MAC id=3D"[acces= s_token provided in step 4]" 
            &n= bsp;                     =                  nonce=3D"[age= ]:[randomstring]"
                 = ;                     &nb= sp;            mac=3Dhmac-sha-256(normalized_= string, [mac_key provided in step4])
        The resource o= wner will asks to the Authorization server if the access_token is valid (if= it belongs to the client and if it 
        not expir= ed, if the scope is allowed etc).

    <= div>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.

    <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: = #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">- how would you generate= a token? 

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

    =
    - Is the id field the access_token provided in the authorization respo= nse?

    Yes.

    EHL


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

    2011/5/22 Eran Hammer-Lahav <eran@hueniverse.com>
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

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

    &n= bsp;

    How you generate your access token string is an internal detail b= ut your use of the authorization code in the algorithm is odd, IMO.<= /p>

    &n= bsp;

    The MAC is calculated based on the normalized string as defined i= n 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 an= d responses.

     

    EHL

     

    From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of denadai2
    Sent: Saturday, May 21, 2011 11:16 AM
    <= b>To:     oauth@ietf.or= g
    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 "Authorizatio= n 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 ac= cess 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]

       = ;                     &nb= sp;    nonce =3D "274312:dj83hs92"

                       = ;          mac =3D "ASDDFGDFGDG"

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

     

    =

    ?

    &n= bsp;


    --_000_C9FE8D70132B1eranhueniversecom_-- From beaton@google.com Sun May 22 20: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 F0E54E06FA for ; Sun, 22 May 2011 20:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.977 X-Spam-Level: X-Spam-Status: No, score=-107.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 dih1a5V5RW8T for ; Sun, 22 May 2011 20:38: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 2ADADE06F5 for ; Sun, 22 May 2011 20:38:57 -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 p4N3ctgM028081 for ; Sun, 22 May 2011 20:38:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306121936; bh=B5+16P9rXh7J1uG3ToktoP0rhbc=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type: Content-Transfer-Encoding; b=ih3WqOX/M+6yWlF4+Jtt8ec7InJTHLGdzftgskQYwV9cM/UYyypEwOeHYWr3nfITe UV86TbxH+vBL0vmK6+mgg== Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by kpbe16.cbf.corp.google.com with ESMTP id p4N3cso3029129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 22 May 2011 20:38:54 -0700 Received: by pvc21 with SMTP id 21so3512560pvc.11 for ; Sun, 22 May 2011 20:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=KAAt+WN/MFNc4fFEgAuLWv+SFiF9nghQ9C1tcMvyACE=; b=k0j0LKBYuU3CTQwVPR3UVl2qCTsj4b9UhZM7OrYOICq1kaoYZHWLCilmu9PmLkYvEl 6Ya8aOSSjypvfrnII2wg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=axzn6RuMoKH6K1ErU62pj+PEin/0UVLQjYrtmgOjpgR6yKJIBOWY6VO7jqZmQ97rES uMGmWJWW4xqxF/L4/hpw== MIME-Version: 1.0 Received: by 10.142.202.2 with SMTP id z2mr743449wff.266.1306121933726; Sun, 22 May 2011 20:38:53 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Sun, 22 May 2011 20:38:53 -0700 (PDT) Date: Sun, 22 May 2011 20:38:53 -0700 Message-ID: From: Brian Eaton To: "oauth@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [OAUTH-WG] draft 16 review 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: Mon, 23 May 2011 03:39:00 -0000 I just read over the whole of the draft for the first time in a while. =A0I looked it over mostly for a) places where spec and reality were going to have trouble intersecting =A0 =A0and b) places where security advice would be useful =A0 =A0and c) grammer and speling, because I notices things like that Mostly noticed nits. =A0I'm really happy with the way some of the trickier issues have gotten dealt with. =A0Sometimes those differences get papered over, but they mostly seem to have been dealt with in constructive ways. =A0I didn't agree with all of the decisions, but I liked that the spec either made the decisions or gave clear guidance on trade-offs. So bear in mind that even though most of the comments in this e-mail are criticism, that's not because there isn't a lot of good in the spec. I won't be able to make the interim meeting tomorrow, but I wanted to send these out before hand. 1. =A0Introduction nit: text mixes =93resource-owner=94 and =93resource owner=94. =A0I think =93resource owner=94 is correct. consider adding bullet point: Compromise of any third-party application server results in compromise of the user=92s password and all of the data protected by that password. nit: =93web end-user=94 is an odd turn of phrase. =A0Maybe just =93end user= =94 1.1 Roles nit: =93- access restricted resources which require authentication to access:=94 seems awkward. =A0could eliminate the phrase entirely and make the meaning of the paragraph just as obvious. 1.4.1 Authorization Code maybe expand the section on important security benefits. =A0=93The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.=94 1.4.2 nit: =93intermediary authorization grant=94. =A0I think =93intermediate=94 = is the right term here, but might be wrong. 1.5 Refresh Token =93self-contain the authorization information in a verifiable manner.=94 That is never secure, because it makes review of issued permissions and revocation of those permissions impossible. =A0Refresh tokens are different than access tokens; a refresh token is always going to be an identifier that you use to look up authorization information. The text should be: =93The token denotes an identifier used to retrieve the authorization information.=94 (As another example of why you can=92t have a self-verifying refresh token, consider the role of the client id and client secret in the protocol. =A0If refresh tokens were self-verifying, you would also need bake the client secret into the refresh token, thus making client secret rotation impractical.) nit: =93..., no longer valid, =85=94 doesn=92t make sense. =A0I think the t= ext should be =93or is no longer valid.=94 =A0The parenthetical phrase throws off this paragraph a bit, maybe rephrase as =93The refresh token can be used to obtain a new access token when the current access token becomes invalid or expires, or to obtain addtional access tokens with identical or narrower scope. =A0(Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.) Should also add, maybe in the second paragraph: =93Unlike access tokens, refresh tokens are intended for use only with authorization servers. =A0Refresh tokens are never sent to resource servers.=94 3. =A0Client Authentication I like the compromise reached here on the language around client secrets for installed app clients. =A0It doesn=92t reflect reality, but the language allows enough wiggle room to be practical. =A0The spirit of the text is quite sensible, which is what I like best. 3.1 Client Password Authentication Referring to a password as a shared symmetric secret is misleading. =93Symmetric secret=94 is used almost exclusively with secret key cryptography, where both sides store copies of the secret. =A0That=92s not the right way to use client passwords; they should be treated like *passwords*, not HMAC keys or encryption keys. The reference to needing consensus on when to use basic auth and when to use client_id and client_secret parameters seems quite reasonable. The current language seems to reflect a poor compromise that will make interoperable implementations less likely for no good reason. =A0I=92d rather that someone picked a winner and the spec was simple and consistent. 3.2 Other Client Authentication Methods Again, I like the compromise here. =A0The language is vague but useful. 4.1.1. Authorization Request Please add =93state=94 to the example. =A0=93state=94 is an important part = of a secure client implementation, might as well encourage use by including it in examples. 4.1.2 Authorization Response =93minimize the risk of leaks=94: this should be =93mitigate=94, not =93min= imize=94. =93SHOULD expire shortly=94. =A0This should be a MUST. =A0The security analysis of the protocol doesn=92t hold unless authorization codes expire. =A0Suggested language: =93The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. =A0A maximum authorization code lifetime of 10 minutes is RECOMMENDED.=94 Again, please include =93state=94 in the example. 4.1.2.1 Error Response =93and MUST NOT redirect=94... this is contrary to some industry practice. =A0Various service providers show an interstitial to warn the user, but will then redirect if the user clicks through the interstitial. =A0How about =93and MUST NOT automatically redirect=94 as alternative language. The language around using HTTP status codes as values for the =93error=3D= =94 parameter is surprising. =A0Who requested that? =A0Has anyone implemented that? =A0Why is this a good idea? Again, example including =93state=94 parameter would be a good thing. 4.2 Implicit Grant nit: The phrase =93...maintaining their client credentials confidential...=94is a bit awkward. =A0This should probably be =93maintaining the confidentiality of their client credentials...=94 The introductory paragraph says the flow is suitable for clients that can=92t keep their client credentials secret. =A0However, that=92s not sufficient. =A0In addition, the client must be able to maintain the security of a redirect URI via something like the browser same-origin policy. =A0Suggested language: =93The implicit grant type is suitable for clients that cannot maintain the confidentiality of their client credentials, but which can be known to operate on a particular redirect URI.=94 =A0These applications are typically implemented in a browser using a scripting language such as JavaScript. nit in step (D): =93(does not include the fragment).=94 should be =93(which does not include the fragment).=94 4.2.1 Authorization Request Please include =93state=94 in example. Validation of the redirect_uri parameter is more important for the implicit grant type. =A0Section 2.1.1 leaves registration of the redirect URI as =93SHOULD=94. =A0It=92s a =93MUST=94 for the implicit flow. Suggested language: The authorization server validates the request to ensure all required parameters are present and valid. =A0The authorization server MUST verify that the redirect URI to which it will redirect the authorization code matches a redirect URI pre-registered by the client. =A0The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. =A0The authorization server MAY verify the query parameters as well. 4.2.2. Access Token Response Please include =93state=94 in example. 4.3 Resource Owner Password Credentials nit: =93converting the stored credentials with an access token=94 should be =93... to an access token.=94 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passw= ords. 4.4 Client Credentials The spec has this flow returning a refresh token. =A0This is a security problem. =A0We agreed to remove it or at least recommend against it almost a year ago. =A0Thread here: http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html General comments on HTTP headers. Should follow cache header recommendations from HTTP/1.1 spec for backwards compatibility with HTTP/1.0 caching proxies. =A0This means adding =93Pragma: no-cache=94 to all responses. =A0See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32. Should include charset in all content-type examples, to prevent security problems due to content sniffing. =A0See http://code.google.com/p/browsersec/wiki/Part2#Survey_of_content_sniffing_b= ehaviors. =A0For example: Content-Type: application/json; charset=3DUTF-8 6. Refreshing an Access Token nit: should mention that when the authorization server returns a new refresh token, they are going to revoke the old one as well. =A0How about: =93The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. =A0The authorization server MAY revoke the old refresh token after returning the new refresh token to the client.=94 Section 8.2 Defining New Endpoint Parameters Telling service providers to use vendor specific prefixes for query parameters sent to their web page is just not going to get implemented. =A0Every service provider has a collection of long-established query parameters that they use on all or almost all of their web pages. =A0That includes their authorization pages. Section 10. =A0Security Considerations I love the introduction here, this is an excellent break down of the different client types, and I=92ve never seen anyone else do it so concisely. One nit: I don=92t think the statement =93It is assumed that such an application can protect dynamically issued credentials, such as refresh tokens, from eavesdropping by other applications residing on the same device=94 is actually essential to the security analysis, and it rules out a large class of applications (e.g. everything on Windows or MacOS.) =A0Maybe change the section on Native Applications to say =93It is assumed that any client authentication credentials included in the application can be extracted, and furthermore that rotation of the client authentication credentials is not practical. =A0Dynamically issued credentials such as refresh tokens, on the other hand, can receive an acceptable level of protection. =A0At a minimum those credentials are protected from hostile servers which the client may contact. =A0On some platform those credentials might be protected from other applications residing on the same device.=94 There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsid= erations/OAuthWRAP2.0SecurityConsiderations.pdf Section 10.1 Client Authentication nit: =93MUST NOT issue client passwords to installed apps=94 is a dead letter, it is not going to change standard industry practice in the slightest. =A0The language from section 3 is more constructive. =A0I=92d suggest the following language for section 10.1 instead =93The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.=94 That does conform with industry practice, so it=92s more likely to be imple= mented. =93The authorization server is encouraged to consider using stronger client authentication means than a client password.=94 Could make that more specific by adding =93, such as assertions as per =94 Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for =93immediate mode=94, where authorization requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. 10.3 =A0Access Token Credentials =93When using the implicit grant type, the access token credentials are transmitted in the URI fragment, which can expose the credentials to unauthorized parties.=94 That=92s basically FUD. =A0This should be made much more specific. =A0It falls into the general category of security considerations for redirectors and clients... 10.5 Request Confidentiality. Why not specify TLS here, as is done elsewhere in the spec? 10.6 Endpoint Authenticity nit: =93server-side authentication=94 should be =93server authentication=94 (copying language from the TLS spec...) nit: should refer to RFC 2818 for server authentication rules 10.9 Authorization Codes =93SHOULD be short lived and MUST be single use=94 is backwards. These MUST be short-lived. =A0If they are long-lived, an attacker who compromises an end-user account even temporarily can mint a very large number of these tokens and replay them later as needed. MUST be single use is a dead letter, because it requires atomic operations at scale. =A0Even things like password changes are not atomic in user databases of moderate size. =A0Authorization codes might be generated quite frequently (e.g. when =93immediate mode=94 flows are used), so a MUST for an atomic operation is unrealistic. nit: =93Authorization codes operate as plaintext bearer credentials, used to verify that the end-user who granted authorization at the authorization server, is the same end-user returning to the client to complete the process.=94 That assumes that the user visited the client to trigger the authorization. =A0That=92s not always realistic, see the =93unsolicited authentication response=94 from the SAML 2 protocol for examples of other protocols where this is common. 10.10 Session Fixation I=92m not sure about the attack being described here. =A0Some of the mitigations make it sound like the attack described is session hijacking, not session fixation. If the mitigations mentioned the state parameter, then I would think that the attack described was session fixation at the client, but that doesn=92t come up. Can someone explain the attack in greater detail? 10.12 Resource Owner Password Credentials Really like this section, nicely put. =3D) After reading through the security considerations section a couple of times, I think it could benefit from a different organization. Specifically - keep the introduction, it=92s awesome. - write new sections for each of the following =A0=A01) Authorization Tokens =A0=A02) Web Application Clients =A0=A03) User-Agent Clients =A0=A04) Installed Application Clients =A0=A05) Authorization Servers =A0=A06) Resource Servers - merge the current recommendations (which are very sensible) into the appropriate sections. Just for kicks I started to write up security considerations for authorization tokens. I'll send that to the list separately. Cheers, Brian From beaton@google.com Sun May 22 20:47: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 04C0BE0720 for ; Sun, 22 May 2011 20:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.977 X-Spam-Level: X-Spam-Status: No, score=-106.977 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 ldt5crNrImt9 for ; Sun, 22 May 2011 20:47:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25DE071E for ; Sun, 22 May 2011 20:47:09 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p4N3l7Pe009705 for ; Sun, 22 May 2011 20:47:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306122428; bh=J5Z61hs6mYEMLHG9qDYBRFbG6DE=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=k4yWPEZbJvjEmjg3dqP9z2PQiLM3UK+Bkp1OsCICzMBuRnykTbeb/sytmqsImvIw+ +lqShsHYVbgKH2nk2qeDA== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by kpbe11.cbf.corp.google.com with ESMTP id p4N3l6fn015079 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 22 May 2011 20:47:06 -0700 Received: by pva4 with SMTP id 4so3163544pva.2 for ; Sun, 22 May 2011 20:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=HgZ8vdJ27sH5OJT0VtDIO7PzdrVfwfzq4AUJuwhnj0s=; b=pr11SEsslkfPKVDeLZ2N3sZBBzAoHdNn/BbGygVP6DBJMisDgHfmYXFWA26xFHamRO HV52gN5Hn0fhcWYmbPaA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=bGuGLaJg4EhA8+lwZaA3gwmaRfBLmCsiX9UBhpPzhnc0AOlJK3gu8itMTZDKgcwmd0 70e3ay9z4doOzY/+nKxw== MIME-Version: 1.0 Received: by 10.142.221.1 with SMTP id t1mr742387wfg.437.1306122426048; Sun, 22 May 2011 20:47:06 -0700 (PDT) Received: by 10.142.14.2 with HTTP; Sun, 22 May 2011 20:47:05 -0700 (PDT) Date: Sun, 22 May 2011 20:47:05 -0700 Message-ID: From: Brian Eaton To: "oauth@ietf.org" Content-Type: multipart/mixed; boundary=000e0cd146963ce08204a3e95354 X-System-Of-Record: true Subject: [OAUTH-WG] security considerations - authorization 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: Mon, 23 May 2011 03:47:11 -0000 --000e0cd146963ce08204a3e95354 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I said in the other note, after reading through the security considerations section a couple of times, I think it could benefit from a different organization. Specifically - keep the introduction, it=92s awesome. - write new sections for each of the following 1) Authorization Tokens 2) Web Application Clients 3) User-Agent Clients 4) Installed Application Clients 5) Authorization Servers 6) Resource Servers - merge the current text into the appropriate sections. I took a swing at the authorization tokens text. I tried to capture most of the relevant items from the current draft, but might have missed some. Cheers, Brian --000e0cd146963ce08204a3e95354 Content-Type: text/plain; charset=UTF-8; name="OAuth2-AuthorizationTokens.txt" Content-Disposition: attachment; filename="OAuth2-AuthorizationTokens.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_go0vjts10 77u/MTAuMSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBmb3IgQXV0aG9yaXphdGlvbiBUb2tlbnMN Cg0KDQpUaGUgT0F1dGgyIHByb3RvY29sIGRlYWxzIHdpdGggc2V2ZXJhbCB0eXBlcyBvZiBhdXRo b3JpemF0aW9uIHRva2Vucy4gIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIGFzc3VtcHRpb25z IG1hZGUgYnkgdGhlIHNwZWNpZmljYXRpb24gYWJvdXQgdGhlIGRlc2lnbiBvZiB0aG9zZSB0b2tl bnMuDQoNCg0KMTAuMS4xIEF1dGhvcml6YXRpb24gQ29kZXMNCg0KDQpBdXRob3JpemF0aW9uIGNv ZGVzIGFyZSBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFmdGVyIGFuIGVuZC11 c2VyIGF1dGhvcml6YXRpb24gcmVxdWVzdCBoYXMgYmVlbiBncmFudGVkLiAgVGhlIGNvZGVzIGFy ZSB1c2VkIHNob3J0bHkgYWZ0ZXIgdGhleSBhcmUgY3JlYXRlZCwgYW5kIGlmIHRoZSBjbGllbnQg aGFzIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLCB0aGUgY29kZXMgYXJlIGJvdW5kIHRvIHRo b3NlIGNyZWRlbnRpYWxzLiAgQXV0aG9yaXphdGlvbiBjb2RlcyBhcmUgZXhjaGFuZ2VkIGZvciBh Y2Nlc3MgdG9rZW5zIGFuZCBvcHRpb25hbCByZWZyZXNoIHRva2Vucy4NCg0KDQpBdXRob3JpemF0 aW9uIGNvZGVzIE1VU1QgYmUgdW5ndWVzc2FibGUuICBUaGV5IHNob3VsZCBjb250YWluIGF0IGxl YXN0IDY0IGJpdHMgb2YgZW50cm9weSBnZW5lcmF0ZWQgd2l0aCBhIGNyeXB0b2dyYXBoaWNhbGx5 IHN0cm9uZyByYW5kb20gbnVtYmVyIGdlbmVyYXRvci4gIElmIGFuIGF0dGFja2VyIGNhbiBndWVz cyBhIHZhbGlkIGF1dGhvcml6YXRpb24gY29kZSwgdGhleSBjYW4gdXNlIHRoYXQgYXV0aG9yaXph dGlvbiBjb2RlIHdpdGggYSBsZWdpdGltYXRlIGNsaWVudCBpbiBvcmRlciB0byBpbXBlcnNvbmF0 ZSB0aGUgdmljdGltIHJlc291cmNlIG93bmVyIHRvIHRoZSBjbGllbnQuDQoNCg0KQXV0aG9yaXph dGlvbiBjb2RlcyBhcmUgdHJhbnNtaXR0ZWQgdmlhIGh0dHAgcmVkaXJlY3RzLiAgQXV0aG9yaXph dGlvbiBzZXJ2ZXJzIE1VU1QgdXNlIFRMUywgd2hpY2ggcHJvdGVjdHMgdGhlIGF1dGhvcml6YXRp b24gY29kZSBpbiB0cmFuc2l0IGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHRoZSB1 c2VyLWFnZW50Lg0KDQoNClRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgSFRUUCByZWRpcmVjdCBNQVkg YmUgYSBuZXR3b3JrIHJlc291cmNlIHN1Y2ggYXMgYW4gaHR0cCBVUkksIG9yIE1BWSBiZSB0cmFu c21pdHRlZCB0byB0aGUgY2xpZW50IHRocm91Z2ggb3RoZXIgbWVhbnMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSWYgdGhlIHJlZGlyZWN0IHJlZmVycyB0byBhbiBI VFRQIHJlc291cmNlLCB0aGF0IHJlc291cmNlIFNIT1VMRCBpbXBsZW1lbnQgVExTIHRvIHByb3Rl Y3QgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbiB0cmFuc2l0IGZyb20gdGhlIHVzZXItYWdlbnQg dG8gdGhlIGNsaWVudC4gIFJlZ2FyZGxlc3Mgb2YgdGhlIGRlbGl2ZXJ5IG1lY2hhbmlzbSwgY2xp ZW50cyBNVVNUIHRha2UgcHJlY2F1dGlvbnMgdG8gcHJvdGVjdCB0aGUgY29uZmlkZW50aWFsaXR5 IG9mIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuICBBbiBlYXZlc2Ryb3BwZXIgd2hvIHdobyBjYW4g c3RlYWwgdGhlIGF1dGhvcml6YXRpb24gY29kZSBjYW4gcmVsYXkgaXQgdG8gdGhlIGxlZ2l0aW1h dGUgY2xpZW50IHRvIGltcGVyc29uYXRlIHRoZSB2aWN0aW0gcmVzb3VyY2Ugb3duZXIuDQoNCg0K VmFsdWVzIHRyYW5zbWl0dGVkIHZpYSBIVFRQIHJlZGlyZWN0cyBhcmUgcHJvbmUgdG8gbGVha2Fn ZSB2aWEgc2V2ZXJhbCBtZWNoYW5pc21zLCBzdWNoIGFzIEhUVFAgbG9ncywgcmVmZXJlciBoZWFk ZXJzLCBIVFRQIHJlZGlyZWN0b3JzLCBhbmQgdXNlci1hZ2VudCBoaXN0b3J5LiAgVGhpcyBzcGVj aWZpY2F0aW9uIHJlcXVpcmVzIHNldmVyYWwgbWl0aWdhdGlvbnMgdG8gbWl0aWdhdGUgdGhlIHJp c2sgb2Ygc3RvbGVuIGF1dGhvcml6YXRpb24gY29kZXMuDQoNCg0KQXV0aG9yaXphdGlvbiBjb2Rl cyBNVVNUIGJlIHNob3J0LWxpdmVkLCBhbmQgU0hPVUxEIGJlIHNpbmdsZSB1c2UuICBJZiB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgb2JzZXJ2ZXMgbXVsdGlwbGUgYXR0ZW1wdHMgdG8gZXhjaGFu Z2UgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGZvciBhbiBhY2Nlc3MgdG9rZW4sIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBTSE9VTEQgcmV2b2tlIGFsbCBhY2Nlc3MgdG9rZW5zIGFscmVhZHkgZ3Jh bnRlZCBiYXNlZCBvbiB0aGUgY29tcHJvbWlzZWQgYXV0aG9yaXphdGlvbiBjb2RlLg0KDQoNCklm IHRoZSBjbGllbnQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBlbnN1cmUgdGhhdCB0aGUgYXV0aG9y aXphdGlvbiBjb2RlIHdhcyBpc3N1ZWQgdG8gdGhlIHNhbWUgY2xpZW50Lg0KQ2xpZW50cyBTSE9V TEQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgaW1tZWRpYXRlbHkgYWZ0ZXIgcmVjZWl2aW5nIGFu IGF1dGhvcml6YXRpb24gY29kZSwgdG8gcmVkdWNlIHRoZSByaXNrIG9mIHRoZSBjb2RlIGxlYWtp bmcgaW4gdGhlIHVzZXItYWdlbnQgaGlzdG9yeSBvciB2aWEgYSByZWZlcmVyIGhlYWRlci4NCg0K DQoNCg0KMTAuMS4yIFJlZnJlc2ggVG9rZW5zDQoNCg0KUmVmcmVzaCB0b2tlbnMgYXJlIHRva2Vu cyB1c2VkIHRvIGdlbmVyYXRlIG5ldyBhY2Nlc3MgdG9rZW5zIGZvciBhbiBhdXRob3JpemF0aW9u IGdyYW50ZWQgYnkgYSByZXNvdXJjZSBvd25lciB0byBhIGNsaWVudC4gIFJlZnJlc2ggdG9rZW5z IGFyZSB0aGUgbW9zdCBwb3dlcmZ1bCBhdXRoZW50aWNhdGlvbiB0b2tlbiBkaXNjdXNzZWQgaW4g dGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhleSBjYW4gYmUgdGhvdWdodCBvZiBhcyBhbHRlcm5hdGl2 ZSBwYXNzd29yZHMgZm9yIGEgcmVzb3VyY2Ugb3duZXLigJlzIGFjY291bnQuICBUaGV5IGFyZSBt b3JlIHNlY3VyZSB0aGFuIHBhc3N3b3JkcywgYmVjYXVzZSB0aGV5IGNhbm5vdCBiZSBndWVzc2Vk LCB0aGV5IGNhbiBiZSBsaW1pdGVkIGluIHNjb3BlLCBhbmQgdGhleSBjYW4gYmUgYm91bmQgdG8g Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLg0KDQoNClRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIG1haW50YWluIHRoZSBsaW5rIGJldHdlZW4gYSByZWZyZXNoIHRva2VuIGFu ZCB0aGUgY2xpZW50IHRvIHdob20gaXQgd2FzIGlzc3VlZC4NCg0KDQpUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIGxpbmsgYmV0d2VlbiB0aGUgcmVmcmVzaCB0b2tlbiBh bmQgY2xpZW50IGlkZW50aXR5IHdoZW5ldmVyIHRoZSBjbGllbnTigJlzIGlkZW50aXR5IGNhbiBi ZSBhdXRoZW50aWNhdGVkLg0KDQoNCldoZW4gY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVp cmVkIHRvIHVzZSBhIHJlZnJlc2ggdG9rZW4gKGkuZS4gZm9yIHdlYiBhcHBsaWNhdGlvbnMgY2xp ZW50cyksIHJlY292ZXJ5IGZyb20gY29tcHJvbWlzZWQgcmVmcmVzaCB0b2tlbnMgaXMgcG9zc2li bGUgYnkgcm90YXRpbmcgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscy4gIFRo aXMgY2FuIGJlIGZhc3RlciBhbmQgbGVzcyBkaXNydXB0aXZlIHRoYW4gcmV2b2tpbmcgdGhlIHJl ZnJlc2ggdG9rZW5zIGFuZCByZXF1aXJpbmcgdGhhdCB1c2VycyByZWFwcHJvdmUgbmV3IHRva2Vu cy4gIEFuIGF0dGFja2VyIHdobyBoYXMgc3RvbGVuIHRoZSByZWZyZXNoIHRva2VuIHdpbGwgbm90 IGJlIGFibGUgdG8gdXNlIHRoZSB0b2tlbiwgc2luY2UgdGhleSB3aWxsIG5vdCBoYXZlIGFjY2Vz cyB0byB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLiAgSW4gb3JkZXIgdG8g cHJlc2VydmUgdGhlIHByb3BlcnR5IHRoYXQgcm90YXRpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGNyZWRlbnRpYWxzIG1ha2VzIHN0b2xlbiByZWZyZXNoIHRva2VucyB1c2VsZXNzLCBhdXRob3Jp emF0aW9uIHNlcnZlcnMgTVVTVCBOT1QgdHJhbnNtaXQgcmVmcmVzaCB0b2tlbnMgd2l0aG91dCBm aXJzdCByZWNlaXZpbmcgdmFsaWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KDQoNClJlZnJlc2gg dG9rZW5zIE1VU1QgYmUgYmFja2VkIGJ5IHNlcnZlci1zaWRlIHN0b3JhZ2UgaW4gb3JkZXIgdG8g YWxsb3cgZW5kLXVzZXJzIHRvIHJldmlldyBhbmQgcmV2b2tlIGFjY2Vzcy4NCg0KDQpQZXJtaXNz aW9uIHRvIHJlYWQgYW5kIHdyaXRlIHRoZSBzdG9yYWdlIHN5c3RlbSBNVVNUIGJlIHJlc3RyaWN0 ZWQgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KDQoNCkF1dGhvcml6YXRpb24gc2VydmVy cyBNVVNUIE5PVCBzdG9yZSByZWZyZXNoIHRva2VucyBpbiBhIHJlY292ZXJhYmxlIGZvcm0uICBB dXRob3JpemF0aW9uIHNlcnZlcnMgU0hPVUxEIHN0b3JlIGEgY3J5cHRvZ3JhcGhpY2FsbHkgc3Ry b25nIG9uZS13YXkgaGFzaCBvZiB0aGUgcmVmcmVzaCB0b2tlbiBpbnN0ZWFkIG9mIHN0b3Jpbmcg dGhlIHRva2VuIGRpcmVjdGx5LiAgVGhpcyBhbGxvd3MgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHRvIHZlcmlmeSB0aGUgdG9rZW4gd2hlbiBwcmVzZW50ZWQgYnkgdGhlIGNsaWVudCwgYnV0IHJl ZHVjZXMgdGhlIHJpc2sgb2YgbWFzcyBjb21wcm9taXNlIG9mIHJlZnJlc2ggdG9rZW5zIGlmIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBjb21wcm9taXNlZC4NCkF1dGhvcml6YXRpb24gc2Vy dmVycyBNVVNUIGxpbWl0IHRoZSBudW1iZXIgb2YgdG9rZW5zIHRoYXQgYXJlIGlzc3VlZCBieSBh IHNpbmdsZSB1c2VyIHRvIHByZXZlbnQgcmVzb3VyY2UgZXhoYXVzdGlvbiBhdHRhY2tzLiAgQXV0 aG9yaXphdGlvbiBzZXJ2ZXJzIE1BWSB1c2UgTFJVIG9yIEZJRk8gYWxnb3JpdGhtcyB0byByZW1v dmUgdG9rZW5zIGluIG9yZGVyIHRvIG1ha2Ugc3BhY2UgZm9yIG5ldyB0b2tlbnMuDQoNCg0KQXV0 aG9yaXphdGlvbiBzZXJ2ZXJzIFNIT1VMRCBsaW1pdCB0aGUgbnVtYmVyIG9mIHRva2VucyB0aGF0 IGFyZSBpc3N1ZWQgYnkgYSBzaW5nbGUgdXNlciB0byBhIHBhcnRpY3VsYXIgY2xpZW50LCBpbiBv cmRlciB0byBwcmV2ZW50IGEgc2luZ2xlIGNsaWVudCBmcm9tIHVzaW5nIGFsbCBvZiB0aGUgdG9r ZW4gc3RvcmFnZSBxdW90YSBmb3IgdGhlIHVzZXIuICBBdXRob3JpemF0aW9uIHNlcnZlcnMgTUFZ IHVzZSBMUlUgb3IgRklGTyBhbGdvcml0aG1zIHRvIHJlbW92ZSB0b2tlbnMgYmVsb25naW5nIHRv IGEgcGFydGljdWxhciBjbGllbnQgaW4gb3JkZXIgdG8gbWFrZSBzcGFjZSBmb3IgbmV3IHRva2Vu cyBmb3IgdGhhdCBjbGllbnQuDQoNCg0KUmVmcmVzaCB0b2tlbnMgTVVTVCBiZSB1bmd1ZXNzYWJs ZSwgYW5kIFNIT1VMRCBjb250YWluIGF0IGxlYXN0IDEyOCBiaXRzIG9mIGVudHJvcHkgZ2VuZXJh dGVkIHdpdGggYSBjcnlwdG9ncmFwaGljYWxseSBzdHJvbmcgcmFuZG9tIG51bWJlciBnZW5lcmF0 b3IuDQoNCg0KUmVmcmVzaCB0b2tlbnMgTVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFu c2l0IGFuZCBzdG9yYWdlLCBhbmQgc2hhcmVkIG9ubHkgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYW5kIHRoZSBjbGllbnQgdG8gd2hvbSB0aGUgcmVmcmVzaCB0b2tlbnMgd2VyZSBpc3N1 ZS4NCg0KDQoNCg0KMTAuMS4zLiBBY2Nlc3MgVG9rZW5zDQoNCg0KQWNjZXNzIHRva2VucyBhcmUg c2hvcnRlci1saXZlZCB2ZXJzaW9ucyBvZiByZWZyZXNoIHRva2Vucy4NCg0KDQoxMC4xLjMuMSBD b25maWRlbnRpYWxpdHkNCg0KDQpBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgTVVTVCBiZSBrZXB0 IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBzdG9yYWdlLCBhbmQgc2hhcmVkIG9ubHkgYW1v bmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUgcmVzb3VyY2Ugc2VydmVycyB0aGUgY3Jl ZGVudGlhbHMgYXJlIHZhbGlkIGZvciwgYW5kIHRoZSBjbGllbnQgdG8gd2hvbSB0aGUgY3JlZGVu dGlhbHMgd2VyZSBpc3N1ZWQuDQoNCg0KMTAuMS4zLjIgTGVha3MNCg0KDQpXaGVuIHVzaW5nIHRo ZSBpbXBsaWNpdCBncmFudCB0eXBlLCB0aGUgYWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIGFyZSB0 cmFuc21pdHRlZCBpbiB0aGUgVVJJIGZyYWdtZW50LCB3aGljaCBjYW4gZXhwb3NlIHRoZSBjcmVk ZW50aWFscyB0byB1bmF1dGhvcml6ZWQgcGFydGllcyB2aWEgdXNlci1hZ2VudCBoaXN0b3J5IG9y IEhUVFAgcmVkaXJlY3RvcnMuDQoNCg0KQ2xpZW50cyBTSE9VTEQgbWl0aWdhdGUgdGhlIHJpc2sg b2YgbGVha2FnZSBvZiB0b2tlbnMgdmlhIHRoZSB1c2VyLWFnZW50IGhpc3RvcnkgZWl0aGVyIGJ5 IHVzaW5nIGlmcmFtZXMsIG9yIGVsc2UgYnkgcmV3cml0aW5nIHRoZSBkb2N1bWVudCBsb2NhdGlv biB0byByZW1vdmUgdGhlIHRva2VuIGFzIHNvb24gYXMgaXQgaXMgcmVjZWl2ZWQuDQoNCg0KQXV0 aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgbWl0aWdhdGUgdGhlIHJpc2sgb2YgbGVha2FnZSBvZiB0 b2tlbnMgdmlhIEhUVFAgcmVkaXJlY3RvcnMgYnkgc3RyaWN0IG1hdGNoaW5nIG9mIHByZS1yZWdp c3RlcmVkIFVSSXMgd2hlbiB0cmFuc21pdHRpbmcgdG9rZW5zLg0KDQoNCjEwLjEuMy4zLiBTY29w ZQ0KDQoNClRoZSBjbGllbnQgU0hPVUxEIHJlcXVlc3QgYWNjZXNzIHRva2VuIGNyZWRlbnRpYWxz IHdpdGggdGhlIG1pbmltYWwgc2NvcGUgYW5kIGR1cmF0aW9uIG5lY2Vzc2FyeS4gIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgdGFrZSB0aGUgY2xpZW50IGlkZW50aXR5IGludG8gYWNj b3VudCB3aGVuIGNob29zaW5nIHRvIGhvbm9yIHRoZSByZXF1ZXN0IHNjb3BlLCBhbmQgTUFZIGlz c3VlIGNyZWRlbnRpYWxzIHdpdGggYSBsZXNzZXIgc2NvcGUgdGhhbiByZXF1ZXN0ZWQuDQoNCg0K MTAuMS4zLjQgSW1wbGVtZW50YXRpb24NCg0KDQpUaGVyZSBhcmUgbXVsdGlwbGUgcG9zc2libGUg aW1wbGVtZW50YXRpb25zIGZvciBhY2Nlc3MgdG9rZW5zLiAgQWNjZXNzIHRva2VucyBtYXkgYWN0 IGFzIGluZGljZXMgaW50byBzdG9yYWdlIGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIuICBUaGV5IG1h eSBiZSBzaWduZWQgdXNpbmcgYSBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciwgd2l0aCB0aGUgcHJp dmF0ZSBrZXkgaGVsZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSBwdWJsaWMg a2V5IGhlbGQgYnkgdGhlIHJlc291cmNlIHNlcnZlcnMuICBPciBhY2Nlc3MgdG9rZW5zIG1heSBi ZSBnZW5lcmF0ZWQgdXNpbmcgYSBzeW1tZXRyaWMgYXV0aGVudGljYXRpb24ga2V5IHN1Y2ggYXMg YW4gSE1BQyBrZXkuDQoNCg0KRGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBvZmZlciBkaWZmZXJl bnQgdHJhZGUtb2ZmcyBpbiB0ZXJtcyBvZiBzZWN1cml0eSwgYXZhaWxhYmlsaXR5LCBwZXJmb3Jt YW5jZSwgYW5kIG1haW50ZW5hbmNlIGNvc3QuDQoNCg0KDQoNCjEwLjEuMy40LjEgIFNoYXJlZCBT dG9yYWdlIEltcGxlbWVudGF0aW9uIG9mIEFjY2VzcyBUb2tlbnMNCg0KDQpJZiBhY2Nlc3MgdG9r ZW5zIGFyZSBpbXBsZW1lbnRlZCB1c2luZyBzdG9yYWdlIHNoYXJlZCBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXJzLCB0aGUgc3RvcmFnZSBuZWVkcyB0 byBiZSBhZGVxdWF0ZWx5IHByb3RlY3RlZC4gIFNoYXJlZCBzdG9yYWdlIGltcGxlbWVudGF0aW9u cyBvZiBhY2Nlc3MgdG9rZW5zIG1heSBiZSBhdHRyYWN0aXZlIGJlY2F1c2UgdGhleSBhbGxvdyBl YXN5IHJldm9jYXRpb24gb2YgdG9rZW5zLiAgU2hhcmVkIHN0b3JhZ2Ugc29sdXRpb25zIG1heSBh bHNvIGJlIGF0dHJhY3RpdmUgaWYgc3RvcmFnZSBzcGFjZSBhbmQgbmV0d29yayBiYW5kd2lkdGgg aXMgZmFzdCBhbmQgcmVsaWFibGUuDQoNCg0KUGVybWlzc2lvbiB0byB3cml0ZSB0byB0aGUgc2hh cmVkIHN0b3JhZ2UgU0hPVUxEIGJlIHJlc3RyaWN0ZWQgdG8gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLg0KDQoNClJlc291cmNlIHNlcnZlcnMgbXVzdCBiZSBhYmxlIHRvIHF1ZXJ5IHRoZSBzdG9y YWdlIHN5c3RlbSB0byBzZWUgd2hldGhlciBhbiBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQsIGJ1dCBT SE9VTEQgTk9UIGhhdmUgcGVybWlzc2lvbiB0byBsaXN0IHZhbGlkIHRva2VucyB0aGF0IGV4aXN0 IGluIHRoZSBzeXN0ZW0uICBUaGlzIHJlZHVjZXMgdGhlIHJpc2sgb2YgY29tcHJvbWlzZSBvZiBh IHJlc291cmNlIHNlcnZlciBsZWFkaW5nIHRvIG1hc3MgY29tcHJvbWlzZSBvZiBhY2Nlc3MgdG9r ZW5zLg0KDQoNCkF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIE5PVCBzdG9yZSBhY2Nlc3MgdG9r ZW5zIGluIGEgcmVjb3ZlcmFibGUgZm9ybS4gIEF1dGhvcml6YXRpb24gc2VydmVycyBTSE9VTEQg c3RvcmUgYSBjcnlwdG9ncmFwaGljYWxseSBzdHJvbmcgb25lLXdheSBoYXNoIG9mIHRoZSBhY2Nl c3MgdG9rZW4gaW5zdGVhZCBvZiBzdG9yaW5nIHRoZSB0b2tlbiBkaXJlY3RseS4gIFRoaXMgYWxs b3dzIHRoZSByZXNvdXJjZSBzZXJ2ZXJzIHRvIHZlcmlmeSB0aGUgdG9rZW4gd2hlbiBwcmVzZW50 ZWQgYnkgdGhlIGNsaWVudCwgYnV0IHJlZHVjZXMgdGhlIHJpc2sgb2YgbWFzcyBjb21wcm9taXNl IG9mIGFjY2VzcyB0b2tlbnMgaWYgdGhlIHN0b3JhZ2Ugc3lzdGVtIGlzIGNvbXByb21pc2VkLg0K DQoNCkF1dGhvcml6YXRpb24gc2VydmVycyBTSE9VTEQgcHJvdGVjdCBhZ2FpbnN0IHJlc291cmNl IGV4aGF1c3Rpb24gYXR0YWNrcyBieSBsaW1pdGluZyB0aGUgbWF4aW11bSBudW1iZXIgb2YgYWNj ZXNzIHRva2VucyB0aGF0IG1heSBiZSBpc3N1ZWQgYnkgYSBzaW5nbGUgdXNlci4gIA0KDQoNCjEw LjEuMy40LjIuIFB1YmxpYyBLZXkgSW1wbGVtZW50YXRpb25zIG9mIEFjY2VzcyBUb2tlbnMNCg0K DQpBY2Nlc3MgdG9rZW5zIG1heSBiZSBpbXBsZW1lbnRlZCB1c2luZyBwdWJsaWMga2V5IHNpZ25h dHVyZXMuICBQdWJsaWMga2V5IHNpZ25hdHVyZXMgbWF5IGJlIGF0dHJhY3RpdmUgaWYgc3RvcmFn ZSBzcGFjZSBvciBuZXR3b3JrIGJhbmR3aWR0aCBhcmUgbGltaXRlZC4gIFB1YmxpYyBrZXkgYmFz ZWQgaW1wbGVtZW50YXRpb25zIG9mIGFjY2VzcyB0b2tlbnMgbWFrZSByZXZvY2F0aW9uIG9mIGlz c3VlZCB0b2tlbnMgbW9yZSBjb21wbGljYXRlZC4gIERpZmZpY3VsdHkgb2YgcmV2b2NhdGlvbiBt ZWFucyB0aGF0IGFjY2VzcyB0b2tlbnMgc2hvdWxkIGhhdmUgc2hvcnQgbGlmZXRpbWVzLiAgQWNj ZXNzIHRva2VucyBjcmVhdGVkIHVzaW5nIHB1YmxpYyBrZXkgc2lnbmF0dXJlcyBtdXN0IGVuY29k ZSBhbGwgbmVjZXNzYXJ5IGRhdGEgd2l0aGluIHRoZSB0b2tlbiwgYW5kIHNvIG1heSBiZSBzaWdu aWZpY2FudGx5IGxhcmdlciB0aGFuIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBzaGFyZWQgc3Rv cmFnZS4NCg0KDQpBY2Nlc3MgdG8gdGhlIHByaXZhdGUga2V5IHVzZWQgdG8gc2lnbiBhY2Nlc3Mg dG9rZW5zIE1VU1QgYmUgcmVzdHJpY3RlZCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoN Cg0KVGhlIHByaXZhdGUga2V5IFNIT1VMRCBiZSByb3RhdGVkIGZyZXF1ZW50bHkuDQoNCg0KRGlz dHJpYnV0aW9uIG9mIHRoZSBwdWJsaWMga2V5IHRvIHJlc291cmNlIHNlcnZlcnMgaXMgb3V0IG9m IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IE1VU1QgYmUgZG9uZSBzZWN1cmVseS4N Cg0KDQpEZXNpZ24gb2YgdGhlIGNvbnRlbnRzIG9mIGFjY2VzcyB0b2tlbnMgaXMgb3V0IG9mIHNj b3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IE1VU1QgYWxsb3cgcmVzb3VyY2Ugc2VydmVy cyB0byB2ZXJpZnkgdGhlIGR1cmF0aW9uIGFuZCBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSB0b2tl bi4NCg0KDQpEYXRhIHdpdGhpbiB0aGUgYWNjZXNzIHRva2VuIE1BWSBuZWVkIHRvIGJlIGtlcHQg c2VjcmV0IGZyb20gY2xpZW50cyBvciByZXNvdXJjZSBvd25lcnMuICBUb2tlbnMgTUFZIGJlIGVu Y3J5cHRlZCBlaXRoZXIgdXNpbmcgYSBzZWNyZXQgc2hhcmVkIGJldHdlZW4gcmVzb3VyY2Ugc2Vy dmVycyBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBvciB1c2luZyBwdWJsaWMga2V5IGVu Y3J5cHRpb24gd2l0aCBhIHByaXZhdGUga2V5IGhlbGQgYnkgdGhlIHJlc291cmNlIHNlcnZlci4N Cg0KDQoxMC4xLjMuNC4zLiBTaGFyZWQgU2VjcmV0IEltcGxlbWVudGF0aW9ucyBvZiBBY2Nlc3Mg VG9rZW5zDQoNCg0KQWNjZXNzIHRva2VucyBtYXkgYmUgaW1wbGVtZW50ZWQgdXNpbmcgSE1BQyBh dXRoZW50aWNhdGlvbiBvZiB0aGUgdG9rZW4gY29udGVudHMgd2l0aCBzZWNyZXRzIHNoYXJlZCBi ZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2VydmVycy4gIENvbnNp ZGVyYXRpb25zIGZvciBITUFDIGF1dGhlbnRpY2F0aW9uIG9mIHRva2VucyBhcmUgdmVyeSBzaW1p bGFyIHRvIHRob3NlIGZvciBwdWJsaWMga2V5IGF1dGhlbnRpY2F0aW9uIG9mIHRva2Vucywgd2l0 aCBzb21lIGltcG9ydGFudCBkaWZmZXJlbmNlcy4NCg0KDQpUaGUgcHJpbWFyeSByZWFzb24gdG8g cHJlZmVyIEhNQUMgYXV0aGVudGljYXRpb24gb2YgdG9rZW5zIG92ZXIgcHVibGljIGtleSBhdXRo ZW50aWNhdGlvbiBpcyB0aGF0IEhNQUMgdmVyaWZpY2F0aW9uIHJlcXVpcmVzIGxlc3MgQ1BVIHRo YW4gcHVibGljIGtleSB2ZXJpZmljYXRpb24uDQoNCg0KSE1BQyBhdXRoZW50aWNhdGlvbiByZXF1 aXJlcyB0aGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIga25vdyB0aGUgYXV0aGVudGljYXRpb24gc2Vj cmV0IHVzZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGNyZWF0ZSBhY2Nlc3MgdG9r ZW5zLiAgQ29tcHJvbWlzZSBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIGFsbG93cyBhbiBhdHRhY2tl ciB0byBjcmVhdGUgbmV3IGFjY2VzcyB0b2tlbnMgZm9yIGFsbCByZXNvdXJjZSBzZXJ2ZXJzIHRo YXQgdHJ1c3QgdGhlIHNhbWUgc3ltbWV0cmljIGtleS4gIEJlY2F1c2Ugb2YgdGhpcywgYXV0aG9y aXphdGlvbiBzZXJ2ZXJzIE1VU1QgdXNlIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBrZXlzIGZv ciBlYWNoIHJlc291cmNlIHNlcnZlci4NCg0KDQpEaXN0cmlidXRpb24gb2YgdGhlIGF1dGhlbnRp Y2F0aW9uIGtleXMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4= --000e0cd146963ce08204a3e95354-- From sweeden@au1.ibm.com Sun May 22 21: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 4B41CE06FD for ; Sun, 22 May 2011 21:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 QM6cImYspXeZ for ; Sun, 22 May 2011 21:41: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 7CE42E06E1 for ; Sun, 22 May 2011 21:41: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 p4N4a5XV017514 for ; Mon, 23 May 2011 14:36:05 +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 p4N4ee4g790688 for ; Mon, 23 May 2011 14:40:40 +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 p4N4f1jX025527 for ; Mon, 23 May 2011 14:41: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 p4N4f1bl025515 for ; Mon, 23 May 2011 14:41:01 +1000 X-KeepSent: 94594AF7:A124E08C-4A257899:0017EFDD; 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: Mon, 23 May 2011 14:40:22 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.1FP4|July 25, 2010) at 23/05/2011 14:44:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [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: Mon, 23 May 2011 05:26:49 -0000 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. From Michael.Jones@microsoft.com Sun May 22 22:46: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 5637CE0675 for ; Sun, 22 May 2011 22:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 wBlzh2NcPP6D for ; Sun, 22 May 2011 22:46:43 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CE3BFE06C2 for ; Sun, 22 May 2011 22:46:43 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 22 May 2011 22:45:41 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0289.008; Sun, 22 May 2011 22:45:41 -0700 From: Mike Jones To: Brian Eaton , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft 16 review notes Thread-Index: AQHMGPr7xrinVSAi8UeTl7CSNizvdpSZ51ei Date: Mon, 23 May 2011 05:45:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943380E804C@TK5EX14MBXC203.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft 16 review 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: Mon, 23 May 2011 05:46:45 -0000 It would be great if you could do a similarly detailed read of the bearer t= oken spec as well! -- Mike Sent from my Windows Phone -----Original Message----- From: Brian Eaton Sent: Sunday, May 22, 2011 8:39 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft 16 review notes I just read over the whole of the draft for the first time in a while. I looked it over mostly for a) places where spec and reality were going to have trouble intersecting and b) places where security advice would be useful and c) grammer and speling, because I notices things like that Mostly noticed nits. I'm really happy with the way some of the trickier issues have gotten dealt with. Sometimes those differences get papered over, but they mostly seem to have been dealt with in constructive ways. I didn't agree with all of the decisions, but I liked that the spec either made the decisions or gave clear guidance on trade-offs. So bear in mind that even though most of the comments in this e-mail are criticism, that's not because there isn't a lot of good in the spec. I won't be able to make the interim meeting tomorrow, but I wanted to send these out before hand. 1. Introduction nit: text mixes =93resource-owner=94 and =93resource owner=94. I think =93resource owner=94 is correct. consider adding bullet point: Compromise of any third-party application server results in compromise of the user=92s password and all of the data protected by that password. nit: =93web end-user=94 is an odd turn of phrase. Maybe just =93end user= =94 1.1 Roles nit: =93- access restricted resources which require authentication to access:=94 seems awkward. could eliminate the phrase entirely and make the meaning of the paragraph just as obvious. 1.4.1 Authorization Code maybe expand the section on important security benefits. =93The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.=94 1.4.2 nit: =93intermediary authorization grant=94. I think =93intermediate=94 is the right term here, but might be wrong. 1.5 Refresh Token =93self-contain the authorization information in a verifiable manner.=94 That is never secure, because it makes review of issued permissions and revocation of those permissions impossible. Refresh tokens are different than access tokens; a refresh token is always going to be an identifier that you use to look up authorization information. The text should be: =93The token denotes an identifier used to retrieve the authorization information.=94 (As another example of why you can=92t have a self-verifying refresh token, consider the role of the client id and client secret in the protocol. If refresh tokens were self-verifying, you would also need bake the client secret into the refresh token, thus making client secret rotation impractical.) nit: =93..., no longer valid, =85=94 doesn=92t make sense. I think the tex= t should be =93or is no longer valid.=94 The parenthetical phrase throws off this paragraph a bit, maybe rephrase as =93The refresh token can be used to obtain a new access token when the current access token becomes invalid or expires, or to obtain addtional access tokens with identical or narrower scope. (Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.) Should also add, maybe in the second paragraph: =93Unlike access tokens, refresh tokens are intended for use only with authorization servers. Refresh tokens are never sent to resource servers.=94 3. Client Authentication I like the compromise reached here on the language around client secrets for installed app clients. It doesn=92t reflect reality, but the language allows enough wiggle room to be practical. The spirit of the text is quite sensible, which is what I like best. 3.1 Client Password Authentication Referring to a password as a shared symmetric secret is misleading. =93Symmetric secret=94 is used almost exclusively with secret key cryptography, where both sides store copies of the secret. That=92s not the right way to use client passwords; they should be treated like *passwords*, not HMAC keys or encryption keys. The reference to needing consensus on when to use basic auth and when to use client_id and client_secret parameters seems quite reasonable. The current language seems to reflect a poor compromise that will make interoperable implementations less likely for no good reason. I=92d rather that someone picked a winner and the spec was simple and consistent. 3.2 Other Client Authentication Methods Again, I like the compromise here. The language is vague but useful. 4.1.1. Authorization Request Please add =93state=94 to the example. =93state=94 is an important part of= a secure client implementation, might as well encourage use by including it in examples. 4.1.2 Authorization Response =93minimize the risk of leaks=94: this should be =93mitigate=94, not =93min= imize=94. =93SHOULD expire shortly=94. This should be a MUST. The security analysis of the protocol doesn=92t hold unless authorization codes expire. Suggested language: =93The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED.=94 Again, please include =93state=94 in the example. 4.1.2.1 Error Response =93and MUST NOT redirect=94... this is contrary to some industry practice. Various service providers show an interstitial to warn the user, but will then redirect if the user clicks through the interstitial. How about =93and MUST NOT automatically redirect=94 as alternative language. The language around using HTTP status codes as values for the =93error=3D= =94 parameter is surprising. Who requested that? Has anyone implemented that? Why is this a good idea? Again, example including =93state=94 parameter would be a good thing. 4.2 Implicit Grant nit: The phrase =93...maintaining their client credentials confidential...=94is a bit awkward. This should probably be =93maintaining the confidentiality of their client credentials...=94 The introductory paragraph says the flow is suitable for clients that can=92t keep their client credentials secret. However, that=92s not sufficient. In addition, the client must be able to maintain the security of a redirect URI via something like the browser same-origin policy. Suggested language: =93The implicit grant type is suitable for clients that cannot maintain the confidentiality of their client credentials, but which can be known to operate on a particular redirect URI.=94 These applications are typically implemented in a browser using a scripting language such as JavaScript. nit in step (D): =93(does not include the fragment).=94 should be =93(which does not include the fragment).=94 4.2.1 Authorization Request Please include =93state=94 in example. Validation of the redirect_uri parameter is more important for the implicit grant type. Section 2.1.1 leaves registration of the redirect URI as =93SHOULD=94. It=92s a =93MUST=94 for the implicit flow. Suggested language: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the authorization code matches a redirect URI pre-registered by the client. The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. The authorization server MAY verify the query parameters as well. 4.2.2. Access Token Response Please include =93state=94 in example. 4.3 Resource Owner Password Credentials nit: =93converting the stored credentials with an access token=94 should be =93... to an access token.=94 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passw= ords. 4.4 Client Credentials The spec has this flow returning a refresh token. This is a security problem. We agreed to remove it or at least recommend against it almost a year ago. Thread here: http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html General comments on HTTP headers. Should follow cache header recommendations from HTTP/1.1 spec for backwards compatibility with HTTP/1.0 caching proxies. This means adding =93Pragma: no-cache=94 to all responses. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32. Should include charset in all content-type examples, to prevent security problems due to content sniffing. See http://code.google.com/p/browsersec/wiki/Part2#Survey_of_content_sniffing_b= ehaviors. For example: Content-Type: application/json; charset=3DUTF-8 6. Refreshing an Access Token nit: should mention that when the authorization server returns a new refresh token, they are going to revoke the old one as well. How about: =93The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after returning the new refresh token to the client.=94 Section 8.2 Defining New Endpoint Parameters Telling service providers to use vendor specific prefixes for query parameters sent to their web page is just not going to get implemented. Every service provider has a collection of long-established query parameters that they use on all or almost all of their web pages. That includes their authorization pages. Section 10. Security Considerations I love the introduction here, this is an excellent break down of the different client types, and I=92ve never seen anyone else do it so concisely. One nit: I don=92t think the statement =93It is assumed that such an application can protect dynamically issued credentials, such as refresh tokens, from eavesdropping by other applications residing on the same device=94 is actually essential to the security analysis, and it rules out a large class of applications (e.g. everything on Windows or MacOS.) Maybe change the section on Native Applications to say =93It is assumed that any client authentication credentials included in the application can be extracted, and furthermore that rotation of the client authentication credentials is not practical. Dynamically issued credentials such as refresh tokens, on the other hand, can receive an acceptable level of protection. At a minimum those credentials are protected from hostile servers which the client may contact. On some platform those credentials might be protected from other applications residing on the same device.=94 There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsid= erations/OAuthWRAP2.0SecurityConsiderations.pdf Section 10.1 Client Authentication nit: =93MUST NOT issue client passwords to installed apps=94 is a dead letter, it is not going to change standard industry practice in the slightest. The language from section 3 is more constructive. I=92d suggest the following language for section 10.1 instead =93The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.=94 That does conform with industry practice, so it=92s more likely to be imple= mented. =93The authorization server is encouraged to consider using stronger client authentication means than a client password.=94 Could make that more specific by adding =93, such as assertions as per =94 Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for =93immediate mode=94, where authorization requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. 10.3 Access Token Credentials =93When using the implicit grant type, the access token credentials are transmitted in the URI fragment, which can expose the credentials to unauthorized parties.=94 That=92s basically FUD. This should be made much more specific. It falls into the general category of security considerations for redirectors and clients... 10.5 Request Confidentiality. Why not specify TLS here, as is done elsewhere in the spec? 10.6 Endpoint Authenticity nit: =93server-side authentication=94 should be =93server authentication=94 (copying language from the TLS spec...) nit: should refer to RFC 2818 for server authentication rules 10.9 Authorization Codes =93SHOULD be short lived and MUST be single use=94 is backwards. These MUST be short-lived. If they are long-lived, an attacker who compromises an end-user account even temporarily can mint a very large number of these tokens and replay them later as needed. MUST be single use is a dead letter, because it requires atomic operations at scale. Even things like password changes are not atomic in user databases of moderate size. Authorization codes might be generated quite frequently (e.g. when =93immediate mode=94 flows are used), so a MUST for an atomic operation is unrealistic. nit: =93Authorization codes operate as plaintext bearer credentials, used to verify that the end-user who granted authorization at the authorization server, is the same end-user returning to the client to complete the process.=94 That assumes that the user visited the client to trigger the authorization. That=92s not always realistic, see the =93unsolicited authentication response=94 from the SAML 2 protocol for examples of other protocols where this is common. 10.10 Session Fixation I=92m not sure about the attack being described here. Some of the mitigations make it sound like the attack described is session hijacking, not session fixation. If the mitigations mentioned the state parameter, then I would think that the attack described was session fixation at the client, but that doesn=92t come up. Can someone explain the attack in greater detail? 10.12 Resource Owner Password Credentials Really like this section, nicely put. =3D) After reading through the security considerations section a couple of times, I think it could benefit from a different organization. Specifically - keep the introduction, it=92s awesome. - write new sections for each of the following 1) Authorization Tokens 2) Web Application Clients 3) User-Agent Clients 4) Installed Application Clients 5) Authorization Servers 6) Resource Servers - merge the current recommendations (which are very sensible) into the appropriate sections. Just for kicks I started to write up security considerations for authorization tokens. I'll send that to the list separately. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon May 23 03:08: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 10D82E06E6 for ; Mon, 23 May 2011 03:08: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=[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 KPYTpJwjiVnX for ; Mon, 23 May 2011 03:08:27 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id 2A874E06A7 for ; Mon, 23 May 2011 03:08:27 -0700 (PDT) Received: from mail-pv0-f175.google.com ([74.125.83.175]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKTdoyGVHPRlsU9PgoBUSvIKnAZMqiyOaj@postini.com; Mon, 23 May 2011 03:08:27 PDT Received: by mail-pv0-f175.google.com with SMTP id 30so2551492pvc.6 for ; Mon, 23 May 2011 03:08:25 -0700 (PDT) Received: by 10.68.65.68 with SMTP id v4mr2059296pbs.158.1306141920444; Mon, 23 May 2011 02:12:00 -0700 (PDT) Received: from [192.168.1.2] (c-67-180-211-155.hsd1.ca.comcast.net [67.180.211.155]) by mx.google.com with ESMTPS id v9sm4224143pbk.17.2011.05.23.02.11.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 02:11:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA902@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 23 May 2011 02:11:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <330DED4F-E080-433B-93E8-1CEA9D68BD78@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA902@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-04 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 10:08:28 -0000 You may have noticed, on page 8 the host is listed as "example.net" - = should be example.com, I believe. (draft v5) All in all, I'm in support of the changes in v2. Certainly addresses my = hesitations from v2. skylar On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote: > (Please discuss this draft on the Apps-Discuss = mailing list) >=20 > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >=20 > While this document has moved to the Apps-Discuss mailing list for the = time being, I wanted to give a quick update to those who have been = following this draft which originated on this list. >=20 > The major changes since -02 are: >=20 > * Removed OAuth terminology and association. The draft is now a = general purpose HTTP authentication scheme. It does include an OAuth 2.0 = binding which is described in less than a page. One suggestion would be = to move section 5.1 into the OAuth specification and drop all the OAuth = 2.0 text from the MAC draft. >=20 > * Added 'Set-Cookie' extension for using MAC with session cookies. >=20 > * Removed request URI query normalization. The new draft uses the raw = request URI unchanged. >=20 > * Replaced timestamps with credentials age to remove the need for = clock sync. >=20 > * Added a placeholder for extension, allowing random text to be = included in the request and MAC. >=20 > * Added issuer attribute for identifying the source of the credentials = as an additional protection. >=20 > Draft -04 is not compatible with previous drafts. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Mon May 23 07:25: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 0653FE07C1; Mon, 23 May 2011 07:25:48 -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 ZYfmNOZYvI1w; Mon, 23 May 2011 07:25:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CB0E07BF; Mon, 23 May 2011 07:25:46 -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.54 Message-ID: <20110523142546.22343.47633.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 07:25:46 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.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: Mon, 23 May 2011 14:25:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Authentication Protocol Working = Group of the IETF. Title : SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2= .0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-04.txt Pages : 13 Date : 2011-05-23 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-04.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-saml2-bearer-04.txt From bcampbell@pingidentity.com Mon May 23 07:33: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 C15B1E07AD for ; Mon, 23 May 2011 07:33:10 -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 eDWJhJZkfScU for ; Mon, 23 May 2011 07:33:09 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 87939E0792 for ; Mon, 23 May 2011 07:33:08 -0700 (PDT) Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTdpwI2qET1XsqKiQPh0HYGU2A6x/Rx81@postini.com; Mon, 23 May 2011 07:33:09 PDT Received: by mail-qy0-f180.google.com with SMTP id 10so3395919qyk.4 for ; Mon, 23 May 2011 07:33:07 -0700 (PDT) Received: by 10.224.33.12 with SMTP id f12mr1846805qad.228.1306161187125; Mon, 23 May 2011 07:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 23 May 2011 07:32:37 -0700 (PDT) In-Reply-To: <20110523142546.22343.47633.idtracker@ietfa.amsl.com> References: <20110523142546.22343.47633.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 23 May 2011 08:32:37 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-04.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: Mon, 23 May 2011 14:33:10 -0000 -04 is up already at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 and the changes are pretty minor: -- (from Appendix B. Document History) -- o Changed the grant_type URI from "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word assertion from the path. Recent versions of draft-ietf-oauth-v2 no longer refer to extension grants using the word assertion so this URI is more reflective of that. It also more closely aligns with the grant type URI in draft-jones-oauth-jwt-bearer-00 which is "http://oauth.net/grant_type/jwt/1.0/bearer". o Added "case sensitive" to scope definition to align with draft-ietf-oauth-v2-15/16. o Updated to reference draft-ietf-oauth-v2-16 Thanks, Brian ---------- Forwarded message ---------- From: Date: Mon, May 23, 2011 at 8:25 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Grant = Type Profile for OAuth 2.0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-04.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-23 =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as =A0 means for requesting an OAuth 2.0 access token. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-04.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-saml2-bearer-04.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon May 23 07:55: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 03A21E07C6 for ; Mon, 23 May 2011 07:55:22 -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 3aclOfjjiuVk for ; Mon, 23 May 2011 07:55:19 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 09B31E07B5 for ; Mon, 23 May 2011 07:55:18 -0700 (PDT) Received: from mail-qy0-f175.google.com ([209.85.216.175]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTdp1VovQllLnAtxil0PAnd6qkOhahTZZ@postini.com; Mon, 23 May 2011 07:55:19 PDT Received: by mail-qy0-f175.google.com with SMTP id 35so1068417qyk.6 for ; Mon, 23 May 2011 07:55:18 -0700 (PDT) Received: by 10.224.26.211 with SMTP id f19mr1814779qac.328.1306162133115; Mon, 23 May 2011 07:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 23 May 2011 07:48:23 -0700 (PDT) In-Reply-To: References: <20110523142546.22343.47633.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 23 May 2011 08:48:23 -0600 Message-ID: To: oauth , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.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: Mon, 23 May 2011 14:55:22 -0000 These changes touch on, but don't necessarily address, some questions/comments from Peter Saint-Andre raised a while back. Here's the last message in that thread: http://www.ietf.org/mail-archive/web/oauth/current/msg05741.html Peter (or anyone really), any additional thoughts on those items? Do they need to be addressed? The duplication of the scope definition and the appropriateness of the URI also apply to draft-jones-oauth-jwt-bearer-00 On Mon, May 23, 2011 at 8:32 AM, Brian Campbell wrote: > -04 is up already at > http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 and the > changes are pretty minor: > > -- (from Appendix B. Document History) -- > =A0 o =A0Changed the grant_type URI from > =A0 =A0 =A0"http://oauth.net/grant_type/assertion/saml/2.0/bearer" to > =A0 =A0 =A0"http://oauth.net/grant_type/saml/2.0/bearer" - dropping the w= ord > =A0 =A0 =A0assertion from the path. =A0Recent versions of draft-ietf-oaut= h-v2 > =A0 =A0 =A0no longer refer to extension grants using the word assertion s= o > =A0 =A0 =A0this URI is more reflective of that. =A0It also more closely a= ligns > =A0 =A0 =A0with the grant type URI in draft-jones-oauth-jwt-bearer-00 whi= ch > =A0 =A0 =A0is "http://oauth.net/grant_type/jwt/1.0/bearer". > > =A0 o =A0Added "case sensitive" to scope definition to align with > =A0 =A0 =A0draft-ietf-oauth-v2-15/16. > > =A0 o =A0Updated to reference draft-ietf-oauth-v2-16 > > Thanks, > Brian > > > ---------- Forwarded message ---------- > From: =A0 > Date: Mon, May 23, 2011 at 8:25 AM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Open Authentication > Protocol Working Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Gran= t Type Profile > for OAuth 2.0 > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-04= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-23 > > =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as > =A0 means for requesting an OAuth 2.0 access token. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-04.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-saml2-bearer-04.txt > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Mon May 23 08:23:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B36E0730 for ; Mon, 23 May 2011 08:23:14 -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 Igy3+2XDZ7Vu for ; Mon, 23 May 2011 08:23:13 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 789AEE06E0 for ; Mon, 23 May 2011 08:23:12 -0700 (PDT) Received: from mail-qy0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTdp73PE8atHImUsMeL2J3Kt3s7iU9EAb@postini.com; Mon, 23 May 2011 08:23:13 PDT Received: by mail-qy0-f176.google.com with SMTP id 30so3476668qyk.7 for ; Mon, 23 May 2011 08:23:08 -0700 (PDT) Received: by 10.224.104.141 with SMTP id p13mr1818791qao.128.1306164188064; Mon, 23 May 2011 08:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 23 May 2011 08:22:38 -0700 (PDT) From: Brian Campbell Date: Mon, 23 May 2011 09:22:38 -0600 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: [OAUTH-WG] security considerations in SAML-bearer spec (was RE: WGLC on draft-ietf-oauth-v2-bearer-03.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: Mon, 23 May 2011 15:23:14 -0000 I wanted to respond to this comment (sorry it's a few months later) to say that those security considerations are important but I believe they are already covered by the normative language in the SAML-bearer spec as well as the references to the SAML Core and the SAML Security and Privacy Considerations. On Wed, Mar 23, 2011 at 12:11 PM, Peter Saint-Andre wrote: > > ... > 6. It's nice to see the security considerations about attacks on tokens. > Perhaps we need a similar section in the SAML-bearer spec. > ... From d.tangren@gmail.com Mon May 23 08:36: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 1F967E06A3 for ; Mon, 23 May 2011 08:36:12 -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 rQ0Y9AFLkkEw for ; Mon, 23 May 2011 08:36:10 -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 23385E069E for ; Mon, 23 May 2011 08:36:09 -0700 (PDT) Received: by iwn39 with SMTP id 39so6316757iwn.31 for ; Mon, 23 May 2011 08:36:09 -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=eM6npuSKMtoq6xOqdQ0H67lgpFKf1U9s3Y++hXs6RRU=; b=vse0GyA2847oc+oRomf7T8wkFC2L734E8XqCHf34PsWFLQlHI8QCpvG/UlWigXskPL P9m6Ih3nQjqYIe8mw0phKFceW1Jq3hpbrLhl7jPx/4CsCWHbKtZ9UxQa8QRpYizl952s NOPr0fm5crGXBfFsf/HtfAGOHSxw36JuQfc5Y= 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=r8QisDMjZjDFcxJtwGDCz8kvXOj6GLFJkndrkZt1nrvpj4a/e3hbuSAmFLLukt/Ntp YXqps+IizyZfp8PP28WgThjVDL9UkQANM5LoGrwwZsplA8lUX4TubdZ9mN7tU8/OglrF ePxOnC+zBhBXfMkTSIGtAqtxjYGiehlhkMLpg= Received: by 10.42.141.202 with SMTP id p10mr2992124icu.124.1306164969129; Mon, 23 May 2011 08:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Mon, 23 May 2011 08:35:49 -0700 (PDT) In-Reply-To: References: From: Doug Tangren Date: Mon, 23 May 2011 11:35:49 -0400 Message-ID: To: David Recordon Content-Type: multipart/alternative; boundary=90e6ba6e8dc000c5d704a3f33bde Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 15:36:12 -0000 --90e6ba6e8dc000c5d704a3f33bde Content-Type: text/plain; charset=UTF-8 For those joining remotely does the meeting actually start @ 9 or 10. I looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's my lunch time. -Doug Tangren http://lessis.me On Sun, May 22, 2011 at 1:40 PM, David Recordon wrote: > If you're planning to attend in person then you'll want to head to > 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind > the building so feel free to park anywhere in that lot. You'll then > want to head to the lobby of building 1 which is the largest; the > lobby is on the Page Mill side. When you get there ask for either me > or the OAuth meeting. There's plenty of snack food and breakfast will > still be going on until 10. > > If you're joining remotely, you can do so either via video or audio > conference. To join, goto http://bluejeans.com/davidrecordon/ and > choose the OAuth meeting. > > Anything I missed? > > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --90e6ba6e8dc000c5d704a3f33bde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For those joining remotely does the meeting actually start @ 9 or 10. I loo= ks like there's an hour of breakfast at 9 (pst). I'm in nyc so that= 's my lunch time.

    -Doug Tangren
    http://lessis.me


    On Sun, May 22, 2011 at 1:40 PM, David R= ecordon <record= ond@gmail.com> wrote:
    If you're planning to attend in person then you'll want to head to<= br> 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind
    the building so feel free to park anywhere in that lot. You'll then
    want to head to the lobby of building 1 which is the largest; the
    lobby is on the Page Mill side. When you get there ask for either me
    or the OAuth meeting. There's plenty of snack food and breakfast will still be going on until 10.

    If you're joining remotely, you can do so either via video or audio
    conference. To join, goto http://bluejeans.com/davidrecordon/ and
    choose the OAuth meeting.

    Anything I missed?

    --David
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    --90e6ba6e8dc000c5d704a3f33bde-- From bcampbell@pingidentity.com Mon May 23 08:56: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 10713E0798 for ; Mon, 23 May 2011 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 6huyPEv14Fl6 for ; Mon, 23 May 2011 08:56:56 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id E02CAE067F for ; Mon, 23 May 2011 08:56:55 -0700 (PDT) Received: from mail-qy0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTdqDxAZVPNqPdwa65mlVs4FCTwXpejDh@postini.com; Mon, 23 May 2011 08:56:55 PDT Received: by mail-qy0-f176.google.com with SMTP id 30so3501069qyk.7 for ; Mon, 23 May 2011 08:56:52 -0700 (PDT) Received: by 10.224.218.72 with SMTP id hp8mr1964500qab.78.1306166212136; Mon, 23 May 2011 08:56:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 23 May 2011 08:56:22 -0700 (PDT) In-Reply-To: References: <20110523142546.22343.47633.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 23 May 2011 09:56:22 -0600 Message-ID: To: oauth , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.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: Mon, 23 May 2011 15:56:57 -0000 One more thing (that may be obvious) and assuming the URI change is okay, Eran, can you update the example post body in section 4.5 (http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.5) to reflect the URI change in the next draft? grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Thanks, Brian On Mon, May 23, 2011 at 8:48 AM, Brian Campbell wrote: > These changes touch on, but don't necessarily address, some > questions/comments from Peter Saint-Andre raised a while back. > > Here's the last message in that thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg05741.html > > Peter (or anyone really), any additional thoughts on those items? =A0Do > they need to be addressed? =A0The duplication of the scope definition > and the appropriateness of the URI also apply to > draft-jones-oauth-jwt-bearer-00 > > On Mon, May 23, 2011 at 8:32 AM, Brian Campbell > wrote: >> -04 is up already at >> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04 and the >> changes are pretty minor: >> >> -- (from Appendix B. Document History) -- >> =A0 o =A0Changed the grant_type URI from >> =A0 =A0 =A0"http://oauth.net/grant_type/assertion/saml/2.0/bearer" to >> =A0 =A0 =A0"http://oauth.net/grant_type/saml/2.0/bearer" - dropping the = word >> =A0 =A0 =A0assertion from the path. =A0Recent versions of draft-ietf-oau= th-v2 >> =A0 =A0 =A0no longer refer to extension grants using the word assertion = so >> =A0 =A0 =A0this URI is more reflective of that. =A0It also more closely = aligns >> =A0 =A0 =A0with the grant type URI in draft-jones-oauth-jwt-bearer-00 wh= ich >> =A0 =A0 =A0is "http://oauth.net/grant_type/jwt/1.0/bearer". >> >> =A0 o =A0Added "case sensitive" to scope definition to align with >> =A0 =A0 =A0draft-ietf-oauth-v2-15/16. >> >> =A0 o =A0Updated to reference draft-ietf-oauth-v2-16 >> >> Thanks, >> Brian >> >> >> ---------- Forwarded message ---------- >> From: =A0 >> Date: Mon, May 23, 2011 at 8:25 AM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-04.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Open Authentication >> Protocol Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Gra= nt Type Profile >> for OAuth 2.0 >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-0= 4.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-23 >> >> =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as >> =A0 means for requesting an OAuth 2.0 access token. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-04.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-saml2-bearer-04.txt >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From bcampbell@pingidentity.com Mon May 23 09:23: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 CAD72E06E0 for ; Mon, 23 May 2011 09:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.011, 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 KXmHtbjaKf9u for ; Mon, 23 May 2011 09:23:04 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4576AE0679 for ; Mon, 23 May 2011 09:23:04 -0700 (PDT) Received: from mail-qw0-f54.google.com ([209.85.216.54]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTdqJ5zXmhWhr7rZHYHHHCjwJ1b+7Z2OL@postini.com; Mon, 23 May 2011 09:23:04 PDT Received: by mail-qw0-f54.google.com with SMTP id 9so5047180qwc.27 for ; Mon, 23 May 2011 09:23:03 -0700 (PDT) Received: by 10.224.214.68 with SMTP id gz4mr869494qab.378.1306167782147; Mon, 23 May 2011 09:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.78 with HTTP; Mon, 23 May 2011 09:22:31 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 23 May 2011 10:22:31 -0600 Message-ID: To: Doug Tangren Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 16:23:10 -0000 Looks like they are starting now. On Mon, May 23, 2011 at 9:35 AM, Doug Tangren wrote: > For those joining remotely does the meeting actually start @ 9 or 10. I > looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's my > lunch time. > > -Doug Tangren > http://lessis.me > > > On Sun, May 22, 2011 at 1:40 PM, David Recordon wrote: >> >> If you're planning to attend in person then you'll want to head to >> 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind >> the building so feel free to park anywhere in that lot. You'll then >> want to head to the lobby of building 1 which is the largest; the >> lobby is on the Page Mill side. When you get there ask for either me >> or the OAuth meeting. There's plenty of snack food and breakfast will >> still be going on until 10. >> >> If you're joining remotely, you can do so either via video or audio >> conference. To join, goto http://bluejeans.com/davidrecordon/ and >> choose the OAuth meeting. >> >> Anything I missed? >> >> --David >> _______________________________________________ >> 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 d.tangren@gmail.com Mon May 23 09:25: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 11B7CE07C4 for ; Mon, 23 May 2011 09:25:24 -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 SX0dApTIFfOn for ; Mon, 23 May 2011 09:25:20 -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 94DB7E07B0 for ; Mon, 23 May 2011 09:25:20 -0700 (PDT) Received: by gxk19 with SMTP id 19so895884gxk.31 for ; Mon, 23 May 2011 09:25:20 -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=0oLS2Wiec5IgstoiMKLEjkbEey2ZSorEj88CeQEk7Wg=; b=M+MfTKa5l2F4UJyZbOJgOkwupALdZE2PE5h/tLm5B2yh6FdrtKVCC34aswK/fiwlmH 4k2rHyepczB1WaO/dbvWzNJ/jqRvgKfzsIpj/4kNWavG/xOdxpGGK6kcsdKbHkEXm6KY P2eTlnq03iG98lQUsBFtwvF0gUIQsdk18uiV0= 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=PBOTt1/O75r3JviAMicFB6pKHNLDxMcnHwJLosOzs4TRDM5N+Kruzkre39w6GhQZSJ ZxNQkWRFsBeAc//4YxDEtn58d812qnh0w4TEC99IpHhvHXkfcdvgis+UqPy4uh1gsdfP 1/7e3YxKMZWDkHuBWw27jfdH4QQuqw0MWpSJw= Received: by 10.42.243.7 with SMTP id lk7mr8410343icb.191.1306167919074; Mon, 23 May 2011 09:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Mon, 23 May 2011 09:24:59 -0700 (PDT) In-Reply-To: References: From: Doug Tangren Date: Mon, 23 May 2011 12:24:59 -0400 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=90e6ba3fcc1fd55cfb04a3f3ea01 Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 16:25:24 -0000 --90e6ba3fcc1fd55cfb04a3f3ea01 Content-Type: text/plain; charset=UTF-8 ok. I'll going to run for lunch and sneak quietly in on the conf call ~ 10 (1 for me). -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 12:22 PM, Brian Campbell wrote: > Looks like they are starting now. > > On Mon, May 23, 2011 at 9:35 AM, Doug Tangren wrote: > > For those joining remotely does the meeting actually start @ 9 or 10. I > > looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's > my > > lunch time. > > > > -Doug Tangren > > http://lessis.me > > > > > > On Sun, May 22, 2011 at 1:40 PM, David Recordon > wrote: > >> > >> If you're planning to attend in person then you'll want to head to > >> 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind > >> the building so feel free to park anywhere in that lot. You'll then > >> want to head to the lobby of building 1 which is the largest; the > >> lobby is on the Page Mill side. When you get there ask for either me > >> or the OAuth meeting. There's plenty of snack food and breakfast will > >> still be going on until 10. > >> > >> If you're joining remotely, you can do so either via video or audio > >> conference. To join, goto http://bluejeans.com/davidrecordon/ and > >> choose the OAuth meeting. > >> > >> Anything I missed? > >> > >> --David > >> _______________________________________________ > >> 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 > > > > > --90e6ba3fcc1fd55cfb04a3f3ea01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ok. I'll going to run for lunch and sneak quietly in on the conf call ~= 10 (1 for me).=C2=A0

    -Doug Tangren
    http://lessis.me


    On Mon, May 23, 2011 at 12:22 PM, Brian = Campbell <bcampbell@pingidentity.com> wrote:
    Looks like they are starting now.

    On Mon, May 23, 2011 at 9:35 AM, Doug Tangren <d.tangren@gmail.com> wrote:
    > For those joining remotely does the meeting actually start @ 9 or 10. = I
    > looks like there's an hour of breakfast at 9 (pst). I'm in nyc= so that's my
    > lunch time.
    >
    > -Doug Tangren
    > http://lessis.me >
    >
    > On Sun, May 22, 2011 at 1:40 PM, David Recordon <recordond@gmail.com> wrote:
    >>
    >> If you're planning to attend in person then you'll want to= head to
    >> 1050 Page Mill Road in Palo Alto. There's a bunch of parking b= ehind
    >> the building so feel free to park anywhere in that lot. You'll= then
    >> want to head to the lobby of building 1 which is the largest; the<= br> >> lobby is on the Page Mill side. When you get there ask for either = me
    >> or the OAuth meeting. There's plenty of snack food and breakfa= st will
    >> still be going on until 10.
    >>
    >> If you're joining remotely, you can do so either via video or = audio
    >> conference. To join, goto http://bluejeans.com/davidrecordon/ and
    >> choose the OAuth meeting.
    >>
    >> Anything I missed?
    >>
    >> --David
    >> _______________________________________________
    >> 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
    >
    >

    --90e6ba3fcc1fd55cfb04a3f3ea01-- From d.tangren@gmail.com Mon May 23 10:30: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 C467DE06EA for ; Mon, 23 May 2011 10:30:12 -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 cJB1fzxdtK3n for ; Mon, 23 May 2011 10:30:11 -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 AE8C8E0670 for ; Mon, 23 May 2011 10:30:11 -0700 (PDT) Received: by iwn39 with SMTP id 39so6433435iwn.31 for ; Mon, 23 May 2011 10:30:11 -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=Dj9eqziRH3p36h1J/A/YTcZRIZzaUcLTXdoMSLlt5Co=; b=MnaadfKTEiqjxlHEEa9EVCb8Ak1M7W/XTeiGaS5BpGVb78naPhj2dB44DT0j7zlvlK Ol5JFKLZNXvK3psENQv0Nsv+KW6W4bUr2573SRf5sLOBciUTU3uAcHkWUeHO0/uMYULg zYbfwyVX2lC4oq5QI1aAICBLqIUlr0dBuUCz0= 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=ETKE+91u1Ln0Qr2bHlWuBD6uriJFjcJME1eJHl9R5IDPJe/jnnRzMX61X7U3ZOBcoC EKRe/+WNN1DwPav1SJAaPhqkg/yh5dzry6hEsUzCNBlaSSISeoOWoSL7Q5KwoyxcxY8N V4Qvb8Va6kseeVaVApwaWdEau5x3cEzLPAv5o= Received: by 10.42.243.7 with SMTP id lk7mr8503930icb.191.1306171811039; Mon, 23 May 2011 10:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Mon, 23 May 2011 10:29:50 -0700 (PDT) In-Reply-To: References: From: Doug Tangren Date: Mon, 23 May 2011 13:29:50 -0400 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=90e6ba3fcc1fd00c0b04a3f4d253 Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 17:30:12 -0000 --90e6ba3fcc1fd00c0b04a3f4d253 Content-Type: text/plain; charset=UTF-8 Im on skype, and the audio is kind of choppy. with regard to the status codes as error values, which is the proper error code to use when an access token expires. Can someone bring that question up? Also, is there an irc channel to log into for this meeting. I may be easier to type in my comments -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 12:24 PM, Doug Tangren wrote: > ok. I'll going to run for lunch and sneak quietly in on the conf call ~ 10 > (1 for me). > > -Doug Tangren > http://lessis.me > > > On Mon, May 23, 2011 at 12:22 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Looks like they are starting now. >> >> On Mon, May 23, 2011 at 9:35 AM, Doug Tangren >> wrote: >> > For those joining remotely does the meeting actually start @ 9 or 10. I >> > looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's >> my >> > lunch time. >> > >> > -Doug Tangren >> > http://lessis.me >> > >> > >> > On Sun, May 22, 2011 at 1:40 PM, David Recordon >> wrote: >> >> >> >> If you're planning to attend in person then you'll want to head to >> >> 1050 Page Mill Road in Palo Alto. There's a bunch of parking behind >> >> the building so feel free to park anywhere in that lot. You'll then >> >> want to head to the lobby of building 1 which is the largest; the >> >> lobby is on the Page Mill side. When you get there ask for either me >> >> or the OAuth meeting. There's plenty of snack food and breakfast will >> >> still be going on until 10. >> >> >> >> If you're joining remotely, you can do so either via video or audio >> >> conference. To join, goto http://bluejeans.com/davidrecordon/ and >> >> choose the OAuth meeting. >> >> >> >> Anything I missed? >> >> >> >> --David >> >> _______________________________________________ >> >> 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 >> > >> > >> > > --90e6ba3fcc1fd00c0b04a3f4d253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Im on skype, and the audio is kind of choppy. with regard to the status cod= es as error values, which is the proper error code to use when an access to= ken expires. Can someone bring that question up?

    Also, i= s there an irc channel to log into for this meeting. I may be easier to typ= e in my comments


    -Doug Tangren
    http://lessis.me


    On Mon, May 23, 2011 at 12:24 PM, Doug T= angren <d.tangr= en@gmail.com> wrote:
    ok. I'll going to run for lunch and sneak quietly in on the conf call ~= 10 (1 for me).=C2=A0

    -Doug Tangren=
    http://lessis.me


    = On Mon, May 23, 2011 at 12:22 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
    Looks like they are starting now.

    On Mon, May 23, 2011 at 9:35 AM, Doug Tangren <d.tangren@gmail.com> wrote:
    > For those joining remotely does the meeting actually start @ 9 or 10. = I
    > looks like there's an hour of breakfast at 9 (pst). I'm in nyc= so that's my
    > lunch time.
    >
    > -Doug Tangren
    > http://lessis.me >
    >
    > On Sun, May 22, 2011 at 1:40 PM, David Recordon <recordond@gmail.com> wrote: >>
    >> If you're planning to attend in person then you'll want to= head to
    >> 1050 Page Mill Road in Palo Alto. There's a bunch of parking b= ehind
    >> the building so feel free to park anywhere in that lot. You'll= then
    >> want to head to the lobby of building 1 which is the largest; the<= br> >> lobby is on the Page Mill side. When you get there ask for either = me
    >> or the OAuth meeting. There's plenty of snack food and breakfa= st will
    >> still be going on until 10.
    >>
    >> If you're joining remotely, you can do so either via video or = audio
    >> conference. To join, goto http://bluejeans.com/davidrecordon/ and
    >> choose the OAuth meeting.
    >>
    >> Anything I missed?
    >>
    >> --David
    >> _______________________________________________
    >> 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
    >
    >


    --90e6ba3fcc1fd00c0b04a3f4d253-- From stpeter@stpeter.im Mon May 23 10:36: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 4328FE0799 for ; Mon, 23 May 2011 10:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 syFGj3j88-OT for ; Mon, 23 May 2011 10:36:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 50BB2E06F1 for ; Mon, 23 May 2011 10:36:44 -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 5C9EA40046; Mon, 23 May 2011 11:36:43 -0600 (MDT) Message-ID: <4DDA9B29.6090109@stpeter.im> Date: Mon, 23 May 2011 11:36: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: Doug Tangren References: 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="------------ms080004040002030607020209" Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 17:36:45 -0000 This is a cryptographically signed message in MIME format. --------------ms080004040002030607020209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/23/11 11:29 AM, Doug Tangren wrote: > Im on skype, and the audio is kind of choppy.=20 I'm dialed in via PSTN and it's not bad. > with regard to the status > codes as error values, which is the proper error code to use when an > access token expires. Can someone bring that question up? >=20 > Also, is there an irc channel to log into for this meeting. I may be > easier to type in my comments Probably good to use the Jabber room for this working group: xmpp:oauth@jabber.ietf.org I'm in that room but no one else is at the moment. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080004040002030607020209 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy MzE3MzY0MVowIwYJKoZIhvcNAQkEMRYEFNTmmvZazuqrpJ0sfDJok2fiLHZ9MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAX0/rRihKWk4eIT1h0Ua48lw+5YHudGJO7McugtzoLKXlS5NVZ/ckih13X WSG0akRoQKpictB99EhdbR1CQCqq6JQ261hzurm7h18czCYl7eYbC1MY2jZvkViZYmctj2DZ t+IXFwvwVVSYlzkFCe8wm2mU7c2y9MFT/u1iYwh+vVj+Wann5VEqR7Tln/Ge8N4Yrpf93sJA 6W5miqryjAjIlWfgznF69VqavUzeFHsqOxdMa7o18nfV73Qx0iRVZgh2zmPnwOsb6K+TIWv3 inqASeuJrie8lzk/mi8UWJnS64//JfLbsTZGP4JPDPLxV1FKndaZVEMFJ9atcirGe3FTAAAA AAAA --------------ms080004040002030607020209-- From mscurtescu@google.com Mon May 23 10:47: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 045A6E0689 for ; Mon, 23 May 2011 10:47:28 -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 Mq1AxL2XhOLh for ; Mon, 23 May 2011 10:47:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 81C83E065D for ; Mon, 23 May 2011 10:47:26 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p4NHlP4t003563 for ; Mon, 23 May 2011 10:47:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306172845; bh=nOOq1SUuPo3MZf4yS/2ByIljOwg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IsIpCYT0Fo1M2s5Gj1hZFUzD7mCVN62FTC6bcGLIzqDNebn+OSjJv6XyLKzd/1ci7 JA0ILK6flgdPYgoSIARQw== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by hpaq13.eem.corp.google.com with ESMTP id p4NHkRRo003050 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 May 2011 10:47:23 -0700 Received: by gxk22 with SMTP id 22so2829251gxk.2 for ; Mon, 23 May 2011 10:47: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:from:date :message-id:subject:to:cc:content-type; bh=sGQfqb4f5xRmzTkV8JCFIUcgidmb3LhGIhPvUkoOmiY=; b=Om1b2k9xBuHEB2GIlNeynU/oGl+YFtHeMpR5NJzwCLNvaRz8th5DrqT/Cj2BmnvnXb gutGgq/6bG9IV4PdYXtg== 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=yRA3DhJD24SNTTggtcb/5aNo1mVXoWLoKbhXyRKZPwJnkK4XHdsvUJMEZCKeQa9pj/ j4X9Cf+Gpiga1wawX91Q== Received: by 10.100.201.3 with SMTP id y3mr4582663anf.13.1306172843228; Mon, 23 May 2011 10:47:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.6 with HTTP; Mon, 23 May 2011 10:47:03 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Mon, 23 May 2011 10:47:03 -0700 Message-ID: To: Doug Tangren Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 17:47:28 -0000 On Mon, May 23, 2011 at 10:29 AM, Doug Tangren wrote: > Im on skype, and the audio is kind of choppy. with regard to the status > codes as error values, which is the proper error code to use when an access > token expires. Can someone bring that question up? The error code would be "invalid_token", from the bearer token spec. Marius From d.tangren@gmail.com Mon May 23 10:50: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 67CCDE0689 for ; Mon, 23 May 2011 10:50:01 -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 MXzmG7amm01u for ; Mon, 23 May 2011 10:50:01 -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 CF570E0670 for ; Mon, 23 May 2011 10:50:00 -0700 (PDT) Received: by ywp31 with SMTP id 31so2735022ywp.31 for ; Mon, 23 May 2011 10:50:00 -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=nBGzBX/2VeL8DRifjApoJkclQsyqOYu1L7+PH9fFqXg=; b=dQwboa6hZAJyRtbQqxFyngArRx2Y8hszrDlraGZikQsTkOOG0w2e2XGI8BV+/gwK6h +h1xdgwq9XKwOySCoPLQBT5m99V3fzkbcWhdJAm3P8FP9GH+9AQTjDcLF2aZ5GCwE+1p o3YtrZbsHXf4oWjiCLxQgO5G4342BdVIoGKZM= 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=JqkijXPA+9dcJgQzI2vXq0wG4PYyUPe5sEdu/v4TMGDvTF+NKw2DQitrBMlbvyVtez b16AJC5x64XPwoxrlwEIikIaVaXLcfmhHjpWZaru2cge4ZikJXHScCohUTebyorY1Tbo Zgc65UP23kqVhFvjBRX02nXQ0KBWskLALxj0g= Received: by 10.42.132.129 with SMTP id d1mr8451622ict.526.1306173000137; Mon, 23 May 2011 10:50:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.158.74 with HTTP; Mon, 23 May 2011 10:49:40 -0700 (PDT) In-Reply-To: References: From: Doug Tangren Date: Mon, 23 May 2011 13:49:40 -0400 Message-ID: To: Marius Scurtescu Content-Type: multipart/alternative; boundary=90e6ba3fcec5b03af004a3f519fc Cc: OAuth WG Subject: Re: [OAUTH-WG] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 17:50:01 -0000 --90e6ba3fcec5b03af004a3f519fc Content-Type: text/plain; charset=UTF-8 Thanks It would be nice to have in http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-6 -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 1:47 PM, Marius Scurtescu wrote: > On Mon, May 23, 2011 at 10:29 AM, Doug Tangren > wrote: > > Im on skype, and the audio is kind of choppy. with regard to the status > > codes as error values, which is the proper error code to use when an > access > > token expires. Can someone bring that question up? > > The error code would be "invalid_token", from the bearer token spec. > > > Marius > --90e6ba3fcec5b03af004a3f519fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks It would be nice to have in=C2=A0http://tools.ietf.org/html/draft-ietf-= oauth-v2-16#section-6

    -Doug Tangren
    http://lessis.me


    On Mon, May 23, 2011 at 1:47 PM, Marius = Scurtescu <ms= curtescu@google.com> wrote:
    On Mon, May 23, 2011 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:
    > Im on skype, and the audio is kind of choppy. with regard to the statu= s
    > codes as error values, which is the proper error code to use when an a= ccess
    > token expires. Can someone bring that question up?

    The error code would be "invalid_token", from the bearer to= ken spec.


    Marius

    --90e6ba3fcec5b03af004a3f519fc-- From mscurtescu@google.com Mon May 23 10:57: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 EC15AE077F for ; Mon, 23 May 2011 10:57:50 -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 fnw8JfvH2oxx for ; Mon, 23 May 2011 10:57:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7FE077C for ; Mon, 23 May 2011 10:57:49 -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 p4NHvmAV006365 for ; Mon, 23 May 2011 10:57:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306173468; bh=oSmr+73UTz2hgHAZXaQKnMN3p/8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=QJ7s1c1bq/YLyYsWCuYuBA0Pkv8WYddS2yz9ofw5R56GCoZU1cT1z2xghimMuckkN 2jxeo4pQPYtFXtY52lcwQ== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by hpaq12.eem.corp.google.com with ESMTP id p4NHvkn5028024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 May 2011 10:57:47 -0700 Received: by gwaa12 with SMTP id a12so2879327gwa.14 for ; Mon, 23 May 2011 10:57: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=qabwA6tnRCVpOfjfNXD4UXp2ar7/PuhXj5MA1cCb3ZU=; b=Mn1XSavq5Cd8FbKONA4W287fXJSmMHN23YuY1ZUgKf9q8lzkMBJZG240HShwsjcfO7 9J5GwILT+CGhJtAoBTcA== 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=bJVFAmwqtkAUYddLYLcqmdQlO+76REeknuBdE8OlKVod8MiOmO5CxW/7Gk+p+6rwL8 XflD/3VQ283wlfamQtgA== Received: by 10.101.136.4 with SMTP id o4mr4479504ann.145.1306173466169; Mon, 23 May 2011 10:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.6 with HTTP; Mon, 23 May 2011 10:57:26 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Mon, 23 May 2011 10:57:26 -0700 Message-ID: To: Doug Tangren 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] See everyone in the morning X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 17:57:51 -0000 On Mon, May 23, 2011 at 10:49 AM, Doug Tangren wrote: > Thanks It would be nice to have > in=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-6 Section 6 is about using a refresh token to get a new access token. Expired access tokens don't make sense in this case. Using access tokens to access protected resources is described in the bearer and mac specs, so the error codes for invalid access tokens belong there. Marius From igor.faynberg@alcatel-lucent.com Mon May 23 11:14: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 BA483E07AF for ; Mon, 23 May 2011 11:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhWoqDnDbh5s for ; Mon, 23 May 2011 11:14:56 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A1E07A1 for ; Mon, 23 May 2011 11:14:55 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4NIEsL5000648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 May 2011 13:14:54 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4NIEsv8017872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 May 2011 13:14:54 -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 p4NIEsnK025943; Mon, 23 May 2011 13:14:54 -0500 (CDT) Message-ID: <4DDAA41E.7080301@alcatel-lucent.com> Date: Mon, 23 May 2011 14:14:54 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OAuth WG 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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [OAUTH-WG] Session Fixation Attack Explained 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, 23 May 2011 18:14:56 -0000 As promised, here is a good description: http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/. Igor From Michael.Jones@microsoft.com Mon May 23 11:38: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 D3601E07AC for ; Mon, 23 May 2011 11:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.098 X-Spam-Level: X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 6JLCSVVVLoPc for ; Mon, 23 May 2011 11:38:16 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id C7694E07A9 for ; Mon, 23 May 2011 11:38:16 -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; Mon, 23 May 2011 11:38:16 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0289.008; Mon, 23 May 2011 11:38:16 -0700 From: Mike Jones To: Doug Tangren , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] consistency of token param name in bearer token type Thread-Index: AQHMEGLvUtk/Y41LJU+xw7NH/M+2opSa0CjQ Date: Mon, 23 May 2011 18:38:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943380F6A46TK5EX14MBXC203r_" 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: Mon, 23 May 2011 18:38:17 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943380F6A46TK5EX14MBXC203r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBkZWNpZGVkIHRoYXQgYSBkaWZmZXJlbnQgbmFt ZSBzaG91bGQgYmUgdXNlZCwgdG8gbWFrZSBpdCBjbGVhciB0aGF0IG90aGVyIHRva2VuIHR5cGVz IG90aGVyIHRoYW4gYmVhcmVyIHRva2VucyBjb3VsZCBhbHNvIGJlIHVzZWQgd2l0aCBPQXV0aCAy Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRG91ZyBUYW5ncmVuDQpTZW50OiBX ZWRuZXNkYXksIE1heSAxMSwgMjAxMSAxMDowOSBQTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBbT0FVVEgtV0ddIGNvbnNpc3RlbmN5IG9mIHRva2VuIHBhcmFtIG5hbWUgaW4gYmVhcmVy IHRva2VuIHR5cGUNCg0KVGhpcyBtYXkgaGF2ZSBjb21lIHVwIGJlZm9yZSBzbyBJJ20gc29ycnkg aWYgSSdtIHJlcGVhdGluZy4gV2h5IGRvZXMgYmVhcmVyIHRva2VuIHNwZWMgaW50cm9kdWNlIGEg bmV3IG5hbWUgZm9yIG9hdXRoMiBhY2Nlc3MgdG9rZW5zIFsxXSwgImJlYXJlcl90b2tlbiIsIGFu ZCBiZWZvcmUgdGhhdCBbMl0sICJvYXV0aF90b2tlbiI/DQoNCkkgYXBvbG9naXplIGlmIHRoaXMg bWF5IHNvdW5kIHNoYWxsb3cgYnV0LCB3aHkgaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlciBuYW1l IHZlcnNlcyBzdGlja2luZyB3aXRoIHdoYXQgdGhlIGdlbmVyYWwgb2F1dGgyIHNwZWMgYWxyZWFk eSBkZWZpbmVzLCAiYWNjZXNzX3Rva2VuIi4gSXQgc2VlbXMgYXJiaXRyYXJ5IGZvciBhbiBhdXRo IHNlcnZlciB0byBoYW5kIGEgY2xpZW50IGFuIGFwcGxlIHRoZW4gaGF2ZSB0aGUgY2xpZW50IGhh bmQgaXQgb2ZmIHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGNhbGwgaXQgYW4gb3JhbmdlLg0K DQpXYXMgdGhpcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBkaWZmZXJlbnRpYXRpbmcgdGhlIHBhcmFt ZXRlciBuYW1lIGVub3VnaCBzbyB0aGF0IHRoZSBiZWFyZXIgdG9rZW5zIG1heSBiZSB1c2VkIGlu IG90aGVyIHByb3RvY29scyB3aXRob3V0IGJlaW5nIGNvbmZ1c2VkIHdpdGggb2F1dGgyIGFjY2Vz c190b2tlbnM/DQoNClsxXTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC12Mi1iZWFyZXItMDQjc2VjdGlvbi0yLjINClsyXTogaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDMjc2VjdGlvbi0yLjINCg0KLURvdWcg VGFuZ3Jlbg0KaHR0cDovL2xlc3Npcy5tZQ0K --_000_4E1F6AAD24975D4BA5B1680429673943380F6A46TK5EX14MBXC203r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhlIHdvcmtpbmcgZ3Jv dXAgZXhwbGljaXRseSBkZWNpZGVkIHRoYXQgYSBkaWZmZXJlbnQgbmFtZSBzaG91bGQgYmUgdXNl ZCwgdG8gbWFrZSBpdCBjbGVhciB0aGF0IG90aGVyIHRva2VuIHR5cGVzIG90aGVyIHRoYW4gYmVh cmVyIHRva2VucyBjb3VsZCBhbHNvIGJlIHVzZWQNCiB3aXRoIE9BdXRoIDIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRvdWcgVGFuZ3Jlbjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE1heSAxMSwgMjAxMSAxMDowOSBQTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBjb25zaXN0ZW5jeSBvZiB0b2tl biBwYXJhbSBuYW1lIGluIGJlYXJlciB0b2tlbiB0eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIG1heSBoYXZlIGNvbWUgdXAgYmVmb3JlIHNvIEknbSBzb3JyeSBpZiBJJ20g cmVwZWF0aW5nLiBXaHkgZG9lcyBiZWFyZXIgdG9rZW4gc3BlYyBpbnRyb2R1Y2UgYSBuZXcgbmFt ZSBmb3Igb2F1dGgyIGFjY2VzcyB0b2tlbnMgWzFdLCAmcXVvdDtiZWFyZXJfdG9rZW4mcXVvdDss IGFuZCBiZWZvcmUgdGhhdCBbMl0sICZxdW90O29hdXRoX3Rva2VuJnF1b3Q7PyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSZuYnNwO2Fwb2xvZ2l6 ZSZuYnNwO2lmIHRoaXMgbWF5IHNvdW5kIHNoYWxsb3cgYnV0LCB3aHkgaW50cm9kdWNlIGEgbmV3 IHBhcmFtZXRlciBuYW1lIHZlcnNlcyBzdGlja2luZyB3aXRoIHdoYXQgdGhlIGdlbmVyYWwgb2F1 dGgyIHNwZWMgYWxyZWFkeSBkZWZpbmVzLCAmcXVvdDthY2Nlc3NfdG9rZW4mcXVvdDsuIEl0IHNl ZW1zIGFyYml0cmFyeSBmb3IgYW4gYXV0aCBzZXJ2ZXIgdG8gaGFuZCBhIGNsaWVudCBhbiBhcHBs ZSB0aGVuIGhhdmUgdGhlDQogY2xpZW50IGhhbmQgaXQgb2ZmIHRvIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgYW5kIGNhbGwgaXQgYW4gb3JhbmdlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XYXMgdGhpcyBqdXN0IGZvciB0aGUgc2FrZSBv ZiBkaWZmZXJlbnRpYXRpbmcgdGhlIHBhcmFtZXRlciBuYW1lIGVub3VnaCBzbyB0aGF0IHRoZSBi ZWFyZXIgdG9rZW5zIG1heSBiZSB1c2VkIGluIG90aGVyIHByb3RvY29scyB3aXRob3V0IGJlaW5n IGNvbmZ1c2VkIHdpdGggb2F1dGgyIGFjY2Vzc190b2tlbnM/PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV06Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDQjc2VjdGlvbi0yLjIi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA0 I3NlY3Rpb24tMi4yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WzJdOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAzI3NlY3Rpb24tMi4yIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMyNzZWN0aW9uLTIuMjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Eb3VnIFRh bmdyZW48YnI+DQo8YSBocmVmPSJodHRwOi8vbGVzc2lzLm1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2xlc3Npcy5tZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943380F6A46TK5EX14MBXC203r_-- From Michael.Jones@microsoft.com Mon May 23 12: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 2E8F9E07D0 for ; Mon, 23 May 2011 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.931 X-Spam-Level: X-Spam-Status: No, score=-10.931 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 BEft1e9UgnQW for ; Mon, 23 May 2011 12:10:21 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9E255E06F9 for ; Mon, 23 May 2011 12:10:21 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 23 May 2011 12:10:21 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0289.008; Mon, 23 May 2011 12:10:20 -0700 From: Mike Jones To: Marius Scurtescu , OAuth WG Thread-Topic: bearer token authorization header Thread-Index: AQHMDm8eraLFxPaXk06szRXCsxzqaJSa20Eg Date: Mon, 23 May 2011 19:10:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943380F6B84TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 19:10:24 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943380F6B84TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Answers inline: Not sure how to interpret the authorization header grammar described in sec= tion 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, "Bearer", there is a required whitespace followed by= the actual token. The token is represented by a sequence of printable char= acters, no escaping. No spaces or other elements are allowed after the toke= n. Is that correct? Yes RWS is not defined, I assume it is the "required whitespace" from section 1= .2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 Correct. If this isn't a standard by the time the bearer token spec, becom= es an RFC I assume this definition will be pulled into the spec. There is a reference to RFC2617, but not sure why. That seems to imply that= a list of values can be specified, which is not the case. Good catch. I think this should have been 2616. The fact that there is no escaping mechanism can potentially create problem= s. The list of allowed characters is spelled out, but what if some implemen= tation uses other characters? Using a name value pair and proper escaping i= s much safer IMO. For example: Bearer token=3Ddfgh76dfghdfg or Bearer token=3D"dfgh76dfghdfg" The value above can be either a token or a quoted string. HTTP header parse= rs know how to parse tokens and quoted strings so an implementor has a bett= er chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Mange= r replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at= least clean up the references. The definition allows the access token to be any string of one or more prin= table non-whitespace ASCII characters. Thus, legal access token strings in= clude ones like the ones you are asking for, such as: param=3D"value" -- Mike -----Original Message----- From: Marius Scurtescu [mailto:mscurtescu@google.com] Sent: Monday, May 09, 2011 10:32 AM To: OAuth WG; Mike Jones Cc: Mark Lentczner; Manger, James H Subject: bearer token authorization header I am working through version 04 of the Bearer Token draft: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 Not sure how to interpret the authorization header grammar described in sec= tion 2.1. The intent seems to be for something like: Bearer dfgh76dfghdfg After the scheme name, "Bearer", there is a required whitespace followed by= the actual token. The token is represented by a sequence of printable char= acters, no escaping. No spaces or other elements are allowed after the toke= n. Is that correct? RWS is not defined, I assume it is the "required whitespace" from section 1= .2.2 of: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 There is a reference to RFC2617, but not sure why. That seems to imply that= a list of values can be specified, which is not the case. The fact that there is no escaping mechanism can potentially create problem= s. The list of allowed characters is spelled out, but what if some implemen= tation uses other characters? Using a name value pair and proper escaping i= s much safer IMO. For example: Bearer token=3Ddfgh76dfghdfg or Bearer token=3D"dfgh76dfghdfg" The value above can be either a token or a quoted string. HTTP header parse= rs know how to parse tokens and quoted strings so an implementor has a bett= er chance of doing it right. Mark Lentczner started a thread on this regard a few moths ago, James Mange= r replied and suggested something similar: http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html If it is too late to switch to a name/value pair, then I think we should at= least clean up the references. Marius --_000_4E1F6AAD24975D4BA5B1680429673943380F6B84TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Answers inline:

    Not sure how to interp= ret the authorization header grammar described in section 2.1. The intent s= eems to be for something like:

    Bearer dfgh76dfghdfg

     

    After the scheme name,= "Bearer", there is a required whitespace followed by the actual = token. The token is represented by a sequence of printable characters, no e= scaping. No spaces or other elements are allowed after the token. Is that correct?

    Yes<= /p>

     

    RWS is not defined, I = assume it is the "required whitespace" from section 1.2.2 of:

    http://tools.ietf.org/html/draft-ietf-httpbi= s-p1-messaging-13

    Correct.  If this= isn’t a standard by the time the bearer token spec, becomes an RFC I= assume this definition will be pulled into the spec.

     

    There is a reference t= o RFC2617, but not sure why. That seems to imply that a list of values can = be specified, which is not the case.

    Good catch.  I th= ink this should have been 2616.

     

    The fact that there is= no escaping mechanism can potentially create problems. The list of allowed= characters is spelled out, but what if some implementation uses other char= acters? Using a name value pair and proper escaping is much safer IMO. For example:

    Bearer token=3Ddfgh76d= fghdfg

    or

    Bearer token=3D"d= fgh76dfghdfg"

     

    The value above can be= either a token or a quoted string. HTTP header parsers know how to parse t= okens and quoted strings so an implementor has a better chance of doing it = right.

     

    Mark Lentczner started= a thread on this regard a few moths ago, James Manger replied and suggeste= d something similar:

    http://www.ietf.org/mail-archive/web/oaut= h/current/msg04671.html

     

    If it is too late to s= witch to a name/value pair, then I think we should at least clean up the re= ferences.

    The definition allows = the access token to be any string of one or more printable non-whitespace A= SCII characters.  Thus, legal access token strings include ones like t= he ones you are asking for, such as:

       &nbs= p;           param=3D&quo= t;value"

     

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

     

    -----Original Message-----
    From: Marius Scurtescu [mailto:mscurtescu@google.com]
    Sent: Monday, May 09, 2011 10:32 AM
    To: OAuth WG; Mike Jones
    Cc: Mark Lentczner; Manger, James H
    Subject: bearer token authorization header

     

    I am working through version 04 of the Bearer Tok= en draft:

    h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04

     

    Not sure how to interpret the authorization heade= r grammar described in section 2.1. The intent seems to be for something li= ke:

    Bearer dfgh76dfghdfg

     

    After the scheme name, "Bearer", there = is a required whitespace followed by the actual token. The token is represe= nted by a sequence of printable characters, no escaping. No spaces or other= elements are allowed after the token. Is that correct?

     

    RWS is not defined, I assume it is the "requ= ired whitespace" from section 1.2.2 of:

    http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13

     

    There is a reference to RFC2617, but not sure why= . That seems to imply that a list of values can be specified, which is not = the case.

     

    The fact that there is no escaping mechanism can = potentially create problems. The list of allowed characters is spelled out,= but what if some implementation uses other characters? Using a name value = pair and proper escaping is much safer IMO. For example:

    Bearer token=3Ddfgh76dfghdfg

    or

    Bearer token=3D"dfgh76dfghdfg"

     

    The value above can be either a token or a quoted= string. HTTP header parsers know how to parse tokens and quoted strings so= an implementor has a better chance of doing it right.

     

    Mark Lentczner started a thread on this regard a = few moths ago, James Manger replied and suggested something similar:

    http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html

     

    If it is too late to switch to a name/value pair,= then I think we should at least clean up the references.

     

    Marius

     

    --_000_4E1F6AAD24975D4BA5B1680429673943380F6B84TK5EX14MBXC203r_-- From skylar@kiva.org Mon May 23 13:45: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 6216BE0850 for ; Mon, 23 May 2011 13:45:36 -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 ZBGSGM+gNq8M for ; Mon, 23 May 2011 13:45:35 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 9C28DE0808 for ; Mon, 23 May 2011 13:45:35 -0700 (PDT) Received: from mail-pv0-f175.google.com ([74.125.83.175]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTdrHbvZGDM+Rz7kxIxY80rz5dwPKFCo8@postini.com; Mon, 23 May 2011 13:45:35 PDT Received: by mail-pv0-f175.google.com with SMTP id 30so2901087pvc.20 for ; Mon, 23 May 2011 13:45:34 -0700 (PDT) Received: by 10.68.30.39 with SMTP id p7mr2378194pbh.34.1306183534858; Mon, 23 May 2011 13:45:34 -0700 (PDT) Received: from [172.23.61.5] ([67.218.98.104]) by mx.google.com with ESMTPS id 9sm4543583pbt.46.2011.05.23.13.45.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 13:45:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 23 May 2011 13:44:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D97DDEA-22C1-4311-B21E-29CA1CA2E6D7@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Marius Scurtescu X-Mailer: Apple Mail (2.1084) Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 20:45:36 -0000 Just for the record, I spoke with Marius just now and they'll be using = Eran's suggested URN for this (as well as 'oob' as a non-complient = alias): urn:ietf:wg:oauth:2.0:oob Still remains to be codified in some way as an official suggestion. = Would this belong in the core spec? skylar On Jan 28, 2011, at 11:24 AM, Marius Scurtescu wrote: > On Fri, Jan 28, 2011 at 10:25 AM, Eran Hammer-Lahav = wrote: >> -12 3.1.1: >>=20 >> The redirection URI MUST be an absolute URI and MAY include a query >> component, which MUST be retained by the authorization server when >> adding additional query parameters. >>=20 >> 'oob' is not an absolute URI. >=20 > Good point, I missed the absolute part. Thanks for pointing this out. >=20 > Let me think about it, the URN you suggested is a good start. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Mon May 23 13:47: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 9746EE07E0 for ; Mon, 23 May 2011 13:47:21 -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 Li9DzovE3WPB for ; Mon, 23 May 2011 13:47: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 045ECE079C for ; Mon, 23 May 2011 13:47:20 -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 p4NKlKVX021446 for ; Mon, 23 May 2011 13:47:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306183640; bh=6ibhZTRJ3lkwUdqAZ+euQ3YrSmM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=MRTVZvC0E/1mhltFsMDR7MW9pQMueroahyziPsKa07eSosODF4uERMZ6yPvOkatny lNVvKJxRmiuP/LEcndMwQ== Received: from yxk30 (yxk30.prod.google.com [10.190.3.158]) by wpaz37.hot.corp.google.com with ESMTP id p4NKiYlq005483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 May 2011 13:47:19 -0700 Received: by yxk30 with SMTP id 30so2320958yxk.3 for ; Mon, 23 May 2011 13:47: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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gf0dOZg0LWgJpk04hMOZOaiMdenJgf5pWEgfKVOFUfk=; b=bDfehFzPYgirfHcWIPPFn4D5BMWkP32iUWAdzE0OsZXJeSeBieaIPXkuliz4BTBeE0 c804Zrsy2qiRzOy+/1FA== 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=wyZWycGwHNklmPt/cdBn5ZQnofTWRlZFGGoUMeeU9JCQ74HdTSkenxHarJNLihX/Ee OIs7iKTS4tb8liZ/OpIg== Received: by 10.101.191.5 with SMTP id t5mr2799109anp.101.1306183639128; Mon, 23 May 2011 13:47:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.6 with HTTP; Mon, 23 May 2011 13:46:59 -0700 (PDT) In-Reply-To: <2D97DDEA-22C1-4311-B21E-29CA1CA2E6D7@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2D97DDEA-22C1-4311-B21E-29CA1CA2E6D7@kiva.org> From: Marius Scurtescu Date: Mon, 23 May 2011 13:46:59 -0700 Message-ID: To: Skylar Woodward 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] Native Client Extension X-BeenThere: oauth@ietf.org X-Mailman-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, 23 May 2011 20:47:21 -0000 On Mon, May 23, 2011 at 1:44 PM, Skylar Woodward wrote: > Just for the record, I spoke with Marius just now and they'll be using Er= an's suggested URN for this (as well as 'oob' as a non-complient alias): > > =A0 =A0 =A0 =A0urn:ietf:wg:oauth:2.0:oob > > Still remains to be codified in some way as an official suggestion. Would= this belong in the core spec? Working on an extensions right now, should be done in a few days (I keep saying that). Marius From skylar@kiva.org Mon May 23 18:16: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 CD9C4E077C for ; Mon, 23 May 2011 18:16:52 -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 mpSh2Qzpiwse for ; Mon, 23 May 2011 18:16:51 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 508A5E069E for ; Mon, 23 May 2011 18:16:51 -0700 (PDT) Received: from mail-pw0-f53.google.com ([209.85.160.53]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTdsHAmdKtjaTGRm51egM+1iMs/JEFuzx@postini.com; Mon, 23 May 2011 18:16:51 PDT Received: by mail-pw0-f53.google.com with SMTP id 5so4254810pwj.40 for ; Mon, 23 May 2011 18:16:50 -0700 (PDT) Received: by 10.68.23.65 with SMTP id k1mr2477389pbf.414.1306199810327; Mon, 23 May 2011 18:16:50 -0700 (PDT) Received: from [192.168.1.2] (c-67-180-211-155.hsd1.ca.comcast.net [67.180.211.155]) by mx.google.com with ESMTPS id j2sm4673400pbg.60.2011.05.23.18.16.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 18:16:49 -0700 (PDT) From: Skylar Woodward Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 18:16:46 -0700 References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> To: OAuth WG Message-Id: <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [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: Tue, 24 May 2011 01:16:52 -0000 Resending to the list from my subscribed account... Begin forwarded message: > From: Skylar Woodward > Date: May 23, 2011 6:14:00 PM PDT > To: Skylar Woodward > Cc: Eran Hammer-Lahav , OAuth WG > Subject: Re: [OAUTH-WG] issues with token age element - MAC token >=20 > So after discussing this today and reflecting on it a bit, I would = suggest that nonce simply be the "unique value" (as it is so named) = without further requirements. It might be suggested that this be = composed of an random+timestamp (not age) value, but that seems more of = a MAY or "recommended" practice. If the expectation is that very few if = any providers would actually check the timestamp (or moreover, the nonce = itself), why add terminology in the draft that requires it? Developers = are doing extra housekeeping (and perhaps for a perceived benefit) but = with no payoff or added security. >=20 > I'm sending this feedback based on having implemented the v3-5 changes = last night (for both client credentials and requests w/ access tokens). = After the changes, the nonce creation is now the most complicated part = of the normalized request string and yet these changes offer the least = benefit. What's most important is that nonces are unique on each request = for an ID. >=20 > There are issues with age as well: >=20 > - As Bill mentioned, if the client stores the issue time based on = receipt, then the internal clock changes (presumably w/o knowledge of = the software storing the dates) then time will also fail. Assuming that = a user with a bad clock (of by hours or more) will never fix it and = actually encourages bad user behavior (don't fix your clock or = Twitterbot will stop working!). Though we say that timezones won't bring = about the situation of changed clock, I'd be to differ. Many users = aren't savvy enough to change time zone, but just adjust the time to = local time anyway. Users who are more likely to get it right already = have auto clock sync enabled (via web, mobile, etc.) >=20 > - What if the token wasn't originally issued programmatically? In this = case, the issue time has to be obtained from the server and stored on = the client then you have the same problem as with a timestamp - the = client clock is not sync'd to the server clock and there is no = adjustment. You want this to apply to uses outside of just OAuth, but = now requiring the client to be able to determine an issue time based on = when it receives an HTTP request necessarily limits the types of token = flows for which this can be used. >=20 > - It's one more detail to store. Hardly an issue for a developer, but = it is inelegant. It's like having a double ID. Yet it's not an ID, it is = actually more of a recording of "my personal clock offset value" but = obfuscated several times over (one for each token) as issue_date. >=20 > - This implementation assumes software programs use the computer = internal clock exclusively for timestamp. A robust program that is = dependent on accurate timestamps would ping the origin server (or = similar trusted time authority) to ask it the current time. Then it = could store a "my device clock offset" value for the lifetime of the = program execution. All requests needing timestamp would be adjusted = accordingly. For age, if the clock is changed since the stored = issue_date, the problem can't be corrected in this manner. Thus, a = significant advantage for timestamp. >=20 > All in all, this seems like a misguided but well-intentioned attempt = to get around end-user issues of mis-set clocks. It feels like a hack = and it certainly isn't a foolproof solution. The more I think about the = implications of the age parameter, the less I like it. Timestamp has = been used for many years in the industry and with reasonable success in = relevant applications. If we change to a new way of trying to sync on = time I think we run a greater risk of stumbling upon unforeseen issues, = such as those outlined above. >=20 > I recommend the requirement of an age (or timestamp for that matter) = be dropped from the nonce construction. For providers that deem it = valuable, timestamp can be an optional value (either as part of the = nonce or the overall header, as before). >=20 > skylar >=20 >=20 >=20 > On May 23, 2011, at 2:11 AM, Skylar Woodward wrote: >=20 >> You may have noticed, on page 8 the host is listed as "example.net" - = should be example.com, I believe. (draft v5) >>=20 >> All in all, I'm in support of the changes in v2. Certainly addresses = my hesitations from v2. >>=20 >> skylar >>=20 >>=20 >> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote: >>=20 >>> (Please discuss this draft on the Apps-Discuss = mailing list) >>>=20 >>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >>>=20 >>> While this document has moved to the Apps-Discuss mailing list for = the time being, I wanted to give a quick update to those who have been = following this draft which originated on this list. >>>=20 >>> The major changes since -02 are: >>>=20 >>> * Removed OAuth terminology and association. The draft is now a = general purpose HTTP authentication scheme. It does include an OAuth 2.0 = binding which is described in less than a page. One suggestion would be = to move section 5.1 into the OAuth specification and drop all the OAuth = 2.0 text from the MAC draft. >>>=20 >>> * Added 'Set-Cookie' extension for using MAC with session cookies. >>>=20 >>> * Removed request URI query normalization. The new draft uses the = raw request URI unchanged. >>>=20 >>> * Replaced timestamps with credentials age to remove the need for = clock sync. >>>=20 >>> * Added a placeholder for extension, allowing random text to be = included in the request and MAC. >>>=20 >>> * Added issuer attribute for identifying the source of the = credentials as an additional protection. >>>=20 >>> Draft -04 is not compatible with previous drafts. >>>=20 >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From wmills@yahoo-inc.com Mon May 23 21:49: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 85021E06C8 for ; Mon, 23 May 2011 21:49:59 -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 MCYL3D1WJn-4 for ; Mon, 23 May 2011 21:49:58 -0700 (PDT) Received: from nm6-vm0.bullet.mail.ac4.yahoo.com (nm6-vm0.bullet.mail.ac4.yahoo.com [98.139.52.70]) by ietfa.amsl.com (Postfix) with SMTP id DDC3EE06B5 for ; Mon, 23 May 2011 21:49:57 -0700 (PDT) Received: from [98.139.52.197] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 24 May 2011 04:49:53 -0000 Received: from [98.139.52.187] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 24 May 2011 04:49:53 -0000 Received: from [127.0.0.1] by omp1070.mail.ac4.yahoo.com with NNFMP; 24 May 2011 04:49:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 950115.96663.bm@omp1070.mail.ac4.yahoo.com Received: (qmail 3713 invoked by uid 60001); 24 May 2011 04:49:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306212593; bh=oAu6YXPzsZxvyKgLb5ik2MsyB/e21YHsWJYQT6NMjMs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ePWMwxiA3LO18fl1aCjW3J4X/8yyqHuFBtkiXxOx86LDFgB40aYGO5UjPoOqCaABCwWs+oJbSZBObyV2ezotnlhgC70ZhKyeujkNGrulbA4Vo2czUuWdeAysBJp07zO24UX0hN1V/fdwgNYKRx2u8CXutQHKrrIKILQ4s/rW6d4= 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:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ExfU1ihcaPrY3L2tRjBP3geq7hPyP2dhHFU6c2dC81iHZVdgVZoarfY8MZRLRw63NvoFeOActqjd7KIyhK4653JXohzL1hjwhKfP7aI3HV5WrCqV1c6AHXvBimuCoDudasSm8fiD6PSPFovcNKtXPm2VkUSqg7LoR1C1O2pxO2g=; Message-ID: <360491.46052.qm@web31807.mail.mud.yahoo.com> X-YMail-OSG: Zi.QJ4oVM1kNHBUtQBDdn8y0ikrvPwr64zNuYjcYo4RKLAj LRgYFuRsxctjfUVjyqZ2oC7EaHiNIH8Gae5K1y8AKmmAfIGe88RCigGyDlEy VXocCUp93DRSxvm2xt.cQfEEvi0HUgIruqfNDIFu8jZzWFMMMXACKuqg0lZg V1V4Zj.drOk42XsugF0WnFagVWSCL7EAB8rLNyyUC8wD6xPimzZUMSm6m.s0 Ig98fMlH7nQvmg_HL4OMma5QlqE_qkVs4OHnnzr4VoCm2jl0DYejXxxl4dyv WgUeoDJ0qYrXmkjBKkni8aHIao3naBX5x8BAVouIEszNb3cWySanf7l.YcIZ ZYGxIhu4JKUEPdQdqfMKPz7oymcXYQvedsRm6uPkgUu45a2OpRZMwvS11T.v zzLtv Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Mon, 23 May 2011 21:49:53 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.111.304355 Date: Mon, 23 May 2011 21:49:53 -0700 (PDT) From: "William J. Mills" To: Hannes Tschofenig MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-29443434-1306212593=:46052" Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Interim meeting minutes/follow-ups/action items 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, 24 May 2011 04:49:59 -0000 --0-29443434-1306212593=:46052 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable -=A0=A0=A0 Concern that 3 and 3.1 do not clearly show a way for a native cl= ient to provide client_id (to identify the client only) without doign authe= ntication.=0A=0AProposed new text, insert in bold:=A0 =0A=0A=A0=A0=A0 "In a= ddition, the authorization server MAY allow unauthenticated access token re= quests when the client identity does not matter (e.g. anonymous client), wh= en client authenitcation is not practical, or when the client identity is e= stablished via other means."=0A=0A-=A0=A0=A0 Last paragraph, section 3, pro= posed new text, reversing the order, putting "since ..." at the end of the = sentence:=0A=0A=A0=A0 The authorization server MUST require the use of a tr= ansport-layer security mechanism when sending requests to exchange an the t= oken endpoint since requests using a method other than client password this= authentication method result in the transmission of clear-text credentials= .=0A=0A-=A0=A0=A0 3.1=A0 edit first paragraph=0A=0ADelete: "(the client ide= ntifier together with a shared symmetric secret secret)"=0A=0A=0A-=A0=A0=A0= 4.1.2.1.=A0 Error Response=A0 -- Character set for error_description =0A= =0A=0Abecomes=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 "OPTIONAL.=A0 Human-readable UT= F-8 encoded text providing additional information, used to assist to the de= veloper in understanding the error that occurred."=0A=0A-=A0=A0=A0 4.1.2.1.= =A0 Error URI=A0 -- "resource owner" becomes "developer"=0A=A0=0Aerror_uri= =0A=A0=A0=A0=A0=A0=A0=A0=A0 OPTIONAL.=A0 A URI identifying a human-readable= web page with=0A=A0=A0=A0=A0=A0=A0=A0=A0 information about the error, used= to provide the developer=0A=A0=A0=A0=A0=A0=A0=A0=A0 with additional inform= ation about the error.=0A=0A-=A0=A0=A0 4.1.2.1.=A0 Error -- remove HTTP 4xx= and 5xx error code as an allowed "error" value=A0 =0A-=A0=A0=A0 4.2.2.1.= =A0 Error Response -- ibid=0A=0AThis is considered a possible area for conf= usion between the HTTP error code and the error code returned in protocol.= =0A=0ATODO: Eran H-L to look at which HTTP error codes should be mapped in = to protocol specific error codes.=0A=0A-=A0=A0=A0 10 Security consideration= s....=0A=0A-=A0=A0=A0 10.10 Session fixation...=0A=0ABreno does not feel th= at session fixation is properly described nor dealt with.=A0 =0A=0AIgor is = providing reference links to session fixation description (mail to the list= ).=0A=0ATODO: Breno@google.com is working on new draft language. =0A=0A=0A-= =A0=A0=A0 10.13.=A0 XSRF/CSRF Prevention=0A=0ATODO: Breno and Bill M. worki= ng on new draft text.=0A=0A-=A0=A0=A0 9. Native applications=0A=0AObjection= s that this recommends against things that are extant implementations.=0A= =0ATODO:=A0 Chuck N. to draft revised text.=0A=0A=0A-=A0=A0=A0 4.5 Extensib= ility =0A=0ATODO: Hannes will look at policy for using IETF URN=0A=0ATODO: = Mike J./Chuck N. to draft 4.5.1 subsection on assertions.=A0 Clarifying the= use case there and suggested behavior.=0A=0A-=A0=A0=A0 Proposed additions = =0A=A0=A0=A0 -=A0=A0=A0 "Immediate Mode" with display=3D and response=3D=0A= =A0=A0=A0 -=A0=A0=A0 response_type=3D{none, cookie}=0A=0ATODO: Paul T. to s= end proposed requirements to the list.=0A=0ATODO: Eran to add extensibilty = language for this based on requirements.=0A=0A-=A0=A0=A0 "RedirectURI" shou= ld be optional=0A=0ATODO: 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 a= ctually using this".=0A=0A-=A0=A0=A0 4.3 (and 3.1) Username/Password=0A=0AN= eed to figure out what the encoding will be here, since these can be outsid= e the ascii charset.=0A=0ATODO: Peter St.A to review the language.=0A=0A-= =A0=A0=A0 Discussion on client credentials -- Tony Nadalin.=0A=0ATODO: Tony= N./Chuck N.=A0 to propose new spec to handle assertions both for authentic= ation and authorization.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=0AMoving on to BEARER TOKENS=0A=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AMIke J. revi= ewing changes in Draft 5.=0A=0A-=A0=A0=A0 2. Authenticated requests=0A=0ADi= scussed possible language change and oped for no change.=0A=0A-=A0=A0=A0 40= 0 vs 401 return=0A=0ATODO: Mike Jones to follow up with HTTP WG or represen= tatives and ask whether there are objections.=0A=0ANOTE:=A0 Mark Nottingham= (in the HTTP community says that either 400 or 401 are acceptible in most = cases.=0A=0A-=A0=A0=A0 can we move from 403 to 401?=0A=0AEran's statement i= s that 403 is sematically correct in HTTP.=A0 Probably true.=0A=0A=0A=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AMoving= on to MAC TOKENS=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=0A=0AEran ran through the current status.=0A=0AOnly sign= ificant issue at this time is body hash.=A0 Seems to be a thorny issue, he = is looking for actual implementer experience.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AMoving on to SAML=0A=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A= Brian Campbell: No recent feedback on the list.=A0 Not sure whether that's = good or just no attentionon SAML.=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AMove to adjourn...=A0 Adjourned. --0-29443434-1306212593=:46052 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    -&nb= sp;   Concern that 3 and 3.1 do not clearly show a way for a nati= ve client to provide client_id (to identify the client only) without doign = authentication.

    Proposed new text, insert in bold: 

    &nb= sp;   "In addition, the authorization server MAY allow unauthenti= cated access token requests when the client identity does not matter (e.g. = anonymous client), when client authenitc= ation is not practical, or when the client identity is established v= ia other means."

    -    Last paragrap= h, section 3, proposed new text, reversing the order, putting "since ..." a= t the end of the sentence:

       The authorization server MUS= T require the use of a transport-layer security mechanism when sending requests to exchange an the token endpoint since requests using a method o= ther than client password this authentication method result in the transmis= sion of clear-text credentials.

    -   = ; 3.1  edit first paragraph

    Delete: "(the client identifier tog= ether with a shared symmetric secret secret)"


    =
    -    4.1.2.1.  Error Response  -- Chara= cter set for error_description

    becomes

             "OPTIONAL.  H= uman-readable UTF-8 encoded text providing additional information, used to = assist to the developer in understanding the error that occurred."

    -    4.1.2.1.  Error URI  -- "res= ource owner" becomes "developer"
     
    error_uri
      &nbs= p;      OPTIONAL.  A URI identifying a human-readable web page with
           =   information about the error, used to provide the developer
     =         with additional information abou= t the error.

    -    4.1.2.1.  Error -- remove HTTP= 4xx and 5xx error code as an allowed "error" value 
    -  =   4.2.2.1.  Error Response -- ibid

    This is considered a po= ssible area for confusion between the HTTP error code and the error code re= turned in protocol.

    TODO: Eran H-L to look at which HTTP error codes= should be mapped in to protocol specific error codes.

    -  =   10 Security considerations....

    -    10.10 Sess= ion fixation...

    Breno does not feel that session fixation is properl= y described nor dealt with. 

    Igor is providing reference links= to session fixation description (mail to the list).

    TODO: Breno@google.com is working on new draft language.


    - &nbs= p;  10.13.  XSRF/CSRF Prevention

    TODO: B= reno and Bill M. working on new draft text.

    -    9. N= ative applications

    Objections that this recommends against things th= at are extant implementations.

    TODO:  Chuck N. to draft revised= text.


    -    4.5 Extensibility

    TODO: Hanne= s will look at policy for using IETF URN

    TODO: Mike J./Chuck N. to d= raft 4.5.1 subsection on assertions.  Clarifying the use case there an= d suggested behavior.

    -    Proposed additions
    &nb= sp;   -    "Immediate Mode" with display=3D and re= sponse=3D
        -    response_type=3D{none, = cookie}

    TODO: Paul T. to send proposed requirements to the list.
    =
    TODO: Eran to add extensibilty language for this based on requirements.

    -    "RedirectURI" should be optional<= br>
    TODO: Eran to send mail to the list proposing language changes to ei= ther 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".

    -    4.3 (and 3.1) Username/Password

    N= eed to figure out what the encoding will be here, since these can be outsid= e the ascii charset.

    TODO: Peter St.A to review the language.
    -    Discussion on client credentials -- Tony Nadalin.
    <= br>TODO: Tony N./Chuck N.  to propose new spec to handle assertions bo= th for authentication and authorization.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Moving on to BEARER TOKENS=
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

    MIke J. reviewing changes in Draft 5.

    -   = 2. Authenticated requests

    Discussed possible language change and op= ed for no change.

    -    400 vs 401 return

    TODO: Mike Jon= es to follow up with HTTP WG or representatives and ask whether there are o= bjections.

    NOTE:  Mark Nottingham (in the HTTP community says t= hat either 400 or 401 are acceptible in most cases.

    -  &nb= sp; can we move from 403 to 401?

    Eran's statement is that 403 is sem= atically correct in HTTP.  Probably true.


    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Moving on to M= AC TOKENS
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    Eran ran through the current status.

    Only signif= icant issue at this time is body hash.  Seems to be a thorny issue, he= is looking for actual implementer experience.

    =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Moving on to SAML=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Brian Campbell: No recent feedback on the list.  Not sure whethe= r that's good or just no attentionon SAML.


    =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Move to adjourn...&n= bsp; Adjourned.

    --0-29443434-1306212593=:46052-- From torsten@lodderstedt.net Tue May 24 00:12: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 A6AACE06CE for ; Tue, 24 May 2011 00:12: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 pD051J50XUSV for ; Tue, 24 May 2011 00:12:36 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1118BE0692 for ; Tue, 24 May 2011 00:12:35 -0700 (PDT) Received: from [80.67.16.115] (helo=webmailfront04.ispgateway.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QOln8-0002Yp-4m; Tue, 24 May 2011 09:12:34 +0200 Received: from proxy2.t-online.net (proxy2.t-online.net [195.243.113.251]) by webmail.df.eu (Horde Framework) with HTTP; Tue, 24 May 2011 09:12:34 +0200 Message-ID: <20110524091234.16813r1vykiwt2lc@webmail.df.eu> Date: Tue, 24 May 2011 09:12:34 +0200 From: Torsten Lodderstedt To: "William J. Mills" References: <360491.46052.qm@web31807.mail.mud.yahoo.com> In-Reply-To: <360491.46052.qm@web31807.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2) X-Originating-IP: 195.243.113.251 X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Interim meeting minutes/follow-ups/action items X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 07:12:38 -0000 Hi all, > -    10 Security considerations.... > > -    10.10 Session fixation... > > Breno does not feel that session fixation is properly described nor > dealt with.  Breno is right. The threat that shall be prevented here is described in the security threat document (http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.7, enhanced description in https://github.com/tlodderstedt/oauth2/raw/master/draft-lodderstedt-oauth-security.html). Here the attacker obtains a victim's authorization code by redirecting the flow to its own faked website. It then injects this code into his authorization process with the same service provider. This is obviously _not_ the classical session fixation where an attacker sets up a session and tricks the victim in upgrading/enhancing/personalizing this session in order to abuse the victim's privileges. I suggest to change the name of the attack/section to something like "authorization code theft ..." and to add a section about session fixation. > > Igor is providing reference links to session fixation description > (mail to the list). > > TODO: Breno@google.com is working on new draft language. > > > -    10.13.  XSRF/CSRF Prevention > > TODO: Breno and Bill M. working on new draft text. Isn't the countermeasure for both session fixation and XSRF the same (state)? In my opionion, the difference is: session fixation: get access to a victim's data in service A using the attackers account at service B. XSRF: get access to to a victim's data at a service A using the attacker's identity with an identity provider Please not: Mark McGloin is already working on text regarding XSRF. > > -    9. Native applications > > Objections that this recommends against things that are extant > implementations. Would you please give examples? regards, Torsten. From bcampbell@pingidentity.com Tue May 24 07:25: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 107ADE06BA for ; Tue, 24 May 2011 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 C3ht7F+pBpAR for ; Tue, 24 May 2011 07:25:44 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 36273E06AF for ; Tue, 24 May 2011 07:25:43 -0700 (PDT) Received: from mail-qy0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTdu/5qDj22hOX7FuKR4Hg+HU7i1MqYcF@postini.com; Tue, 24 May 2011 07:25:44 PDT Received: by qyk7 with SMTP id 7so1716998qyk.5 for ; Tue, 24 May 2011 07:25:42 -0700 (PDT) Received: by 10.224.137.133 with SMTP id w5mr2908961qat.178.1306247142165; Tue, 24 May 2011 07:25:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.74.66 with HTTP; Tue, 24 May 2011 07:25:12 -0700 (PDT) From: Brian Campbell Date: Tue, 24 May 2011 08:25:12 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 14:25:45 -0000 One of the action items out of yesterday's meeting was to draft some text for a section 4.5.1 in core that defined the optional but recommended use of an "assertion" parameter for extension grants where the use of a single parameter to carry the grant/assertion was possible. Below is a first cut at some proposed text that hopefully avoids some of the awkwardness that EHL described in previous attempts to introduce such a parameter. Comments or edits or editorial improvements are, of course, welcome. But I think this hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other actions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will change the parameter it uses from jwt to assertion and drop the registration request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 & 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "grant_type" parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named "assertion" be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- From gffletch@aol.com Tue May 24 10:25: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 6C95E13000E for ; Tue, 24 May 2011 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 5MCq01fH1aIR for ; Tue, 24 May 2011 10:25:03 -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 4257413000C for ; Tue, 24 May 2011 10:25:03 -0700 (PDT) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4OHOrw3005943; Tue, 24 May 2011 13:24:53 -0400 Received: from palantir.local (unknown [10.181.183.168]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7AC95E000099; Tue, 24 May 2011 13:24:52 -0400 (EDT) Message-ID: <4DDBE9E4.7080904@aol.com> Date: Tue, 24 May 2011 13:24:52 -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: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000800090509090003000707" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:465946880:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29434ddbe9e43b7f X-AOL-IP: 10.181.183.168 Cc: OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 17:25:04 -0000 This is a multi-part message in MIME format. --------------000800090509090003000707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Do I understand this correctly that each resource owner can define it's own format for the "printable non-whitespace ASCII characters"? It seems like that would make it difficult for clients to use standard libraries because the Authorization header format could be different on a per resource/host basis. Thanks, George On 5/23/11 3:10 PM, Mike Jones wrote: > [snip] > > The fact that there is no escaping mechanism can potentially create > problems. The list of allowed characters is spelled out, but what if > some implementation uses other characters? Using a name value pair and > proper escaping is much safer IMO. For example: > > Bearer token=dfgh76dfghdfg > > or > > Bearer token="dfgh76dfghdfg" > > The value above can be either a token or a quoted string. HTTP header > parsers know how to parse tokens and quoted strings so an implementor > has a better chance of doing it right. > > Mark Lentczner started a thread on this regard a few moths ago, James > Manger replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > If it is too late to switch to a name/value pair, then I think we > should at least clean up the references. > > The definition allows the access token to be any string of one or more > printable non-whitespace ASCII characters. Thus, legal access token > strings include ones like the ones you are asking for, such as: > > param="value" > > -- Mike > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, May 09, 2011 10:32 AM > To: OAuth WG; Mike Jones > Cc: Mark Lentczner; Manger, James H > Subject: bearer token authorization header > > I am working through version 04 of the Bearer Token draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 > > Not sure how to interpret the authorization header grammar described > in section 2.1. The intent seems to be for something like: > > Bearer dfgh76dfghdfg > > After the scheme name, "Bearer", there is a required whitespace > followed by the actual token. The token is represented by a sequence > of printable characters, no escaping. No spaces or other elements are > allowed after the token. Is that correct? > > RWS is not defined, I assume it is the "required whitespace" from > section 1.2.2 of: > > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 > > There is a reference to RFC2617, but not sure why. That seems to imply > that a list of values can be specified, which is not the case. > > The fact that there is no escaping mechanism can potentially create > problems. The list of allowed characters is spelled out, but what if > some implementation uses other characters? Using a name value pair and > proper escaping is much safer IMO. For example: > > Bearer token=dfgh76dfghdfg > > or > > Bearer token="dfgh76dfghdfg" > > The value above can be either a token or a quoted string. HTTP header > parsers know how to parse tokens and quoted strings so an implementor > has a better chance of doing it right. > > Mark Lentczner started a thread on this regard a few moths ago, James > Manger replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > If it is too late to switch to a name/value pair, then I think we > should at least clean up the references. > > Marius > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000800090509090003000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Do I understand this correctly that each resource owner can define it's own format for the "printable non-whitespace ASCII characters"? It seems like that would make it difficult for clients to use standard libraries because the Authorization header format could be different on a per resource/host basis.

    Thanks,
    George

    On 5/23/11 3:10 PM, Mike Jones wrote:
    [snip]

     

    The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example:

    Bearer token=dfgh76dfghdfg

    or

    Bearer token="dfgh76dfghdfg"

     

    The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right.

     

    Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar:

    http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html

     

    If it is too late to switch to a name/value pair, then I think we should at least clean up the references.

    The definition allows the access token to be any string of one or more printable non-whitespace ASCII characters.  Thus, legal access token strings include ones like the ones you are asking for, such as:

                   param="value"

     

                                                                -- Mike

     

    -----Original Message-----
    From: Marius Scurtescu [mailto:mscurtescu@google.com]
    Sent: Monday, May 09, 2011 10:32 AM
    To: OAuth WG; Mike Jones
    Cc: Mark Lentczner; Manger, James H
    Subject: bearer token authorization header

     

    I am working through version 04 of the Bearer Token draft:

    http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04

     

    Not sure how to interpret the authorization header grammar described in section 2.1. The intent seems to be for something like:

    Bearer dfgh76dfghdfg

     

    After the scheme name, "Bearer", there is a required whitespace followed by the actual token. The token is represented by a sequence of printable characters, no escaping. No spaces or other elements are allowed after the token. Is that correct?

     

    RWS is not defined, I assume it is the "required whitespace" from section 1.2.2 of:

    http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13

     

    There is a reference to RFC2617, but not sure why. That seems to imply that a list of values can be specified, which is not the case.

     

    The fact that there is no escaping mechanism can potentially create problems. The list of allowed characters is spelled out, but what if some implementation uses other characters? Using a name value pair and proper escaping is much safer IMO. For example:

    Bearer token=dfgh76dfghdfg

    or

    Bearer token="dfgh76dfghdfg"

     

    The value above can be either a token or a quoted string. HTTP header parsers know how to parse tokens and quoted strings so an implementor has a better chance of doing it right.

     

    Mark Lentczner started a thread on this regard a few moths ago, James Manger replied and suggested something similar:

    http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html

     

    If it is too late to switch to a name/value pair, then I think we should at least clean up the references.

     

    Marius

     

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

    --------------000800090509090003000707-- From bcampbell@pingidentity.com Tue May 24 10:31: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 E8340E0796 for ; Tue, 24 May 2011 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.017, 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 iv3HtOJf3jmL for ; Tue, 24 May 2011 10:31:47 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3AE0795 for ; Tue, 24 May 2011 10:31:47 -0700 (PDT) Received: from mail-qy0-f177.google.com ([209.85.216.177]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTdvrgfPZadWmf6/cUAANq5HJITLE086O@postini.com; Tue, 24 May 2011 10:31:47 PDT Received: by mail-qy0-f177.google.com with SMTP id 38so4556550qyl.15 for ; Tue, 24 May 2011 10:31:45 -0700 (PDT) Received: by 10.224.137.133 with SMTP id w5mr3122253qat.178.1306258305352; Tue, 24 May 2011 10:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.74.66 with HTTP; Tue, 24 May 2011 10:31:15 -0700 (PDT) From: Brian Campbell Date: Tue, 24 May 2011 11:31:15 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] formal definition of client_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, 24 May 2011 17:31:48 -0000 I noticed yesterday, in -16, that the first time that client_id is mentioned is in a parenthetical in the second paragraph of section 3.1 which is a little awkward. The client_id parameter then shows up inside two examples before being listed as a required parameter in section 4.1.1, 4.1.3, 4.2.1 and others with a reference back to a description in section 3. client_id REQUIRED. The client identifier as described in Section 3. This feels a little circular to me, however, because section 3 never really formally defines what client_id is. Also, based on conversations on this list, I think I understand the intent about how client_id should be handled for unauthenticated clients (a value for client_id is always required for the endpoints/grants listed in the core spec while client_secret, basic auth or other means of authentication is optional) but I'm not sure that is fully communicated in the text of -16. From stpeter@stpeter.im Tue May 24 11:16: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 58DC5E07AB for ; Tue, 24 May 2011 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 gidvVzU7-ad1 for ; Tue, 24 May 2011 11:16:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06AE076B for ; Tue, 24 May 2011 11:16:03 -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 3A0B340046; Tue, 24 May 2011 12:16:03 -0600 (MDT) Message-ID: <4DDBF5E0.7090405@stpeter.im> Date: Tue, 24 May 2011 12:16:00 -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 Campbell References: 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="------------ms080200010008010209050306" Cc: oauth Subject: Re: [OAUTH-WG] formal definition of client_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, 24 May 2011 18:16:05 -0000 This is a cryptographically signed message in MIME format. --------------ms080200010008010209050306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/24/11 11:31 AM, Brian Campbell wrote: > I noticed yesterday, in -16, that the first time that client_id is > mentioned is in a parenthetical in the second paragraph of section 3.1 > which is a little awkward. The client_id parameter then shows up > inside two examples before being listed as a required parameter in > section 4.1.1, 4.1.3, 4.2.1 and others with a reference back to a > description in section 3. >=20 > client_id > REQUIRED. The client identifier as described in Section 3. >=20 > This feels a little circular to me, however, because section 3 never > really formally defines what client_id is. >=20 > Also, based on conversations on this list, I think I understand the > intent about how client_id should be handled for unauthenticated > clients (a value for client_id is always required for the > endpoints/grants listed in the core spec while client_secret, basic > auth or other means of authentication is optional) but I'm not sure > that is fully communicated in the text of -16. Good point, Brian. I'm reviewing -16 too, and I noticed that we don't say what characters (Unicode code points) are allowed in the client_id parameter, how long it can be, how to perform comparison for authentication purposes, etc. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080200010008010209050306 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy NDE4MTYwMFowIwYJKoZIhvcNAQkEMRYEFMHQOU3LJs39GbUvHSf5bdco41HlMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBr4IxRWvqbyxoFi0yrh1CeR09zpC+k57UgQZ4TtP5bQS83vHnxXKHZkk9p Zd4Zn6vj4lyntZLsIEQwxXYbso88R9+bg/S+Cbst7lcb02LyDahPltQCgJAetzR7dtJQY0Pm b4pPxVy2091B+iOrQz/ndb3bmZrdiAgjPwtNIsardHuOVIE/gZiBizSwVikYHm20aT3iTYwC KWi9FU2l1+VivtIRqrv3ro2nFZkWKY6hJk9vPOwbLFpL311ZlKQnJ8Ehs/teXmzIiLqvXMV8 HXrMWxiwwatf1Ocum2YCTsfsfLpBykxzgj+eOqI3yqGFGfVDG/AlXnk/NtOE3f7JQmAyAAAA AAAA --------------ms080200010008010209050306-- From mscurtescu@google.com Tue May 24 11:28: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 38C5AE076B for ; Tue, 24 May 2011 11:28:16 -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 yM+RWqGFGHOz for ; Tue, 24 May 2011 11:28:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA6E0765 for ; Tue, 24 May 2011 11:28:14 -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 p4OISDQ0013817 for ; Tue, 24 May 2011 11:28:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306261693; bh=qv8mAn1U0tJfgqMO0N5lgbq0QVM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=JULiWqsG49X2bDYTyHGU+/X/9nTctn+cCIWcRTLZ3IeHFePJvsYzggd/7cgFK5S2q zfP8p38jE5upS3JG9Vf6g== Received: from qwb7 (qwb7.prod.google.com [10.241.193.71]) by wpaz1.hot.corp.google.com with ESMTP id p4OISA9e030804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 11:28:12 -0700 Received: by qwb7 with SMTP id 7so4539483qwb.40 for ; Tue, 24 May 2011 11:28:11 -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=MQcimcjJqUSB5Qh4cuXa3aqR3OYVgL5Wly5w/EZua/M=; b=Ty20lGdOlg445tvayTAjKUBftzpmkXhEJw0EjQCurCQp99gTd34pzqz0ZWdf1ZA0Tj 0WjWtcrtraxoDl9tT6CA== 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=sOIcxgP9YuwlkV/Ylf71MLVsHUdJLPQ+f/UUnwVdPFnT+rTDnogVQVq6pwOEv0eQxq qbIgn0WVewbj74+uPVyA== Received: by 10.224.185.199 with SMTP id cp7mr3215335qab.103.1306261690342; Tue, 24 May 2011 11:28:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.6.133 with HTTP; Tue, 24 May 2011 11:27:50 -0700 (PDT) In-Reply-To: <4DDBE9E4.7080904@aol.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> From: Marius Scurtescu Date: Tue, 24 May 2011 11:27:50 -0700 Message-ID: To: George Fletcher 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] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 18:28:16 -0000 The "printable non-whitespace ASCII characters" represents the access token, which is supposed to be opaque. I don't think this affects libraries. Marius On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrote: > Do I understand this correctly that each resource owner can define it's o= wn > format for the "printable non-whitespace ASCII characters"? It seems like > that would make it difficult for clients to use standard libraries becaus= e > the Authorization header format could be different on a per resource/host > basis. > > Thanks, > George > > On 5/23/11 3:10 PM, Mike Jones wrote: > > [snip] > > > > The fact that there is no escaping mechanism can potentially create > problems. The list of allowed characters is spelled out, but what if some > implementation uses other characters? Using a name value pair and proper > escaping is much safer IMO. For example: > > Bearer token=3Ddfgh76dfghdfg > > or > > Bearer token=3D"dfgh76dfghdfg" > > > > The value above can be either a token or a quoted string. HTTP header > parsers know how to parse tokens and quoted strings so an implementor has= a > better chance of doing it right. > > > > Mark Lentczner started a thread on this regard a few moths ago, James Man= ger > replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > > > If it is too late to switch to a name/value pair, then I think we should = at > least clean up the references. > > The definition allows the access token to be any string of one or more > printable non-whitespace ASCII characters.=A0 Thus, legal access token st= rings > include ones like the ones you are asking for, such as: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 param=3D"value" > > > > =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 > > > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, May 09, 2011 10:32 AM > To: OAuth WG; Mike Jones > Cc: Mark Lentczner; Manger, James H > Subject: bearer token authorization header > > > > I am working through version 04 of the Bearer Token draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 > > > > Not sure how to interpret the authorization header grammar described in > section 2.1. The intent seems to be for something like: > > Bearer dfgh76dfghdfg > > > > After the scheme name, "Bearer", there is a required whitespace followed = by > the actual token. The token is represented by a sequence of printable > characters, no escaping. No spaces or other elements are allowed after th= e > token. Is that correct? > > > > RWS is not defined, I assume it is the "required whitespace" from section > 1.2.2 of: > > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 > > > > There is a reference to RFC2617, but not sure why. That seems to imply th= at > a list of values can be specified, which is not the case. > > > > The fact that there is no escaping mechanism can potentially create > problems. The list of allowed characters is spelled out, but what if some > implementation uses other characters? Using a name value pair and proper > escaping is much safer IMO. For example: > > Bearer token=3Ddfgh76dfghdfg > > or > > Bearer token=3D"dfgh76dfghdfg" > > > > The value above can be either a token or a quoted string. HTTP header > parsers know how to parse tokens and quoted strings so an implementor has= a > better chance of doing it right. > > > > Mark Lentczner started a thread on this regard a few moths ago, James Man= ger > replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > > > If it is too late to switch to a name/value pair, then I think we should = at > least clean up the references. > > > > Marius > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From tonynad@microsoft.com Tue May 24 12:02: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 91918E0789 for ; Tue, 24 May 2011 12:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.333 X-Spam-Level: X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, 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 lUeLdp0yYfcb for ; Tue, 24 May 2011 12:02:17 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 11F68E0658 for ; Tue, 24 May 2011 12:01:43 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 May 2011 12:01:40 -0700 Received: from TX2EHSOBE005.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 24 May 2011 12:01:40 -0700 Received: from mail192-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 May 2011 19:01:39 +0000 Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2-R.bigfish.com (Postfix) with ESMTP id 65682D30B84 for ; Tue, 24 May 2011 19:01:39 +0000 (UTC) X-SpamScore: -42 X-BigFish: PS-42(zzbb2cK9371O542M1418MzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail192-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=CH1PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail192-tx2 (localhost.localdomain [127.0.0.1]) by mail192-tx2 (MessageSwitch) id 1306263699153082_14438; Tue, 24 May 2011 19:01:39 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.248]) by mail192-tx2.bigfish.com (Postfix) with ESMTP id 1730C7A004B; Tue, 24 May 2011 19:01:39 +0000 (UTC) Received: from CH1PRD0302HT002.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; Tue, 24 May 2011 19:01:38 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.222]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.052; Tue, 24 May 2011 19:01:36 +0000 From: Anthony Nadalin To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: AQHMGh6Rce7pl3szJ0+GR1glz7f1HpScVTIA Date: Tue, 24 May 2011 19:01:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%PINGIDENTITY.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: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 19:02:17 -0000 I think that this will be better moved into a separate document on assertio= ns (were both authorization and authentication are talked about) and not to= include in 4.5.1 but would like to see a reference in 4.5.1 to the new doc= ument -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Tuesday, May 24, 2011 7:25 AM To: oauth Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsectio= n on assertions One of the action items out of yesterday's meeting was to draft some text f= or a section 4.5.1 in core that defined the optional but recommended use of= an "assertion" parameter for extension grants where the use of a single pa= rameter to carry the grant/assertion was possible. Below is a first cut at= some proposed text that hopefully avoids some of the awkwardness that EHL = described in previous attempts to introduce such a parameter. Comments or = edits or editorial improvements are, of course, welcome. But I think this = hopefully captures the intent of what was discussed yesterday (and before). If we get some consensus to make this change, I think a couple of other act= ions are implied. - The IANA assertion parameter registration request (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) should be removed from the SAML draft and put into http://tools.ietf.org/html/draft-ietf-oauth-v2 - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec will = change the parameter it uses from jwt to assertion and drop the registratio= n request for jwt (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) --- proposed text for sections 4.5 & 4.5.1 --- 4.5. Extensions The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "grant_type" parameter of the token endpoint, and by adding any additional parameters necessary. If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2. 4.5.1 Assertion Based Extension Grants If the value of the extension grant can be serialized into a single parameter, as is case with a number of assertion formats, it is RECOMMENDED that that a parameter named "assertion" be used to carry the value. assertion REQUIRED. The assertion. The format and encoding of the assertion is defined by the authorization server or extension specification. For example, to request an access token using a SAML 2.0 assertion grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client makes the following HTTP request using transport-layer security (line breaks are for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue May 24 13:04: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 47AB6E0795 for ; Tue, 24 May 2011 13:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 yT2wLy8By2Eh for ; Tue, 24 May 2011 13:04:39 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5AADDE0670 for ; Tue, 24 May 2011 13:04:39 -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; Tue, 24 May 2011 13:04:33 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0289.008; Tue, 24 May 2011 13:04:33 -0700 From: Mike Jones To: Marius Scurtescu , George Fletcher Thread-Topic: [OAUTH-WG] bearer token authorization header Thread-Index: AQHMDm8eraLFxPaXk06szRXCsxzqaJSa20EggAHsNACAABGYAP//pZSw Date: Tue, 24 May 2011 20:04:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@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.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 24 May 2011 20:04:40 -0000 George, you are correct that resources and clients must agree upon the form= at of the bearer token to achieve interoperability. The means for achievin= g this agreement is out of the scope of this document. -- Mike -----Original Message----- From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 Sent: Tuesday, May 24, 2011 11:28 AM To: George Fletcher Cc: Mike Jones; OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header The "printable non-whitespace ASCII characters" represents the access token= , which is supposed to be opaque. I don't think this affects libraries. Marius On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrote: > Do I understand this correctly that each resource owner can define=20 > it's own format for the "printable non-whitespace ASCII characters"?=20 > It seems like that would make it difficult for clients to use standard=20 > libraries because the Authorization header format could be different=20 > on a per resource/host basis. > > Thanks, > George > > On 5/23/11 3:10 PM, Mike Jones wrote: > > [snip] > > > > The fact that there is no escaping mechanism can potentially create=20 > problems. The list of allowed characters is spelled out, but what if=20 > some implementation uses other characters? Using a name value pair and=20 > proper escaping is much safer IMO. For example: > > Bearer token=3Ddfgh76dfghdfg > > or > > Bearer token=3D"dfgh76dfghdfg" > > > > The value above can be either a token or a quoted string. HTTP header=20 > parsers know how to parse tokens and quoted strings so an implementor=20 > has a better chance of doing it right. > > > > Mark Lentczner started a thread on this regard a few moths ago, James=20 > Manger replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > > > If it is too late to switch to a name/value pair, then I think we=20 > should at least clean up the references. > > The definition allows the access token to be any string of one or more=20 > printable non-whitespace ASCII characters.=A0 Thus, legal access token=20 > strings include ones like the ones you are asking for, such as: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 param=3D"value" > > > > =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 > > > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, May 09, 2011 10:32 AM > To: OAuth WG; Mike Jones > Cc: Mark Lentczner; Manger, James H > Subject: bearer token authorization header > > > > I am working through version 04 of the Bearer Token draft: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 > > > > Not sure how to interpret the authorization header grammar described=20 > in section 2.1. The intent seems to be for something like: > > Bearer dfgh76dfghdfg > > > > After the scheme name, "Bearer", there is a required whitespace=20 > followed by the actual token. The token is represented by a sequence=20 > of printable characters, no escaping. No spaces or other elements are=20 > allowed after the token. Is that correct? > > > > RWS is not defined, I assume it is the "required whitespace" from=20 > section > 1.2.2 of: > > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 > > > > There is a reference to RFC2617, but not sure why. That seems to imply=20 > that a list of values can be specified, which is not the case. > > > > The fact that there is no escaping mechanism can potentially create=20 > problems. The list of allowed characters is spelled out, but what if=20 > some implementation uses other characters? Using a name value pair and=20 > proper escaping is much safer IMO. For example: > > Bearer token=3Ddfgh76dfghdfg > > or > > Bearer token=3D"dfgh76dfghdfg" > > > > The value above can be either a token or a quoted string. HTTP header=20 > parsers know how to parse tokens and quoted strings so an implementor=20 > has a better chance of doing it right. > > > > Mark Lentczner started a thread on this regard a few moths ago, James=20 > Manger replied and suggested something similar: > > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html > > > > If it is too late to switch to a name/value pair, then I think we=20 > should at least clean up the references. > > > > Marius > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From cmortimore@salesforce.com Tue May 24 17:30: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 47FD9E078F for ; Tue, 24 May 2011 17:30:09 -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 GjFWIBLorJvA for ; Tue, 24 May 2011 17:30:08 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by ietfa.amsl.com (Postfix) with SMTP id 2F8CBE078B for ; Tue, 24 May 2011 17:30:07 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKTdxNjundWCwu0dnMpxC4R6EM4iNYezQ5@postini.com; Tue, 24 May 2011 17:30:08 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 24 May 2011 17:30:06 -0700 From: Chuck Mortimore To: "oauth@ietf.org" Date: Tue, 24 May 2011 17:30:05 -0700 Thread-Topic: Text for Native Applications Thread-Index: AcwacuSN23DIGpTmB0CupclgrTTPNA== 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_CA019B9D1A43Dcmortimoresalesforcecom_" MIME-Version: 1.0 Subject: [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, 25 May 2011 00:30:09 -0000 --_000_CA019B9D1A43Dcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of my items from yesterday was to update the text related to native app= lications. Primary goals were to: 1. remove the explicit preference for authorization_code grant type 2. provide a brief overview on means of initiating authorization requests= and receiving callbacks 3. discuss the pros/cons of the different authorization requests and gran= t types Here is suggested text. -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 by= providing a redirection URI identifying a custom URI scheme (registered wi= th the operating system to invoke the native application as handler), or by= providing a redirection URI identifying a server-hosted resource under the= native application's control, which in turn makes the response available t= o the native application (e.g. using the user-agent window title or other l= ocations accessible from outside the user-agent). 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 = during URL loading, 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 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 --_000_CA019B9D1A43Dcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Text for Native Applications One of my items= from yesterday was to update the text related to native applications. &nbs= p; Primary goals were to:

    1. remove the explicit preference for authorization_code grant type
    2. provide a brief overview on means of initiating authorization requests a= nd receiving callbacks
    3. discuss the pros/cons of the different authorization requests and grant = types

    Here is suggested text.

    -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 ar= e examples of how native applications 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 by providing a redirection URI identifying a custom URI s= cheme (registered with the operating system to invoke the native applicatio= n as handler), or by providing a redirection URI identifying a server-hoste= d resource under the native application's control, which in turn makes the = response available to the native application (e.g. using the user-agent win= dow title or other locations accessible from outside the user-agent).
       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 includ= e monitoring state changes emitted during URL loading, accessing the user-a= gent'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-o= ns 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.    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

     --_000_CA019B9D1A43Dcmortimoresalesforcecom_-- From monica.keller@gmail.com Tue May 24 20:16: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 35061E06E3 for ; Tue, 24 May 2011 20:16:50 -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 WAQJ1rNhKC7x for ; Tue, 24 May 2011 20:16:49 -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 92AADE0682 for ; Tue, 24 May 2011 20:16:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so5869543qwc.31 for ; Tue, 24 May 2011 20:16:48 -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=RzSLMWWmsseCzf3E34hIvZ+FycGTbRMQaT3DCMrMdfQ=; b=s9W33FDveOMlWm1PqLxem9Oqh9HbB1G5Hi9CWl5zdbYXNPThfPpZJf9Rb1ChmuFMcY 1ZiE75UgVJdWSlT7hP1udqECOXOjSfyXfv7iARBwobF0PJ4bW+EhqinEvPjpC/HnUauv ybjso363HTJbT/4RNSu+Urq/qUjaSyFhChKBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=phikA6WzvtrmXQ58k495seyLETbB3NovL1IgjuWWrzV57r9AUflUy7mEtLN4dx0jI2 07yn/9pBbsudsWGPGvaRJpSzaiPhEOGqFmEUftR+k5/P20bwP7fYLchGOmTcDbE941Rd kemr2ejVuNDt4tKSl+YJ+QjH8sWZfqvB2nIzg= MIME-Version: 1.0 Received: by 10.229.72.27 with SMTP id k27mr3549315qcj.19.1306293408624; Tue, 24 May 2011 20:16:48 -0700 (PDT) Received: by 10.229.236.201 with HTTP; Tue, 24 May 2011 20:16:48 -0700 (PDT) Date: Tue, 24 May 2011 21:16:48 -0600 Message-ID: From: Monica Wilkinson To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001485f6c84097f15904a4112271 Subject: [OAUTH-WG] Does Section 3 contradict Section 4.2 ? Recommendations 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, 25 May 2011 03:16:50 -0000 --001485f6c84097f15904a4112271 Content-Type: text/plain; charset=ISO-8859-1 Hey guys I am working the engineers at my company to roll out OAuth 2 support for mobile and desktop. One concern is Section 3 of the spec calling out the fact that client id should not be used by itself, however the implicit grant does just that. And the new native apps section does not provide pros and cons of each. Can we get some clarity on what the recommended approach is ? Here are the excerpts: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3 The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2 Example: GET /authorize?response_type=token&*client_id*=s6BhdRkqt 3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com Thanks Monica --001485f6c84097f15904a4112271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey guys I am working the engineers at my company to roll out OAuth 2=20 support for mobile and desktop.

    One concern is Section 3 of the spe= c=20 calling out the fact that client id should not be used by itself,=20 however the implicit grant does just that.
    And the new native apps sect= ion does not provide pros and cons of each. Can we get some clarity on what= the recommended approach is ?
    Here are the excerpts:

    http://tools.ietf.org/html/draft-ietf-oauth-v2-1= 6#section-3
    The client identifier is not a secret, it is exposed to the resource
    = owner, and MUST NOT be used alone for client authentication. Client
    = authentication is accomplished via additional means such as a
    matchin= g client password.

    http://tools.ietf.org/html/draf= t-ietf-oauth-v2-16#section-4.2=
    Example:
    GET /authorize?response_type=3Dtoken&client_id= =3Ds6BhdRkqt
    3&redirect_= uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com
    =
    Thanks
    Monica
    --001485f6c84097f15904a4112271-- From eran@hueniverse.com Tue May 24 20:35: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 B9F23E0751 for ; Tue, 24 May 2011 20:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 7IVxUmgrmand for ; Tue, 24 May 2011 20:35: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 25612E06F3 for ; Tue, 24 May 2011 20:35:40 -0700 (PDT) Received: (qmail 359 invoked from network); 25 May 2011 03:35:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 May 2011 03:35:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 24 May 2011 20:35:16 -0700 From: Eran Hammer-Lahav To: Monica Wilkinson , "oauth@ietf.org" Date: Tue, 24 May 2011 20:35:01 -0700 Thread-Topic: [OAUTH-WG] Does Section 3 contradict Section 4.2 ? Recommendations for Native Apps Thread-Index: AcwaijSSLl8I/vIkR6G30HC6yzU70wAAl/AA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E4D3C@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_90C41DD21FB7C64BB94121FBBC2E723447582E4D3CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Does Section 3 contradict Section 4.2 ? Recommendations 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, 25 May 2011 03:35:40 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4D3CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All section 3 says is that you cannot use it alone for authentication. You = can use it alone, but it is not considered authentication and the client id= entity is nothing more than a hint without other information you can valida= te. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= onica Wilkinson Sent: Tuesday, May 24, 2011 8:17 PM To: oauth@ietf.org Subject: [OAUTH-WG] Does Section 3 contradict Section 4.2 ? Recommendations= for Native Apps Hey guys I am working the engineers at my company to roll out OAuth 2 suppo= rt for mobile and desktop. One concern is Section 3 of the spec calling out the fact that client id sh= ould not be used by itself, however the implicit grant does just that. And the new native apps section does not provide pros and cons of each. Can= we get some clarity on what the recommended approach is ? Here are the excerpts: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3 The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2 Example: GET /authorize?response_type=3Dtoken&client_id=3Ds6BhdRkqt 3&redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com Thanks Monica --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4D3CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    All secti= on 3 says is that you cannot use it alone for authentication. You can use i= t alone, but it is not considered authentication and the client identity is= nothing more than a hint without other information you can validate.<= /o:p>

     

    EHL

     

    From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Monica Wilkinson
    Sent: Tuesday, May 24, 2011 8:17 PM
    To:<= /b> oauth@ietf.org
    Subject: [OAUTH-WG] Does Section 3 contradict = Section 4.2 ? Recommendations for Native Apps

     

    Hey guys= I am working the engineers at my company to roll out OAuth 2 support for m= obile and desktop.

    One concern is Section 3 of the spec calling out= the fact that client id should not be used by itself, however the implicit= grant does just that.
    And the new native apps section does not provide= pros and cons of each. Can we get some clarity on what the recommended app= roach is ?
    Here are the excerpts:

    http://tools.iet= f.org/html/draft-ietf-oauth-v2-16#section-3
    The client identifier is= not a secret, it is exposed to the resource
    owner, and MUST NOT be used= alone for client authentication. Client
    authentication is accomplished = via additional means such as a
    matching client password.

    http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2
    Example:
    GET /authorize?response_type=3Dtoken&client_id= =3Ds6BhdRkqt

    = --_000_90C41DD21FB7C64BB94121FBBC2E723447582E4D3CP3PW5EX1MB01E_-- From SRS0=ydD/36=YP=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Tue May 24 22:30: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 DA587E06EF; Tue, 24 May 2011 22:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 QNTZbnKvXigY; Tue, 24 May 2011 22:30:24 -0700 (PDT) Received: from smtp01.bis7.eu.blackberry.com (smtp01.bis7.eu.blackberry.com [178.239.85.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB2EF13000A; Tue, 24 May 2011 22:30:22 -0700 (PDT) Received: from b17.c11.bise7.blackberry ([192.168.0.117]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p4P5UKNZ016699; Wed, 25 May 2011 05:30:20 GMT Received: from 172.18.204.203 (cmp33.c11.bise7.blackberry [172.18.204.203]) by b17.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p4P5UKwi019037; Wed, 25 May 2011 05:30:20 GMT X-rim-org-msg-ref-id: 623547103 Message-ID: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal To: "Chuck Mortimore" , oauth-bounces@ietf.org, "oauth@ietf.org" From: torsten@lodderstedt.net Date: Wed, 25 May 2011 05:30:21 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Text for Native Applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:31:33 -0000 SGkgQ2h1Y2ssDQoNCm9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgYXV0aHogY29kZSBncmFu dCB0eXBlIGlzIHJlZnJlc2ggdG9rZW4gc3VwcG9ydC4gSSB3b3VsZCBzdWdnZXN0IHRvIG1lbnRp b24gdGhpcyBpbiB0aGUgY29tcGFyaXNpb24gd2l0aCB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZS4N Cg0KcmVnYXJkcywNClRvcnN0ZW4uDQpHZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2 b24gVGVsZWtvbSBEZXV0c2NobGFuZCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+DQpTZW5kZXI6 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcNCkRhdGU6IFR1ZSwgMjQgTWF5IDIwMTEgMTc6MzA6MDUg DQpUbzogb2F1dGhAaWV0Zi5vcmc8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0dd IFRleHQgZm9yIE5hdGl2ZSBBcHBsaWNhdGlvbnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K From mscurtescu@google.com Tue May 24 22: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 9465AE07A5 for ; Tue, 24 May 2011 22:46:21 -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 SqbGsPWa4ve3 for ; Tue, 24 May 2011 22:46:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id E705EE07B1 for ; Tue, 24 May 2011 22:46:19 -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 p4P5kCD7027186 for ; Tue, 24 May 2011 22:46:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306302378; bh=at5t0+CgV53+FKYikvZz61r2DoE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Na7IeDils/Akhv60WAxchfgc8l+FB+O7MUa6I3Cf+WBlXqzSZv6hCotKKU4kzR1ES 3qjq7xVug72jjuI5unXyQ== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by kpbe12.cbf.corp.google.com with ESMTP id p4P5kAwA008070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 22:46:11 -0700 Received: by gwaa12 with SMTP id a12so3741436gwa.14 for ; Tue, 24 May 2011 22:46:10 -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=Emg8toh8K2gjCkoQkwJUXQn9ReDTICmNr+vKshG9mjg=; b=ff/wjElqEtpx/qJXqn4xGaWirmlQiLUUqi1/tY9lWhuSbpmcRP+TipJOHR5lR3PAU3 Ur5UCdGqY+NYwNZHbheA== 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=gkldYoKU3UEnY34HIBZyo7JzTHpL0kYzjUUjMpvT19ZMmqjLj32Tkgdct9lA5sKbBo P1oXtvcAog4bb8Wd/V4w== Received: by 10.101.19.8 with SMTP id w8mr5768142ani.57.1306302370246; Tue, 24 May 2011 22:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.6 with HTTP; Tue, 24 May 2011 22:45:49 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 24 May 2011 22:45:49 -0700 Message-ID: To: Chuck Mortimore Content-Type: multipart/mixed; boundary=005045017138bf72b104a41338fb 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, 25 May 2011 05:46:21 -0000 --005045017138bf72b104a41338fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 24, 2011 at 5:30 PM, Chuck Mortimore wrote: > One of my items from yesterday was to update the text related to native > applications. =A0=A0Primary goals were to: > > remove the explicit preference for authorization_code grant type > provide a brief overview on means of initiating authorization requests an= d > receiving callbacks > discuss the pros/cons of the different authorization requests and grant > types > > Here is suggested text. > > -cmort > > ----------------------------- > > 9. =A0Native 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). > =A0Native applications require special consideration related to security, > platform capabilities, and overall end-user experience. =A0The following = are > examples of how native applications may utilize OAuth: > > =A0=A0=A0o =A0Initiate an Authorization Request using an external user-ag= ent: The > native application can capture the response from the authorization server= by > providing a redirection URI identifying a custom URI scheme (registered w= ith > the operating system to invoke the native application as handler), or by > providing a redirection URI identifying a server-hosted resource under th= e > native application's control, which in turn makes the response available = to > the native application (e.g. using the user-agent window title or other > locations accessible from outside the user-agent). There are other techniques that can be used with an external browser: - monitor cookie jar - copy-and-paste (manual) - automatic copy to clipboard and native app monitors clipboard - local web server (no need for special native app flow, regular web server flow just works) - browser extensions - file:// scheme with local HTML file with JavaScript and corresponding browser plugin (native apps can easily install a plugin) > =A0=A0=A0o =A0Initiate an Authorization Request using an embedded user-ag= ent: =A0The > native application obtains the response by directly communicating with th= e > embedded =A0user-agent. =A0Techniques include monitoring state changes em= itted > during URL loading, accessing the user-agent's cookie jar, etc. Embedded browsers normally also allow the application to see all HTTP headers, in which case there is no need to look at the cookie jar, just monitor Set-Cookie headers. Also, same as with external browsers, the page title can be monitored as we= ll. I am attaching a document I circulated before, it provides details for most of these techniques. That being said, not sure what is the optimal level of details in this case. Maybe mentioning just a few techniques as Chuck did is good enough. Marius --005045017138bf72b104a41338fb Content-Type: application/pdf; name="OAuth2andNativeApps.pdf" Content-Disposition: attachment; filename="OAuth2andNativeApps.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_go3un22u0 JVBERi0xLjQKJeLjz9MKNCAwIG9iago8PC9MZW5ndGggMTE1NTQvRmlsdGVyL0ZsYXRlRGVjb2Rl Pj5zdHJlYW0KeJyVXUmvrslNBrE7LBgklkh3gRik6KPmgSUKmRk6NHQgYYcCQglS2LDhZ/CDKbve k+PyQa7HaqmvdPR8r1wul8t2efjV219+/Zbbl5TCl6//9e2vvn776u1Xb+FLn+nLL9e/4csv3lpM v/6X/v6Lt39/++btP9/il/9+S19+sFD/8RbDl79+++m/hC//un4ev9B///Vvv/7Oxy/fvxWe/79/ 7+f8l0A/WgT9+Xfil1S+fP3z9Sn6a/zS05fW82uML1//8u1PfyP92df/QcT+v9gZXq0f8D+y4DGM A/wTE5zSq7UD/42Jz4uYeuB/aOJLfeV44H/LxNf4mif9f2Di2/p+dnxfMf7bJnisj5cD/5WFTyEc 4O+a4Fg0503KU4p6pdHE56G/by421fQKEZeE1M7F/sgGNy3D/2TiR3iFc6e+Z+JnfuWOMzOH9f2C n6kcu/7+35v4vJiZHfiy+DMP/D+e+Di0+kiTWMrYn/2ZBR75AP+tiR0H9scWdo7XnAf8ny14jEnj jzWmhdBrDOOV08b+hYUd6ZXHAf+hCR+veqB/ZKGX/p3lgP+tCV+iOA/490z4fNV4wH/LgseQXrUd +G/b+KUGBk59jPEVkwefX7U76I9L0s/vJxOf6iue9P+RiV8nr57f/4mNX/zJB/4bE18in1RU1GLp r+HZ3xpe49zfP7DxjS9M+Pttaz6B/76Nz68wHfKwLuR6fv/HJr5HvqYE/p9t/FIfB9xUInSFe7i/ NEM8P/8dE78Oe/OcxnXa+3lavrLwKdTXmDj9aQHnqdr+ysTH+goNV1ZkhESHtKVUXqngpzEt8zI7 tjflqk+LTf86vfPk/3dt/NDSb693ma/Rw//aX+mk52c/M3/QkhYgm6B1HEdyCNw6juqyMwU69aEF yFSfaSwGnQfSvHvTyPq6+ycbP30CPZd+8PBzGT0p4/zJobzyKRB/b+JjeJXuwbdXHfiBycvfCyf+ d2z84k/B+ZPT4g+u/XMu7B6i4pnLYs/JfvM2yiWRQY2fr7wOfHYouLwOfHGYD7mWV3GYD3ld1w5x zsvPUnazTX5b99HA9XPu9TUd0rZOe3FQP7q2hf/BxE/fbZRn0YfX1P5leYnq8Jr0l9D04TWls9Bt HR3fp9v6pP8HJj59uo1MZVXSp9vIFOZCt3XClXnJny4vUzuUZZur02tqh1IqLgylfLq5TEO41E83 l7259dPNZS+2sl8MG8Klde1ImWex9KwdO5s/vemb0aZnFP19WxhG0/yx+Uk3u4f/Szm45GEpB6V8 TNOtLuWg+G8e3rqUQ3fcpEuN1+Vd9AG4IX3pzQNtStoyqdr5cfNULb4vuiXclLNlUKUTbgdXOoUn JNxUyTHk1wk3mR7DJA0r8eaNwtEMz/fjYo6D+mVNjZMc2x1d1tToODNjjmROwVsbcyfrBaeHzK95 4C/BkkzBAIm/BEsmudP4emt6RVw04/K2mmO1ZHs1x+6S8TXwcxh7ek38kMflap28tANbg/WZxP/d NZThEX0KZUxc1iiUoY6i7SmScXTK/h/aoYxETwbw7nLo41yvGWJO6+yWhvMnrbOoVIkdClhnsTvI X0exn0q/AZEMnPzlqCSH5qRIhlJVtqPe+MUGp2d5Kkr12PSQuXPyx3R00zJ3kkM1pz7JVpb4YQcm uv6+Hdmay1aODv7MdVVknD85JM3P37XxTfPTjMPndZOq75u+Sl43aXOslwITPePqJ6/jOAqufigy MXFxyOv0zlM72HGhUl6hO8iv4RVPesy7KNemLYFLHGNS4FXi/8QOHHT9fXu71nFUloapHvK67OaJ Ny0BijQodWJepnl5H8OhfvLkx0ucn7PRM4vEm95lXrfpyc5L5CBqw8p2LkPXpoztzK3LseHKigMN B/z3bq4Nqc8MukGtkGXC2G5ix0vB7VfgwhpBwO2H2kBPKxJuEr7cyeWuSrhpXkQKFE+cmhgDm3cC b5oX/O6acfLJsyFzUOBN+yKmzuYXTH/OFFiWeNszy+11kmPqj1jSKzuoWdZRSQ5qKofRcW7Wqldr vxO2+ErtwNuOXOP8FIm3XZW+b2eY/mUd1VP4TWuHnA/1/csz7WT1Cu/XUq8xOvZrv7tKvGntpLD4 c+6Xae2kdRrV901rJ63TOBzrTSlrbWI7W2ldJ6f8285WThRJh+WB3l3TyR/zeqNktHSu17zf2Ls5 v2/eb6k0egeWePN+I+9m4OKZWng5dCf7Ng0/7ezbdFya2bdx3FzsqziurkTpVNHBnsE5LhJvP+qu q1TRY4Ym0jq9SjvbxuCyjpQ02K+Eoej12sY7PdI6boscC/veKP8p21Dtr73edVfXiWsH9p0c5KRl VzVcmbCr5bDD2HfKDvaT71Qd9JSuL4uLLxQoCQhn/zIGmkM55zrYdUWVZ17GQB+4MiTfbDqks0d6 iIFPYx5Bk29vF7laxbFdZAs4uL88s+y4KvIcHMdDd6ss5VAdVyO7WhmnvyxlokxJm55lOiQHOfGT 7rffdNMn3W8e3rKUQ3FY2iUX9lxh+jPH7FE3p5SsfUBT+MvSDdlxtvhVF7czyjq6yo60HenWKP0K 5+ayBEJzLLc3zZ7LI/DUqsfUDWUMTb/5SFFm1fSb/KFH1+q4imrYb53oeumRtnVc3GpM/AiC7leN nPEB00N7RbdRAUJa+xFYoE2t/DwCC7iZZ/Y8Agu4yfe52SLgphjMzRUBt705yoHvB/7yCjwoZ1vi be942WvjpOcSK+lsbwq8HYtZ3twcB97OSovLnSvDQRAlwTu2Ky53rp4MurzTRn6cgDeAkuCzg35K gj/pscMfShousRVOhMGZs3RyPJlvP0q3oY+WHarqRdNjM3PZX6k4mLmOepoO/qyzXiKuGuLS4TXj +LS8s1Zx+tMywBzbS6GY4djeFLnmCidn2V/zXK7tHC+Dqpx4O5SxDKp6ssd2jund2HEW07KQPGeR QyvTsb11h6rg9dapxd8OHiyTSh13OxRGeXLTIQ896KvOfMygYIxHfJYFNs7tNd80OAH+XK4dG6J3 5uI4LlSuVh3snDtWhYo/xVbmibed3XVXh4yLM8VWYsX5Q7GV4bA1cop6vbY7Snd7wvmZc9Drtd/J c9PrvTxMT847QK1ICq50x/GlYMnwrLduDwc9jrkFx2Y1LsfCid/p7xJvBwp7eqXkYH6vrzTww7jz 5XFe7nx52K7NlOLlUP30iK1U5yUUs18dUPpLqBybQHUD5ctnh2yWpRtKwsWnxJ0jhV69nC/v8LlK 3jlPqOyXddaL42rkfPnu4M8668oPsfer8jM/Kj6lFo6jwttbu1ZV9na1oC03e7mtO/aW0t+bY7H9 k56193Ykzh9DXS6KrORTNu3I0E5nx+mfnSMrqA/LkZWBb1YNncO06GZVyh876TEjbTVp1WkHklJ7 ObhZ18kNDk1S8yfNeY3zbB/8zvk+2F4WcDvQwxW4Em7e/0+gR8D/xozcVP11OylmPwMLuO16L1eR jFOBtzOql5CRsYaSw0k0yUHPUx4g8HacZJcHCLjt2T/lATD5T3mAwF/S/QtnWaCiQ2Ge6OBO2fpe 4O1ACTU9OeB2nGQn+8PMrINtNZiZlHIzHMxZfuUp+XaUZLmJNXrwk201mPx1n7TpYD41Rji/b2fo UBcqDz1ka3pkbdmOHtlPIXHMFT2KXE7g2F4qDzjJsd3uuN/IBd5uLJAK2y7wctN+I0fFJ+X9Rg7T /0SRUE37HkVCL61UJmdPCrydALQOe574aU/rtKvjZUfNKCp0qs5LlGc/esP7tY57P+m/hHmCpt8W 58FtdHD+0IuM46KmvgineNqe6Lqop4Oc9yiPwP/UjtpkjjGjVxG3RZj4crn6oOLakNsiVMd6887n RK0wivIodXJJuZkchUG1P/VFUPTYgZLdFgGXh+X6VQf7l+dXHdqBg0LwWlviN3h4byl9pjh4r/Sm /XFKpHUwZlkBijGX3JmdigTL5RhardlyuTsowGrq6aAAyw13UHCYkE8HBYn/2o7wVPbjBN7OT6DC hoLzkyNCDRcH7ojQcHkouepzfokgffIQ7P0qPg/haYqA01M/uQiXEFLXRrxND2XeFlyRlFY5AIzj h5Z/O+TUi6bn0kQhaQfZ5s/uUIrzfwzltNjiQEEkB/u5J4LjmuYg0rnca+HQOpEBDakEUrZ34+up G/pAI2VDH2ikaugDjRQNfaDNIjwKj5wfv6bBUM3hB9z2t3dnRwG3HcplcoWDi3Y1+9rHmnDa086q BPnIbYqnhNtNDnPmYuoPuN3jkN7gjq/bUamyUyo/4HaHw7qz49Gl1qy+buc21cnpCCjtu50jvE27 m6OA20GF3vk6QJdKmS+HzNjhruUjZcdSl4tUDr7b0S5Ke4k47XNwfB1UMpT0QuH1D/g96QU+2ZTC kuE95QSWBC+U+yR0mI2c7pJxvuTCjhpKe9l1WSjtFNVIONcpqHEcjkuzx8bJrqA8UqvHiKvr94gG ypknQIFy5klb+YDb4adlx8yDmEvSSlPa3eYMBTMqzndqjdBg7U6xjFOhXkIZXSlUu3riiUx8wO3+ i09gAtwmau/YYcZQYc8p7nbzP3o+KPDJ5rIeXMJyiRyxBM2NXHYFK0pM2QWsMDHUZRhVSrlWZUDa WR4tKgvyGo/IBSe9h1fBaaF4BH6LcTyiw2ogL/ek4YYS9XMcEd/TZS2f5/rSnTHwCwBoPVAdD04L VfFEXHpLTKd82V4tPS5EWIFx0AK3qkranX5AcSxpKmIu9T6VHwrQr5eobLYLvKmv22xfxzoNWB7L Otd54hJDman4WSqtqLNkZ8fsfo/wUpcaOJ09M8BeelXE2BI5ojrYl7BD4dcHlPbRPf5VoRRWfJee YmJwl5Zep06SEzHBuAJHos3rdFfgSLh5qgcbjxJuLnNyQb+E22GKsVgo0ZcCnEjdjiT+OoQinNRc mpUslXTAr6GHVnBWUlqGIsf+PsUqTvbYrmHiklGJv9T35KAJMuNgT/MUib+EQ5ripz1Do2S9Xpuf pdLNKvGXPoyRypkk3vbM6XloHnjTaObGjdXBnpbpSsP3t/HrnMTbaUCdu5Dj8raUcU4Ofg7OwcbX O7Kmxw6PDc7ZxuVhTHotxPeXQikH3G7esZuzwMtNrOph7nOmSMG5T4O8XOREfU3YvvG25mBNTpki aeCbRa1i1CVnBz3IoCv4YaHWL9PBfTIAz8/bYY/SNDmXRJGkr65LIkp9FYcqp1Yx0yEMS/VMx7VO eSjBca9T3CZOx9miLt4eYd6mGi49k6PV+Honh6sl3i5xCJX8fJh+SkRpuHTmyEEKWPi5OslBTez6 rJu7xWkoOPM5C8Vxr3AWiuNeoSyUPvDNzYWnG8H3RN4jCnHur7O7fCCc/sqp1bAFnxvnVuP8bJxc DR9eKh8azSH8I2o7zF7v4HkSsFnO8zaqQxlyAZHnNM6pDbFrAdFw3F0lRn21X6I6DruhrMNbHDcX dVqZDmmgwIvyAC+5IklL86U6iXMbJN4M7lGuSK4OfOXRRvBpoejLdJxeGqARHNqN4y8J1z4UUWmO q5F6s3SH+NBN7ZFNKjhyUEOZJR5pppCNg5nU0s1BzTIDFDXXoE3u+F7VpRjKxJlZw3CZDXQr9k5t Eu5yv+t1JNy09wc3+5Jwe5gH9fqSaFPnLLaXA30dTXpSfpnNUekVT+Ivo0y5LYvEX8I8kUoWJN5+ /49cnonTkwLbpujGxtTYNkV3lqM853rtqFnmlvQSb6fU7K4sEn+t16EwBsz/0n301KTpuVbsjFPe btlgpXEVCHZgC1cPM/aPTSy/6ku4nQ+2A7MCbu7qE5gVcDuOy4FZgTa7A1AX6RIP/L2L9Pl9O9JE SV4n/tpFmkQeXS1VwCUP/TTwJnnw20YTeFulFR7ihX+/cNds/Pv0cjwd/KQjUg+8HUhv3H1D4i+R 6L6NNJggKms7N+AyxGYbaQJ/mWLDjbMl3taxY9ATMo6npK/u2GBK43II9G5eJOGXoTedVTLK/qfZ EXx+OfPrxNt5PLt5Ecyep3kRLA5PmRq+3sytXPH1Fq6HkPhLWRvXQ+D01G2tweJQ2VxD74q0jq86 Lbb4tM4BD4G/9FKa+vTawdZeNT22OIxtscHspOijhz9zW2ywOM+mxdnOXwncRw8WNy5rK/h6KZwY 8eVSeDAlXLnlxA0y4O3KyaH5uXFRdfAmV60a7ODasmZbd+zVsk7VVWrja6bSIVg10CTe4GF+49oG +Ozy6N7i2KzOpi9savBEnVMYzHlqM3C/mt4Z+5v/e/HkJPgy6SRyLaHEX1L/qZZQwm2TJ/NcTom/ vI1nljOBtwedUJ5idJBP3cfzgb+MFgksxwJ/aYvQqGQIp4fKIaODniWXoTv42aZer/243LdDJPD2 43IvHGUQePtxefCgPIm3yy9S202z95DW3/yfiwstwTdjP3AkSOAv/nDj5wWBtzlZJ0uCwF8alUbW OAJ/HTJDzgdM//INyPkQ+Isv0dm5FPhL2kNi51Xg7XjH8iUoLUfgLy0p4qs72DM72+KoOFAawyw4 OWTrh5P9l5YU3Aodp2cBR8a3i3yDMR30JE7BhsWHZtK0josDJRrEE28aGKkUfVwuM2ka+waouFF1 SJ8Oftakj9el0erg1AFYfhoPPJV4e0ZRjy+Htkrr9ObkWO7Sy7nj2opKStTxskcOrdM+HNonDZ44 iIvzTBwJgPkzOYkbPo7UOFUdx8vQm04N5WD6aYiNWu+l0WrX6sduFbDUgzrutv2bKrvqAv+Xtj8R 9XG8VK90ThSC+VM4mxvnf8n0dgTLG/krwfX9SeWJsDqkFhwuepY6UfTYhUzLGoiO80vJD2p/L50y Kod6YPzSJ83Dz8GjM+DrncbSqPXaoXiyI6mKs6N25Af4Mql7ea7x+PjFjqlc9SDxZk8/Chr3E3+x 8zjlTcCvIWMSTIG/FAlvwRf4a8i49gN/CRlPNrPh5c7KeQ/wemngUMTpp5AxmbUCb8cU485LQNdL +ao54utNKXDQTOBtu4HsvJMe+2JPg+oEYXmgmHE58ZcE1K7puTbIb83Bz7INH/j7dacvC7xtl6/j Wxsub1Q33E567Bh82wkKAm/bwT1oeuz97dnBnD41Mbbwj6oPry0MgzuQ4sI2uUwaZ/7kOmlYN1OE eTqUFY1hbw5+5sil0jD9OXILUom3o6iJG7/h9Cdu9SLxdtQ1sw8Ok5O3Dw6zp2wfHCa/0DQy+KhQ c/xwcv+SMFl3kBzerjoUPZcEVE5HRm8iKiVOycH93jh3H8Yvl640hzCsw+u52Wk0oEc5ZOpmPHHp oSns6ma3A4DLJMwzUHgUMwkFGDIJJR4xCSUeMQklHjAJJRwxCSUeMQklHjEJJR4xCfHlbpMQX+82 CWF6qNlt6Dg9VMIUT/5fxlGzSSjx9pUeG90q8H5RqDCd+EtTmKrpuYQKI5moOD9zpbQk/PslUlqS xNsm2zYJYXlI657I5/G6dpI52XkrSvIQQ3HC6hCG1hUxlwomrnvGZWdbhPhekUV4yoJt/k7u7Avr ksfCg2UtB+7sC9P/WHjwduUw6Z0ZXi9ZeEo32DZM7JqeywAkrlDD15uapucyMClp3XBpQ1MpzgzL Wy6B4sY4/wsPfIKvXrYJi0N+KpUR4Oys3AkYJ79xbTLOnja0qrrYkEVph4tJyFE8B77p03tpMZN8 p3c2fXovJuTUlsbFhKz69N5NyM7vmKAJ+QGGXqcl3n49ronCABJ/KfofFG+VeDu7nnyVceDtvIDG HdEl3jaBO3dEl/hbauxgo1D84FJlH1/5gF+6FXLaO07/5CYNEm93vA/UGkzCrybkiPhqU4ysNtHt pSr4OfHl0sCEk5zLY3OndA/88znTYzbOzaX1yUiC2Vn49UDibQu48qQ5/PvrdOXi4I86KneLsDmY s3R+chxFfgr2HEV+23UcRX7bPeCXhoGVnsJg5lPHwJhxcuhpN058s+hpdziEjaYlzFPYzK7obLKd 9Nh3eqJ2MvBNQW0GW3Us97Hw4OXmwd4fetPNwC34ni7S98xGAf6NYYKXaT3LgbevRJpZduKvTZDp yhX4S8EZ1/tL/O/a+MJKUOAvfYKS/r79JFq2koLXWwvFByX+kqAWSAIk/tLHh+dhSvwltZGnukm8 nZBH9f71wF9SGxPrBYG3Uxs75/JK/DW1kRphlokajx9gzHgUeMh4FHjIeBR4yHgUeMh4FHjIeBR4 zHgUP0CMRwGHjEeY/sd4FHjEeBRwyHhEV/tuPKLb+248ost9jEcBh4xH+POP8Qhz8zEeYXY+xqPA Q8Yj/P3HeIT5o44KZDzCzHmMR5j5j/EIH8V34xFewDYeBRwyHlHmvxuPKDnvxiO6We/GI0zPYzwK PGQ8CjxiPKI3xbvxCC/3MR7h5T7GI3rTkfGYuYsMaDx+gC/DPB7jUeAvxmDicyXwdp3IYzwKvH1F U31XPPB2ZW/meQg4/VTflQ68fSMWnogg8bbxRfVgJz9tE4BMmPP7l6aUNERBwu+2F3UIQk2vX2Mv ltG6G6pE250oa2Wmf8Av0z+4QkTA7WfWXSAi4BdzNxAHP9C2idkbmzgf8MuT8qTCbvjrg/NSBPzy 4MutNgTclsXJnTYE3D56kxttCPilxjzzayNIewrzdQrYxTZLp4BdCsyHxF5eebmZnoBfjDhOOIa5 soyyNGEBSHkq8bqM/qhUOS3glxzByZc2Skzd79/oFpH9doiXbT0v56gMfKnU9wpfKZlvDf/42C/f H3DbOByTcjlhUV+2WGu4QO4SDfTrT4UGyhkqDq/wnlJpeK2wtPMrbYfZnhOnNaJsJ6NqVpwx6yyF ji+1cKM6VJlS18hTy1yaRsaXY5OoaqLhpFNc4iD92jAyZliZcslExtneK4eb0KV2boQPL3UkdaHa aQbUmKzju0ST73AFSbM8En5S2fgK/PILWl8fYCzwJfBQ4EvgocCXwEOBL4GHAl8CDwW+BB4LfIkf IIEvAYcCXzD9T+BL4JHAl4BDgS90te+BL3R73wNf6HKfwJeAQ4Ev+PNP4Avm5hP4gtn5BL4EHgp8 wd9/Al8wf9RRgQJfMHOewBfM/CfwBR/F98AXvIAd+BJwKPCFMv898IWS8x74QjfrPfAF0/MEvgQe CnwJPBL4Qm+K98AXvNwn8AUv9wl8oTddTywQ/19OGalhDV0n973NzLdMbD+wX1nYMQ7s9y3s0vNL UUr4jy04NU5U+H8w8dRJ+sT/nYlPJ+3fNsGZS3El/hsTvywWCf6RDfawpQV8ezjp//y4KSY05kTh u4mnMSSePfosAybbUyj4YlOsB/gfTXCqekNN4U35BH/PBO+GRDBbqMddSPg2Ub2iwpvbxE3rPPSv ey/kA/8dEz/KS+3UD038rPr75s5SArbCmweKZ0Kc+K9NPAXuT37+xMTnT/w3+UkJyYoe08Ugbb3s Pmgy1HIZl8kh4aarvlzGPA+4ab4t+6TUA263p46Uaivh5gU5uS5Awu1R7FwoCtNOI9EUa+xIPI2N bfhieRr7wMnnmWjZ8f3EhaISf+nUO8hzkXjbUc77goXpz9xKUeLtt4dSqAJO4q/vJs3Df+rUO3Bp 4znrxbHeRmF2Cbf92DbIb5d4Oy6wlGzPDjyNFKuO5S6lXOOBv4z8Clo87dfL2chZgLeL/PZUcXHg xrsV3y5uvBtx9UDNuEbD1QM145oDlwdquuAhJ02a5IIvdzkXyfP9XKkZEb5cmvo1HNtb+stDfuWW BbByo/q61h3cX4e3Oy4LCg2o03Upsft0GV369GZNz7XrwowOfu7x7jh/Bg/chLUPmWwO5cYT20/8 ZcJ7pudYmP1kESrpv5TY8eswzB4KY4+Ei8/T1xenP2XNHzsYnz7dXZeSvKqP16V18KfLy8wbzuXT 5XWpgft0eV3mhGUt/pfWWvxWjK+3JW3rXQbED23r2fJGHpQLP/X3bX4uw7w72DOjOr0XeFNfv88I c2xuoQCXwzIpgfsAwvTwTLHhoCdWbdiaV+MzzR3erLLnf+L050AT12FLrygvxyamBGriJvFmTJXm uSsnzbT6S03UeAGnpw56xIRls7SsLzp7c6kBf3LQ03mQM+xF8dAvh6alqV/Zodlo8vpw3HRlj/PE D9ce5wnf7HWP84T5WWPUhpu53ho5pwjmZ03cEQeWh7puXnUYzcNe6eZ1LHfnXMLkU6hnOSLv05XM o7XHlkm4yck9zV7CTcoHT8KUcDt2Q3PLJNqsY5qdHt4k/DKdPtObucRfhizNV8aXSom9JR74S2SF p81L/H3a/DzwlzFnnfoFSvw9EXjiksCJwB56yBp0yAJVneXo4H/hhy6Jv6R0FMoxw/lT97METP+e To/TT4Mh+oG/jFhK7HvD8rOnzeP0DK5axPk5OPEcl4cZtCqx6Z88wEHiL6En7ssN05P2CylMT1p3 1vn5S6RnPweg7E9xsMkAk0/2o0M8KWVkNAc9Sz3MjosDteNU6sSOfeSpj+Ml1Ta/POykZ5KEn660 tMNwSCdNfBone8y21jwQ/mSP3Y6obwsbZk/PWptcunfu2IfAm0MZKZSktM81lJRP7dxt/KQUIvx4 zcruEyoPFEtKA6efslKyQzxzGA5iaHy8wwjLcWrVeUlJqdoMswNnaWhL6dJ7KVLyH87MzCMZJP4y 8ylo08oOrCz3UplWduBpuZeeq5rSgbvjqqPKbaVMLoGhTtVGOP+fjAyYnl704bp8v78ifhap5Xpy 6GZquZ494kPDHB1HcTbtJ1x6NSUt/Zck5aGl+TJAPricorK0Q3GQv3zX6rjpSmraMLFjH2kH+dGb ruSqDRM71kNvRI6bjubTT8dNV0qnfHhY2p559rByfubZw6eFZhsrQ8mOrdAjUXTwcx12dfOayp8G 1HeHoUexp+FQPmVUrdzs78+kj6+9v3M/UaP7VQMXwMKXUQ1NX9YmP3nmfMeVf13HvZ38tPN9KVgV HRvQEzemfZ+nbR72zrnNEm7PyI4UZpNwOzrUSXFKuJ2qEygILOGmIEx+rJXw2wTuGQ+4Xeu5DMh5 rtV2R2lm6DjwdviAHhfP1dqtoZcUKPrtaFjiKWywJHB4aODcj5mntuH82eEheLueqfaw8FCd+HBI PlX8jI6L/hMewvm/HMAYHfS0ps/WdT5j8qyXwknDsd4+XgU/6k/iEE4+RZO6Qxwmj2HF2T8nvYDA 7OHoUMPFn6JD+fy+ncqxE41gflJr7plwfj6JRjB/dqKRhNuZHDtxyIEfZJRI/GUoX6C0PJz9JWvp t8M9NBA8OdhD4aHiEB8KD00H/Y2LfmDtmZZ2KA0/Lmmd9urQJjQRvGXH98en2+vSzbvr43Wp+M5a nC9T9oIS58uA77VcnDtU8t0aLj0U7+kdl/5nIDgsDZwI5NgtTgQ6d8uOl+Tqkh5OBDrpMZuocPym 46eFZuYFhzKneE9w3O0U74kOQ5XiPak46G+fLi97v9qny+s6Yy97+NO50QRsq1LNeDjl045HDn7b gLVzpsvdoW13qhHO/mULRIeypWbeyaFsKXUoD3y7yrrbx8DFjWYVzvN4ma5LSUmbqvZ6KYs44uJQ ljHQHeqBIkTD4YqUpU6Gw1QtxXETlRrJvceJX5aAx+ct62ZPjrNeGvdDgm+60j/5XTb9u50ufHYL 3ewOWSYf38GdySmsuKitk67sAPPZioM9BedODZmCcxJvPlvV8Ekz24lA1A0u46qqxuFSJZSY5FEl ZAMvTy0jk1V7ofwACTcFeXBuvoTbNWWcaCThpo7aiUYSfk80kmg7thKSpv2SaTSoh53E2753jJp6 O7YSufsHzByKDWV8p2LaKkfgL5lG3IMNJ5+a6Z3fv2QadR89JWh67O0ic3N6vj/ZHBF4u6ipVrYv BP6SCRTZvkCFmZrBzOzgf+s0Kgc+ilTwXTzfX1fQOL9/yWQamh57vwZPhsWP1+DJsDj9S5nM6The k2Ml6PHimrWEixuFktLA2UmhpO7QDhxKOuB2Ys+6UkLEpZlr0LJjuZm7o0v8b9t4LrKS+L+wQz2c e47Tv3PPJf4ytG1o7XPpHxPpvVbim43nuxynf93Tc+DaJPXh0m5Up+/RbjSIzaPdONTjOS6PSYhq t/yYhAJ/qSpL1FYRPl4cHDrgduwjNq2sfvZzO3gTXg72UGxIsf9aJJYd4sNtDIqDnqyV5yW1Zwea UWVIk3y7B1+z/v51Dls+tcl1NO/w4HvQ3/99G5+pFwO+Xb1TKhC+3mWXR4ftQIPblLa9hJImB8ph eii5x2FL0izfeuLt2EHo2g+5xGKCy/QvMWvT347FxKlvO3Oib0lV3162A04jVs/9tcMTyzZXtrPN /7Idapif67aOJ/2mNVDKdsAF3pzlUyo3BMDpb5kaDuD8bFPbtnZAo3NXF4k3a2A4W+eAm41dyij6 82akv9DAQs9y13FMDvGpIWl1ZRdaLVu4OG4XTr7BtVXd3XhhW6BGx9HlPJ1TlZiWQE3cExS3BOo6 uyqAYwfDctGOwjU4RKOOOhAI6/s9VcDtxKH9nCrgdkugQIVwEm4nDnGnKgm3E4cav4YJuB0uCfst VeAvmUP7LVXgbffyyQQS+EvmEBeiSfwlc6ho+m33Owd+rRL4S+ZQ1vRfwkM8KRjnzy4Uw/drF4rB 0hNrZINf4O1wRt0OCMxPygRykP8k9sDk7zoxnByKxpzst1sLUwuhk512NG9ZhNkj/pTt7TjscXKx LC5us2tlcgnfFH48RsWB5jCo42WnulCh2Em/XRlEhWInPy/xm8IWDKprqfArd5z/1Cy4JFweKBVo JlweaCRDKLh6o1Sd5FguZd44jhcVcmWHduDwzXCIQ4+ankshFxd+4evtU9NzyexpuOrnKq7mYOY6 6zE6ZGed3RZxeijW0xy6kDoCdcdVl+n5z2HHZHr+O/nzOzZ+cqIFyk/uQdlx4clkCpzft7371LVu uwR7gjZ9bHoomNQd/M9N68ILPVObGpfEpK6/b8tPzVrXXjoODW0q3QvLHOxsn1S/nWdEwafm+H7n Hjz4dvX6Gq7vD23p2eynh6KM61oKVg3HVc2Fayc9dqkGjb9QDLpUunVN0CW6lfVdfSl1m/yShgoE NTVyqP8Sd14kulzqgaS8RvOphXogKdPT5n/JWduel8ykpm3hS2bS1LbqLTOJEwvg/VquSBsO+pft 08/7yK4FpOSkgh8Aql1rDgVUWtX689I3KWp6bPnsXSsse7+W76JsVTNiQsJZK7lfWLSkcDCYsd8y sbvMSsDNa5d69sQDblLyVGUJuN2emedTSLgpw3Nnqgu4HbrZieoo7XOyQYJ+/T22IvC2M/3EVgTe bnISt0JGyeeqrJMeu70xVWWd3LykxiR+LYT5k7dGFvh7E57kWO9SaOQNwfxcCq06yK/7NQbe3uWc 9ZP9l8yYxolVMD0UW5mO7Vr6qU8HO3d7Zom/ZMY0LkoUeDtUNXnYlwPf9fcv7Zl53BfMH46VePDU ZPHEm/7T01QH5j811Um45nwPraCq8z20ArMz8/RiWPzTOr3NcVFQaEVph0uV1aeL6DLvsvBjMLze 9uluufRn/nS52LGVRpOPcDiFYs7tvUxi6k0f30uV1VT0XKIriaMHsLjt9sw4+7k9M049jVI4V3tp kRM58IeSQ4k0IePKgQY9Vcfdy111Ki4OHFxxbBd14YkOaaAuPOk8XXaXnFz0XX1JpQn8lirwl/bM jZ0VeL/qdg7g9dLoBc/+UppsxsWfuuqo42tnPvWsL0dbfvqny+sSPUhanu0aRqqa8sjP1JeXLQ7r blfiY5M/2WmCt4urpjrO/veqKXS53CbnFOdL8CC4xJn65DSH6U9VU92xveXJY0UvX6qC8tielHmj bE9TnVAmzYy4PDw9mmF5e3o047fp06QZ37AetH6+VE41rW8vlVPcpBkXuPHJN7Irrab2jexYBvW9 caiH8rydoN+vz9sJqm6pT053WBs1ppfDNaLwSuJo//2oPJVKAo5UKgk4Uqkk4EilkoADlUoCDVUq CTxUqSTwUKUSyvn3SiWUOU+lErpT75VKAg9VKgm8+d7zXnkELzdPftAQeDt3gsIrHnjhaBW8XOp5 c8BNBRXrzrQX+Eud0s6ch8lpO/cTFk7KdPHs7pPpgh4tHkyZHeslg606tuupU4K/Tx2Rz/Xeh2VF nJ9ceOQ4XTTlOldcOdCUa4c4JDLYGs6eRAbbwLeXozEOTcvt9XFVlZa7FZLj80uXKFV7CcYErWov LWyaXq5NP9lrJ/svwZuhdecleMP96vH1LvesVYc0P4kusDQ/iS7wepUiv7Q33okuAn9JXCn6nr4U EW3jC7UD3hNR0M16T0RB18uJKNHx/bQf/gT+p3YsYyeKCPwl9tH0zWg7r0/iBypsuewOKqiwZcoZ zY7v112iiqraTMMFcLuEGswEh26gBjOxOZbbd4kqLD59t/9CTew8Ir/Dw/RTxW/EdTOFSmJ30D+L vkkvDWm65s+l6khb/dc0jppw8stytdRNan+f8jgmLg4l7TQXVNXSbCpliF3SMnb3L4G/tBTm7l+o cqasDIddQkkZyhu1S3zqjgMI/DXpgOpSQK948gsyQ4EKDYEGCjQEGqjPEGigPEOgTV1AuC7Rl7ar PPRHwG2TfecP4PDhIoa84SnhtveZEkmIgNvOJyVvHku1fed16A7S7WFI64IdEd5SdoSPr9thheUH zwyLFzXgCIc0XgoyeNIPKuo8uKfhfGwc54J3aZdvCLg5KY+n9hy02/kjNLSn4Yyke/Kg3U5fmJke EGEh2MOcBfzunlb47FFuQZsOeKenf/SoUjftkxjzqO5EAZQxT54AKmFPmgDMx50lgJ49HrxTYfml Ec7z+LrdHYK67U9YIFPNFAKBGUkDnBvOGZrffMiv3aSW0wNgNCXxJVwee1cn9VLWMU9a7FjAqK+C s2VyBxJYYKa+Z2zKZ1d8uXi6WZ1T2/MI/AiDajDuvNpg+eKJzRHmDA9sxs2BnJo6StfiiYDbYFwL cSzV9rjXuT6Pkr1UCkUfu2o7WIX71qESmenGhqV9OcM43eQJ46Zpbhxixb8+yY9ELY3HbYZ3lC53 nPRRlIKxD9IM6lRf+240XK8/05kF/DpSx2EP8qzlin99j1pGGUne7Gmx2e/ySd9JlwYa+k6ye7dS lgBuxtAwndngY8qe77FUM8rI5QX4qabqAtwu4ed+/ILkPqk4X6hLasI3qQ/lFl5G3ER1OOw9Hfys B2/SGPQoCS+VrusM7yl1PG34pcSv/BXeVO6PCutH7o6aYDVQKSEPV5Dr+hqJjNM7yzvnxQq0PdYm 0qkQaHuiMocGBdp08DgdQIBNG3OyrhBoc29oAI4E274dJW9WCTeN4ydQIuD2y+8OlAi4HZygrIEI 7w9nDWQJf4+/ffX2q7fwpS+Z++UbYX/x1mL69b/091+8/fvbN2//uZBfvf0fBLE4nQplbmRzdHJl YW0KZW5kb2JqCjEgMCBvYmoKPDwvUGFyZW50IDUgMCBSL0NvbnRlbnRzIDQgMCBSL1R5cGUvUGFn ZS9SZXNvdXJjZXM8PC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJ XS9Gb250PDwvRjEgMiAwIFIvRjIgMyAwIFI+Pj4+L01lZGlhQm94WzAgMCA2MTIgNzkyXT4+CmVu ZG9iago3IDAgb2JqCjw8L0xlbmd0aCA5Mzc1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtCnic lV1Nj25JbU7Erjch2UfqBUJBIS+nvqu2CAYCBBjmZoYE2CGC0IBENvkj+cGpx+e9067qieuxRpor tZ4+7XLZLttlu/768v0PL6m+tlJfP/z+5YcfXj59+evL9dpGfP3z/Pd6/fKlhvjVv/j5ly9/fPni 5S8v4fV/XuLrTybqTy/hev23l9/87nr9/fz18Ir//vu/vvrO229+/Nb1/P/H7/1BfnLhlyZB3/tk fiC/fvjD/BR+Gl5bfK0jPcLrhz+//NPfXN/58CfQ+rXQnh61avQPLPQIj1w0+lMLHa5LY39tY/uj FJqQEOojZQ3/hQmP1yMmDf+GDc+PsPDwExOewmNo9K9MdL4eeWH5ZzZ8PK6g4b/9rYkv9dEWar5p wmvYqLH5XscjZl4CWtuI+ZEJ7/uu2rRPcVxZY3NyjEfhlxqvthHzuQkP5REWEfvCho+NMz/W8Dgl fNfolh6p3NhmYvtjg//Ugvf86HmBm5SM6zHKAv+GCc+yRQr+7ya8PWrjiQlXEi4q/Oc2forviv+1 iZ+bmlfyf2Hj26Ov3PnCxE+7NALPzRDTY6z8+czEp+tx9QX/AxtfH6vo/MSE5/hI0bFduT9ydiy3 TOPk2d5p+8bgRT/UqX0r+39l44ccIwr/nyZ+mr/QHPT3uIu/zZ9eHi056J8GcxPPT218e4zKi3+8 rl1d1sPq/S8Ul/zH6SVsBJkLhlHe5N9ccIzh4ZDnGNsu/zb5Ux2TQ33jVMdN/n9m4yd7koP+PNmz ysMnJr5c4qTR35/66JHnWIZLnmMt+9n1rza+P4aDnBZ2aTOteWxlP+xs9vQgLoPC/8bGT3YmBz19 PKpnvSM+WnZ8f0z289Y2XZOdq7aYh1Gayn45lpvCdAcdy01hevmOwzrNw93hV6V5VnsOxxSH63BM Ke7Gwf7+NA418LYw5bwr449M/DQO3eEZppIeDlcs1enKrOw0z9I0bUPxsH8qe13Zb3qqaSp7cqx2 euWp8qY2zcC8V4eyTF3fPEN7d0f1KcsMnoLjqMhXftTCm/IcrkdzHI051EdfjY/tauQ4fdXOLzjH squjuQE5BYku2Q3I6V2oY6pXzu9CHZv+XF2hSM7j4XCd8zzaL4d65RofITvYM4/qWB3LneqbAm8e cpvsCY71Ttd8OFyTPPVxc61M85bnWbqFCqarnREpB158CiJlh70qV320zutjCXETH1NbShgua15i 3q25Kc1leual8+JZUnK5SkiwlD69n7NT3rLYkTe0Kff9EivyhjaXieztQokpk1Mk20KJnbmJYm9I SuAKFo22A2+4gk3DD2meLmEcSXmYjmDgWY6kTVx4budI4Nc1mjEhzhgu0dIS4sQtX/8PO2GTN2IO CZhLfEaWkfPMKYXnzDxC6kKMnZwqRUwMC6+SZX9D/72NzhK7sSudxw1Ctzf4d+3Ezgw1Gi9hyAMt tJ/TQLzqSRZoEXfTcQ3TDORlqXYKdNx+9BvcThFMzb4iTXucbuKq2XaCY55KhTd4cR5KlTcEMfRH q/Q2xXkmRV7EPiaLWNrnibTaDZv2NDZVtYnJUdwH0l7H3MV7YGkv953CG9xMk8a6HzU27c+sDyti d9KHJR05nMjTMsO61RCYXljseTMENjHjEqeWJWYkiTFZxswQMEdaBtIVH2Vh+zF7U3likLxp/FKR u2mNVtWE+9/GL3We2YnfJmRiCm1QJQ+zsN109FOeBrXSEpbyPGp4VwlJm+jY1Bn1rRJm0y44epPm kc3bmNSuTXoP+ZdpThcJ+KENn+Z0kQA7eYQj2CG9vW/Sa3o+aWTJdZAHfBp9OwrsSBWZmmVPTY8T iZqwwM0TO4f9oLGzHGE/aOysQtwPGvvr6dqcQtOHzNO5dpwFyOisZ4F5Tf8xoUPaJMnPBJ4zyM8k nvYyNj/MThY9szksMc9kzhvcvOfIU1cbf3R8TOWwS52q3fn47WPih9Um5H34IDvPKDvQVilPzY6R ZnuZmp14WgoKXhaBND19ZHw6f0hKxifQNq/Eu5yGNDOS7+Hj4I/pHtJulOlcOyQMyaEsscGZizMy LAvazuDc+R4FN12NZ8JHwc3jGrLYF7jJlSmMaUHbEfYMDNO6VFPWw5RGHNgKb6c2QpITm6YnVIkN Ff6Q9olilOjvTwHu617ZQX8KEh4qvJ0oSmmnx85BQIbX3T3U9lRecj4W9tCbNQPE4mFmabvgm1ol hT2R16uPhT2s6Adc/hXHenvYhfkfbPyd7lb4QwroTnfT652R4krOz234eER+tajq2UT5kHcJkupg pSHO4C8PfrVxRn/wQRXedKAlsdMc9CCzk3hTIqmd7OBPGi5tkeSOZ7+Q3fHQg/RO4bUx1mvXlkNZ T921xc6qtLibfnu9qJANju+jRDY6+D+1sTsO0jgc51C6rt202YmVK8nFIv/9u0SWXWyabuC2uXaU /yyRpelHiSyvuym+O1kO2ZhpGzovyynV3UmyyU93wTxNTy6SYaHXm++LVFb2UykSuSm8GQPDl40D 6sL5vaiCr0T0+yxSV3CmSF3BmSJ1BWeK1BXcdgWhgmnB21coV33ElRz7NJ8qmHjeSJH6ykv78I9B ErkKb18YTU92/fzhBrOJY63wvzs5siE7uA+Nqg5uPovUafpR91Yd7ETdW1/wtiOOOJWVzICqt1V0 bMd0Hp2hOZg5j05Ye5r4qbd5VRXbEZ8R6wi84oZxV/nR/JmO7NUd9CA32nn+4H6y8eyJ4RJPgSU/ zqC1N17V0TU0hoP8WKXBQeEPBedR4iAe3yXDxG5vnLqVq4OfKDjvDn6WJBXSrO5KwXlx0IOrR4f6 yt1jcuwXbh+z4/tTHQNvHeDIRocplILzdbvs+noknKIDjxqj5hCfqb19FX/bOcKVZeG/L3eWDnWX W8iVnmMFeXf4JU/fV8F/efJlr8pL20dfljWeuIqsnbdWuIvsvLR9vIukuf+8jKR3t8ZHdhgTqSB3 OCZSQe4wJgnNsY3XXikJHw76p/aOlX77zhNnqYefKAl38DNPbdz291BC3iQtwRrzjMPUwf8c7pJ5 VntzTHKlxlqfPA/fOhz0z8O3r9bcLgFOZQ8rDvj2cBhb3E9u5NjLndruUa+Msz3x4okbzU29DhX/ uKR0WNs89T06wkApOXc4e7ll6UBQ+EOJ+tgDC3vD+qq8dv8ELnuiY7G4enQIf7nCw+GolqvvIbhd 3x3uAkyWNyXcFZjsXsGLmVF+jTfWLF+b2wQzq+AmKdMqw8oquCn2z0s5BbdTGUVsrIIfGuIvsbEs 8UhlwMYqvJ07mAFRWXlp1zOHu62EpidGScXQ9ERpWVRwu4oY1diF575MAgkL3syCBdSCreTbqR7k JoqDPchNVAf96Mlb2W+nA5CeWMXHTjcgPbHSY+ducC+38tPO3cAFqw5xQ2F2dfBzumC4GaL5iYEm ycGfqe153V+7Jh7pjMrjkc6oDmsSny6Ywts3PdMF28zPoUB7iAuv8GYmNaIpb+W/PZAgtl2e7QAZ FV/ZwR+UfA1ePuUmL/P6hQb9WnhzHksQl4fVL9zkbfpl34yWJvkPer9qknwVLT9T3/Nw0N/uAJ/e rzb56fl8382JnZ7rWTpaWHOC+u4+HOTPCG0Unv24K7waLz7pKlJFxdKPou06ePFJ4S6bYNebQn9k frtSvGdZsdYnPZsEaXJwV7hac7OEBvmV7bS26clx1y6bnmkdRnLwJ/fH6A56cFfoIKf0/TC18yU1 uw7TVNt+mHY7v1L275dTfiWuh8X3bPzY6Tm00Eepr6T5g8N95b+dz8DhvtJzqLV+5/vb8SvyK7z0 S3ol8sYB6ZVNG+2IFNfSfByFbEmPjtWmviujTc50zbejzt4tHNUO7crzqPZoV56ueVzZaWfbatnP rkMJeJcredb1QbZko8fuM2h1p8deb5cGdJr8XqQVgCa/70eRncsbeY97TWko17uj5VCrnfaT1y7W vobkP1j6C07qwNuSEu8SPtZzkHpth+1p8bUgcdJurHmrhDu0usBNu3NXomi4XYItlSgabt7JjBVr 527aTvihTOSCBdH4Q9N9RQpP4w8V1VLZRTNScjfB8f07d6Pxh2RMQSqMZieSN3Fl/yEZIy3jPD/R mdcd682YH8WTj+uwlf32sMHpfkUHNei2W3fLrsdHv11ykI+Gu7HgD5Uo47Ey3858oOMuOvAYfbgK g13RPg14XDfXzjyNisY1jT/0ycddGQ+FKH1XRjt0RU01T368785oKyiFKOt2HQYr1l1XDiXVA0Vh PHvuuzCePShcCQ56pq6n5vg+Cl0ib0uk0CXz2iuTFauD/iI1nBpvxk5xxlrb983Y6U6saLgZOmHy YXPYwmdihbaFUlgSHeI/5F6Itg7xnr5E4yURU/j1StH2+v1D4qbv9By77bfttUPR0Hb+H6qwAzoc eHpQte1gD7xHh6ckiRuHpySJG4enJIkbD/1I3CzwaCdWpGpO479lJ0rmWbfAD5MVJUnOc3N6AqM5 uNkkSc5zp19IYmv8oS6moiCYF+YhkwDps0vyMPzJni+HHZdueochRA4mNN4Q5qmIwWEIJQnj0Cyp cXGcc6hxaQ4vElmbNhz0pL5r4qGr/p3Pf2irf+fzn7M2mTfk6MOvDr9Hsjbres1wFDUowxEl5HlQ X44QNs+DetN1W1m6zNmgD1KUrVwOvxZ5mOyI0SQPw5sGmZLoOHeRhmmNZ6f02K/qYs4lQ9qmd950 luiwPWjJvxx2tqSw2yp7xmOSaeE0PXDwWkCa7XzGoU56hZuk3H32Gm6X9EifvYbbjfMyK1HD7bRQ R02Jhh8a5wvKFDXerpOTGp3E0yOd9n3B23mqu9Ne4+28yt1pT3P/OTKRpx9FOut6D53zXZx3hT+M Qcwi9zR/kBdape3QoCRjFjXeLnIpZafnkBmSTD3PzypjRnj+NHkASePt1E2ru7wdUkMyPpGnv99n KE0/UknNIT94RaPz5gFFOoEnHzU6ofLkS42OQ31jkBomnh7U9AzH96e6Z4d5iFFqnmhxRk1PdYgz ano2a37oaUq7OT/U9EjZOS8ORSa18/QXmdROn3WxyqR2nv9TfTfzfJioKJPaNd7O3dzd9vx67257 Xv5H5jfr2W1PE/PstqeJeXbb07Yt3Q9S8fgoQI0/JG4K7gnpzU1Jxq7z9Ezlyh56ctiF3+4hwsTi 5OA/ztLCG6tUpm/C2wYZgOgRH2RuuoM9d4sST89dH0vbhtTenS12Kqm/O1vsvOjzFodmPwYnOmx5 wlGdHOKJo9rhCqDk5lrl4VATc+3qdUgPzbN3gZ+GNRQ8gUYOKSs54kpPsMnEDnHwFNyUSnBcYU8z 6cNKiSmQM5yvK/wfTfgllQZ9CPZv/9eOm7oGn+7G5YVQjT9MD5PeRo23+zKizPTW+EMQNw3x9gcO QVCWg0fh7SBlGm7cPyq8PRUhy7xVnp4sk701/hAEdfGiFN5MfOF2HMUGCn+YNp/lQlHh7fviKs1+ vAA1afbj6e9hX++hU6HLwanwhyBFKsFpeYD5mIHENAuUqUH7WHt+99sHUzP9Mw23zYc0U2m4ucq7 mUrDbWvTEDlo+MnaIP8ZC2ltFPj0rOiFEEnjbeWbx8YMkXj8DMHqSo+tHMi4LPBjwmVGSBp/GG2I QdAafpicOFzU3Jd1Gm9rxm1peGaWAs3TeNuywjJlB/1IzyzwwyjE+mgOUatjp8ZeLYqsq2OzukSP Gn+wYxI9arw9AGckByvxCNoqCocinIjoTuPt9per45ClRQFFO6nwzI+hIZOm8eYhgiqcmhzrTfIg JE8/aqx5PUcRTsy8KCPTspFjkz+Du1552Y8zuEvBg5duTI23nTQcEBVV6+T58BX29Eq1OKMKbqtg GHCiFfyQXhdXVMEPHbbjsaAPR4M0PCq4fTUwJaY0DT9m4qdTRjOmSHRG014S9l3BD3YesZxCHybS RiRKaFpqwT2ngtuHAko4Ok/MXcGh4IcEfIIvqeCH2KXLPE6F/6ZttSNq8WhqpvuWBy0z0iIbaJnB xK8QaCGId/0Gq3vIpcdOSwFS6SnT24pMOo4PUrNxGgReJHEYhIV2+2zKeaP9UAB5bbTbXy+7zTs+ LO2wedK2qtH2sddud/gNbs5HjE0ib5oxU/lWxpjKhOx5SLz8jmvb1MMD76NIZEHqKp6I7vRSEVfi bvPrXD0Y/x0bE0rABfstC9ujqLSC/9qCT5bUusC/MOEyHFvDf2XBw5XEAVb4X5p4pAzX7//AxMe8 r9YkH7Ffawv+ZyZ+Wo2NPZ+YeDxRWBa8ubHhaTfo75fbitH8rzIgWOM/s/EySl7jVxV59ws4XNcN +KaJ72EnyN5gvPe3bsCnJn70nZ4fWXh5k6/x9CPI2RhkMhRnYHOsN95PgWj85yY+SVM6rQBxCujG n6OVuqQqTrDEVGQNJ6YiazgxFVnDianIGm4egkPes6aJgV1rY8EfJhXJTanGH4IiuSnV+EOOTWYz avzhXdcLZVk0N/Fs7Fj5Y7utGObYF/xhLHJ9rKJzeN5DpiLz23W/8MEvtwTxuuntKtJRwYtDlQ4J nv6nWaa/3zIKlfn1NumQ0Ph/OcZInu3t4mIquF3zNZV38F9/vtqq8fWU2Ep1wR/nAvXK2xIktspK z6F9TdrRaOV6tqPRyv5sR6OlQUIlD//vdjSNP9QQZVyAavyhhujCnByNN9+fkTnKC/w8Rjk6tncq b+oOduJBkJX9v/2OHTMl1C3Qxv9uX+O3625fo40JgqzoONflIVePuA15r5QX5zHEx2b39zkXiKZH 2tEibx7SM4FJ03PfptPqLu+5rvtrh60oa9rs1WEykLRV0BuAMqjNGThMUhYgfdrJKGWHc5KQyqy8 vcVkoOawV1LXtPLHHOGA0UC9OwSiORzV1OTBU423x2pj7nLkrQPmAo3sEIaRHJwfZTeFh9ddg1wF szuFocvVYZpliFDiF4sGts3tPwx1Hi43O8e4ewLHBrbLYZrRwBYcMRca0qIj6Mo57J6A3TCW5fFT 3rTl5yUX/Qcw8i84GFovVMfzDKpSsEZrI+YCBQ9D23g4jiJc5q3U2/1oSJ8WXn2f/W70yZXHO0Nr Nv9g7HJPvHrhzdfNVtk9XfOkvhyOPOYuN4ejWu6sisabFY9lqu/ghWE6bbDOpdC5GA0ncjEaTuRi NJzIxWi4XbNyv1Cl8YcXreSFKo0nXqjScLugJwRclGv8YQp028k5XFEn+Hc0N8OUmhwd7JlGv6yb e8jdyNxQHo+xzm3BH55blXiC5z+q3Fd67OvhIuMweP7cHWO8+KBjzCM/VWbBafzhvhqz4HhtaWPX rkPDWETVN08+XnNdv2/nnsblowcPd6z02B02yPYEfnulwyzx2xvvKnda3GIoKNOgTW2MAS4JzX95 z7Xw8hDThQIDjTdzqTFVFF/Q+/WcAs3zE++5OtiTpZyCtp7ynGtykF+kRpjfXmR7Bm/d5JEth3XA I1ub9bGTf3iHY6XH9Kliv3b1tbNhXarsePXCsKJVPO3s2ai42dB4ez4KXsFy7K9kezrPf2R7rsSr l2R7HL4Phg85DusEZyA6Po/kUOfFM0Xp6aLFQXJD2YFHy1vhxRmvbIXVWp2ahFJjGANglSobwRId Qhp+6hDSWKJDSMOJDiENP9XsyzSmINhzTaYCHy7Y7pymxh9q8CWn6cBXXFtrvF0YjUrLtuAPlZlF rIbC2xd4eBxupd92ciC2K/7wlImkKDXerkNFI1xyrLcM5CF4evCUyQL/je1jhsdK/WHmQZPok6YG Ocrk4E5vj1V4Dh6spDR5cob05Wi87XFd0pij8YfpmZKlpOkBK9GpTD79lEKFiRcs0a2k4US3koYT 3UoaTnQrafjR8mEIKVuNrsCn96hvy6fwTG+kxh8qzBOiOwU/GD55UljjD4bvjqYU/tAZWSU6UvhD Z2SUaISmBy/CL/BD7H49uoMamMmVO4e+yIQBXBp/KO6e3nnJjuWi2Xk42N9kfAW/YDQgNQc99+2P xh8anIa4nzyDRnb9gXhd+x+wo8dLLts13g4Hr/FY+WlXVoc718XyE8F7i7w8o5wvrvjDk09jp+fQ hBQfgZd/6VlaybGDx7s8lRbPZ107bTwxHaZ03njG+s7Y2pUjVa7O+e1FKfzKT/sJ6Ha7pTT9zWdt Y39nbW1xHmGn/1B6kXf6//kUjG/fN28hMCBmW+9lB8vScqjx9iM2MbvWi9G723oPA1/Sbs4Pb1Kj 9l/D7SeWctmN56EwIojHpvB/Z+MdJzWmvVwOWcPg3RgcvGlJ0ub00ZJal6iAXkAPktlTeDuT06VU nOf+eOcZ2nfDl89Y5ctnrPJUrhx5Y5XDO2Nl3w6HvDtXhyeNgmTSWFcAxQtlxZue+XT5UYrWIuny K/BpxGNAZKPxh/EpkrPSeDt6xoCC5qAHPatpwR+fCmljwdtO9j09ReMPPv881Rf44T5QhqFoPDMM hWc/RhSs22uHUDJygOcmZqdUx27hYbfg4CaeFvHs7vQZsmd3MWtlxdvXsT3v9ByyKRUlMrw4jLjT Y0+AHQO18TQ/41VQG6/xhwmSMqZA4w/V3AXHBC1uCBGCY39xvxc6v78SInTHemWsgYYfirMDrD5P PmaQN3578cjrNXhtx31dDA56ECKs9BwGSBZE1Dw9TYbcOfAe5ndxMfjF9ncnkc38kXbLf+qAfXe0 HG7fpDuYVt50tV16jk9/XCuD7NLjIHl6erdw/bYZ/8PEyerSlhQlT08rL97y2LTlcJ0Wd2054Duc clpbUGrdV/whAqnwyXn+FMlJ08YQIyRzdvCzSUExrZAYIbkZ2+PrH5vrdhghmXbjb8tnH7sCH14L kT5Cjf/5KWYZgd/ffKVdfw8xS9v1166XDRXFOPR6UUC9OWOHguIoBcL8AtKF3gpagHKqu8LbQWOe AuGBj13f7Rhz+s7J4Zzk0lFtQtvnXMOuj3aBfG27Ph7qoeXJTZ4/eIc1O7arx/38OhRcd5czKS+A RI98jrYHU6ZBl6dVE79hCKqb2CAyqH4DH8oS73s0jWfu0TT+ECTfrozC22HLPQhK4+0q3nskqcbb Uek9YlTjDxdjl1hmmj9ZsiUab4ddJaKiwYHvGG3H0383RWm8PQL0Htqk8XZFBoY3L/DDxRWqDHnp 6QX3LPxq7yFPvDQMqUqktQXXYqPwy8XYilx4bsYQxc4q/CHoldd26fXK7CaH9MepjZlXXlyj9cJv L2pgh4OalNB2pfF2yWyW6QY8N+/Rf7SuP0f/afwhpi7ihdHSg1O6OfhT8257bPbjVF/5f3iUYfLH IWxt7KbnECVHCdlZUxj7cOztiLslsdNVQ4bA08SkKz82euwIIUh5PE0/6lmrQxbS3RNFywK6nZuH fumJ0nAzt55QGOigJhVcUPOrxcjGVdTs1t8c0GvOcz+X3cuw8yUl7Hb2cEl37fQfnnBIO/2H+Hug 3Ejj7Xj3fgyANvy4NNwss60t/Z1lNi2nvL7pYP+4w0vWkOPxzZx4cchXlHSPwh+uDLuEfwpvh+uY XuVQdlwBpsiLA/qdN8tsXzHGuNNzeOAzu9wwidYdbphE6w4/I+fLwczpBVyrLB+ao/vus9nETNtQ HREXeqM9lhy90R5LLr3RwcGfOnZdt4WtvbPl9np7QLERLwyIoR3kjwuNMLTTk8d9j8ays1z3PRqr W+Uqu+0xTScyATMGrInNBLyBDxWv93PdGn+8Xm/r9z+cMgFjgduB5V1Rq/GHef5RxIxeLipqo2O5 SNnnBX9sPWgr/tAagJJaDbdHe8mgZw0/NM9KRZjG22kVPNcdHN9vGUUlGm/O9sLtd2oL/nBbfmsh vbtDnhvlpQe33yv7D7flQzwAhT/Ux0a0o9HSILflwfP9LhdiCn8Y6p9Rr8vTg0cAVmm2Q1088V14 7ZLb8uag537im//+/WS3xh9nn43Ky3+8n+zm+YPr8gV+eARAXuzml4vb8pV8uxjieVtOsx8vfDvU S8ZLdwf7+xQfBznTOmzSdrhfj7u0HZthU+K1S+pvV3rMXvkULrm+Yc8WPNDYBy8OafrvV+DXiwca PdqIbtVNGw/hfRAXleYnJpk5yMnXrrx2dJzr7jocovsoHip7WKBkd+XmoaIWpW2O5VYZZMJzv10S HdPLRWVbctDTBiYV8OzveT97D5fxbafHTk70sfsOh/cZi3jwrDVBNsDBTkkGrNtrx0NBmjto5c2h 84a/RTnqvnauUXg/3R73E+1ZBPxtC3tPt9dwYrq9hpvTtJGuKQvcniZ/pZ0aexr7MxJSeHsa/j3d XuPtafKxL+Bugqfnsn28mPh8i5fCf9fEl3dbZRNfVs5UEzz9EMiuwttz8xEFr8T/1MTfY+o1/sc2 XsbU0zuLITYj/P/f/xp1kjk5T9UjRn9pODH6S8OJ0V8aToz+0nBm9JfGM6O/NJ4Y/aXhzOgvjWdG f9HMfI7+orn5HP3Fs+ce/aXxzOgvHn+P/uLpzw35WI0/jEGQOew8P+857Bpvj7moCf4lLw8Ym7Cu 9zCHPcDf5cXzntvOr7dfiD55ft6zvHj671le/P4OSXHz8ola/85/H9mOuMrzcdJCW/GHMgmZ9E7z B5PbN/09TGKXbJnGH9+4Kqs82P2fM56pw8HPfO32rdv4vn+/mPhSkV7Q+O/a+OGjv8ad/kPhQ9/t sy0/KExY8YdCBokIaP2NvSBC4fd3yINR9PdRjh8d9hnFBiny8ozy/dR5/qSA9AttHhLeegwOcu5G O365d6OdxtvplJT279sBIq4CVvrtADTJjR+Pzw7bLFPYXR+vrr1CvWHkTa3kLlbTcBjCnvejzg7+ kYxwqK4kIzyyM1V9M822bHbJ7fD0oOLQoen3HA6e/NGQmKW3Vwr9V8tsj36+X5Z04KXgkJbOjMEd DlVEc3KIvPigOXkTZ5s/970BLQ45FWQqefoxuWP9vp0MwuSOwqtXxuQOh/jnklDIw9N/lyjy/Jme wLV+3y6WQIli5PVFGgmyQ96mJ3Ct+2U322PSx/p9uzJHBr3z7L8Hg/DigD6Flf3nPoXsoGeUnT32 JHY4Jo7Dq0zHZHNkTOtZcPHReXEoYT/s7NqKaX2GI64u09HYzl6bnBT2uMgeVJ/eJXFOU+JC60im n7dq4sIKN5eK58QzDx/3Ka3g5vjPuUD4PApuZ5/uM13BzcyZ5HP7grdnxd3ZJAU/FLYUyd6w1Icg QI0/jJaT1z14eqLc7Wv8YRZdFiOi8IfKGRnmx9OPlpjuoH96qCv5h9lyuE7R8MOL5zJGXuO/b+eG 7lhL4e06JMyNGA7uNJmsy3O/SaxFC1uTq26NN2MhSSUtcHvqxZDGPZ47U3Xbqlv2FItnJomVZamD GTx75M3AwtOPOpjN9BwzSaPxsi9vAHrov98ApKUfdTCRt4TyBGDkhVMST9XBnqnqm6k6JLbGTo/9 /ZJ3U3WYCn/t37f5U+Wqm9/eFndttBNDeNMvOL7f70Q8e+7CYagJpTmccwH2P69+icnbGn6avK2x xORtDScmb2v4af5suJ0uYM/VsgpMTd7WeGbytgMvk7c1npm8rfHM5G2NZyZvazwzeVvjmcnbGs9M 3ubXe0/e5umRydsaTkze1nBm8jZPzT15m+eOTN7WcGbyNk/OPXlb45nJ2xrPTN6m6QErp36xVm/6 FB/fJiAGb2s4MXhbw4nB2xpODN7W8JPhG5inxpm9r6DUsIA3NGPy3tDHp8unp/eGts3LPUvvDX2Y ni3jjt7Qh9t4GXbE8gT5es1B20zjzVSaENT4a/TBIoqFYwkR+8buTR2Isd7QdsghIwHYNeKJcr3G wxzrLlUzLN0T1xotJfcwAFK6n6MASErildl9FOOnibY9RDx1qnfd7ohH+KLAh25+GRZAauSz95/k 9d35z64xyTQiln8zZqmd3pi7559dJOb4aLR9jM1oZfn2IfaQkUUsT9C1p6XEjjvuNDf77TtrTfJk njTz67WSR80b9uAi3WeNgjOHjYIfzg8ZM0PD7ykzCn7IqCWIoILbozTTeCzow7uMcaPlkH3rqH1R 8IOfLKPJacYUaR6liamS+VZwOxVYpa5GwQ+zaOSVBgU/ZOo66uDpTe2SC1Hww+iahIllCn462cZG zeFoi0jy0sTjbOO3VZ5/8MDL9vVD0i0gdmOFBo8/XIUn5m49YxmJDF2l+Yj83EqL/fCAvPtAk5Ik la3gh/Ez8iAq/fUs76EquB2z4aa58JuEJyIWebRfB61S4Uh/HdfAidZstKfNWILmTJOZYDTfp2bn ZamnMTWYskPD8Rg3T/rom1GyXzLAlJpO8xGPLpZMM0Zm1CzE2EM9MHKm03qNiTMOcccI11XcDxNc yybudpnTPUCGJiZL2pIV9zR1b/VO7OE6U/cc3glKuurg+T5VNSxwu4AK3WgOYurYiDkMei2rq2SL e5ch2fQu3Y1oNGOG3IOyzoy0lS1we+7EPWOGFZnniBkFPwxslYrQr/n6py9/fZke/WTbn1+A/fKl Tjf847/4+Zcvf3z54uUvE/npy/8BHhyQCAplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKPDwvUGFy ZW50IDUgMCBSL0NvbnRlbnRzIDcgMCBSL1R5cGUvUGFnZS9SZXNvdXJjZXM8PC9Qcm9jU2V0IFsv UERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXS9Gb250PDwvRjEgMiAwIFIvRjIgMyAw IFI+Pj4+L01lZGlhQm94WzAgMCA2MTIgNzkyXT4+CmVuZG9iago5IDAgb2JqCjw8L0xlbmd0aCA3 MzMxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtCniclV3Jjm7HbXaQXWeRYR+gNzEcIDmqecjS sGTH8SRHtmJL3hmKYUgG5E1eJM+S5wvJ8/f9WXWvWR8hQA00vj6XxeJcLNa3L9//7CW3117b62e/ f/n4s5dPX759Ca99ptdv6Gd4/fqlxfTuJ//+65c/vHz+8qeX+Po/L+n1x4T640sMrz99+eJ34fX3 9Ofxlf/783+/+87zL9++FR7/f/veV/KbwH9EBH30SXqN8fWzr+hT/Nv4Ogka5jWIym9evvdX//vP n/2Rif0gNoahwd/5oQmO5WLqFP6XJj6FK5UF/yMb365cF/yvTXyO11jxf23jyzXjgv/UxJd4hexY b+lXXNf7uYmvxB8H+TVfqS3435r4Fi/PbrV+5RX/KxPfwzVX6fmZjW9XGY7l9nnVlZs/MPGjXq05 pGfGKzYHPbNcKeLsTyHt3zelP4Vxpb7gf27iY7h68uCza70ptis55CeldOWMa1dK4yoO7U2k7TXi 1irlfrXs4H/JVy+4/KQyd+tmyn+qZf++aR1S7ddwsL/la67b9Z8mntQ3FAf7e77CxNUxkfpu6mLT Q+q7iY+NJ/Utnu2a7ZqO9eYQ8MXm0HbPaBKTY7yaw/Rn8ryt48KQyfP2ietiJs+7eUabnjSv2fHN yrldW6TxHya+JI/rymXsrsteLqlicQQmuYWrOgITMsttVibpfVZymLBjW7mBH1nAITS8w/7SxM4r PqGfWFBSizGf2B9Y2BhIDMcT/HMbPK7an2CTCzGmq7Qn+N9McKqsDe/APzLBOS9f/tgEk9yFiNJc 6qU410xsrVfKKMlkyoMSi1/ZYHKjihm/McEUg6WKkjEKe4gPk/EhkS+F41PBdhM7rg1uGgMiY5QF birrpLC0LnDTlFFUxzuu4HZOEMIV84K3o9Jwc1zh7ZyAbMz6+Z/YKVm8+vr539j4vpNzSMnyRSkv zE1O4UpysCcnDvI13nQkMQ8O8nE8AXt30E8p3Fj5bycRlJPl7NjeSinudPCnEX8WuJ2TNYpDuoOc NjnGx5fby666hxyuX304ljvyNR2fH23XdTMFiuQXV2GzM2Ly4XW1DZ9Y+BTibkvsEDn03ZbYGRzZ hjpw9iRyqm39vp2xUtS4fd/OmEjZ27pdH5t4UvYRHfTneo2OS2cq8crdQT8pexm4dqUar+gwtomU vTmMbSJl34yVTQ9pe8kOfpK2b+u1U8pOcRbuGtOILuOQyLFvxuGQwYUrecif79naX9hJHKl7w7dL kjiHb+EkrjtCB07ihkPc8l0+xb9P6lhW+s1YI9/lU9hc5dx99JS802Oak1zIHE4HPTVxORff3zp2 dbf3l+utK3/spPguuMLynHvmrBU2D5mc70qOGQtkSjCjI9TL5KuTI9TL5Hy3UMlO0sn7lpX9Zr2v kPetDnUsnMw6QrdC3rqt5sdMW0rMl8OZlji5foeTnxKXYGBpKOysHWlUIevQPeynyHw4rElhZ50c 9BNwevjJzhqP3Qr7aocw1Lm79u+b+FZ31/5fJr5HKcvA3CFXXauD+90RRxZy7GH9uBlHlo1ym5K7 jgtb8TJJrYYH33azYy92kpkauBWvHDXgRrzelV+YPZWChuAIwioFDXHgglwpwU8FZ08lM5Km5/tz DwJs/lDMXxxWnANO+id6BGghHWFWKrhdd4qSSyu4uVPkDttKjBnNcol2hdtlqrQTY359dglNFdwu 84TM5wUab9cZyBeyb1b4Q9kpSaIO00POMHQHPeQMe1nwf3+Smlg53MEkLATeW8FmE0vCXha4STZX mhTWVIyHvCi4LQBFpFHB/9Eumr7W0ZjnjD33jCjwd35s76T0jGg80jPiwEvSo/F2D8ud9Gj8oWeE zHte8Kbj5p6RttJvV9TunhGNtzXjbgLReFszKK6Z2bFeCmzmcNDDFccF/oVdECT2LHC7fMv1w+Sg hozwyA7ujH6twmNX20kJp2ezKPYI63LtCgq3jKzMPxQcJSWB6WFW0gbUD51LfgjLsjNu7HcPZo/Z ouC2Kbu5ouAmV+bNFAU/ur4VfrR8JXEdDbR8T/DhpOhh+RTern0/LJ/C27V7jtzmgreFN1X2kRpv ++wcd3psYb/LPRp/OGoJV4kO/pQmlljhbdtRk1hiHD+u3hz0N0rRkkMeWhctgfnZC2ddOJ7rN33B 255wtF1+jv1yfTr4QyHIqA55JsVdP29Xd0PhQ3KYHLaVm/raxXhul1vpMavH0v62io99GJLk3B6n JxeudsLbm0i9enTwh9vfOq6O3P42huP7pI6b+NuHUS3s3z8cnnQH83vebfOh+a3tumUfVQw5GsCJ pzhk0y375IeLJg235dL81nB6MuWDoeP0sBNNnStWoBN9gg8ntjFwdUjj7XQgNj7D0XgzguLEMaz4 g5MeEozA9GdJwDT+kG5kiV4U/t9tfBOnrvB2EJDnTr8dIJMEjPX7thMqQwRN4e0edQ7THOy/O6Nw 9jepJjnwnY+48O3iHvj1+6aTEB+dHesd0j2k8V9+eXTS1bEAdtIL3LabIfAhBczPFKR9CFZf7nAo A1ffFOVQQOPtHmyKsbfv23afYuxa8P1KaXJ7Ek5/liIUjienvn3/0OHQxKkrvO23yEknF77v3z90 IATJzxXe7oEnfR/TIT89OIjhjvbmEGY+Y3HQMuJu+u29pRggJoesTanc4+TPursWmz1z7K7FNOXc A799/9A+kTymJ8exm55Di3rcTbPdkk/AzVXY5JOnrqto2qfxue+m3O7mKGm35DY9Rc5fYXq4vkMp TkY6nQlbhjRP3C7oexaYxJ4+qvG/sOBTTh403O7QDmn/vN3ETAFkXMn/oY0fLMU4nvidsoMesvgh Or5PaVntC/7QlN45M9D4fzLxZMG37x/azfNOv3kTgQu+2/d/a+JH2un/tYmfUjXD+U9WLeS/vN4P qElpifvOBAv0tWs40Neu4UBfu4YDfe0ajvS1azzS167xQF+7hiN97RqP9LXDzHz0tcPcfPS14+y5 +9o1Hulrx/F3XztO/93XjvOn5l3a7MSGzEJcxc305tJ47qGHYq+80nMobkqBROPt4uaQAgnOT9LG 4JGH2fiYz/H9ydVHmJ8pEH9W/tsFpDA4OtJ4O5iNlW9/avyhlTzz3SGY/1wNrQ5jyNXQVh3rzXJD UONPDQKFVKYjxUHGZikWCxZoENDwU4OAxgINAhoONAho+OmYrHBoVMAKnwJDDQIajzQIOPDSIKDx SIOAxiMNAhqPNAhoPNIgoPFIg4DGIw0C+HrvBgGcHmkQ0HCgQUDDkQYBnJq7QQDnjjQIaDjSIICT czcIaDzSIKDxSIMATA9rOZ+roXV8Bca0XOEhLcfxt5YrPKTlCg9pucIf6uxd/KvCH0bNCFDj7XD6 YRUUHrIK8H5V6YLV+MPFw9vfK/yhkD+58Imvtye+bIDzvxeJp2H5GYHvIuH7xfGiQ3zYLqziaR+L yFk4vFouy+eCc5PL8ivcTFTl3mHEV8v3DqtD+BObp4kLT0qF7xHiy+WaWHOwMwcJphXePl3le4oR V0a+pziTg5/31QecP3L1QcPtSSq1870lHN/kzrPG/62Nl3t4+HL5mmJxiE+Xe3uwrkthfjjoGTK4 R+PNM9nHYT5Oz8x86KjxtlOn3LCseDPilHuN634dh9OEjPOH7zVusYB9jzA2Hz0p7fQcK/nb923+ 8Jl7xdU358mNYjA9FJ/y3bdasVwy9wcQaLl8hwX6Ld9hgWbLd1ig0/Id9pQ/8hSd0sDIUoFPVwUk stR4u1LFbZPr9+1KVeKZATg5HCiu5NiBKKeD2YPvXBjF6aHAb3TH9zm9mwv+0AUpgR/Ozjvw0/jD lMHEXZYabwdyfYhiKLwdaQ2Zf6Txhy7IxM4M5/8cV8WXKwlex9nPdb+0sse0dSnK6Ry8XB4COBzi z12Qszm+z12QzbHeewggLM6PIYAab4d+JVyb9bF9fcl8bOLAN6634fysiUNRXH5q5bwT/35L7MQ0 3o612rhWcbMj7x457cS3l9K2vH7fDoXIDXqsAw8ZnNmBJ20Pq/ra/UXkEmvFxY2HDMJ7JUMGI87M TGnbZkt+eor72vp9+0J/lAI5LJvckbGZTjNvyJTmlepYL8d9EZdlifscwiNxX3HQw72TDnYWaXCB ZV+GGDp0MVdpcMFls86dHrthhXstk0OcuTMgO9jZpQEedi08zyI4TG3mXsvo+D63Wrrwff++zf8p IwZg8SxBRgzA4l9i3CMfUx0L91o6xL/EVfjteQfpvSjeZGbhRkuHsBUKyz22quQ96rfXyo3y616Z YUApdTdV9t7W97IEm3weNzlxW1KazIvF2dlkXiwchpUufds4P3vbwzB7HAfFAbE4+ElxQHK4ljLG HoYdhk6EPUuz6eEprKvumuX5SmnClqXZUyTINpSM2waeUlEd/JGMncehxhv8N3bGHrk2r/H2WUGU IYIab58JJh4iiMOztHLg5OQmIb/C2xksmZKV+sMNCgFqvH0ScU+10vjDBErp5NB4+0pElWqaxh+u IHBFYP2DQwWh7QQdMvwkfhRmUJfWD5webmBdNyzYGX7g1hVcfkjXN/E/nOHKOwIw/W8lAZQeKQlk nJ8pyuwPjbdT8CQdrDj9PKhqpcdO2ZPMCtF4swUnkf6WVX7s0y/y7TXh8pmKHLbj/OR3ARpuIB4X I3F+8sMA2SFvfPySHeu9R0/h+PtupMbbOTXfi+gOeRhT0liYn/MODRXejuND5NZFmP85FInFUH3M fOURdy9y+tLx5fJUyTgd5N8DonD2JLk2AqsXT5UcjmggF3l2BudPKbs6HqY+hl0dTfOWa3Opo6TV q/jY917YPa7qZftfyaurgyBulXDwZ8izMxpvT1UldRzTsd7pIKawb0z4ZhV+Y6c48KRc2UMP3y/s ju+Tr6sOZZS0t+LMlLS348oiaa/D9kseu9JjTwas+SoTNyalDslzYP63KiVSeL1t7Pz58ivrD/gY M0eWCQYDx5hPMDQtRuORBjmNP1xgkGkxGn8+9owL/pDlyMQAnP4sDe4ab5/TFZmVrvGHwfwy+1zj D+ekQzJ2eL0t7fw5ZDlyE13jD42tUSyDwttpGk+LWddrtyHzTfR1vXZDIFdHV/oPnbBDqqOw/PNF dMf+SstbxvkvN9Enzn/pecPFQabFdFzcUpzShQAvN8msdPz7OVwT5z4fk4bV+tjneo9jUoW3W8Ae x6Twbj2OSVFpfjsmhdnJb6tFBzvvx9VwcWh9197DuWeQIFXh7WFDfO650m/n+HzuudJvB5EyYCY5 FkDqW1aBsKN+HkyJ089Hn5s1sc+i4l0jQveXL5d7rMnbUabC20nC42gStZ7yvtpqfszzBD7KDNGD v1vCYHry2Om3zyZL2emxW/Bq2KOf4yj/2nF7lWuV4yJ4vRQNBIc5z63s9spOktvkjmdc3rrMt8XX 2+u1aqN9sj3ibh4Oo/+LdJnA2zX6bk1semaWmjManLwdlaLby2ljcLhHjvq5ESqhUf8TfIjyHlG/ wttR5+MoROEPWYIchSi4HfQ/jkIUHjoKgb/PzzrWBW8HtXzLeYEfjh7kQWWNPz+ovJJzOGqZ/L4Q zn2O+aeDniaXYDXejuHvSy4af7jkLC98aPzhslyTIBWWzvv2G87P+/YbLG6P228ab0dJj2ZHdL1y srHS8w92UB7EK6La/nayAa/3foID3l++5Jw8eB75uOLtS93chTBx+X+LslH5SS1Kjqzw9snSI8pG 9Uui7Orgf5fpWbA+ppGkFKzwdhbFUXlx8HOmXV/+zsZXKdUqvB218clGwunJoe/6ZZeC+eIHri58 76Ot5NhRRqo7ew73OOJuTuygKhcpuSn8IWiWgVg4O+9+QdR6clASZFwbGJQ8wafZKzJzU+PtGZQx 87YquO3l7hGdGm97rXtEp8YfYp4hpRiFty+E5FuKFf7QoJHl/BteL8+tjg528rNm3bHeKnPdNP5w 4V9eZMH508ZO/2EmZvTR3/tOv80fPoAqDnr4yr9D3PiZsgV+mFqddm7a3OeYJ+HckZhnpecwIeCO ARTeTJ14gmbuODclRlrpOdzVlQmaGm/70HuCJsx/iZFWftrdHPxMWXast9xdsqjx5Lu6OePiJmO0 PfTUtNNzqIxOqcTA9LSya7sdM3NMtdJvx2y9ubRXKp0OdXkUOmF14ZBqJedw97bv4nwcpN0czuKt 0KnwdozEQzSzg554X49DzZXEYA7jzzHYpr72aT/FYN3hvDI/D1ZwecikvluwYQ8xLXMXf7uQV+uu XodCYZSCD7xeUsc+HfynlGgU3HzmLudEqPXkJ0U373VoFsm79zoUFu9zH9S65Xmf+8DbNe+MFKW/ hLt3Dt0ufiO0OrarxLCbB7twSaF2mPh6efCPi54Ud3rsewxJCnSoNpYc5LoezM58nyqh1pnbV+Zw bC8fM+K+q1QZQoNzk29hdFwZudtlix1sdrbiykQK10scy+33/TiYnD5drp1nsHZHaCWXNhy2jS9t JI/wz7iH8mZoW+Z9oQ4NtWvIuzKa369hbsp1eCk0SUcHGvrMcE8qQQ81FPjQqhOlrKXxplN5JPga j7zBofF2inY/ZKXxh1lf0rCr8YdZXxLSavxhol/y0VPqTs+hlSlya5LGHxL8wAm7xh9GODQuA+P0 8AiHlR57BAWPcMgOPNmFUBz0kJ7H5vg+X9wc+H49WpNg/t+tRrD48yhWMssaf+jlSBJz4vTzXcxV Hg7NQ2GXTztHuy9gwPqbuCm1Oei/L2zA8vy4sAHLj1zYqA567mMQfL18waPj9pPna83hoJ8fv3KQ z29frew/noJs6nJ4K0vOtHHyp7wJovGHt7I6p4Aa/392Ch5w4mW2Fs7LHMZOyyG9L3xXBl6r9DE5 RFlGLKz02H1Ddx8T/n0esZAd9PMjGY69lcsgzUFP6dzXA5v+XGU8Mr6/Vabiw6YnN3k0EF8vXwbJ uKnlvqG40mOXP+6ZCbj4k+utjlDgMTMBXi/HqGytBhqjPsEHn3433mg80m6v8Yf3BWQercbbMSHF qGPFH2PUGRf8Yb6szPTD13vPl9X4w61i7rzByb/H0Wq8nVK0eHl2ixLdvOIPQ8bkTpnGm1cSI7nE MhzLpcy4FsdyuV9u/f557HR27NZM+3rtDI1fI8CX+7ixrPHmLMPEb/Qs8I9seOMyjMb/i42fnBHj 5PNLris3D0dcg8swGm+3AfFLrs2B50ffBm5L2GjWwX4XNJpP8KHf7GE0Fd42alGGtGj8wWjKC9Ua b6utjGbU8IPNlCEtOPk8w3vFH2ZyRz4L0Hhba+9GAo0/dEPWa3rgdywIs4fLBo7N4rkQ6+Yenr++ Q0GYm48qA0zPo8oACw/b8O6QhiHvyeHs5KrEul77JVoeI5Ed9E9pOYf5I1WJlT/2QW1ofNCPfz/K i0ewPMjQ74bLA1cxesK1S6oY6/cPzZZB0lZUvR6NB7D8SHNmwuWHGw82eg6NB3mnx+Y/Nx44zIO8 3+34/N13gLOfb+46zAMPotzE32bP3aeg8fZM9952eg4veEtrO87OUXd1PLz2KReyNN4OGu5GBRjP olP+wsDv+P5zkKzt/XHKECzsyKLlCm4+Fzjl3paGf2rB+dU6Amr8T2x82cn53MZPSSRQ8vl+xljp sV9T5Gfo1u/brzumvvPnuyY+dx/9FGJs9Nv4ewalxv/MxLf39tfeL3k8SMPtxx0pRB5jwZ8ms8eZ 3z0ECTzuqOHA444aDjzuqOHA444ajjzuqPHI444aDzzuqOHI444ajzzuCDPz8bgjzM3H4444e+7H HTUeedwRx9+PO+L03487arxdXqh1//7hsR7pgcTFoZVdmu3Ql3xzqbhucehem0MeyDdTAq3xh1Bf Dphx/k85YMb5M+WAGV4vh+4l4uvl0L1mnH45gJz4fj0eg9R4+8AvcfXOARenpfH2gLAsTwTA5oef 60ndwc4iAwFxdpL6llUczLnbPOxgDFwd07a3h4Hwbbc9hzB/7n7O3iyK2zdHZw/Ap7h9syWH08e4 25LDxPm6u0Zbt4YcjuPCMPqu64fBCGFzjfZZ9HzPFdkHQkEGccDbxf3F6+ft8yCu+BXccmau+DnC Hm4X7s2xXK74JZz7mUt+AzcNfMVrJlza+LxyOkxDvo9hNN6+0sYlQodpkPblVbsOcxcqn8fBgSS3 L2+Rhn2jkA9iMq6Nuec9EjjMkJ97JGCf5466RwLmM8B5yDBDfH/5fHPlv5lU5Cl3q2D+8JtTLeP8 4f7i7sgruL94RFwfS5QWSJyelHf5PI55Dw555nl3CVevwq/DOJxLKcROBze5JOeI+wuX5BzaXjbR N7tP+enr6AgieTRecgSRhZ96WbfKHgXY5/79Q/evjI3F93aU3bEf8O8lFYfuZTncwkV51p2eQ/fv e0mFmSTX0HZTZe4vtwsPh2moUWYkwrpSo7wwD5u2yre3h4P+vCcVp4f1uK+0IMfp/Y7fFdx0iiOI 4Ci4GQEP6arX8NOz7n0lxu6Y4ZddNdpu/Q1pp/1QGBriPxXeznS50lNwzssJ88CZw205Gd8pKfTE BX8oDE1xb/ByuTCUHeRn6TzF6aHwsTt2i+tCyfH5Ko2nGm/XbSi3zN2xXJ6ZOT34wZcPNf7QllPE xcHSxnWkuuDPdaTu4OeQyeIab/dXTGkC0/jDW4Sdm8zw9c4p0SmqLvySwFz5ebhLnvh2IMwfqSOt 2v6vdmGILO3A5Z/n7azbdXjGOV3J8fUs70pofLPLPFWCTVS75BXnFX+o9JRd2+0yGD/7vNr+87PP DtvPbelllX4z12IPfT9VgHlzCpbz47TSfO+B4sxcFrjJRk5vFfbkm+NKid2YVcTzK/jpyVxu8xxF sOc+LgU+zPK9+7g0Hml+deCl+VXj7WZcrtL0BX9o5JIHrTXetqv8xu5K/+GCljS/avzxjV3WJIU/ TGBpLOb4eqtca8XpkVNTDf/CdoPEngV+mEwtzds4NTx/JTu4M/iWqoafe189m3UPndP4gxOUoXMa f3iuR8bZwPQwKyWKxaweP/KHvw+u4cAT4RoOvBKu4cBD4Rp+Mnx8ogaavXdQ6J3wJ/pwx1RM3hNt B8J34+oTbR9f3r3+TzTS6f9EHyZsSoH5ibZVjd9GmQp9GDQVuDj4RB8OmWWg/hNtm9xW+Igf3cse OPFAV3mPxkf5zSMuJkw3pQR1wlJ1D8V/ou22Bz4mjihPpL8zoXRzaD8SyhMeKjUGqg0yUmqgUiVB PQ5uHEI90ceD4UXlD8fC0paPsvtuykfZzYMmBszuIqXRJ9pu1K2Voy10lRT1dy2wh9PasJqqAzqv puo4OSokVIn59sNiqg7fnqupsl38PTTqiT5M7RwcjT3Rdpvw3bf5RNt3tcn1dTmwx3zfE3t6QlOc n4Lb/uy+uAHDU92+blvvex6Dgh+uYUhhG4bf0xUUHBmuoOCHOx6DlU3BDy6zcGYDE3PfqYD53uRV XZiYJo/kwvBeOatRcLv4NuTdNAU/hO2UM+EiM6QPF+Yjj4Va2G5PlJzyOi5M+pQmXwW3LcDtmNGl yr0LXNx5xvXExZ1985ywhLFzLhM2M+Keo4YfBkckro/i8MHOCJVfbsOaDdZsngIRcBHj6txqgO2+ HtLsOHEh4FpbxIlpbZN3W2Yo4V8F+DBAhELi9fMHdypNK7CM3f5Uwe2GLT5H1ejD8Ad54A2VGX6r cwx4pTlG2GrkmDe9/p0NH5teHxupwiLsbzHjpy/fvlBQQfHNNy+M/fqlka9++8m///rlDy+fv/yJ kJ++/D9wex+eCmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8PC9QYXJlbnQgNSAwIFIvQ29udGVu dHMgOSAwIFIvVHlwZS9QYWdlL1Jlc291cmNlczw8L1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdl QiAvSW1hZ2VDIC9JbWFnZUldL0ZvbnQ8PC9GMSAyIDAgUi9GMiAzIDAgUj4+Pj4vTWVkaWFCb3hb MCAwIDYxMiA3OTJdPj4KZW5kb2JqCjExIDAgb2JqCjw8L0xlbmd0aCA3NTIxL0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtCniclV1Lr223bXbR2Z4U/QEFziBt09fK0lvqMMjTdePe5CZOYmcWpEFg B3An/SP9wSW59t6H0jmhPsKAL3Dw7QWKIimSIqlvb9//eEv1pZX68vH3tx9+vH24fXs7X9qIL9/Q v+fL17ca4vNf/vvXtz/evrj9+RZe/vcWXz4l1J9u4Xz5z9uXvztffk8/Dy/83//89/M7r798fOu8 ///xvT/IX07+ERH0vR/FlxBePv6BPsV/DS+DoOc4OlH5ze27f/V///TxT0zsu9hwdg3+5JcmOISj 1gn/ExvfjjZ//6OJj+kYE/zXJjydxxkn/Gc2Ph65Opab6hGiY7k5HjFP+F/ZeGLPjP9rE1/OY+bm v9nweqQJ/gMTXok7YcL/xsa3YwTH91s+zpmeauJ7OFKb8D+y8fXozbG74zxKckjPiMeY2f8LGz+O c5bmLyx8POMRCi4N8SxHDJ7v9yPO0v9zEx/ykbqDHlL2PEvzD008KXspuHbFOI7aHPSQtrfk+H7q R5/p+WDicz5GxeU/lnAsxtbmT2nHbHw+t+HEnuxYbi1Hm8n/sYlv4egecSB1Hw71iq2t4mazv5P4 OMgh67BIm8190vbqsCZxkLFNuHYl0vY80/NbEx/OI83WxDxbUihHH7g4pBiPM+DrTbG4tDHFvmqj aa1SCkcbDn6mtrgONjn5XJXXZmeuq+tgKnsq8SizNJuHaSp9NQ72dtW8GAd7uXRWx1nazLM0NbKd xcH91tez18Z3Mg7zdv3MxNNZnQduTBKf1Q7b3+JLHeVI8R1esp+2YsnQCvC0gGSgyFl+Yn9uYYle Osuf2A8WNpzn0dor+DMbnCcqvrDBg3mAkczOfVdk/NIE02Gvv2xyOMQ2cePfTTBpco4oN+jMTjCf SYe7Yt2PTXAN7D2DrKvjGIp1vzXB/ZzIsFlHikWK+wQ3EzxoU1DOjXaEAcpRPAO7Uk/w5za4cBT0 BG8VlfYw1neW9wZLJ84M/w8LTpzreYKblJBFGmWCmxZ4ZD5eNdz0bljHQ5rwdnB1VjbwGm8er6Lp E9yOfSjwb/Pn7dgwtJUcO3Jm81BxboZYRelh9lAsUObNtWM3igVqdeAJyCZZ4U1nnSP/GB38z2Ol x46FSzlCdfCHrFfsDvEh9yN55KdWTgRpvOkfBPI/hkNb2li1yxafTs6uZ7vINpTgYCcZhzqzx05k UfCwqJcd+1Dw0BsuDhz6p4abQg79c8fVN0Za7wQ3nelI2uvYLQ78PcIcU1mFeZMo6Ksw26EhAfO8 W3ZomPsRAi78sRBwpscMDWONR2gO9lMwUJtjd1viUAxfL0Xy2WHMIzk4Hu3iUH7RLltbRly1y850 jC4OF0p/Im9nRNx4JnLJR8e1MdHhew58v1K43GeUP4kP3+RYL6lvmumxgzcK5buH/uQwPYmAYWa+ eVKncnKOHlaWVC7vFGYOBfKLstjCUC9XGVWuVItLWVILq7JsIv+2Op725tJRWh2eQOqFEx24cI4g cYfCf2rjm0R46H5lcrSXo9Hcr3ym1fM0lTeTo10cYUUOZfX0bPoDyVvA5T9HCnMSLm859mMWT/Ps yikfNeDilil6X85Gmz25rmejqb65BE47OvBt/b7N/krmZODqmMkRzrj0Z/KDyyxt5tGVKeatDmuV O7HHIfz37AIs/OQHd4enkckPHgMnn8N7cg5J/veSRnatTGhTjjl3N3/c1JLexONE4Zw7yBPcTjW0 46wT3L5WpuigzHg7eKXooHacN4GigxluB2cUHIww4U0Z5uzfmSa8HVsSMHvoofCgjAlvnighB7Gw Cm8Hl/dcgMJHO1a/UqMKb9+Lk8mp1UFPTceiKGY4EVpYv2/zv+UjONhP3n6MDnEgbz9lh3QOKfKA lxvJAcg4NyOf//PnN7fuVfw1lJscqg/P94Pc22m8fU3MoX3FbQ+H9mXWrr+18Un8QZifFEzUWRvN pG5MSfLsCm+nMtKQExReby5ygsL0U3DfcMsfS5REJ0wOhROLcdvE9kliS4U3M0+xnYdHetqVR4Wl s5XDYaoiuy/zKW2eXLG/MbV25oD9EYfpj3zyBny3EhmHEPH1JjIOwbG7nAlYTupN5qAdjoOdEwEj 4sKTuP4u4dKTuP6u46Y/pb6e1JtL/bCKz3/tcgE94OKTSuVbZY23Y2OuqEsO8amda1Tw9fJJ7ZAe Du0du0s+cHT4wInr74ZjtcNxTCSKDE7HsZjGWDVxE6YXiftQ4jNpYnJsVeZj1+EG5FAlLYR6VTlG uVFW+J/a+Mqls7BpyKS6IePCkMnJXlTLVMXMxXQOS85x/Tlwecglr/Tb/CdVX0yPzR9S9ebYLtL0 7jgo8lV8B6t6vorpcPGXYjp8tX1Ilgf1sTOdo8VhqQqdo6fDbyh8jjpMWyGnedF2088oobu0vcRw OISt0LnrUfYSx6os2zRJkAvhvaKQw8acV3C7aCLI1ZOCm2aT8yRjgttFE6ewXcFNMRt9/boduHId VZ7wm5qMyyYrvB25hssmK/wmryIF4/ByH4kSlJvSLjFwUQgUaoXs4Oc9sYJ//0pWKvymaCKs9G/a Ma57MIU3Q1dWExKJ+l4R4DvYQv7O2S5sMrGDExgabucS04S105Ti5Wi4aVdH5tVp+N/Z6vdS6OAp F0P2fUQKvEmpBbm003hbM6Jc2jnwlQ2HxtuayoFJm/AbTSrcOqLxdn0HByYz/dvGoDDjbUkviRPm Gm+3vlyBDL7eMjirgNNTucBDw7/cZhwnuJ2vJuemRQc15Nz05OBO56sCDbfNHinh8GzWFcpo/LbY J8zM3xT7NE4SwPQwK1keOmj2sgS1gv2Hjdljtii4bcourii4yZVxMUXBbct38UTBt5aPTlcKZ0HL 9wre352w5VP47eUJWz6Ft89IigPrTM9XX9k/6MJI9YON6QsrQbYpS5WdLI03HUruoSQnC2do7uxk afzG9Em9gsbbTkopnJ/W+I3pCxz44vTUIkcPzH/OEXnoZzPQHfSzcZ3gtunmJJGDGtJyPqjg1ZJt TTM37bpX8nAW7tsJYfL3RsLVkW3rWXD6Y+D0uobblYWhcsoN3qxI2p6yg5xIwobvViTbkAsuy9xx uRi3TaFm5zAc5z53bxTc9sQ8VltiJsX4cmYEB/vJLTqjgz81rrZkg6/rejeFmnG1Jabby6dcSCxB 4Cn3Ct6cWvdTTuEh/17hN+X/iSN9jbfjDS4RCBN+M1jg8u8V3q73vvv3Cm8b/VzErMHfL4H9Fpz/ pfE1ncZvyvm5flvDt+59iw48yWVPju1t0ruKk9869+JovO1jdEly4eznGsTuoIdOIZc4j7aKs63n Z1rFeXPKjVWc7QgiFE4swfyMMfDkAni9MXLzqobbFRoprp+3SyhS5jwUrC0xn5xH1Xi7PjzXVZw3 9fxRIiF4vfVcxd9mJ9/5z98371q4nj94xIciueiwPpHUK2XH90m9csWtOd/Kl46rC9/KN9w4J/Lx UsXZz5352XHYJXLyFm3cdNqfi7ZsqvMTt95pvOlzJjobk4c9Ka3GYdOYP1bttQcd5MZZXo3fFOjH VdttaSh91fZNwX3kqzSc/xzQJcd6SRuX79sF9Hw4zvJgF100GfuC4/sba2ivlyLAVnHrmSik6571 jsjlkbg8kHVY+GMXxJ9vrKfJn3xK9wts3XKIxyz+dkImB4ewZTp5F0/GvgaPbxxz+144navpt8si 0hWxwPSnN465TX+O61FhX+NzWYHr+42rL3FhKOdKv80fLitwGPNMEeZy1NntFFW6a2DjzHUFMzmb doTm0sXc46qL9naR57DYKvv741xtj729I630bPoRhqSHUP5wHcJZcHoKOeaLJ2aKWwmBC8RwY0JR Wh7SkPZW1tY5DIytjQv0BPv3Fpb2NYQJbk7/6FL+oeH2MJS6ft0ekHG2CfwrExwys0Pjf2LiI5nv hi+V8+nnzEl7YEcKbKE0/qvvmj/Igf07/YMvbfxgf03j7Rkwhb1lnD8896RPeHuoSjtXcuz9anKc a7w9p6RLtwYsa9yqH+tfpv89jeKxjfdbJGAAiYYDA0g0HBhAouHAABINRwaQaDwygETjgQEkGo4M INF4ZAAJzMz7ABKYm/cBJDh7rgEkGo8MIMHxV9MRTj8B+8z/zbVZ4AFcOD9L4wpBjbfvLevJJycu D5W9apyc2rnyRePtW8smfjLOTi6tntlvJ7y7JLBxbeziJ+P0XE1QuHiSk0B+Jvx9HvBUZ3G2L7bO tqqvffNB6r6o12ZWaVvVy06x8UVYx+UhUhw0Oi5vMXGpPb7cLH4szv4sfixOThY/VuPNW91YJIcB G3PpUnJYh1jzah3sjCI5DS05tqtJlzhsTaTvyKG+0nfkUF/uOxqO7aUwZVQH+YObyvHdoqgmO6SN R5WWWdrsERLn5QKjxifxbWHCuSkJUYfnI/NNgoN+cuF7wKUhpbxql912RGf1ORz4ktb12o07RTK6 OD85YzlwceNhost6NyNF0mpNNiNLBke5sDzLCBLc+KT+xi3ftB4Fnl0Gny3cerR83056nHH1HTYT SAoXicBhhbQqzebBLIOWViWcPZnHfs+7ZQZFkoJsDvLTubpK2xSkx1WSFKRDfHIuq6tknqX5GvuN b+/VqYTTU99Yw03rUV2tw6aVKPAMD1ycyXVODtct93O1Djb91yBvfH+vXiX8+6OsvoZJf+FZp47T t/D0L5ydhW8jM25subXJk0Xg1qbF17Bbs2J2OQ9sCbmPZACW86oY1nA7XyIVwxpu50ukYljD7QLj zvkJhbYDrlP6QTV+k/6QflB4rSHIYxXwYkOoEqDB9IfBWT8Ft9MB93QJTM41o0XjN1XDMiJP47cN FjM3N51EScJFeLdyPaqDmde0Vo23kzc8Y27m/nZaax8T3i5/q11yf/Butcshh9fL2Y95tzYTYwbX YOPS0IuPnt5XejYvwcgMPpw/Q24JYVMSSdnPmR67wChwxQdMDlcNp4gvN4axKtemyrguymVTn2SW vcb/jY0nf7bhu3sf14qTz+NaZ2W3kx/5zTG0SX4kB+9LXU2DXRvFfeXzXtmle6TqsTuIb1dwgKoi Z1a641zh2rHFVNn0UCw3ZlW0Sw/JuzubQxjIuwvDQT/3FGfctCVuIB24aeAJMPN2mRXq6XrQQuM3 tWZlVXW72CmM1W2wUxOcKsGlWTIlEZcGedTFcbCk6y0InD10ri9+gL1b3DzkcARkeGxw8IcP9uSg hzMxBTfNiZ9g89DPB/vMT3u4Ll9rZMd6ub2n4tYncXuPAy/DXR1uKtd25eb4fgjcfAbzM1+F1bA8 S26l4fqS45soYVM+lrh20vH9N1HFdmpMc8ibTI1x2Iec5Nkh+LSQcrDhkIcSpBIFpp9zNw7HUHI3 Dvt5TY/F2VOv1BYsbuQMzNwx79i5Giw7mMkzZqKDmZzocURFecT16LULP8eV5kfxkriZlWs3ToKH M7/7bM972FNuBQQLjJPQ8N04CY0FxkloODBOQsN3TdVs8EsR7L7dTIGhcRIaj7SbOfBS1arxyDgJ jUfGSWg8Mk5C45FxEhqPjJPQeGScBL7ea5wETo+Mk9BwYJyEhiPjJHBqrnESOHdknISGI+MkcHKu cRIaj4yT0HhknARMD2t5g1W8Qfp31++GrO+h3A8wMi7hCYZmJTzRyKCEJ9iMo+QRu1fsZqyR1JA/ wZvM5eBD9Am2k8zXrANwU65BB0+wbRGvK2OQc02KbcAFckiT0QX2k/2zJ9jOsvKsgoaSwZEMvEBu aVF83ow0kG5ujOaoWWGbAZ5MEEGCY0iT4G+6R/ukU/ZAYW4djaDIRX4XUi1wU7IVefAIplPy9nNF uZGlZBsTjHgNtsTkM15TLUGa5X1okOQqVc7gnsgsS3BLrkGWIJifhFZbspntLK1N4Pp65kANZNyQ pqYn2Axy4nUdjH05Xe9eYhrIfaZaMjZNpoFrqp5gOw1G6prVl+2UYpiPkw0Z0o/0BNt1SLFoObIz O3xaolxO8sTPE2xnNPN8mGwGSGfOzzzBdp0PKav+8mZ0dJ80e5PWy3yDgh2tiU7LBAtoq1ysA7Ku n5NS2RvYC5dZgHzuUm+JWQ1O+rWOSjOflhkEc3pwgCRLm2gBSc50uJ4NZHMmbW2o68BzoRvqOvBQ 6KjAditjzBMZm8TeORk6O0t6NYViEiodnqjVkHZN1IRKIZayMWbBOr8DFTK6g/WcXOHNpOjKdyCY jeFiqg5zo8tTZiCfybvNHVwgh8e0xgy+yZRyYQdJsMCIQA0HRgRqODAiUMOBEYEavs1m0aGVKhrq voJ3pTtXtKvwdrqD7+xmvB2qcMzbHPREaSDV+M37StJzrfGb7JT0UGv85i1kmRCo8ciEQJx+ioLP 4aCfNKPM+O17TJy9U3g7N8DTk2b+2NlBnoaUHPST75yTQ366tEri6yV3u8zrNU0vJ7RqxeWTE1qt 4fTwe/N9Xu8mng3iYCn8prxGLplw+qNcMmm8HeNHeaIQ3i/uXYoO+xO5gHqCb6YhSXcIzv6rflrj 7aF8pL414erOrye34tgu7l0KDvq54bk5tqu21TxsnliSBmkHPq70bCpyrssGVB05Dq8efnaZbYfv 1wir+bFb94Z0t8DmjV9b7o7jjsc5Leq7ectRQuiODklX4I0dv/sBCm/b8bsfoPCbc11eNtb4Tc3v OGb4Jv8dJdRU+I3b0CVTDZNPsTonq2H89diTxtsp6/ulFsz+67EnnD9VWlA1fjOjscsxqvC220Oh Ax+jMD18DTbzZ3NPdeXS4f29p9NhfnLbVXPwZ8jDxhq/H/07y6dtZ88kSXscX1Z6Nm5Jlzw/Ks8y pHHeL7uslWuDAs5PfsixVAc9ZB5qx+WBy347Lg6cdE+4dHKHdHNoi4wKdkgzR7nkd8b2zs6yrC9Y HtH4wDYLSxKjsfN95AoeiSVA439hwcOZJ/A612UGh7x+fJ3TMuNj5uyKxptM4dNkwa9zWmY8RYkL /qc2vq702/RwdmjGFxNf3/DH5md7wx+bn11S0Rr/axM/yor/3MKz+Vvw61igBV9d+8tR0/L9ZOJj WvE/MPE8hnKW509NfM4r3twvDiPO8pf36x03UO4FUTdQgT/5R9utK5wk0/hdlULgfgf9g03BhEzn 0vjNKJvEhl7jN7UN0pGo8Zv8TuGstcbbF+Tk2LUZv6k+Sis99jNbFPAt399UK7VjhtvpjrthgMkn P22RH7u8SV5owHf3enFB4+3auyGjQmDu8OSYUvDlcu9UxYXhenBBwzdzY+TBBVhX7g8uaPzGieIH FzTcjp35UKwO8smHCrMs2D5pahwi4ng+dKtjc3Nd6bFzR/watkMWSuGYHFate6oGN5384MJoDoKu XA0uDi1xalnj7XoQnrztYD+nXhymJPbOo4dx6acQq+CmRHqhAs4dntNdZ+5veq1kTqTGm6Uc8np2 wNnJr2c3h3jyXJrloLD5E+tyUNjNNezxRA9+8BUmTj6d057P574eFJupNHk9KOy55HytUnBbxXO6 x3BID+dfZvZsXs8+Vz/Mfnu9yVNBuLTROR1m6d8/t+2Rzi6dmPDZIi9uB9w4yBgbBz08xmY5Kza9 Vufqdm5qMLizEvZSM53Uw3HUcWvT4oZtW5sWbdzUQciYV423x8zQ0dsKbmwzJzwcxjDT2TsSLp4y uXo4xKdKqyRsPGUsTcLNA1dSRMfRLqOu5+/blRq9rN/fjJYOnE6EzaE8oR1w+gsdvktUt3lyu7pc PZ4zs6ivKQ+Fwtgl6jIPa35COzn0hR+9ytVBT5LCY403u7k4vo/yqDoY37+Csfhe4TfXNlE2SuHN +1O+5uGFKvwmvJe+BY3fvJXVuLpL4+2WC3JLZvZsGhik2kPjN7NXpH5H4zfXPFFceIXfpFf4ba35 B3Z65Sr3wPlfB/fMavymPETKPTR+c28T+P5U4+30CvsZzbEBfaz02OkVrthsuPzzPQz7eQq/eVNR MgIo+dLqMLPfLlMPg6sr4O29ZwQU3H7riLSxBAd3OMJPjuVmmVeBL5ffvprp2VRXnBKCK/ymeqOK 26Dwdnk+ef3nwKWfJ88u2mtnKMjrr8XB/1b51hL/Pr+Q0R371d+cFrb0jzenxSYFMq5sMErQI8hH 7fkjyFd4O4w6hwTV6AbIxBMH+df4O1h9uadhOd3tqFf6GnDupCxeP8ydfK7GfDvwJA9cfROpbyi4 et0f49L439n4vqrvZkCKdEbg/KxNvHKYfj58g4OfTS75YWcg0eE7HN5MWlyfzXSU83CYKg7wa8Rl gbsllpPOHg9BAX7rOD0yTMVBDin6Yqi2DnyQd0hBB/4VjDnwCo9d0KkfQBd0Cg9d0Ck8dEGn8NAF ncJDF3QKD13QKTx0QafwyAWdgkMXdDD59ws6hUcu6ODdvV/QKTx0QYdy53FBhy73fkGHCsPdHVdw 6IIO1ZXHBZ3CIxd0Cg5d0MHk3y/oFB66oIPx9ws6eHPvF3QKj1zQwbJwv6BDVetxQQebzscFHUzQ /YIOFof7BZ3CIxd0MPvvF3Qw+fcLOlj6rws61JQ8fHeUOw/fHT0oHhd0Cg9d0KHsfFzQoex8XNDB /Lku6FBD/rigw/HXBR1M/nVBh9qexwUdKjyPCzqYnNIklkBtFT9LMZKD/iqPKcInS2pvDq7NMxNt lebtw7iLNG8fxg3z9+1ZmjwVJDnoH50L7GH+3DuYYdsmTcwV13Z56NYhbzIczeGYSIPyrC47h5+f tYpoxl6B7a7Vu8Ov8XaG/MrYa7xd+X75+xpvp8jTyU6DxtudAakyIzV+Ex9wSkXDNxn4znKGL5ft zozfhBNj/b499IftSJvwm+nnkQf84ezpMvof/36XoZ44P4cM9dT4buP7+v1i4bmyN4cJ/682frjo Z4Vd6Ld9sCANgvD+cv/kTM62fbJHBzk86sCzXPICxrxcOyOd5D0Wjbd9PB6QMIunnSHnGQkDtw5c +BxmcfiZjZf3VWDxj1UG6sDmgSeUx+TgP1/0dwc/+f0Zh/h0GZeDi08fqzRv3nKL7ETi28v5+oiz X3z4jLOTffg6cP6kIN3qGm87waGv6mLjOQFfHPTzzD5c+iUBP7PTTpBTwN67g5x8rr7DJsHfVt/B 3t4iTqfGb5zysvoONvs515Yd9NTG1/c4P9mJn+nZOnldWr1AJ+8V/EndOXkpT3jbCSM5TmPC22k8 8mZLcHyfncI24e0kLR1b5/x926viGbQzftPe21d6/sX2Cuv6ffOZOJlBmyb8aXt5ceX/92x8962X BXNe73aqbO0OeeCpshPczupylUWc8Pspsdmx3DE4EabxttfAjxLO7NyMn5ShGjA9PFRj2V47MRqk OhanP8q7I7C6xCjBN7y9kc4Vjulg+ulcOR3ieU8Ea7wZtHC/66JeNv2c2fXwp8qAMI23nXhO7Fbc vMUqD2Lj8sZTLxz6IlMvZn3ZDXvnwq13B9uvrYWMJev8wO76gTUW6QfW+G0/sAYj/cAaj/QDazzS D6zxSD+wxiP9wDg9Vz+wxgcTX9/wx+xfvd8qarzZf8vjFhb8Zza+rPjfmPirfxiWBzb4i/xs+oHP Ff8dEx/TijeFmQ2sC5/frHfX3xt4QgPsaL6CP/ln23GscjIovJ3eYcdxgpvZmkcyUeE3fp3cCWm8 Xf3AfuD8/f3YljbhN9nBUwIahTfTETLDfMbbfnXpko5Q+M3Y8ywHm8Jv/MCTbyxx/t/tgsJ/x8R3 mVOE03NNb4PxJPeDXC9Q6p9QKIP+irZd9St//oreCLzUu7+ibXZzeqAp9EbY6/ztjahHrqR/RW8f 6WgavRHzNH97I+SVK3Ze0RsRj+xbvaJtgeJAKsH85jBKy4kt3FzbHmFKuhxJIJoEu40DfqniFQvl DRTcvjwQa67Qm8ouuelRcHtiV5JUqIJv7pHaQvrmnufkkEzBzWeLwvVitIJv3qJIbGcV3JZZvhRq Gr5pyqjHvKnbK6GIM4ZijVg1fGPBpWZWwTdS3rlE9R34h9u3Nxbq+PLNjbFf3yoZq8e//Pevb3+8 fXH7MyE/3P4f33DniQplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjw8L1BhcmVudCA1IDAgUi9D b250ZW50cyAxMSAwIFIvVHlwZS9QYWdlL1Jlc291cmNlczw8L1Byb2NTZXQgWy9QREYgL1RleHQg L0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldL0ZvbnQ8PC9GMSAyIDAgUi9GMiAzIDAgUj4+Pj4vTWVk aWFCb3hbMCAwIDYxMiA3OTJdPj4KZW5kb2JqCjEzIDAgb2JqCjw8L0xlbmd0aCA1MTgwL0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtCniclV3b7yU5cV4pb+clIAFvkX6KSFiiqGnf+hLxFMFCgEBm d8Jw2TwFEYQWpM1L/v1Uudtnquq0P1drpZ32+HNPle36qnzpOl8//vX9Iy1va1ne3v/h8eP3j3eP rx/z27rHt7/Qn/PbV48lxOef/PdfPf70+PD46yO8/d8jvv2MUH9+hPnt3x+//6/57Q/UPLzxf//7 P8/3fGzZ3jWf/2/v+2P9m5kbkUA/+Cy+hfD2/o/0Kv7b8LbSC+Z92kjKvzw+/eRvvv/+zyxsxdI/ thnsss5P7IqwW1LYnyLsnqY5KPhnCB5mwmtRfg7xIdv3v4P4WCz+FxCfZot/D/FZg38DwSX6OzIs 0UoCBzQsq8X/FuLX1fb8ryF+I3y6Ic8eLf7L76MGkaeCbvArjN8s/nOID7tV+HcnfiYDjWSgh3l9 /pPHsr4tZZ8ymyU9pjKthUzwC1kRYzqfueJj6azRbY7SS1XPjJecptX0MvgXZFVadyHWx9JZYxo1 uUzdpVwxbkqwf5G9/QJO25Q0/qcQn/NUFPzHEF7mabnupw4+TTwOAr9A/BKqNbnFJ+sLSeH/E+Jp FnKXC/xvMX6Z4n5Dni1OOVzKA6aErCqpiHn0sXTWmEZtHpm6S9nSlpVgG1Ik7WHaNf7XGL9OOfs7 KhPrkFt3D1ye1ynqifcNiA9EN3rgvovxm33/zyA+5ind0ZccXNb6vsP4ZSrajj+ceMlr/BziFEaE p0inFlSrWrAVXZKM88R/yTLNSIctTGFR8B9BOI3wpuCwhyjiyQr9G4jepxL9soS5TEtS+F9hPDlF LTzkxRBC5S2B/wzjFyvP5xAfI4+1xH+B8du0rQr/5ZewQaL5rxtAewzpiBrcApFfCuXGgJFjiloe yFehkDFo/AeMpw7SE6jZO7At5OsVf9eCbnbapK7pBwhCsB/iAKFU4rpQpBMghCmXy44FGiDnJIpn nW52Kq5r+h5NCBY8Hq1vQuuUkm5Bc5YJLNUKbvEtwcGnnPRYto37CLKpHFN+1m3O0ktVj4PLvrA7 Gfu1defRlnBIk1vhf1nCoVWQoCUoOGSlPTOJSfh/YFJNHKxJ/IC092kPfukDDce+KvwvML5wcCfx mLRpqhl5sFOgiWbkGbyfAsPV3/2BjI5iCokfcHCY9OsHPiGTB1d47BJKXRH6xSnLtG83psOSJt37 2CMs27TcmDxrmBaNVw7h2tT7zC6pj59NoydBmLquQ5CCeRzClSLIIVz1K9Chz+wfS0eNafRU3NR1 HYJbcXYIdxSvS5xrxTsOJM9EMNxin5btaPHtjw7kqRk/L3nawsgbqIlQC7rZUXqp6jqRNXJMU+X6 x4ETIc8p4diJLOw2JRwaHg1D0XBoeOxEtOyY9GZa8WvhB06HlFXwQSB/DLHAww0O9glRv3/A8aX6 QIH/Oeb4UH2OwMNJfcbl/u4hjg/75fvR7EQUpqy8Fky7Nq1NXZ/6hHAu6vN2VqO+i5mNlEA0Jopn nWnXlDd1ffrzKt/oz6t8o78L5SX38HOuC/8BK6mhrQXd7Ci9VHXJLO9TWA+5fgDJbJuChkP+2PIU s4JDe932yjYCDmOUvUxbUXC4zUALkqTQmJtmGmH9dsxNM0VAu8Jj7gh19CQe7uGFsNV4VeDh5muL h93y8CHSfikPmmyIY5QJ1oJp12apqetzkxDOxU1e5Rs3Cbzipo4SiGNE8awz7Zrypq7PTV7lGzd5 lW/cdKG8pBJ+DisvWQcko4a2FnSzo/RS1eUmcuLl5MwvP3Us1wUeemNefys0PLw5IycBx+Z0Rk4C /xOMXyqZufHn8tstDx8k7jfeT8AYFH6w/N6muCj8P4yW0xqO2S/t9vU4cM2FT/Ik/ncQX9KU9PAO dkDrjqa/+4kJ9nypLzIXxJKKRGrBtGt2Zur67CqEc7GrV/nGrhedi5RALCmKZ51p15Q3dX129Srf 2NWrfGPXC+UlGdJz3hNv6QxoUg0tF3Szs/RS1WVXCnO21X0eJeE48qvnURI+Po+SaLiXyIGfhuNF 78aLUq/kfHo1647B1MSBn1Z1eHq1aunh/gEzt3n/4PSKeucG/FzzCvwvMX6t+7jesWLm3vTEUWve zlRGDKYMnAum3dMGTF2f+YRwLua7UAYyn8Ar5usogRhMFI860+6pvKnrM59X+cZ8XuUb810oP9jy YwvcX7b8nprx8zpzeDIgPTUZakE3O0ovVT2uzGu95uDlSgl3cKWEj7lSoh1cKeFjrnRLfnKlxHu4 UuI9XCnxK8bXzSB359RDJn/n1DW1fj2+2BAXM1SS+nozE1GYsvBaMO3alDZ1XeqTwnmo70oZRH0S L6mvpwSiMFE860y7pryp61KfFM5z/A3sonP8nYkKcj5afEdQWZOUn/PCW/gDTlKDWwu62VF6qepS WclTWf2Laon//WDHb9NwfAa+8kUzCYeTaq8XqSUcMiUvwkNSeLyqOy4uSTymD764tCo8psuQef// Sn40vsiw1byvBdOuTQxT1ycEIZyLELxj1wjhYjCQEsiwRfGsM+2a8qauTwhe5c9YyK38GQu5ZyKb aFp8O9WMJcdUPER2HEZKOI5M6mGkhGNr3vl0QMKxNRc+HZDwgXXWLTWJ/zv4+vm4yFr7kL+QmPkc +b+p2bc++SY3nLkEbFs0H1wU4sstPB0Efni5ZbuFX+z7B5v5sU43gcddS4u6/Q4+J/t+HMex7QWF x4FW3tlOJB4Tayk1rhR4vIhdKELfbvTnQv5dwbHfWal7osL/LcZTnLjd6E4y45JuiL9R9+jhgk48 ELsFjceXi4jdoh4u7Df3fVr1dMAfHsyJ78tKPL5MxZ/ZbKu/QyOtM/bkn5+RHPm++xWOtGDP+v3w aCKSvZfdP8CR7N10KNY31Qu8Eg9PWtl3b7vfAKKZzfCoIZJTDPGG8GW1xgtnZ1wS3xpxk0lcdt7h 8k+GNfLJrH+waBVR7nQmxdTrDXEopl6XG3NzpwDqxlTYFz4pkXi4Bo60EDJTDeLTHDie89t6mpdb cz/NuxUIkk8KydouDvUCkbMmz3+D+Bin5YY4RA3xxmxLRA1JWwv+FolCgU3j4Z2plPONvs9rDSi9 czmVet/cbbqpUOfosYJxQKI4YL0zthQHbMVvummtlzD8/XN83+o2xrSlKeQbxrXVS8w38PWCm19+ ChxM3AyPXRMFAub9cHwzLdBNYAIvU2by63Hx65vJ1g2XQNeVyda3G64rk63fMa5s/BacDJmcuvGj 8IZQzvVzVPfk5wX0emMyZAri191v7LlEa1x4MpRt2pcb8vDH6VpfeOMjL5s1Ltw/a57ijUVRJmNP erLBRWDeIt8m8vcPGa8JamGclGk9Pmv5YeCQeU/jRpBaKIpfbhhXYUet5f8mxAcKgm+sokoodhEO T3WKGVxojCUFa4w4jClpsdY4uJ+41U3mmDwL0lBDbIkfnCHPvDUj8cODEaIqiR/cFlr4cqXEQ1Os +xmrwg8vZpfthjy0vlm0voOPe2qMLfH43KsE3hCQ+MEHmetUtDx4f4iWOPOd8VoWPmGVeLxgJyq8 JQ9RoZEH67vNfGIq8fhgbeOYWcIhM+xzi3zsTuC3nTuBH5t/+sk/Y0sLHOFKPP4kgC0tKvzgW+O6 Eyjxg+sddSdQ4gcX7ZbKFAKPZ1Kqt0YlHo90LpUpBB4zF1tOuCFPyZUpBB5bPlvaHX2XuTKLu//J 0rQ4eGNyjZOWBvPcunEI4e/NLfNaVuLxPu+2cwjh78098r6YxGOeIAvOu78345wnbVww/I/kTFfd nXivgsJ/M5nxzhWF/3Hzd0+k8N8YL04YEzf+Ws49HWLKdnIOtgFXPu/09w+tGAwZDo78Fj7vdJND pBWAmc7QWngncAs35CE3aaYzHt915ohY4od+hgx4Ty9+5jteP/Ns7vQzAj+IANc6tQUe7kpVv5QU fhAxHhGdwA/8TM1ZJvHYT55+RuBdfkbgBydOm5UfR0Sl5kLy9w9/fx1ujNdSE4tJPGZejuj0/MFx xOFo3MO1Fr5241d3C/y5ucTjAJ/WquHG6O65Rk3e18d55vs5Eo+Jbq5LSYkfHzjFzT9cfOBkBBoe OKUb0y2S+ZZwB19T5Pjlj/VSsr9DKQwNN+iEM7HxAtRrLpyJLen5CTNQcSq2fGe8SqoLIPd4lXqA 59d3qQd4fnmWeoDnpvO41O9V3PQW18CnDH59acGX4g35ee9ruyPPbuUfnJkVvujil3+7M1h74VMJ v7IU5RrfhXfF58W+H3ZOIvIpN2KBRGSyaHlgGJTiPV/HR1TG12F9KWzdir8/+YjKvB+fIlHYuq83 +pNvt9x6/1LXnF4yTBRrGPnxqVMpNhaAYSgveWiZGq+WAOE1pW6Kic/TK3aUUldiHSl1JdyTUlfi PSl1Jd6TUlfiPSl1JX6YUleChyl13R15ptSVeE9KXYn3pNSVeE9KXb88R0pdiQ8IH+di8T+C+FDq VqPAf4D4GCwezgSOjAwe9mdMS10zeseX18i8kPP2ZyzB4r8L8Uu2+C8gfi1WfozfXvTF8vMRcfGT TqJQ3PS/DsVfGoR4S2EGdgaMnSSnaYjHTX0Wnfz4eeX+WRO23ApcJYpHnW52ll6qekwe9/2lY9E/ oerSHKRoonjUmXZP2Uxdb29QCfdPeMG2cogi8TCDLrNAUXC4GxKPCOiqr7rLryUo/PdGG33m/Xij idxNHev9mlRflzu1ryUeb3zxYaHG4/A21aNUiccRbq6pVSS+2RCaQ6ouU0sx90TxqDPtnnPP1PUi ZCUc/ICWL3DtWeFhjhsOd8374eSrzHFtqN3w2Aw2nHwcHpv343Ax18Nb9+RLNNhr9k++RB7IvH9w iSvzVpx78nHsmsPl5EOTSNXxBx9i8oniUWfaPSefqbuUL0dtSTAtEKeuTrqz4D5nJkvVhofv/NDY LXpu4EzguZ5YuMeO7+QY8fGdFlqqJD3WCeJ530N3J74QxfsYxT+X+E7Orm0NZw7f6gW2K1uTvpuf l3pwOPDqyqvWgm52lF6qusEABWflXAI6vkCWcEf2cAkff4Es0Y7s4W5Zzo/wJN6TPVziPdnDJd6T PVziPdnDJd6TPVziXdnDZQNP9nC/QEf2cP+AHdnDJd6TPVziPdnDJb7ZJDIvFNCqgKMWTLtml6au HwgL4eCHg2Gv9zeulOmeRORy2blICRRRKYdXC6ZdU97U9SMxr/Icid1Rnq/Sd5RHSiCPLopnnWnX lDd1/UhACAc/veRIYM+IR17SYaR6W56/FyFCqS1ECvWnpPycE3PIwKuomV0LutlReqnqOiOKA7er LYgXbP2EXMIdadQl3JFGXcIdadQl3JNGXeI9adTd0p953CTek0Zd4j1p1CXek0b9xvtrGnV3959p 1CXekUZdwj1p1CXek0bdL86RRt0/HWoadQl3pFH3T54jjbrEK8/YsXXk4ZQDqAXTrpGEqet7RiGc yzNeKAM940XfIiWQh1MOoBZMu6a8qet7Rq/yzTN6lW+e8UJ5pATycKJ41pl2TXlT1/eMQri/F36r vYefj9uvAwek5l0t6GZH6aWq67fix2vDjsztEu7I3C7hjsztEu7I3C7hnsztEu/I3C7hnsztEu/J 3C7xnsztEu/J3C7xnszt/u45MrdfvR/NTsSYilBqwbRr09rU9ZlWCOdiWm9nNaa9mNlICcSYilBq wbRrypu6PtN6lW9M61W+Me2F8kgJxJiieNaZdk15U9dnWq/ybTfSqzznoOko31uzULzGxJBqsp/a QqTwe2pGzzwLKRIckLiyBC7oZmfpparL/XPme1njQ4Aj0b2EOxLdS7gj0b2EOxLdS/g40b1EexLd S7wn0b3EexLdS7wn0b3EexLd++U5Et1fyYMmG6JkxVhcMO2es9TU9alcCOeicq/yjcoFXlF5RwlE yYqxuGDaPZU3dX0q9yrfqNyrfKPyC+WREoiSRfGoM+2eypu6PpUL4VzbSRcMJXmRn497YwPGVPO0 FnSzo/RS1SNa/qJvPxMfehIMSvw4a79EO7L2S7gna7/Ee7L2+/HHbo9fniNrv//9R9Z+ifdk7Zd4 R9Z+Cfdk7Zd4T9Z+ifdk7Zd4T9Z+f/cfWfuv9EXmgihfMWItmHbNzkxd11VI4Tyuwq386SquOhcp gShfMWItmHZNeVPXdRVSOJzA9bgDcjUTkVCIwkXxrDPtmjKmrkv97pE8o3j3SJ5R/NVISmbn5+N6 wIDz1TytBd3sKL1UdV1FWXlvwHuoLeGOtNoSPj7UlmhHWm0JH6fVdkt+ptWWeE9abYn3pNWWeM9P EPjlrz9B4IcfmzcS7/kJAvdYnT9BIPFy86Y3lREdK7aqBdOu2YCp69O4EM5F4xfKQBoXeEXjHSUQ HSt2qwXTrilv6vo07lX+jPjdyp8R/5XySAlE36J41pl2TXlT16d9IZzYJn++h59jvRIz4Fc172pB NztKL1VdWk6Jc6K4aVnAPbQs4A5aFmgPLQu4g5a9kjdaFngXLQu8i5YF3vNrB+7OOX7twN05568d SLzj1w4kXLFsZ2YitlRkUgumXZvSpq7PskI4F8teKANZVuAVy3aUQGypyKQWTLumvKnrs6xX+cay XuUby14oj5RAbCmKZ51p15Q3dX2WFcJ59lWuSEGSKD/P9Rv3Ab2qeVoLutlReqnqsjKf0+039lUE 3vHDDRLu+OEGCXf8cIOEe364QeI9P9wg8Z4fbpB4zw83XMmPxhdxlDLhWjDt2sQwdX1uE8K5uM07 do3bLgYDKYE4SplwLZh2TXlT1+c2r/KN27zKN267UB4pgThKFM86064pb+r63CaEc3Gbd9oT3/At Bc+SkqDr5tuLOa5VCLTjJygE2vELFALt+AEKgfb8/oSAt5+fePf4+jGTXnwIwNivHgtJ0f7kv//q 8afHh8dfCfnu8f+4myotCmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKPDwvUGFyZW50IDUgMCBS L0NvbnRlbnRzIDEzIDAgUi9UeXBlL1BhZ2UvUmVzb3VyY2VzPDwvUHJvY1NldCBbL1BERiAvVGV4 dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0vRm9udDw8L0YxIDIgMCBSL0YyIDMgMCBSPj4+Pi9N ZWRpYUJveFswIDAgNjEyIDc5Ml0+PgplbmRvYmoKMTQgMCBvYmoKPDwvTGVuZ3RoIDEwOTUvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJyVWcmOXUUMbYnd3UWC/V0g1GxMeahpi0iYh4YHYQgr ooCigBQ2/D6nmgy3LuAu60nd6qdTJdvlYx+7n2/vXzYte81lvzze7l+2m+35lvbaZf8dv9P+bCss r36P759tv20Ptz823v/aZP8EqKcbp/3z7aef0/4Yx3kfnz9/fXXP65Mv70ovfr6878ntN2kcgkHv PZCdeb88wVXjW947oKlTg5UwixKn0vbLL9v11ZtX9969PMVx/AXz//M0p3Y4fn31zjjxv2DO1G3C f+3iRSiVCf+9j2/Esz1funhNVGTCf+jjC9XZ/jd8PIAT/EcXbvV8vR+erAN4xH/r4yvl2d0vXHxR ShJwtxQ6pcPHPr4Ta8DfmklywN/aqHPA/sbU64T/zsdXshn/mY/vZ3u+cvG9n+P5jYeXhPisZ7+k SmVOt49cPCvVsh5O4UJtdvcHFw+2KwfsAdtN19NBFNWkrz+XqFG29XQWBb0i9xuq7Xz/Ax+fz/Z8 4OIzU5nf66GPN6ocsB/lhMs6fQXlRGa63Pj4TtoD+VaFLAfiWSv1HLC/2bkbud1Cejp3Iz+fe6E5 ne/5cIQnQEdNCM/8vG/7+E41r1cfRXNvNYAXVNu2Tl+VTCXwXKpMta6XHwV9T+np0ktNSQNiQ0Hf poH3skatraezgr4ne3z7S6K8zkZFcy8BMaBgb6nr2a9o7rUHngvNWnrg/tGsOeBvV8qR5wJ78xz+ +x7eQMdAeCwhGwLhN+Zz9rjFyhjFsK+zy8SIA+E0SG3RgL+Q2poD/kJqB6SzjV4qAfNHLw0ofwMZ S18no4GMLSBVDb30VGz95wUbT8XW7e02eun8XK72MbDXAtLfIM1zQHsaem8JjDrWGqkE7u9GZuv5 kBOKZ0Bb5aRUIqMIdH/paEi8UPkZwjxPcH+M4j4q+RHvjyHQ2XU2x23sDN3cJ7g/tBuPKfOId0PJ BhlWJ7z7tJwhw2Z77piSQa05nK4O62kvyM787/3JW4v7k9fHr6+q/3JQ6DLhP/VfDlXFJrw/oAoU +myPPwC/yIwD/o59CJ/t8e+HJNMZ7z81JBkmgAC+U64T3mdCbmNBs25/MRILxKfUoWmOeJ8KNY0m ecTfsUApY2Gxbk/to0se8f4C65+FyLo9Q2PN+eNTc3By9tddYMnQWHnd37FAmc3x9y3QWH0Ojz+Q cxsD/7K7ggmprmeDQJLVss52EURzgvvjssrJGresi94K1iPe30ahDUgJBNPqGHfWgwkFdwq+bw/a gM1cfPTIP9CGgl5PtiJng1xyjXXI6X5/nQCyc8DfochyAN9SzN2xPZnv97dpqCW8XkoEpUQkkA4Y 11rE/N7Hvy6Wa4OmMpZFy61aWcayaNlfRS05tQp/nEVxMF7PHsW8hvF3OT6qOpafy/RVzGs1EM6x PJEAHmzvgU6tuQ79f8S7om+osHpb/afQrP+H7wafvwFfv4G0CmVuZHN0cmVhbQplbmRvYmoKMTUg MCBvYmoKPDwvUGFyZW50IDUgMCBSL0NvbnRlbnRzIDE0IDAgUi9UeXBlL1BhZ2UvUmVzb3VyY2Vz PDwvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0vRm9udDw8L0Yy IDMgMCBSPj4+Pi9NZWRpYUJveFswIDAgNjEyIDc5Ml0+PgplbmRvYmoKMTYgMCBvYmoKWzYgMCBS L0ZpdF0KZW5kb2JqCjE3IDAgb2JqCls4IDAgUi9GaXRdCmVuZG9iagoxOCAwIG9iagpbMSAwIFIv Rml0XQplbmRvYmoKMTkgMCBvYmoKWzYgMCBSL0ZpdF0KZW5kb2JqCjIwIDAgb2JqClsxMCAwIFIv Rml0XQplbmRvYmoKMjEgMCBvYmoKWzEwIDAgUi9GaXRdCmVuZG9iagoyMiAwIG9iagpbOCAwIFIv Rml0XQplbmRvYmoKMjMgMCBvYmoKWzEgMCBSL0ZpdF0KZW5kb2JqCjI0IDAgb2JqClsxMCAwIFIv Rml0XQplbmRvYmoKMjUgMCBvYmoKWzEwIDAgUi9GaXRdCmVuZG9iagoyNiAwIG9iagpbMSAwIFIv Rml0XQplbmRvYmoKMjcgMCBvYmoKWzggMCBSL0ZpdF0KZW5kb2JqCjI4IDAgb2JqCls2IDAgUi9G aXRdCmVuZG9iagoyOSAwIG9iagpbMTIgMCBSL0ZpdF0KZW5kb2JqCjMwIDAgb2JqClsxMiAwIFIv Rml0XQplbmRvYmoKMzEgMCBvYmoKPDwvTGVuZ3RoMSA0OTIzMi9MZW5ndGggMjE0MjcvRmlsdGVy L0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJzsvXlgFUXWN3yq9+6739w9Cbk3NysJJCSXJRBNQyACkX2R oJGAgICjEFREnxEYRVlVcAFUEMR1wCUkqAF1jI7jOo46iqOOjoyiiMojo4gI5PZ3qrovhLjNPM/7 fn98XxJ+fbqqq7uqTp06S1UBQABAhSXAg/uCBZdFj595z/uYsxFAnjxz3oUXK5/vLsD7owDi3y78 zZUz1x8vPg/A8QZAn6WzZkyd/veqASMBBo/Hd/rMwgzvIn8S06sxnTPr4ssWvlP0x8sx3QSQePs3 cy+Yyj37rzkAVy7F9LsXT104z/eBsADgEfwmROfNnzHvX8M/DWD6twCev4q7IYPhAcgQ8iADwNiX QnK2sY8+o5T7AoBkmrB+muEh+BspIFFoIccgCEdJmPSCYSDA99jTR6EdbgMfjId1xAs5EIAJMIwI WKYIVpM7jQXGATgDboatxhPkGmMbPr8JXoCj2IJ/CAT6wkgsPwFmwAH+U6gz7gAFloENBsBYEoCp 8A7+fodtuAVuhT+Q3xpHsVYfXIPfq4SBMNB41jgB3WG1sEZ8V30M1sKTRDIuMGZDN8iGlVyR8Y7x EeRBHdwDD2GbikibMBRicBFcBxtImH8B726DeyFJ7Fw9Xy0+gzUNg4lwCVwBK2EbvEK8ZLT4rnjI +C9jP0iQBgXYptlwgPQmI7j7BLtxpvE+nAu74CXsL/1tE84VHhDPTVYZm4znwA9PEI08RZ4Vy8Qb 239n3G08AnZsTy/kyEisZxpcC8/Cy/Av+IZbbCyGoTAOa/4TySRRkoccf4cLc4u4Rfxb0BN7W4+t vRw2QxOOyG54Ep5G3vwd9sKnxEfSyXAyjawl33B2bjr3On8nv5N/WyDC75HfcchFHl0G98Hj8Gd4 DV4nIn6/lIwmc8hcsp5sInu5Ju4r7ntBEa4VjgvtYl5yb/K4MdL4DkIQgbPhKliMvL0HWmAn/AX2 wDfwLRwhbtKPzCJ3kyayl3zFqVw2N4qbx63j7uMe5kfya/lnhd7CIOEi4TXhffF6cZU8VU6euD95 S/Lh5JvGE8abKDtO/H4e1CBHf4dScR88A2/h19+DD+FjKj/4/QFkMjkfa7mULCe3kofJn8ib5Avs JbDfbG4ANxhrncvNRz5dw93C3Yq1v46/b3Dvcx9yX3Lf8SKfzffhG/m7+Sa+lX+D/0xwC3lCT6GX MEqYLBg4MmXiWeI48UFxu/iceEiqlKZL86TP5Wvkpcqf27u3/yMJyVnJpmQLyq6CknQVcuIu2Ipy vxPH4BXk6F+wxXvhMI5ChMRIPra7gtSQWjKCnEPOIzPINWQZuZlsIHeSreQR7AH2gZOx7UXcQG4c N5WbwS3llnE3cDvxdzf3MvcO9y53EFse5ON8Ed+LH8ZP5s/lL8E+XMYv4pciZ9fy2/jX+bf4/fzn /EEctaDQTbhcuEq4XXhA2Cm8KZ4tXoy/W8VnxDbxTfGEeELipIiUIZVIc6QHpY9lSe4jj5ZXyG/L 3yrzSAbpji2PQocfLoxzsBu3jfMJi8lBzMgkAriw50U4DuNwVnwLVXwSx8VJn2Pb/FxYSKNvSrqA +om7jDwJvcmfYLHE8agVhb3QTD7g9gp/5M6APaSBhIUH+EvEV7gYbEdttIZ7inuSDIKdXCU3kdvI A/mUPAiforwvhFvJReRS2E4Okv7katKXLIa3uQA/jiyFSmMrJxCVDCOHAFsAvxOmw/nwiz+kAj6A A8m7BIfwW9RPrbAOR/Qh+Ij8Ho4R0fgKtRuP2mgqapnVKO/XAdV69TjPFuN8DKMG+Y30OuwkEmrx vtKZwlVwCH6AA+JulKhBqEn3J2cLdwmfGH2NHjjDcJbBgzjvZsFZOGM+RSl5GtM0dR7OdA11SRnO 6tEwGabD1aj11hpNxkbjWuNKYy68iu8eI8XkGNmCM6IV36iEl/D3JniPrMJ5eNYv9/PnfpLToQ2+ ICGSS8pwPhwUF4hrxG3iTvEP4mtSL+T2UrgTJfpjlGYNe3ABvAlfwPdEwbEJQzEksL39sO2T4Ddc Hf80VJMIzMM5W4B6fJDVk0vxK9cg9zbifH4a58Yh1BPnwR/gXcKRIPboAqxfwe/UIp+nYOn7cQSv JS2YMx21dnf4EvvtJP24y7A+Hb+0DrVWG7bpA/gMuW2wdhWjXhhMJuK3vodzYDrW0AdGkx04Ao9D BWrWwfyfkd85xA2DSDa5F99rwBnqhEyoED8hHBQnRxr9uNn802hjDMzfgtYrHc4gjdgKF/ajHfxk FPROjsU2vEV4oYn8lbXidm6GsYy/IvkbeBV+j2OiCwvkwQD6wPF61ZlnVA7oX9Gvb+9EeVmv0pKe PYqLuhcW5Ofl5sSzY9GsbpkZ6ZFwKBjw+9K8HrfL6bDbNFWRJVHgOQLFQ+I1DdGmvIYmIS8+dGgP mo5PxYypHTIamqKYVXN6maZoAysWPb2kjiVndiqpmyX1kyWJO1oJlT2Ko0Pi0abXBsejrWTymEl4 f8PgeF206SC7H8Hu17B7B97HYvhCdEho1uBoE2mIDmmqWTBr5ZCGwfi5HTatOl49Q+tRDDs0G97a 8K4pGJ+3gwTPJOyGCw7pv4MDxYGNaorEBw9pCscH0xY08blDpk5vGj1m0pDB6bFYXY/iJlJ9QXxa E8QHNbmKWBGoZtU0SdVNMqsmOpv2BlZFdxS3rVzd6oZpDUX26fHpU8+b1MRPraN1eIqw3sFNwav2 hU4l8ePe6knLOj5N51cOCc2O0uTKlcuiTW1jJnV8GqPXujr8Br7L5dY0rKzBqlcjE2vHRbE27rq6 SU3kOqwySntCe2X2b0Z8CM1pmBNtUuOD4rNWzmnAoYmsbIKxV8aaIxF9l7EXIkOiK8dPiseaqtLj dVMHZ+zwwcqxV7aE9Wj49Cc9ine4PSZjdzhd1o3d0fFmxsln7I4Vp3e1Y09yltAWxYehQDRFL4hi SybFsU/96GVGP1h5QT8shj91BN9qmo4jMrtJrW5Y6e5P8+n7TWKuOx5d+R2gBMQPfnV6zlQrR8p1 fwf0lsrJSVHD56n7pqKipu7dqYjI1Tim2MYzWbp3j+IFrVyf+Dx3FAmyD0Yjb6fW9S9B9sdidIBX teowDRNNS8ZMMtNRmJbeDHpJUV0T10CftKWe+CfQJ0tST06+3hBHSd4J1Gn3Nyl5J/+43IG0IbP6 N5HALzyeYT6vHRevHTN5UnTIygaLt7XjT0uZz/udfGbdNaVVT+LTOeuOS+fZUxTK804WpolJ9iYh F/9ITKinN/EolCyDRGua3A1DzWudFov97DutstLhpVbjEH2LkVOvWa1s6l90enrAaenTWmdfyWN7 hTyudvzklSu1057VoAJaubImHq1Z2bByaquxZFo86o6v3MU9wD2wct6QhtSAthq7V6U31ayuw07M Iv1RWDkYtCNOlo/ZoZPl4yZP2uXGSGb5+EnNHOGqGwbV7cjBZ5N2oauis1zuZC5NRWkKagkKejOn sEfpu3SAJeypwDJY+oJWAixPSeURuKCVM/PcLA9/eqAbQwdfxF/0CmQYtJMjSUlu5ar0NBCFJA+a LCQJhBVJTHL8UyQPVHSGQxAqch+pbK8c6T5cOaK9Eqrw3n0CL71KY56YJxcvBB2ME1G+7YQuwnGI Cm3omsBAsoybzW3Busr0WCnR0WD2xZrdfJQv5QV+sOiGKJTi47Bw329CRSPd++pHuD+rh5KD9b1K 0/DLA7kCdDXDyf30a+XoddnFNvTcqvQpj4Uej+xKf0V4MfRG6I3wGxGlOr06ozpzYvhO4bbQNuH+ DEWKRKFA6hsZKlSHqsPVESUnlBPOifCBPGGisDy0MX1jxsbMbRnbMhUvZLozo5m9MhdkLs1ck/lO ppLZarTpAZ8/kcm57a5M2kyOtlTHtuKjFm8gAa3c3S0csbtayUQ9nmUvsXN2HfPt96eJ6ruBAJpb ApEs17vuK7hwt7eeo907POLwwZHuI42VlSPcB6GqvahxH7KyqL6x0uOtIJ7yonoU9l2QabQ1eypo G5pdjOhOd4WguCtExYPUU1HEfup2SFz1+Em6TU0Pp3PpaYT6q/gh/FNf16uU1NeOmfQ0pKMyzkBk Gnv79etXRxrr6+uJJ9bH27dP3z69E3nxbEnO7ZNTXoZ2XJIlQZIF+4l895av/lDUf0bdpFlK8vMw UV547+hZI8qTR84KEDF5/Fai/n1H1TkTzp8x578yPn/li0cuaJk28PDoPJQv6pOhl74bpUsjA3eB bLyrq30rElIBXmTaF7Wgd0LS8YKpd/XRsXx8hpdC6C50Fwu0Ens/6CtW2efAHG4GP1OcpVyofc67 hkuEU1TCa6oqyCpBZ1L2oc8qqYIQFSWfKEqKpkcyz9RoFbZIZkLL5XheEtRW8pTulGROFDA4V+zB YARHbqpuyyIsZFxCeNLK5ehqlkpK1SUqp+7mckDAEmpUJGLYdv4FbOTqR7SHj9Q3Hq5vDLWPHDJj 8Gc4CSrdlVWVIw4iv0twFIsql4k9i5Zd/fyyniFKZHdl5bLnnzcHaaeaUB0JKKLjUttkG1fb1A3V 0S7gjWSzImi7jSRy6sQOSejXzxolc4xjMR5/SSyN58Vnkn9Y0v74lckXuAGkovsrL5ARyRZx94mV XLR9L53P65Dz05DzaSitxfCuXnVFdzLLubD7Z8IRQVBjflUqKI7lBrxZ/lF+rtT/qJ/z+33x7Fxv mhL15RLg0vPnSUswsKotyH/UTuxU0FVbwt7KrcbZ21PvObpnQ895PZf0XNNzS08l2rO0J9fTlx2F aFppGpfWyq1q6dFrnMksqiVGuOsbjxQ1jjh4uP4g0xgUnoqS+kYm5H5jSXNmhZ8KeYSSJTvSqFzX YSGCHKWCfJJXLuTVDi2KfKmH+rRYWTeOymqASiyKrBjDqVPWtw+V5vy8OO+JWYm8+Dpu+CPbl02e O+X6NfV3Lxie/DTpIAXPPdz97HNqhxe/uY14txQNGqdf+Yq4O/O826dc+FBR/lOLpz/d6FA44YXk w6J6zlmDJ6hi+67kQtVeP3LQed2pHppq7BfPF9+CCLyjj7xeXeFbEdgMG6QX1bf5t23f8WquWmAv cBT6CgOXi5er14uKnCYHg2nBYCHXnc8V5QLxdnG9+jL/J5tYRUahThzrBrIXXXqO6RZPKMGohvKC 3qseDPUQFKfu9CactVNcZJSLuHR/KIF6p0DP9vbQeNfXzonwNbBPRUozSIY/f4tMXHKWXCrzqNxX t6QvssYFR2Oku/5IPQ4K1T+HUfXsK6KU3qDOhXpC1YMoCfEoeNwQiwYDQTGPKgmPO1Be1keoIlmD kq99lfwguZxcRRLE8eD0suTfI/ctuOfVl7Ys2Maln3voALmJTCaXkNs2n99UM3/pF8ljyS++Wkc5 dxtq8EMooTZYo5+hiIKs5EreLJGUio+KnCiqvJCLdlFTc22AcUQtzw3VwEZskaij1KE7eIegRglV w8golDZ7R2lj3aoccbjycOVPCJuIUpZZIaKUobCJpwkbL+I87VVa7on5YxZuE6pOHOD2tkf5cnH3 0eST3ycbv8fWr8fWL8XWqzBfr8LWS2KuHFVKlWeUjxShRFmjcIoCZhdUbH+VNArn0lgebS4XidpK bZzt9PZrP9X+etp82ngvbfxPtW89f7B9ADe9fSNt231H29dSzq7Gy05sGw9zWW9byhIJkUpRPJdR vcoXTICoi6PFJeJeUcwSG8R54iFRWCKi1HA8KBz/HvoGTRhV8m1UFmk738CUAJcIvTZb4jPfMv9V ldS+NM5HHmLDPKtJgbj7WA22YxPy6D7xEXQwztAjo2X6bQFlHhRBjMgc37H7Uq9dHbufpN8d0W59 mn415t9ECri94iPHh31P+4gdlcLYRzsX0m02Pk/Js6ETQXgcTl3N6J/Qov0HJNRWY2+LRfV7M3pi Ll4kVdE+Ub/SUA9qWhqXIbjVLC3OFQtRtUS7kJslzFDnaFdwC4V71W3aY+pu7Yh6TAtsFtaom7UX 1Je1v3HvCu+o72n7uc+FT9UvNMcV6kLtWm61cK26WlvDyZNsM7g5woXqLG0Bd6UgD+ZqhcFqrXaO co46SZNDWokzwfUXEuoArcop85xdkFRV83MRIajKlhXPQkZpqmiX5TLJaS9jbhKnjFYcCRu9sF46 bY6EojvzEzZ6wayNupve2BQe/S/CyRoo1C5VoT8RtLyEelJy0P32QZqR3moM0HtgLVFBUdUyXvDx vMDZNK2M5/CWw8/wdoHj7BpaWVnJchJnK3G00Ih+N9ePidW59aY4BceNT4hlsi4vVojy9GIchadt UZuda+X66V6UIx0Lgo6FoCyLmhL8jKPX5ehGHm48WFTkrvxvd2Uk7G5vbG+sjITcaDwxw72vERvv ZlYVW3u6NbUsZ9o4nM2KsXeHLUrNZD37YXJYBEWNVGwIoS4pQZuwljxJNCKTp5IHkx8mP0n+A41l iP/8WI1wzfFFFChTG9BmxumcJn/RnSovKWE+qAhenA3IXWjx2qr4VrPblOrdsUd8maz4ZFnhFY6T eRX5hbziBdpjgfZYKJNeR88BRVwP67bRtgYbP8+2xMZtsbXZOFMPKKr1UZU5d+PGJdQyNjPaqH/J VMPlJ+cGOhZoSrGTR6wUm3/URlYAYllP2nnkkClH1KXYq6soFUrUlJG2J1QqNcz9oDqvV2k1K7Xk cVtvZYmtN+vYGZGeCWUcXkQ+wJfxOi/U8NehStuiNCv7eOl5/nXlfQXd9hIlwQ9QRik385uVLfyj ShP/jGIz3bry3glOL2du3V7dUVKW4KL0Ivt6Y856XY31THDj8cJK13SLYgovCifLIY4PysVcvjyA K5dHcrp8HjdRVn1cujyCGyLfIW+XX+Xe4z7n9ss/cLZ8rkAeLi+Ul8sPcRLVQfOLUj+QEoU6YJJA dQjxbCBRbhJJS/6tfQcKQA/+rWM1/FMnBlNftQ4t+X605C5Ih636hPXiemWDfYNTUIjsVFxyKD+0 UL3CK1/hWei/XlihrLBf77zOu8K33L88uDx0fcQue1ESIn5vxBcJ+SNyWg+HGu4h84H8RzUCmluL arxGvadoaaae2ZA5L3NJ5pZMKZp5KJPLdOdvAeKCLBb/UCOdseiPJ400853oDVQdrDpIFWJ9I3o+ CfRr+vYpt0wzEJ8XTbLpw9dVlz184YoWMphcl1yUfDq5K7mI9Ppsx45PPnziib3c23s3zGsu6p+8 JHlHclNyLhroWT8kDcM4cfQ45QO1y0dxFlA+XKHnSuIu364Qf5ZILhTfETmvJ9fhdEK6m1o2FyjY PZnIlndI/Qs9kJVZavVPzHS7Omr5jNNdQtMjPGXiWAwJ9Y1M46OzYbl08XiYw65ZHt1t5O/EOXbR tmnrR855+dmtjy6oPn9o7y3i7kDsw0eXtc72+Nv/JjyXbOg5beDoWQ4NK6ae8FPYHz/E4Kh+TYVr mOsceY5tjn2b+oBzS/xx57uqJimSFlQCWh9njbPGJStu1eNz+lw+dx9nH9dZrsudV7rf0mwL1YXh BZnL1eXh6zMlNeBT7S7nOOflzqXOW533OEVn1GH3ORx2l93vCAZy09w+0uDb4uN8PojGKLuQcX5Q nDQIyQeH28E53k7P3yI1SW3SGxhrLZsXJ9F4aZyLx/wduZbd64JTXGOyYHnRTDmecg6YFkANUO+8 2v088VheM3pxGOUhQ8sYP9FRDqbF+J5cPO7xnOIqOsdzv9yz5LlnG66e05K8653548+fWfn3PXMq Rw3N2blf3D3qlWvu+1tGv+u3Jz8mVdvrYu0b+ZE5kwYNP9cuUms83PhM+AbnTjF5Qz9jl6c18/GC F4oFdHX96Or6Q0UzxBkFl0kLHZcVvGd/J26v0yY4J2TXxWfZZ3ovjM0uuLD4iszrM9fF7N44tdjd shKU6jPCkcSY7DHxZ7OfjQuN2Y3x32X/Lv7P7H/GpSKtuyMnOyde4UjEa7Vax+Ds6vgcx4z4lY6r slc4Vmbfrz3geDA7TdVUh5QtxcNa2BHIlrPjmkMgwYkhPRxNzA2RuaHNIS60m5uBcXGbbo9UZKWT 9B4+HoYSqpaGRaIJuk4xmjSQNWQLaSJtRCH/LeiRCrdAhB7d1dDXRpAE9bRgIlgr5+dFemblb3E3 uTl3LfnaYw5guMdfLZmvHTdpB+j96lgMhIE/0qL51PFuLDpcX7TPpPOL9qG1M1UXc1azkR/pmWci P96w6CfNaRXZyB4kmHq52UtTb+gub4Uj6q3QGFw073Pdacc8R4UWokirKOr4k1ow8PfX+jt6Z/dG Pg5zVGfXxO/Xfp+tAV00YFMxLTcQMBVLPvvtneiDSkcwAwFZ8vuCAYFJFo0ShpNoZPOym9aecXZi 1383LFv89e+JjwTl5LtpV1/9u2Elxf1I0+uXrzbgmeQXyXfIhxlrl185JjEs3dtzwMQrH5n3x5nf vOJovKB3dkUit2TmxU+vWvTBRYRQ+SpGnbSLrSPM1+MlaqlQKo5W52GEvkaVJSJyuQLPyaCoGNAL i6m9JT10TZIxpofFdBZh0sM7R3PzuCXcGk7gwkr7Q9aojJm0g8NRYd52eyVeMJ7fZ+mkSuZ+ouHo TX1t8lFyhHBDcqTw3NGjx8/EVt2CFiMHWxWGlXo/WZFV2Y1KRD1LOUuVz1Enute513s2+O8MPOB+ IvA3/6fSEcnmsNsxtpZz01S7Lep4nTpV6Bpk6+mj0xvS+XnpS9K5aHpp+pb0tnQhnaDfHQ2XhtvC fJgqgkgHR4BF1KYXUEntAlUGzA1Pi3lwSAJsaqPNczu5eHYeHbdbSIEt7abfLloSIQWlv3v3kb++ t8iXiUbws6f7Tb74wnWP8EUnksmj76+rm3rnhEVHKNdlAHkV9bGJoXuL+CIpaiu3CSARmx7pn5DQ CW1BynegzeHe6MXs11W65hLGiz2VApoS6ayuC2QmhCheZHR7JXsE/Goh5KryAW2//Xv1B+17u/ii +LL2ov19eBu97HfsX8CnqrpduEfcrt1nf1JoEZ/UHrO/JKg9hWyxRIva7xRuEe/UbrMr1uqKQpwO iVokZ8x01FS8QSc5Rpu8scX0nzfqfupNT6cpm8QDkQUWqbGR7+AxM6WavvM5myBGW43SFgkd5laj TD+PB3sUeI6LEvChkGqSKJbZNJ/NpqmSjKGg6lMUVbDZ7ZZrjZXwdgz/BDsvajZZVSRFlkVRQJeR mE42mgaU3xL0oVtJqa5FpadtT+slNKbBpD1KF6g4Enak1qAi4RHt9ZFQe3sk3F4fSi1DmR6z2/pl rcc/HnYFD3WkR3T0pE8npkfIHOlGy4uil8Z6uuiEXnQaUkLIjORWUvIhsaNeJP8k3ZMbky8kP0h+ iLLk4b8+gUEietVDj7fixBtmfC70FM6EOJSRRn2WHFEyxMxAZHj60IxhuX93f+RR+4RrwufkzQxf mHd93s3hWyL3R3alvxh5Kd0uSQ5/QAoH8qVCf134Cu567n7pMekFyf5M4j03l5lT1stT7MjRi3om cvTsAryEMxNzc07kcDk1bJW01OlKnJFJ6GpuU+YPmUJmZjEpBx1zqZ/FwYSYnuGpiunpbryEIolY K3fZY4Jsd2jFVHbwGaP4mFEsUYwldN1n69YrTylUCxx1WfbNdg4jGgODGt0ZSNgjoxIk0YAz58ZS ZFN5YWxKkHwUJKOCU4Jzg3wwXD57YCp2Ru3feLCeBvpFZmofm8fIbRRAdOyZTWCWvcgU6+aSTNJY dzDl2OegK5+emRifMz2Hqy+qoyuEONa8020qrcZ6qrzzUVVTs8/7AsEY1d6ShMqAavC+ffqariKh HpbfF6BrZn379CYzjKK/vv5Uay2fnpv8wuaW+aH31t/79MQ7b/7T2aPn1o4n5/f5IqfvpMFnDyl3 27iPe95xa92KJ5Ktq687O6NvWKmpaV4++YbajNxoxpghA5J/9ZaF8isHTCzL65szA1m+DKXhVuZZ ZsCmXeA1juq9bBV9089K57wTpYnaxMDEUF3G97LUWxjgGJDWO32IUOuoTRuSfqt8u6rZnSj+EMFB aBZlHx2LNJvNBVowpkTmdSPd3IUcn+dqJYW6ncyDJdT2ZlaZ/G6sHHGwvfKzkehxmv7mQaox0cA1 1pP66km6baY0U5sZmBmanSHWY7zA1jGQdV50rZFh+f40VKknvetlJHxN83PJZPuuc3fo3sSwK+uv XXrhjOvF3e2Hbk3uT/6QPJR8/9y6jVz3+0bN27z98bs3UV06AftehTMhDP/Ux0xy1XnrArNcs72z A1eHrgyv59bbX3C/EPqb+53QAemAciDtgP+olNYvrZ9/uHd4oCZUZ59tl/t7+wb6hvgrxCtcy8Tr XSvCD3ofCOzyPh5QnUxC0xOUPub1JZzlDpoT7pZg1OVJOHYTATTkmddjAx2Lgo7loHwNyuluVF8C PooGZUJzSQxKHPTGERuFBiqSLsd84cgkk5V0zZAuGRYdPlhEFw3r9xWZa4ZITY8BeWouEjKp6tNX pEJHgxQURaFX8kvnBaNmX734otEz/cRXdPi1A8kvSeDgc59yX5WNG79229Mbz51b8ofnSB4RMFrP fYBGJOORd1MtuVmj9/DWSXVandeUlg0oGkdVdV63Jd24/nzC3t+fCA/nB9uH+weHb1dVHxMXG5Ua 3WmTnS4cCi1Y6HTkESopLhdEbqKyE1PCmZMqT/aw8YgpMcwamFEX86NRVhyzpdnabK8pLVJ9XSzW 2+ogxl9BjDE7ioowNXl84I7JTySPJ59rvoaE270lg6+aunzphdOXbTy3juSjP+kk4Vs594l5286+ 5L57n7h7M/Z3IPY3H2XFBxnknl3gxnlSY6u4Xb3Dsc79oPiA9qT6pKM1oig+MpQ7S6rRRnV70PG4 9HjkRe0l+zvau/aj8vcOR4Yrw6+jhvDrTk/C5X/G/7qf9zNp6FbFqDOIlLtBxyDGO9rZ4OScIS/1 ex8PpydIuZctO2dGzeXn7EKTFvUwaSiDUd2F6nQL3UN2Y7OneL3I5hbB5g1RdufYZIiREr8pRCXd pnSb221zN6GbK6boDlcCGW5pw6LT1qEPotur+0J6ga8qpHdz4QVVcIjqaua1VrUzt9iLjcASXtoY LOS1VDWlzamihy0jxl4AfOCtoI1uDlLS1KJqZ7LkwFgVM3N1+6gGrWfVO3XkkpNW6qTVO3Vklrlg wjZ30DlH01rO/C3UFoSKeBRdLCrjwMeY95Vm+sdB7hgJ9TnwaPLL62YT31sHiVdq1/lrpg6anM8v nHheZSUhY0vuuPuxtR+iLBQlX0w+ffWqoeQ3Vy2urr6U6o0QToDPMLIKQKte1kcg3YWoO+qpE5aE REV4JsT5Ax7O5w14nGkucDvTCLg5n6q4bGSKzbBxNjoQmkQ8rgAxAiRAk93c+N1D+Gkpzaep5VXK KGW0wisF7hLPFA/naSWC7nCm5XG+KbAl0BbgAlQmVHsiEA4u3MXNBnPMUKXSPd8T9egyh/dBCKcJ DUIRVXipKHPhj2WH0spZzFAWlJlW8Jf746he46GNFbdfvvDSvOozz+j9178m928U8kZfv3RczvPu ijG1H554gh/G5n5yjNDAPIgSMlKfdkXmskzOa3fM63W9Y0kvIUowWuZLSTlXzuukmqvmz3XV+epy JxZOxKG6yHXUczTNO8BRHhhQUF6MYWKgtmBw8SF7e1C7EW22ze6wdbc78p2BoL+Hw46BTCiHzoDH 2Axggu70MCFpsdlNWtDdnADxXJP2SpgTQfWnM8M/RaQKJ8uVT4lT60EZbvPLobDUvdCWFwlRpaOG w5HITb1IL1RBrboG5Tkxb7j0pPY5bOkf90F3+76UsWo/bK1spew/sMaxyptxcJj4Euq20qif7vpW yIo7ZeIamd5yzfbNzr2wcGbR7BKJWrmgGAim7H5vVGGWAAd7YwSBUUMUHYU03ylddiUZqGQWTLyk b26aY1HbO1dPI+SZPy0h8pnznrwp+c3HJ65tuPDG5bNmXFuT38/fLRboFT//zoceu2kPsZHIw7ed OOup3XMqd93o5K79/aa777pvyyZk1s0Y1dWhXg9As17kIlmkgg6kexAZ5PkH+YGoshgQc7hJnlke kRAuzefxpvE+jrgoUzN5WdU0n18LANi0PEXVozmJR1ViqERFNtMd++ycxJrQlhA3L3QoxH0dIiHw 5QX8TG1h2S1+cshP/OFglcl4jLitrRe8O2KlzGgAPeqDyNMgc68UFmahNaAOQjfOj6KcYOZOordk +/Knp24clZncHx1zRs0l5cn96BZ8unnovOU3ta/lej0wuffgFde3f4WdRtm+BSfiQ2yfRoYrdoFK d2Y8WpWujla5JWqT2qa+oX6tillqg7pY3YIZIi/JIAo8WjGd7cfwUI8+kSRKsqBxMtpMJouxnIQQ Vqx+nepHFZuebAvJbTmJ84vowQq6NnoLPVhBwsLjREieOD5cyDv+Po7QChyhKWyP7lu6Svxhi8PD 1sD1q8M9EjLv5tOkfHWm9Kj2jPaS+qr2vqaN4xt4ziGH1BrpHGWBJD6ufiQcFE4I30niSHmkMlO6 Wlgt3ClsFO+Q7pDvULQswSsVCUVid6m73F0pcdQKtaKGPqmqqYomaiovCTZRkOhRFZtNkTVe02xC K3exHhFLlIosmcgzHJwtjywBkoUNDtur/stysWm/w+4jjSGcUTQWSi2YmfsJytXu55XKU8vkLzWr MWtLnkY/ML/e3M2iAU+MyJ4VJEyGkcnJ28h1yTeT312Lwc4RsiD52/bzyYcrkg/R1YCTozmO7brp hXQsxdEit0RsEtvEN8Svza22xeIWzBCxSzy6ZHwegdSoQVj40ahZ41RujpG1s7YIQNqAWjGfDNgF hfh2PdaFVsjulwL2BJ9QEqFEfDA3RBkSGhy3R/mSwnFqQ+GSws2F90oPyPfbH5MeszcVvlG4t9AJ hSWFo/HBM4UfFUqFeiQjUYXpJeyhKMcEOZJJzUazJseY9RBkt8eTn56RkZevoei53Hlejz65d4OH zEVBauVqdFckPS8zA/PmZpCGDJKBeTtz8/LyqcfVDJDPnBC1ilK9D7Y7H4vm6wMRlYic/ES+3v+M REn+6/kf5fOu/Kz8Jfk85EfzS/ONfCE/XPBJZSqIspayTF1ZeQTtPZqkI431lKSmLguIUYV2OEcw v4iaJVKUFvPT+CjIoqRggE3l/JNT+dSsXkT4VW0z15XWbD3v8q0FOLcz88cMmNUzub9bVZ+Bs3ok 9wt5a38/fsKE8VPOG7yhvY6bclfPyqGr1iU5rubOycU1S29vP2HuWAp1OGYB2KyH5LRg2mRlliK0 CgRHyz1YGew64BYlpto8stMh2W02dFU5khcAptqAGPQM0c+oNs2WZ3dS/joc9pMazk4OoZU7XcMx Tv1IyZkTI+Xlxk5TaYxJqOiEuuT+nDEVwy4rQkUhrnqr/o5RWVy3h2b0G720OZkl5G3cWT1r6X9R vTYW/dc7sKcOjHbW60M/J/uV79O+9wsvcp+LnDcshlWuzj0xbWKgLrSe2yBtUNbbW9U93N/FD9Q9 9v3ifulzh/sB5VXuz9IflRfs4uXKCmmpwnuYFNqClEU+QfZVyJGG9HnpXLozBqeFJ2aQZzrtKeun znbPRJ99dkgg1PSR+rSEF7sFfh8GeDl5uR3s3NiV7Rv/RRLJl7+6Ofn9ShJdd8klt912ySXruOzV RFqZfPHrfyX/uNR48K4HH9yy8cEHaX9XJX8jrMf+ujE+uUPv2S9taBrnTfAVjoq0RPpgfphjWNrg 9B/SVRrjpuKWI/IP6QrOn47xbMBmc7ucqXjWU+h0uvLcbhao2DpHtCMOVuJAuvf9KKZltonaexrT dohT6FkZP5V0sIJaGqqc6vUqIpU/MmcX4ZIndk26aRQOceDGmdOuuf6CC5fj0I6envxHsj15JPle zYT2A/yulu2bWh7YSmOVc7Hv07DvHsiETXpfbyWXcCR8lRnDucGOwb7hGcq8LJKp+IOJOrFOO8cx Ma0uWBeZmHm/dn/GUfWI43uf3QPOdMoEweY3g3rZ5ZZCGJB18xZiZJrn8bCgXr3JTdyRLNNNOtKh /4c7db+o0WLAbHG2NjNtdnB2eGYmMoB4JObkmJEo9XJI4lSYyg/re++Uxy5fSfi2OXdWEj556Lrp M1csnTr15uRvuMBZ45ZvJm6CNmbyuZuO1fA779m8tenROx+hHvoyAL4vG/0H9YL1IlGdZJw4U7xc 5Eu8k5yznPO8gqa67Fl27ia7Yeeq7KPsnL2Vu0IvlGWc4TwnaQWgutVSdZ4qqJHF3s1ebop3sfdR 7xteweuGPLoAiBLAcUvIFroC6KnaRTIgtbBxckIfqQ+PMB1xZAbO74oyUxgaobYpOK62qTc7N1XW DyUhxmb1SZdc8pAtdE5XXzS4oe6cs84YMLZEyFt/0eDe3/UcuC35L+xjKc5oN/axO/ec3iZ5pLiS H/QE4xu8G3zr82/rrsq+Gh/nfdKxy/li7NP4UceRbKnQMcExw3Gbbb33gexddnlgXM8ZnHdh9vS8 Zd5lvuuzr81R++YNkWpswx2jXDWxQdlydk5+Xl977xjdi+idI0ua6FFjIUe+PTs7Oy7nZOvFl9oX +q70Lyi8vPty/9Lud/hv674ze2fcsYTcFFwdur3777s3FUvBWECPxRMBPSMrkRUgH2HQU67ERufe lMvl6qHMRG6kmB1ZQLszupiUFpOSYlLcLVaKwlVOYmDZJvPslVZlWma6Wx4uWthKWX4C7Q1bu7N0 KDvTRi3RQbA2VHpLhEgkQPKy+8RqYuNJXXA6mR08QjQS5IRILJsrSHPYuYLIFIEINQW20RESqUmT MWrCP9SBT6G+MZ1u/7xKY45Yq0mz2fZYDk3vbcnKMdPhCEvr6XhzkYP0ya7J3uC4Nfv57LezpVi2 3SEIEbCiGiin8U1LsEcVsUJgls7OTbAdr0y0/kDMPS+hgSwhhwgPKPd0B0xgJdMCWJIQfQQIZIpw SOBoFwI6fjpQHtTxu0EdPxrUe/dNBOnabFDPLcQLftcVzGLLoEJwQkRH++WKkNERI8JZnWebYOyH nkGrb6Sn0eabSZMZ1q6VGVM24k+9eT42x3hZV23eKlcBXpAPXz3uqLD77BX0ttlO98G+2GGrYME7 oYcBGq0dLXreNT8vP4ftaFGF0HFDi/49FrpUWkoi3ksuuLhvrs8/LPnQuYve//T9twuS33umTJpb Gs3II8/WTTr89XvtpKRo7ISCjJKo3+epPXPi7SufunFVrzMHZQXi3fwZM4fXXn/zX5twFmUZn3Nr xU1oFV/TC6OAwatW6OrvHO6sc8lhP4T4gB+C3jQfCXo5HwnxqqzJ9hBltwuCW4JNQb4BSVuQD2KQ 3uwn1Gi0gJ+e2b5Md9ptaolWAhgnT0EtQcP4ghCfF/RO8Ff5Nvse9fENviW+Nb43fId8Ivjcvqiv 1Cf4wpGFW1LuVG1TX9QTA9hZVJ/RRjfFTph7Yu7DLMY/yM56Y9F99GRxuRXj1xMM6H2Mp0HJ2mzy xHuX9871cFe12fIz8oeHpv327KsqbOrvfkciQt7e5PhrijLS3+9ePmZIr9vI63vfuje5AvlzA2qZ cUIeekgb9eA5ngs960RelcJSJVfpqeVqPfs5mcV+HsEWAM3v82mqlObL8/uBKkhngPlJ5kLHL/hJ qnLSQVLIIYUoPx8Cmkamk39Uby745eXR7TXfqZ02fmT/p2dftO1sEs4aWzV0fncS3jxh2vnb1nFb kqG9MwaMunwfacOgCvtpQ09wMvbTRtJ1v1gQKUnI9CLRi0IvGGK924KUhXPRSP/EHQKReJuiaHYb xqycl4+oES0bethetNlxbh/SA5nRhAaizQdhWy50tyWgv20ZqNaOmEYcdvYtmxpMCARUIoEGVfRk WIW1w6V7baAJNk1VOY5IeK9W0LVjPZRRkLA5stiZS8ERDEbcWpU2ih1lKdVtAldhE6qEUQIv7OZK 0UVdorvsvYFEUYXwJGx/HmUrTIWrKDTiYD1aqvow26hiaeahU/fcW0GwCWxqF9XT9TTztDOJpQXp RkUahmBPJMeT/Jf6ByWn+xUSSyL32j9+bEigRw+um8lTFSOifshTO5ev90LOaiBxmiyq6RDgugke MSL71G6ax25nG5lxWwVfIQ3lh0ob+A0SWz/XFxafhSy0CYIoqDZNsKdDRAiIPjWs+e32OBQI+WIP tUDLt/eCvuKZag2cxZ0lDpWHqVfAQuEKcaG6ULvCvgyWC8vE5epybZn9PXhP2CPuUd/T9ti/gC+E feI+9Qttn/0H+EE4Ih6Vj6g/aEfsPcRW4y1dTe+fEPLworYa77OURlP21DOgKbapGe5vnuNCatPx 0nnTU7U2Pf0q3fSkqdT2pqTSQe+wvXn63uYIa2/zbL2M7m3+0n6lZO5XaiXOKidHNy2VgSpxQhR5 fjHYEDrwxLkzSsKO53eRiOmr0P1Ka7vS3K2s/ze2K02VD6byZjocLQFQzb/TpjsqsMdHmx0V2OGj qPZtup3mHEK1z5tEouckbDS1N2UEmBWhfhGVrzT6h8R4ntQlm4jnxSeIa8erxJ/cnvzmiZ0oY0O5 Vorj73Pb2yeglNlx5jawmbtBX1UgvyRwG+Rd5AOyRz7kEBU5IoSkAqkv9FOGkjryW3K5rOWRIrkP 6S/XkOHyBttR6ais5gp5cnctIfTXqoWR2h8F5WxtvFCnTRcu1haSq7VbhXXybm2P8IF2QnPwgiyr WkCICt21cqFKqxFUvxDW+msjtYu0B4QnhJe1I4IqY29bvCGqL95tQV9boO6A3+5JEEGTBTqISBRQ FXqQce/jhT0SBjsqu1d3BXISfB6n+jhOFSWbzXp8yEborR7Ex7Y8EH0AoiSK6KsqqmoDsZW7uFkq V+k6jE2ZMcqx2bHXwTt4ms2V22i295C5LUBPwQgw45QmaAzRJc7wCHf9EXYHJaZ2xQs95FnUmNqP Nu9Sa5rBClPQH9OiKNO0g+aCTUo86hsb5xN6KSdsXAkdVTtZnFxLznnqBTI8uYGsSD7w7vtcnOOT H5CcpNr+JhmWfILqDmdyjDAWRzWNJHZ6C0SSRrsesrsSSsDhSsj0ItGLGMA8jk6uLNTJoiQJDptT cnOQJglpnIBSRBfVG9CVbCWPokJ1OUqcBRD1l/ob/DxdbGS+Vl6CrUF6M7ol/PS8SgWvh8KJxWyf P19XOZbiCEdTXlIBekafhHWWyPe8ZauLRrSH8Ur1qvkXUJBb80e4D+/DuLe+xJxQqFPNM2BsQslO thpsTaP62iY3mvr+aOqbBTfsNnC0jEM7eDdhf+PEOib/ue50eKrS3GlhvHhDVSIVM0xQ2oxp81t1 5iSSnTxGV/lsy89JipJHSTy5ojq3+pzFo8eMDA/qPe38ME4oJ/fNCW5X/bQzsj0fOC6tA/b3D0Xu pgOH2x+c4qr8Tgkr7G9yb/2kkv0LHS+UNq89duxEuxsUP9PyhL3B3pPPTI6EajccO3bsKjdY+Sd/ HL0lK4ursLANWvlXYZ5wKXgRNXIm1IkvwmSyH87DZxchqvlMyBAegglY/nJMX4r0Fq7CaMfyExFb EeWIEYg8xLmIcyyMQwzEd15GbMNvTKHfYfQTmCO/BmdgXYBYh5iKuFWcCLfhs/VSBUyj+VjXavxG HO9vx/xN0jZYi/cb8HkdLcsofX8iDMfnxXh/izjRMOQbQMY8wPt2zA9g/TfTNiPNw/ovFS41DuJ9 d/z2MHy+DOkEpOOt9obY/Sf0HdZX2scV9B75swjz1yLGIlYhzkX+0PdL8b0sTN+A9zZsl4rUjnAK ANlYppI7A5qQ9sD6q61+A+s39uNkn7D9rE0/jQm0fR2BbaL9OoB4DfFGh7Z1xg2n4VIYzJez8aN9 diAGcK/BIORLkvZL/NT4ngIl713s15MIUZgOvRQwtmE7q8SdsAHTZYhKhkuBCBthLn8Yx2AnXCWt g7sxH7heiCOQy30FESkX+iL/JuH3z0HMwG/+kcnDdNoG4yukWcKn6GFcCg2IOVj3yyk+Ud5geiiO 6yQse4LOCOTrUsRs5MEGxHzaPqy/hPIcx/17MjH5eyy7F+uppcA6sxiw7+a4wuX4fiN+i7B6zHEw KQKfz0GePoJ4BvEsbUMKTM4ssG9tA57bZnyLNA0RQbyGWEvlDdGAqKBlsH4Ny2tMXlFmqGxS+aCy Ib7IZHUcbbvZBzYXVllz5mJ8/1xEGFEgPQTnWSjAspQ/06jM0vmS+jaVLSozKcpk+iIm9y/RflKZ 6kBvFdtgDG0DqxdlK0XpvMPvXkkp72dtuoPfA2uozFJ5S1HKFyprdD7SOWHR0R36WmzNkWJ8vxuT dZTFFE3x4iR9He7Ab06U1qKcfgkjhfdhJP9nGCleifRm7N8uzMP+CHtQhxXBKKUNCnEsR+G7t3ei GyjkPWQO1nWTsB15sQc2Mb7u4bKFPUQUtxsHRCAvi9u5Rez+R7QzSJv5jFKKjs/+0/z/Cbh3xO0w E++/EPcYBvbnZjon5C9JKSKaopjfjFiC6K4UkQ3KRaRVngBuCeAwYq6gQ39Rh75CG1QJftCRT7mY P0E6i+ndNfj9F8mXcAOO1/WyH+L8AdSNWBf3DtoHBP0+0hEd5Og0messSymaktfOlMoM1btIRaRh nHe7EU8i3rfwT8THKI9DEWdR20D1M7MPqKMRN5jyahw8KZ8vw0akN6bks5Ocdu8kn3JnuexMqW2h +p3ZFpyn2I4bUv2n+pHqOKojqZ6jti9VvjPt8P5tqDv+xvTwazDZmteFiFJECX7jKUuPPIkO6mGc o59LbxlPylXGk/wrxpPS7cb98kXGS9JOYyP2u/CkTW0zdRmdTylbSvlE7WLKjop5MNPSZ3ewslg/ s6MTmR4A6Uqcf3NgGn73z9Su0nnIb8R5h/zE710jPAi/ET6GNdh2F/+omS+Mg5FUJwoL8B7zUafT 5zZ+DXs+VvgWFgiFeP8g0jvBI8mwQHqOvmO8xvI+MZ/RPHEyrEe5KxFWwL3iDphEx4r2g+ttvELH Hud8RFkCm2RAGf4Y7hCOYZ/bsI8vMnonkyf6botxjPZPHgBBkcf+0TII+o64CaIWP9YxXrQxHt3G ZBh5Qb8pvc38DRDfxfKb4WpFgzuUfNRP30FERl3C6toB5yg647vA7PW/cH58iTI2AZaLPuMHJv8P GQZ/DOfQlzi/KAg+80NY/BLuxLm0nPHHpKvo/OG/BD+VEezfeOZPfIkyfh/Ml7bDaqkN5W4P2oI9 OG5fYl8ugn54v1bYbhzHskPwG0DrxvwxzD+hdko33qDzRW6DkKxj/ViGtoH5f1gv/ym29xZYjrpk oPIl3CNRLxvogXPohuhlgqUXIxYhVptgeW6TYpxxC1xN87kZ8BK2ggMwCJ0Lwu9x7t0JA/kHQBNm ov/wBVzDlcAyfiTK3UG0GTxcTdNCMRTwB6GWP8rszzJRg76sXADt+OcwWqjD99tgutAM03kD70OI 21Ae8T2xFSaLF6CfdT5+xwLXB99RYbS0Cu9LjIdoOVbHUSNAIVwJZey9DmBtTYG2eWuHNt+Gvfod ygNtL/3bQR3aS9t6sp1WG3+qfayf9Lv4HivzdxiIfPoAkWvS5BjuBtiO2MK9j354Gywi64zdyNea ThjaMS0sIssRoxGCsAjuQtoD6ReIPYiNiKcQ/y30huvw288ibaFxAQX3B9RdSPH5fYinEf9IPesI Ws9P5XeE8Jmxu2NaLIMKCq4YdXrx6c9Y+bsgISxEPVxq7KbgF4BGITmhUFagkPsY8yfie53SYgGs F+Zi2bHA/1qbfgn4U9qBj3rHPqbGA2ng38AHHWiUUpxfPah9/t+0738CHN/FiAsZ/7dATyZDn6NP Lht/JE/B+WSvcQz1uURhpiHC+HkXeFLjhPnLWX6n8UNZ6UN53jkf7yspUunO4/prafzu7I5IyUEK chnoFMI/sDyicxrtgU4hURkr/nH6ZL0/h/GQQD7VCOOxLR//OC25oYSCm4fpDfj8M8inOJkeD4UU tCwF8jZOgbzeTcF9DDEKfiw+G8vKn0nRga+TKF/5Nvoue5+NT0rOO48PvgvC86iP9qHPPB4inWnH Odt53nbOS+mSnyrTaW6U/tw3/78EnDuvIF5EvPB/tR6UcwIoqwg3oE/3FvobTeir3oMx5qtwA0D7 coDjzwKcmIJ6CG3wiYcxbwLe5yH9FyKEebORojU6vhfv5+GztxGvIbYI6bDQ8ivDmB5ivtt+v/W9 XPN9+t4x9HaO9zHfP74McSfe/wWBUnb8j0hvRfodlm/C9+qQog9w4hqkCUyPRqA8nHgT02ci0O6f 6I84gMB2nkA35kQJvn8XYgH1R34iDv0/S38m/vh3qbkGAPXM58T2do4h/m2aGs9foZ1jjdT4/xpN xRI/ohYf0Od7haJD7POLMU6K4nj+YOEw4mthhdGOPqXM/Gj0ZZnPTf1HizJ/ew/zJ4m1psgo9Z2p /0p9Z+q/It3I4rzXsT2Xwtk0zmftStmRDrqVK4YZiIAF1HtQjWX+iu05hLrHhfb1O/Qt11BYC53n mzBeRdvlQp37DHnK+A7pa5jORFumpmxaSrf+SMf+2Kb9X03/pzbyf2BTR1mY3Qmp/JkWOj8vsZBN 0dkW/6f4Ndv9P7blP2OjO9rp/206ZedTUM+EMgpZx3brP/ZLO/sBv5b+NT/3P0139js6pHdQ/MJz lu7sl6TSnfGj5z+WPdOfieB8S6HTvPtPgfN0kDDXeC81X1Nt6DyPT843Ky0thsGIISlKHoQC1COF iNVW3BXHe7SBxlXUviknoEx5GMow/Rj7t2aZzjHqTNtnrCY70Zf+nv07u9dhWhZeY2UnWaj7NXnu LLfUP2f+IfKMtX0NjsVhKEEMQHgROxAXnxzrEnrWLvkSj5aXxrn8PuM7/NZ3P+cL/hzFOG8+jfcw 7cK0C3VxurQDutF1DRZ/t2H8+gnqxRdh9qk1PqNdamFlzmNry+/DSNTzMzEmnit8YjzE9nBCGGrM T+2jsLW12629lHS6NiR/Tfd+jIet9bmJcgjt4LcwQRoI3dg+hLkWPx3LXkDXprh/0n+jmq0hhyza g65PUXslFTIb4+ywjtwfUSf0ge6ICmuf6lz+GH57K3t3FduTOQ5NwsMwke6FadvgVvVFuFXB/qgT YZOcAZuE+XCL1h82KHQNOQPWUnuVsqvI++RPrP3RtcycDmuarM+dfQLWvj6oVyuMrR3rTb2nVCNv xpp7Q9Y6+y/6NvidvogeiMOIz356vdN4zVr3XGLZ+AtP2vzO6/R3QU+hkNVnrsmizRbt+B07azvj cee2pOpCvrT/nC+U8k2sNSq6z3aNtQeXQPisvPHMLxgIZ+N4jaJrZuIyCAkrYSy3zXj+ZBn0mdga 41+YzK6k7RTMfbt0S+Zu4eiB5PfAx9Yk32Z7eNdZWIRyej/bM/uSrYWNlbYj6LqjAWORV5+dAs6t kzA+E7ZjXRRs38943sKdwhgmn2FLNtOFozBMeJDJjNfaE3QJaxGUd/NQRvtYuJTuvbH9PUYZr75E vq+EUayPdG1uO8ot8oe/i60Pnpsqq1TBeHkFyuujKDvXYL01kCVtQByGkNQb/cOV2O8h+O41sJz7 F5RRkBuNjzkB77EhFDxAmYCeOeoeoHu/dE/Y2le7HHEr9ofubX1Ly7Gy5l4uRXcKbhuJWfuEqfs0 857lvWLhWwv3dwCWM/6JOM4dpCuH+H0O2/XfZpt4N8pqJ+A70yzwiEy6Byicg7w6HdWdge9SWtIZ mE9pbmdY+ZHOwHxKB3UG5g/6iXb8XLmfa8fP5ed1Bubn/R9ox899N94ZmB//hfbVdgbm1/4H7fg5 Pud0Bubn/EI7RnYG5o/s3A7UT48insEY9TFqP9FWL0RK/z35M5DORTyC9xj3GjOt9EtWuVmnQH+M LAuDETSWRntsfIXYiBhzCrQuw2++k6rHuAjvv0F6llkXfTf5pFk3g1Vn8n6rrU8gdnVI07Zj3cmP zfpY3diO5G7TjzHusMoPsOp9wGx3Moj0MrM8fU77yN574BQMnH4G6vF22rdxp0DbnsTY37jb9JmS rRYvt5r1tmOcaIQRPazny0/pBXiJ7RXRvR201QoHQCnVtUznzgZfB1uV2rNeT/WdhK0RKiFTQh8O v6FRv4HqcBZPot5n8eTf2L76dIYctCNvY/qf+I0tKIdO1JtLoYDWwfZlLqXnWYyt1Ofg34YxFMzX aGO2eiC1B9oZUCf1xzYdhgh+P13+C6yWzqfnS5jNs8mzMH0h+h10j0yGBcpdsFp+F5/zUIP2qjqV n4ptpesMQywGW4ra+kOd+jTmL0VfKgK1tD65N9A1nb6puk/y4SEa57Jxp/zfhngY4EQR4mzWZmwv Ug/S9NS5AcaTlzEm56GY7Tl9jM8JOKQgzqsTUCCr6F88DstVDm6Xp7DYfaqw+bTzAj3o/pP0VygW rwV/KnaX3ke+Xoy+tEXp2khqPUDcBHcIL+G3NkGU7WtZ6wEnaeobdL/tS7iTnpXo7Nek/KiT/o21 RnCyDqs/lFLb2aH/jHbwN8w1hR1wDt0bo/t4zO/oRFNtovt4dC8Nv3M+87/OhPPlq9C2Pgw10vNQ LVajnz4cqpUIROX7IEz9M3kmyib11+gaThR6iHcCznGjGsfnZaRXIJqs+T3RmnN/Qzxk6Y6xZj6b m5jXfoeVPwfxW8Rs8zl9Ziw279u/Nr/Pnv3WLN9OdRXdg+PoGo2FdnPdhs3Zo/S+A5/XMZ/+xzS1 d3+r5bf+Mv0319DoHKZnqn5ij78zpfvDA1JpnJ9/NUF9OeMvKT+6MzX3+5kPS/f9v7TohxZ9lcoa 9fU6087nV37uPMvP+7HWPEvR08+9dKZ1J8/l/AoVOpyT+Sn6767dsf161FMp+uPzB9aa3Elq+eWd z+Gcojejn/YPy491muuKcAM7m/MLOHmG61vjG+nbjhR1JIKe6fkpSN2wXDcA+RHjG/mRU5SdMfgF SDfhezehfckyvlGyOlLwUWCb15gwHkc8j/gH4itEC6KNJ8Y37H8wWmt8I6ztSNF2rGXxyU+drxsr bcJ6N2E9E7A+1OLyy9he1ALsTMMvAH12kJP43jTWx2+pLfxF/AXrQW9BuR7ruR7fOYb1HGP0W4oU 31N8TPEF+7afjVeqzan6re/+b8cRv7n6l/Dz42J8S/F/qt+/1HbxReNNxIf0HufSB1Zc8oF5dg+/ cXqbb2Tt/gz7iJDPMcHO0mwzvrHwLfL1U8TfqY6y8Jx1ZulzKls8ygAF1mMB6+ksB99asNLm+Ruj XfrMeFcebnxI5wE9+0NBfamf4o88w3gTZfBDeR3Sv+A7c1iMRH0vuv9M127oGduplu6Lqa+h/bqB rclEqa1XmlC2AfXPszDzdJ/PGGfpYHoOlp4p8kotMJ5PwjkYL68V7KiT3jE+o8C6llp42cJa0/cz /oT4o3VGkub/viP4ntCNAu/7Y31Yi7HJ8repHzvfBP1vLmj+qXadPCOJnjDGuoB9m4rj7WL+y+3Y ttsxBiewmvoLzEa4MB5fADeiT+lkZ26suJ+tPfwLqYkY8mW8cDM7MzqO4QCWo+dqEOxMjnlOaYyU A2OEvex8jXnml571/QjxDb77FfqcE06draHfoP4g9Yv4T5CPqFP4rRjjoufM34N0ggmBR/pbjNHn o4/6D7xvQnTD/GykVyAW4n0e0qsQ5yIesvL/C8ro30rgRbynwFhaeNykvBVXs9j6dRN8FOvAfO4V LLcUEtw3mDcUoSGGWaBlnkIfjz4bxMqVcQewjrNB49Ot+2p89j5CMeN3tq7wjfUsVWbQqTLiQajR NqBPlYZYYewWBxq7yQHoJoyn54cMBwJHMknjoScsPwpnqzEKcRddf/3RuYDUPrlFxZegQrwZyqQA XCOGoRZjgYGSC+3wJChA/UPPX08wY6Ikje1m0fPE9Cwxv8dc97bWx9m99Ab0VJdi3ItelnXmmFFu u/lfeZAJzHays/SEem/bTY+MnZ/GuZbyc+UGuEG+G33Ju+FcSxdNtda6PNSu430FWxMqhEHmGSpj kOnjG3Q+jEPdcHLtlVJ6po3KluUL0vIP8QF65sroS/cq+DPoeS327lDEMMQii4fD8bt3ddh/epyi 85mN/7f3tzrvT/3cftGvnc34tbMaP0r/h3sqnc9u/NpZjl9L/2gP5lf2y4RPjGepD031qJxJ7409 iD/xeE+Bsmzgs/dRlmJY7lruEM7ZD9A+HIcsa000HfN9qL98wlEmf8vM76F/nsvWXOna/LwOf89h FfquM6lfyu82nqd6jp1DBLZmOazDWu3Ak+u0Z8IYpmtRp1prtTfQOI3pII1BonqG6iByCDQEUD3D 1iUvw3TM1Ev0nluAs+FGvB+Nz4eZeorqIH4KvjMF846ZOovpTKrb6DxEfcXriPMx/YUF1EHcPqQI /g9mO7jP6V5N8mYT1OYkN1PbxHQnZ36XrUPivfX3Uajto+fWp2K5gb/mL1n+ZcrHfL5z+tf8Qizz ckd0fn5yD+cjetYf/YUXIWD+nRcr7rLORkvlLF5hegfHMr3D+nvCWnNOsPFaAR7UKek/igt4mEvH NhXTI59esM6WpOgUE8xOUz7uZ7qSQD2rA3WcJXcS82tofEdjh23mXoQV+6ViuYAlWwXYt3VoB5fT c/6WvX+K7rdYuJeCttva8//N/xK7fwyu4X8OtHYgog6XfmtCRl0sv3MKyvkdgHXZnAAOO4ATLbhz nwk36m7vgwBpZwL4upkINPx7CF0CEJ4DELkfIH0dQCZ6Gd0QUbQDMUR21ET8bEQrQC7yIA9HPL8G oADbXTgYoHsBQA/8Ts8bAUpwJpa+AlBeCtBbov9/dRe60IUudKELXehCF7rQhS50oQtd6EIXutCF LnShC13oQhe60IUudKELXehCF7rQhS50oQtd6EIXutCFLnShC13oQhe68P9rEPo/NsE3UAk3gQQc uKGE/s1V6Rj3HIjA7Ri/ZKCDfwgeReBDvEYRWxA86PxDLbKjTG9F6vUx2hwoKttltOFN/3KW3+PW siVP8dthCpRj9vbmCTR7e4s+uIzR8gEmLenFaLNiPpZ9ZVkDI/haCYIDl3U3CnETYjPiGYSEDdoO HyEMBM8/yG9trsnCL9yHH3IN9PH3Yfd0vL6OMBA8tv4+7Mt98LWVI2Cr7mlR7bT6e9hb6fw9+JYL r27EEsSjiNcRIszF62aEgeDxbis+2wocv5W/u9md5R6o8XfBYgTH3wEuQv/j0TZ+Q4ub8eb2Flda mT7Qzd8GoxEcNPEjoA3B4WfX4mtrgcPitc09ejEW1rZozjI3ll+FjV6FDVmFVW7BK2FpHUHLr2pJ C9DPX9vs8rD3/qu5NGHetLhDZaORCwuB8DP4SyAOWfwipN2QXoA0E+k0fjo4WDv1Fpe7bAnWV4XF q3g/FOLjgXwAypAO5iOQzopd3uw067m8uaB7Gfa4mg+xIi7eAQmkCi83l2VFn+R1xvzlLaqNtm95 s9tf9jR/HS+DD0stwVLBLNfTvIYjq7GejG9RHWVrBtr58djN8ciWLGwjQS5fwj70/5R2xrFNHXcc v7tn/JxAEidAcEnCvcTYhrgmJiM1CBS/59lUq//AEFrZpVUNXaRWk4Yl241G2yQgIS2pSKNVmjRV W8ykpaiszfPzSG0ShLusUrWpw9o0LZ00zX+wv0ZF/5j235R972wCm/JPtRe+97139/vc3bu7vJf3 D+/7FhoyOpWY0ku6Ufc9pY/shp9U9kn/QLlOTsJ/WvL28uqK8p6kfiQaRfejja01WmprH64aLcoo ak1lDgswJzufL3mPDhPDqxwgQYhhjqeQm5Kbfha5WazaLFZqFis1i0HNYvcRZQY1M4gZUi6RjDJB 5qEF5MW22m1hQisys//AcEV5SnFhYpwrmEqK0r2llnYxMpfVtVOGuUo72ofDd5Qs9nkWbepKrrTH NXxxRRmUl/J0ydUjgIyF7XpH2dNYGoDdYknuKL2YCDExfco+azc3DY5zsZE5oey3rCYmif2R/Uks N7uHc+G/a/oXTf99wzeqrNb4pWB/EF43etnf0dgr7K9kATnGVtgaCQL4CyuLUbAvWYWE4es4/y68 Av8W/LbV/zkvs3IJhrG/b7V1i4tla5Z/qJnhnmZmT08z09U9bHjYr9mnpBdN/Bm+H/4pq5IB+F24 C15lOfI5/BYbIcfhv2r6b9iq2OLsE7ZMjsJLVrsYgmmpwpYsu7CPLdI4SwzxVfYxu0n2IvQjy7sX pTdK3v28YwXtUfYLlrP6eJfRyq7TJP0nggpkXTjpYj+3QqKReWtV4xU2z+Z1V0j36AF9UQl6goHg oqJ5tIAW0hY1w8nmcANZYPj9Ze8gDRGNYfdAOjTPZixbyDT+jWsS18XINNKCzKWRZmSOIHVu1n4t c2F2lZyCGNqYhKagaegysSG9BL0JvQW9LUtyUB6awN0kAyIDIgMiI4kMiAyIDIiMJDKy9zwkiDSI NIg0iLQk0iDSINIg0pIQ402DSEsiASIBIgEiIYkEiASIBIiEJBIgEiASktBB6CB0ELokdBA6CB2E LgkdhA5Cl0QQRBBEEERQEkEQQRBBEEFJBEEEQQQloYHQQGggNEloIDQQGghNEhoIDYQmCScIJwgn CKcknCCcIJwgnJJwyvXJQ4Kog6iDqIOoS6IOog6iDqIuiTqIOog6mygqNeMzIDUgNSA1idSA1IDU gNQkUgNSA1JrXnpOTgbDtpmEpqBpSLBVsFWwVbBVyVbl9spDgjVBmCBMEKYkTBAmCBOEKQkThAnC lEQBRAFEAURBEgUQBRAFEAVJFOTGzUOC+Oab8hsvDbtMkw48a9k0PSh9ijyQPknWpb9NitLfIovS 3yRXpF8iIekTxCsd7UnPEe6gFg91GN24BZyCXoEuQgvQEnQXUmXuHvQ3aION6AO2DvWUuqAuqXfV bUtqXWUd9lP2BfuS/a5925K9bmea0cPa5H0UtxbyrkynkD6E8BBBGpa5MDuCfo/gPjuCnyPsiN75 lfZwkN4bpHcH6dIgfXeQGi3sWWqTdzqNhBgGTpP6Du8oX4dCXt8o7kxzyw/2cMv7DC/T1YYd1P3w B1ARWoSuQCFoGApAHojLskHEJ/WBZpOrkA/qhzTRBenuJoR0dTr0Cmuji6XP2kiL6Md3ANyK5QvC ypbvFOwTy3eBGy10mfjEX0X0FlbuJnzJ4vdR/VHDfmnxFdgNix+BvWz5DsHOWb4vuNFGnyfcJtCz TR/DdQs/Y/EXEHba4gdhfsvnFdGD6MiD2oM0Se7DPU1qf6Mnt8WPwwYsfkxEO4hPLDy1k4Ac3jZI uFLCgB5WaNJG9e38K/4efwD8H5hYbI8vtbINds9Tpi/orXw18DMEG9wyWkU8ng/FppvCb/FFzwx/ H21RzzL/CT/E5wJlB4qvYdwzsguLX9HK7Ka+k0/zIM8F7vMsf46f52f4yx6UW/wlviqGSVI0yW4u 8wQa/A6uwmPxZz1lOcST/Adc5z5+TFsV80uONtoNBVbFDJDhRu9PY34HPWWxx58PlWmnPqh+rc6r 59SIelx1qwPqPrVP3eXocjgd7Y4djlaHw2F32BzMQRy7xBd6/eKbr7vs8tOvdptIbTLvZCKV/2MN HlXUwchzxNypxFl8LELjZvVVEr+gmf8ac5dp6+kXzW3uCDW74iR+NmIe9cfL6sYZM+SPm2riXLJI 6VwKpSb7YZmSs8ky3RBFV3vMrm+jkly91lMhlD519VoqRVzdb4Rd4a7RzmMno1sk6Wbqf3y4nsz2 mT+OjyXND/tS5rDIbPSl4ublMe2lZIV1sLZYtMLahaWSFVuGdcTOiHJbJppC2H0Zht3cjjDiE4Yw R4RoIgz3k4gIwxo14rzAEdcvDHGtbcQr47ytbTLORkVccV2LRYuaJmM8hKzLmHUPeSIGOwZstOj1 yii3RpMiiibdmhzYQdkQ5wgJcBlC8XedbIhT2Zk59DjE0wwZ2QwZkX0p9HEMb8TsOvAoZtcBxPj/ z2M84qelw/nJtdi4O5Z2x8ahtPnOG6+5zOkLmlaczIsKzVS86Quvvib8/LiZd49HzUl3VCseXtui ek1UH3ZHi2QtdjZZXNPHo9Zh/XDMfT6aKoVPJI3/6mtms6/kiS0aOyEaS4q+wsYW1YaoDou+DNGX IfoK62HZV+x1se8TyaKDRMSnnaWX2PZW7OF0T38q0u3MjIoNXTne75rsuW0j9AbZ7k+ZO9wRsw0S VQEjYIgq/J6JqnYUdzSrXJPH+3tu0xvNKieKO92RzY+tExEUN0dOx83+sReTYquY+vmt1ywrDlnt IrHXo/iH85wUfp6MJNktj9xWRz6fz4ok788SEjcHx+LmM6cxElVFV+loCmWHHpUpiiwrtrTEyhtV VPoxCJoT3Ymcn/oxg3or3rpUVrAXVCZeFXKlvX3DF+/gCT4F4T2OTVhD8vWZTZQGPOL9JVcaGmk4 XleFW3v7h8X3wENAhXsarncGkJn3zAfmQwVPIVAI2VG6vIhCvigepdbQokJy/uyjiUA2l8Jki292 o7/rVm+f7LggMn5/yp+Vn+km/zvV/uanwDHpmxObbbaalc3nHi1IozzbbAQr0eg9/wjLNyFZmZdQ o5HG2Wby+MAZIf8BPr0QGgplbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjw8L0ZvbnRCQm94Wy02 MjcgLTM3NiAyMDAwIDEwMTBdL0NhcEhlaWdodCA3MTUvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 RmlsZTIgMzEgMCBSL1N0ZW1WIDgwL0Rlc2NlbnQgLTIxMC9GbGFncyAyNjIxNzYvRm9udE5hbWUv WFhYUVBNK0FyaWFsLUJvbGQvQXNjZW50IDcyOC9JdGFsaWNBbmdsZSAwPj4KZW5kb2JqCjMzIDAg b2JqCjw8L0Jhc2VGb250L1hYWFFQTStBcmlhbC1Cb2xkL0NJRFN5c3RlbUluZm88PC9PcmRlcmlu ZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpL1N1cHBsZW1lbnQgMD4+L1cgWzNbMjc3XTE2WzMz M10yMVs1NTZdMzZbNzIyIDcyMiA3MjJdNDBbNjY2IDYxMF00NFsyNzddNDdbNjEwIDgzMyA3MjIg Nzc3IDY2Nl01M1s3MjIgNjY2IDYxMCA3MjJdNThbOTQzXTY4WzU1NiA2MTAgNTU2IDYxMCA1NTYg MzMzIDYxMCA2MTAgMjc3XTc4WzU1NiAyNzcgODg5IDYxMCA2MTAgNjEwIDYxMCAzODkgNTU2IDMz MyA2MTAgNTU2IDc3NyA1NTYgNTU2XV0vVHlwZS9Gb250L1N1YnR5cGUvQ0lERm9udFR5cGUyL0Zv bnREZXNjcmlwdG9yIDMyIDAgUi9EVyAxMDAwL0NJRFRvR0lETWFwL0lkZW50aXR5Pj4KZW5kb2Jq CjM0IDAgb2JqCjw8L0xlbmd0aCA0NTUvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJxdlMuK 20AQRff6il4mZKFHV3WPwdQmw4AXeRA7IVtZahlBLAlZXvjvI9V1aiACH9Bttav6iFL++fB6GPrF 5d/nsTmmxXX90M7pNt7nJrlzuvRDVlau7ZvleadsrvWU5evm4+O2pOth6MZsv3f5j3XxtswP9+F0 +v2p+Jjl3+Y2zf1wWROqfv5ak+N9mv6kaxoWV2Qirk3d+ldf6ulrfU0u143v4ekxJVfpfYkOmrFN t6lu0lwPl5Tti/WS/dt6SZaG9r9l8th17t4f92KsCtmishBj1SJiMfpKo4rESCUiXQfp+VQQI3lE L2IkRrQTIwVEjRhph6gTIzUaeW0SJLTqSzFSQlSJkTpEemCQcWyP0ykZ3XvtG2R076MYmRDpUUDG gXwtRo4aEUwpA3wRizGgIgUxBlQkrQUGVCTIUwZUpJ0YAxSSlgfDs4mzGMMLokaMAaJXbcZwRtSJ McA9F2IMcM9qHQxwz5UYA9yzF2OEeyYxRshhFmOEHMaLUEbI4SjGCDmMF6GMkMOqBYyQw3g3ygg5 rFrACDmsWsC405H6NzvbdG2Db8Pa3Od5nWP9Oui0bnPaD8k+INM4bbvc+sv+AlY2ErIKZW5kc3Ry ZWFtCmVuZG9iagoyIDAgb2JqCjw8L0Rlc2NlbmRhbnRGb250c1szMyAwIFJdL0Jhc2VGb250L1hY WFFQTStBcmlhbC1Cb2xkL1R5cGUvRm9udC9FbmNvZGluZy9JZGVudGl0eS1IL1N1YnR5cGUvVHlw ZTAvVG9Vbmljb2RlIDM0IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9MZW5ndGgxIDU2Njg0L0xl bmd0aCAyNTgyMy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQp4nKS9CXwURdo4XFV9XzPdc1+Z zGQyk5AJBkg4AtG0conIfZgg0SA3iBBABEUNHoCIiu56oK7gjScBAgbUV2RZXQ8Wdr1Wd1V2xXNl 5e+yrAKZ+Z6qmYlB3//32+/3Taerq6uvqud+nnq6gzBCSEGtiEPm9GVLYw9HPvgHtDyIkDhx1qLZ C95e0Xg/1I/BesXsy1fMGrLbMxghoxmhKaVzZk6b8dG/Uy8iNPsmuKbfHGhwVXszsP8S7JfOWbB0 +YlLsqdg/zBCNe9evnD6NP72HxbD7dth/88Lpi1f5LpQ+BShP66H82OLFs9clHx/1Cuw/yxC2v8I e1AQ1pDwJAryKRRAKPslrF/RbWZu9it6nG7JN3B1R35FaAt6Ds9Fz6FX0D58DK7ainajdvR75EdD YFwr0a/RGiSiKdByCxoPiwDtv8bBbDuqQg8DHB5GB+Dci9B1aA/y4UD2a3Q9upl7B666GRmoBJ2L xqKF6DZ8YfZKNBV9yt+I+qML0RVoEW7NNmRvz96VfQw9jnZzv892Ig2F0HRYDmT/Kfw5+1fUE664 G21En+K7lJ3Ihqe0wpm/QYvR/VwTj7OzsyehB3F0FfSBR6PQAbyXpOHuM9GXOIBXcoPhLo9m27L7 4awIakJz0P1oD+6Lh5O4MDU7KnsA+eAZy+GuG9F2tAuWDvQy+gjrwrHsY9ljKIgq0QgYTzv6A97L ZTpXZeoBYgJAqQeqhSML0f+g19EhnMCvkoWCLvQRbOHq7LvIg3qjSdDbJ+HKL/B/yHWwXM+9xg/L noccAJc7KbTR79DfcAhX4TF4MulBFpKHuMVIhif2hmUGmgvwvg/u/glO411EJwe5R/ln+FNiUeZw 1gEYSaEH0G/Qq9iAkcbwEnwDfh9/RgaTS8kD5O/cr/mn+D9J02DUl6AF6Db0DPoPduEBeBy+GM/B K/EafCfeiA/gQ/grci6ZSOaT77g5XAv3Mn8eLBP4JfyNwmrhVvGrTENmf+aPmf9k+2RXo3FAD6ug 93ejh2Bku9FB9CEsn6K/YwFr2AFLDMfxJHwNLNfh2/AjeAt+CrfDUw7hv+Ov8ff43/gUQbCIJEzi pASWBFlMriK/Jg+Sg7AcIt+SHzk/V8Klub5cHdfILYRereE2wLKT+xsf4g/yWYBzH+EeYZOwRXhG 2CccE3XpBhnJb59+tLOi85MMyqzN3JPZnmnP/g15AYchgEIxqoPeT4NlHuD7HqC4regdrAPsQrgC n4MvBMhciufhFrwcIHkTvh8/zvr+PH4JoPQB/g76bJAI6/NZpC85j4yB5RIyk7SQDeQu0k7eJyc5 idM4J+flKrjhXBM3k1vKreDu4dq4t7mPub9zJ7jTsGR5lS/mS/gUn+aH85fyV/IP8V/yXwpThbeE z0VVXCCuFjvE/yP1k86RxkrjpCbpDmmX9K7cDNT5W7QTvYC6/fBhbhU3lNuJbifVfJD8gfwB6PlS NIMbRYBSyRa8llyL20mpsFwcRAbh0egYnwJYv0Y2kRNkEDcKj8QT0DzSO3c30cM/DZs6/rfoKP8S jO0PcOfloo6vI9+JOtqOEamFZ/6O68WnubfQR9ynWOIfRn/hVezHR8mT3Figgpf5c4QGFOceRM9z LfhatJMMRUg9Ja8HOh6Nnwa5MBH3wT9wWcSR0UBF/bnP0I1oPvkzOgp8vBbdi2fws9HtqBqvRF+i J4AreghXiBWiF79B5vLriBu3I8I/BaOrxaWYEzzoJtzE3S9+Rz5EV6KDvIo+4Z6F3h8kz3Oj+GPC eDwHOOBatBq1ZFehFUID/yc8G3F4Mkryh0G6reT68HHYXg9SZSrItF3A3XtADpzLjYKWAFDOhUAX k0BC3A/LfSAneKCgucDjF4EU+wNqFyeSDjRbcGCQOgjxb2XGoynZJ9DG7Gx0RfYu1BPkwZrsSrjj FvQ5ugNtwTdnrkGLUBQ45xN8oTCMHBSGZXuSdeRDMoHccyZ+AdpJHEDfwPI87JwjvIjW8R+gCag+ uz77HlB3OUjYjegydAE6AqP8JzzhfG4vqs6MJtuyw7hFMN5P0bjsk9lirKI52cvRGPQSelwS0DQp DThuw3+C8V6DZpLx2aXczMxcgMMdAAUboHUlyJ9b7MGTJp5r159zdt2ggbUD+vetqe7Tu1fVWT0r 0xU9ystSydJESTxWHC2KhEPBgN/n9bhdlul0GLqmKrIkCjxHMKocmhjWHGtLNbfxqcT55/ek+4lp 0DCtW0NzWwyahp15TlusmZ0WO/NMG86c9bMz7dyZdteZ2IzVobqelbGhiVjbgSGJWAeeMq4B6rcN STTG2o6y+ihW38DqBtTjcbggNjQwZ0isDTfHhrYNWzZn3dDmIXC7bZo6ODF4ptqzEm1TNahqUGvz JxZtw/5zMKsQ/9CB2wiSDehUWygxZGhbMDGE9qCNSw6dNqNt7LiGoUPC8Xhjz8o2PHh64rI2lDiv zZlmp6DB7DFt4uA2iT0mNpeOBt0a21a5d936DhNd1pzWZyRmTJva0MZNa6TPsNLw3CFt/quPBH7a hZu7Bjes6X40zK0bGpgbo7vr1q2JtW0e19D9aJyWjY1wD7iWJIc1rxsGj14PQBw5IQZPIzc3NrTh m+GRMToSOqrc+GYmhtKW5nmxNiVxXmLOunnNgJrQujY0fkV8eyhk784eRqGhsXUTGxLxtvpwonHa kMg2D1o3fsWOoB0LnnmkZ+U208oBdpvDma/oRvfKzK5jrMZOp7WR47sgi2mPEiOAINpi02PQk4YE jGkALWYOQOumD4DT4NeI4aq2GYCRuW3K4OZ15kDaTq9vE5JmIrbu3wgoIHH02zNbpuVbxKT5b0Sr lE66SA2OF+pt6XRbRQUlEWkw4BT6eA7b79uzclkHSSQWmTHYAPjQWIDttMaBVQD+eJwi+NYOG10G O22t4xpy+zF0WXg7sqvSjW2kmR7ZWzjinUSPtBaOdF3enABKbkfUXPW2yamuP6fpcw+dM7AN+/5f Ds/MHR85ITFy3JSG2NB1zXnYjpx4xl7u+ICuY/lam3twAxcm+RoJc+woEOXUrpPpToPexifhT2RE PaNDkoEqWQuODWszm8/PlY1qPP5fXtSRPUavYpufLst3s21g+sz9QWfsn9E9fR0HHQZVOXLilHXr 1DOOAanlHjgivwGKRxMb4rHBbWgScGYS/jqyewfQtTHcZgPIBtMTgP5yTfndM04M5+uN8KPU2bNy GAi6deuGJWLD1jWvm9aRbb0sETMT63aTfWTfukVDmwuE05Hdc2u4bdj6RoDVHDwQmIKg87Yl8Npx 22y8dsKUht0m+AprJzZsJ5gMbj6vcVspHGvYHUPIZq2EttJGuhOjO2gkhkFuJzI7P7zbRqiVHeVZ A9uf3oERa5MLbRhN7yC5NrPQRqCNz7XZrI3+qIwZPLGhO/UwlmzsCdRIMDOwBQQWu4RQ3IpbSSgw KN3TMW7vaVtAp1CM3wuKEa3MjCPNwjvIRGfbapkTI9MlyabZgat3oE0OGba2JW1yXII4k4txHPes 9Zv1gbR5oqnzxFHzxFFUX1df17sXbsIpYtX079e/WpRg8ZoYf3r3H0ZNeWnVirKzE2mczox7Cf+A Hf/8qPPUocZ197z4cqY4Ezvj+TNtvZyUm0RRTYxcCu2BuonDsG1Hm7hLHECR7aZJJkHlh3ank1WO tBsGq3xrO1WVTHI6ih3E8awr38c0/H7WT3cCWTVlKViqfaBrTdK5CqfTJWeXXb3qpSmjDmbG4cP4 by/tvmfdlD+d6vzon5nvMzL08unMJ/hG8I9UNHqnCkB9RuzAY+0U5uoIwSquQyrhYAeJA6SBY8B2 XAiW0GZAwGbt4fugJ8ebjh8xj9aZdaieluZRs/Motly1vXtV9632ekSprF+//rsOjL2oT20/7sCB lltTo4LTLobnnos7yDyyAPBYaQcXkUUcGYVHwSMTiISERXBCkF90WyA92jzSZH6BqkYd7d0LtcAg +8a955IeuGPnTorjPVCsgd5zKGkHCO1sXa6LWxG/GY5v5lkvTzQ1AZyO5jq158CBA/Ra8HtJLeCH QxN2Iy77yXZPLenIfmLHPLX3cphwm7itHOGWIeyBs4HwOKRyXyHyFeDtKXg4v+NquHOdefyomcPB GuGsdNO15n6Ki3Tai6sxfmpDpiEofHuS3gH8IEROCXsB0lvtGGcbVs18/npyB9ko88/yWEGiQDhF wDrBb6oIuN1W44maXghTWurIHmYUApVvbIuSCIroOpQOSiXQeswOOp3iJGTqOi0NA8qQLtiGs0ag 93LQewk4Bh4oEYLaHlyHb0Y58LakAUDp3A926kZ1AjLr/bXYqqVDQU3peMISRakvYLKanGo/952J 9/69ail/zTkri58f/ualdGx1AA8JxhbFr28TKfvaimUaAbdbnGR0ZI+3Wxar/NNWTBNqUY8Q7ch+ ZfvpCdEoPRqNOOBIVKc9j3aQF22dqH5/rNi0CIkVA0VVvXuAlgdQ1VHa03pa7gdzM7yNdD1Qd7kI e6CtOC1SeM5hW3O5yaSoh7bRe2+HW8Pj2zWNTPJTDmNQ/N+elk7nnkefxh5m9xskDBJfFF4RX5Re l9+ISCP0Rn2iY74+w3G162r3La6XXJ+HPg8fC+mvaC+4SdiMmEVm1BT/J3sMSWDtyLBVAFuhqGrK ovhmJOSJREJyJAQUJ4cinBE1O8hjO8ZY2OrAgZ10BIiBw4mJri7xvwPQtgGX+EWyCsWQiQfYurWz Htz6heR6kMB7SCkqxndsu5VRPdDmiTQlUSDQzrr6o51NRywXxSwUaxxnpR1ArjluRQPgh2mBmnDT 4sbGpDee6g8Y79evb00qUcIYuboPmPBACfDHS6f7E3/y0fu/27LxmhsexLvdP/zxnRPnP7nvkanR 5547t2763uv2fz5r/q8eXOc++OE3zzU8/dJja6f1BkqZnP2C9wGlpHFjHnFaMGBT+AciCFNSTeuw g3skVMOpO6Oq2sMbjfDRHhGhh5Ew9EAQRGjMpMQfk1IUi/T0VFX6AP2jC3LV1teDIDoK+Dv6mvma q9bcn+5DV4q/csHwGUON1QY/1LrIWhbmxvsuN+d5ZviuNFZ4VhvrPLeEHzdUIcYxutF0w8FLGJ6L KVqoGnsR0/COgfu267qXD+whj6EgmWOXQS8F6KbhWnJpbGGMxAKUkmOt0pIUxVevFEYpM0Wgx8df oEdSG3oGOvCA7cF38B48AITRXluD82KIqsUNlR34rjwO00cZFoEzjx5PMzEGeDxCiRNkLcVnDp3A qoBA4Fbc0uju7/NV98khTurfVS3gkCJRoiVKlKQmtxffPf/6rY9cW32hx6Ut6Vg9b+56T3v8m+eX vzl/1owbNmS+ev/VLL4xsHFN2w0rH/Y8RJZfO/2Gm26K7Xx99vYZlz54VvTl2/dm/v0FdHo3kOZq PsU08wA7xgtIlBQi1vFcHRZ5kMxVqB4RKs0elvO6owWGUw+YojRYC3+9e7lBQHOw7gYhzTUeOHD6 SRDWBE0B+aKDrI6CP3uTXbU+dGuYrAytDJPLQjPDZL4+zUGmABuSfo4hDhIOyhKPzDLLQkYPD46i DrLVTsRL4nXFanFdSUmsLh6PokuiV6iX+OeVmpfEgNnmJS6awsBNVSoAvI4qtU6m1E4A4wC0j1gM yE3wQ01gFPSlNsE5pDtkeQpYB5HoAPCfcdTXu/TFAY9dteT+wO7gf976AKMpNzb0C5GOA3huqWve qIGD0o9fNnDupg0bfQc++uaJ5keWjr6g+fLMvXTE2U6wcxqFPQBLB569CzucIP1BPX3fnq/80E6p iFBZ10hlvqLTUmBlldnLnC3PUZrNtdwG8w3hNXGveczUZKERTyZjzTlam/kv/V/GvxwKr/MG7+DA HRd4HmhdFiVJh7os6hJoSHiM7WR6JibpHjhEOI62eWkbF+N1D1ylRAVBjoqc2EEW2QqS9a9tsCXJ HqwhjDXbpcfQTIkbP5Y/yH/Kcxt4zHdgbGtj9b3Spzq3Qcc63Ted0kGJXC+1SkT6lfP9D3L0EYQV /gJAI6GgefQoCtTXhY7WH2HoOUo1bhpE2JqzAmzLyMiqrV1j7t/v2L9/jZDbAtZGtmkTRrZFwaBs 552cLO0BMYyyP1B514gXtzTltF8CdHaCi3PuOJcqEyWOVP+RNHz8TOcDD3+I/8/GYSWRamHPyWH4 pcwQMgXfs/uq226ldug9QJtfA6YsVIQqsHs34gEnwzVNnMTzwxKTE7MSS5SbFHFu6EphkbJEu1G4 URPLfAoXKKuI+ooUxe2KVlT06IEiRVGAWzGoQyQHUqJO9b3Ykf3Crqb6XnRRGSmKFPKiTO8uMlyL HkoH4sRkSo/QK3SVnqdTuvDSs/RQZVE0xoyIWN6COMFsTFbJWw8n2xmScxUxZ0+ozIZoSg+aGuiy D5pAi4xmO6NAGOV+ed0CKzAJ8ExdbZVVS6VSTihR+6HaineTOg6SwPE+OcWSSoD13ifHRlC/h6S2 vLVk1uyb77io9dX1mV/hs1cNuGDksBseyvwFL7gkNXjKwIl3r888J+xp3D3zkieqy15qnb2tuTc3 3vLNGjViYY9TmyV9wPxh41f0pjbJrOyXwjKQGUXonZ3TybwignM6n43vK/tSWouhPsZ0tAgtLWpF NxVtQPcLz3CPG7u5duN14xA6UvSvIsvhKrKKirgKsdyqiMSKhxuTPRd5JwfnCPOLrnHd6rqf2+i4 P7IFP0a2WO853MiDQqbHDPHUlNxeXss0Ws/yWtOJMB92R3UuHOUVM+W8AKViGONQsT8Vk7Gs097I wej0qdQoA0E/6igAGsrjOYmfEz6AgaYWAGgaL8Z+kU+UlALgXKUgefxSisoh4vW4qLzn2/ednfnt 50czHzywFQ/e91dcOeiV6n2/euqzqQu+WP3o3wnp/d2pV/EVf/ocT9p2+K2em+96JPPdnS9mvl73 Ehip6CGQPVOAop0Au8/tqlgxHiznqNMyo04kQ5cVXMyUtsKISlEpRSkB1sJIj4mkUHGR+V+T3n8K pPdDgfSiPye9fL3pJ5Lr3WvwCrsfF5ZkURZkXubFYCAUIKKmAh+onOj1eXxuHyeGOX8cuxxQBORI HPtUK44Aiul0BfxW4SZKoX7wmlxeDwH6TMb75C2fMqDKh/CPz0y5rnHpktFX33ng5sw2XHvn472H jrr38tHPZd4W9niLLrwsc3D/k5nMU9P6PNev99Cvn/jiPxVRGPUjIBnovJqG7ra9ohCVZUlCHE8B qSpRDckSpY4i01UjTeQuiKkxg6ghg1f+f7CrPujiHAHlgTaKMWzTqONH0j/nU/CGrLg3nl8f4UtP P8SlT7/H3STseS5T/2zGeI5y0RYYw80wBgXdZqfZGO6QcNcwYAgPgq2jERLS/ot+2xrruJ5nwswv uq8Omtqt+936fwQMhVzXm37e9y3cx6c/J22dY2m/Bz7XOQv6sAB4fzfwfhK77VDYE/aS5jJ8iezG Lq60FMVdfpJEUcKYM0b7gLHojzq4eFRUME6VJUtjHAfjKmsmHKG+OB0J0750JFD5iGGAad8wvZ4s bi3DZUWpmIpV5oKpwdT0i7tYeZTZdCI/Hug8td0YU1MHo47t56y4WmqJA0EP4RPhSCgSjHCinjKT 3lRxSk7yqUQyYBTFkc/pjsPJHndMgr0SIRnHEQ0o22NBEVXicVTKQYHoA4HCwZSpSxd+lNbBROyb tM6QHj6/dBYB8UHjGx4XDwKkv8VdSBbckTm0+c+ZTe078Ni/bML4rtTW+GW7Ft6876r4gDWY3Hnd sXNI/bO48/DiJbvxJX9+Hy9pn93x616LWkeNu2nM2k37Mz+0TuuPLcDHYyBRShgn/Hk3MgDqIbe3 hueiirpZPaQSVSBEk4GDY5IEKu+fDN5Q+d7WmNZj5r5ILfIA03yYab6mVgMbRIvlPWRwmOGm/wX5 yXny6yZxfHnuiRk4Zow1mo1FBj+oMQBWd5drnJNAOTymKQ0yp7+2qYqJIQxKDkgS1gSUj+0jJ/ft 6xSFPZ1PkCknh5EdnaOgj68AQ60CKHDo7Z2Udwh1zXcMOJu56Duqa3Lbnr1y2/IeuW0imdsWRXPb QCjn0lcYZk1M2CBsFYBWwVi7A21GbYivAg9iLPoUHUOCKwaNGxDHTmeQRIE8dL4tQOefBeicsM2c pceg8wj/fmM34Tt4asP2VjDnmhpbFtd1NhVAQgMFlBWrrVf2UdMIxtg/+yU3jVlDT9nmTDJbXEqu FNcaay1RYfzWrlF268AhW+OjTkVJqaqc0jqy37D4BqvQDmk56cAqOaVNW2wfxZjWFHPjmNt2j3U3 u3k3TiHmBuZE4jcFpP41L1NGunYVRnLUbGrJjYhaj8CCR9PQfdSU95f69YWBgH8LXtGgrdKi6SPm le9rfPWGVw/gzYEtKwcvuY77/nSw4815n1C5SK2+ChingBbYOiZAywKSY9S4JU/aTolw/7UQP/EL xSf+QvF90ZST3jlgx7337CN/AoD/6zl4xH0IiU7oiUmO5Dzq3UgGbDJalx2GxeQUoBkqAg3BlNOa 7qKHBafOKQgTWdEcSFaIqokMC2YeBSd3MRSY0LkvCvGnHwojOZ0bSRX08QArgBj27jUPHdpL/dF0 mtkraRTOB4SKJUZZIis5VvKsFFgpU25P0Bph6gFEH5Wrjp98G5WVUsH1kSnAipkrLWA9prpqnKwQ dA5hByhXGbQsHTi9G6uwm7xIJiMXwGqybeT1kFgAP7stwnQsx6tABTEGr8sNpik3GvZjkjUdtq9H xCl7SFjml+mr9d8DKPUR+ggn14NPGpWOBu5ifpmx3LHGkDUiyLVGP8cYMpIbItnyKOM8h3of2cjd I90jb+GelEQXcTocvQTiEQQi64bRS5ChKuvjneOxDc6ULCuqBhzscJgUT82uVhdx7SFbkIF7bxdi cgfubau6osZs/XoNa3tgkA6swRHSAS6Y4gRCdC4ysdlBJr8QE5qFVgGEAtmyw6JCLkijuE11AaAz 5mVBPdS1c6QJfC4Ag9ltCYEnRn2vNdcy1ws2wEU/uVgvIz17CmjwfXBj32ce1sg2HY6VwzEq/X/Y 5lBpKwgVuvvurnitozJea3RAtX+to09/Vt3ZE1p71uZA3gg+GmppAvnTCOSPff5+/XEcRC1OYOs+ XIov7uUL9sWXYuHFzOStmQZhz6nv7zx/7APc6ZPD+LdO9eUPn6LM+CBooWJqy+Brt7m0gsaQA7oP vFnqE8RpTQYnNybJ4O7K4MpzssITokgyz8VEUShITqFLOQk5TgJ1YocYOTfFNBzTxmrN2iKtVRM0 Gewipp4MeNh/ZyDxv9RQXQZSN7GcbkozndRy/AydBE4wpl4wzzCUYz8a4T78gm7VyDEogIIbe/ei 5gHgoF22h9XC8PfuGlYr231y1T61UkmQxcN3BaHaJ1elrYlclFxL1EoOD6xuun98lxuqRblqEVS9 tPrDNm8ef2ncjXUAhdWYakpsPfg6R/a8fjoDCFvFXw/Iaj3VSj2Q6WC/fSy8ixwojN60x4ac2GN6 PGF/OMzzJu/R/FqYf8q/y/Gag/P7A2ESK7KtMe4xfjvUIDQoF5mTrEvdU/yXBiaHLgrf6t9IzGCU 41xRTfGmYmC+Un1BkSAV9J9Ep2Ao6CWqQSj0JRq2pjCXKFriTPSEWotwkTNFcSh2Ex3BSMFry7lt TQXJPSrnu1EvGLw2cN3cJor34amTwayv/iaq7oOsGgKuG5qO1+J+b+Fhz7Rndr1yMLNny+9x0Qd/ weEVX9/5h8wH5E28AP9mX+bxv36a2bzz93jK/2T+kzmIa3B4B9Z+lfk857XxnUDdBgqg7XblTGu+ h4w0R3ouNi/28JoeBQmD/IGc1e5KySxOIJt52Zu3Y+VQLIThLxQw/r8a87/0RYLd1Vg+dtDSlIse dJnzOesJjFLmgkXBgSXxuAX1Lu+L9Lhr1OV3Nf4z80ZmLb7mpYeaLux9U+YWYY/DNXPXghcznZ3P cnj99VNv9BqUch4GHn8OoBBAJfi0HXdpDuzqF5lSPEteUAyON9McrJRYWUpNEjoONk1BK3qhohUq ro7s33e4QjWwPbajpKzGovtFZTVmfuvMb+H4n3cUpXLH4Xwzv6XH7RFQSTouiFwQm6BNjSyILFaW O1Y4b1bXOu81nnJ2OL9yfOk0QdvFLKfHspyWU1dcYRIP+VTRRWc2hICi+PyhYNRPRUmQAt3vR/ES hs9AwOl0yNGU40GRknbees6hipnNJcyAFlmoqClWuqi0tZQrLQn8tzgW/6/yKDFoyy8ctjwDBI8E qKNOFUYe12k4VldbxWYgchMQQtd8WbcfyluctirbzlqnOdByDaRiA7cwjeEA6RMK1logn1ywOuxI rVnigbUY1i6B09gt6ASevTvBnUWAnBKMtFg8PP4wWbf/7avffGdU+aQLs8f3Tbriop7xkX/DD998 z+h7H830EvaM+f2KB98vSpaOvjLTgnvftH6AJnVeyVX3XzF8zmpqA07Nfsn/A7zMXsRrl03npvNL uKU8nyzry9VGBnMjpAuLhhYPKR1WNoFrlKYWXVR+i9uRoE4khXdpoZIsVFKFSlmhkmCoyJ2cqyQL lVShUkYt92G0Vm6kSkkpV5bs56xJDEkOrZoSm5yYlLxcm2fMd8zyzAys0K42rnZea15ZuiS5mlun 3WKsc95m3lx6Y/Iu4x7nPd5o3lLrGU+5wqmQkuoBpjXqEXLxfXqn0ExgLqPnivAtYRJO+oye0bIk Tgo+gcqOXOw52lOJRn0ck3lp8Gabco4t3TSxOYqqo7klbPdMljoMTYhHiqJhWRJ5jog4WVoCbaIQ DfcM2ZTs7gA5dNSHejI3nWlZE8fwWNyMF+ENWAQnos1296SPpI+GHl+gpFAP3IOKcIeDTOpBu2bQ 63qE+sCYcMpF1Tc95CoQuasrxO2aSHkh2DvvtjeNOsI8hqMs3vlTIM4E7+cILY7TEQEZ05gzjXU2 Uk+i5ScqBpnv7h8l1X3ycaTSslSqb01uAiYfrfN6/D7ez4gUnI7S1NQXjEt/f+3CpyeMnTooc/m4 ubOv+/7Xj/64WtjjfO6ptodrB+APG1qvXn3qN69n/rURf2BecdtF5y0ZMnR2wj8t3f/RmQtfnTH3 7VWOW29fdfGY6ur55YN2Lrvy4JKlX1NK7QW6YQ+bTbjFNgQSBYAjloCndJAlO2K5mPwLYgyTKg5z UN+J8171V7bGxIOclw3fF9yWvxeExOmCUMjkDGh6R3nXxu4eDIATrJMjTV+YLFMgF7mLW/G+NH5D 3Jkifl0mLBjPPXfyX7S3D4P2p9ECD/rQVlPOBr5BfkPmfZQMfGBD1fCD5GH8BfIy5xPCV05JR8Tq IC+2i4onRQr2Gemyz4iZD9UctiPMvWiK+XDMN9ZHmn2LfK0+zmewsE3BHFSZOFQL4lAtUIraJQ5V Pu9S5MSh2iUO1SYvNc9+EofpJhr6yTudOWuAabs0asLgauasAOZ1MgfU4pv3zcicevcPmZOL9g1/ 7tr3dwl7Tm/7OHP60dux8TU35vT2V3Zeto/lI6AgQtIyqufwX+xUD5SyerhSgVrUz6p19QuMQMOt Ea7hgQZ0kdXguihg3iff5yR59q42cSiY9tYINfoQYYg+0jtRmKhf7J0hzNDne5cKS/VrvE7BS70o lwxoJzLVMPX0Rym+iU2yhO0ox4OvIkqyLKgAFcVwOJ26x+1yeX3+QMDbka3bIaBAjG51l0W39hQv mMJIIATsYQ/GKCDIctQb8Hi9AZeuKFGvC6ouS3c6Y6blMU3LpehywCs4LRNwDF0SuIDpdCqKLBPo U8Dlsiwkh/z+kHmugsehGNKh9MJqIwGP2xWjAfZgsAPfui2npJpCwVGd4Np0hoKdgdFDZw75oks/ FVwbqpvoJFJhBTN6VHdH58wNYHWNw9y/H4q6/YVa9wI8Hyd4PhZ4PttdagBoKecOJaGxgrlDiKZ1 5Z0nB7Ts0G3BhpNAnODFTXFc7WbOTrXbBRt3NTg8dGoK44cy17z+aWlogIr93/xpTCLS84vfZq54 MfNWmeT3ZN4Auqm/9+5/lHKfdIYy3/7r1nbueTCum9bHZg4/9Sg1X8FKGgbUo+N5u2RlIMcPUjqy X+5w+WvAFvzSdkCFD0LB0UKhdk0gTg/92R4EFb4cCleK7yFXqFUOfg6eI87RPhF5gec4UZYUUVRE TlF1OjMQUzWPqmoiJyocVVU+2srFCPYADkVdEzGIIqx1kKCtqKrCERBMjg4SsBVdGW+rrSo48Xin bWiaHkPc+DHkDkIIbVGAgjwFy8XWmHjS8yLp73khRQK7DMe+eDOgP30i5yMdbwIRntt8QSUReLbH mY8PaF9zVjotg0UisAlFWltDpxFNKEa2+QFBETqBKOuKzu/JHgeP6jjLmGCSHzOLRVHAIpFh5cFH 2hakxkhjl0aIW7g657qC+0MGdb71LY6PHXreJTjy984XyAJuVGbYypVLNuCtp3d0/gp4PPu3zFwQ jP9AHAKFiOtpZhQK8oPPZXk7hawoDoRoMf9UZu4NN1D794LsV3yEPweVo/6kp12pGEpF0AhV9DAq KmqNft7+4YEVIyqajKaKecbciuZe64zVPe73PRB6yvCWFyJtZVTqMwvzieDT5buCL5bvDx4s/5P3 43J5iA9HqVa1qOBzuX6acu5L5eskWiv2FwfSlRU1tXxt5Qj+/MrJcmN6ljw3vUxfo7+h/2j8mLb6 1zgwb1aV1vj7xD2BS3ss7EF6RKoc9Y47HJscWYewybHV8Z2Dc+j5XLhvCtlxx20vzR9ysCwhh0gz nhyOCOfvIE/vCtztiUQkRE8KMYU0tEztE+G0HtPMaUhkhJGMl1L9kDe/vs3ph1Ke0kopjfLTfKBS avXTsZfSEKJGH1fKHlRa0HSlHeRi21Fm03yOWKpXamtKqKVeBLUrwCx7fxer9K5lLn80UdOrdm8t 2VyLa/20b+fSO/qTgZKq0lfEgyIpFutFIjqYyc7IVwwwW12nnRGZcyU6mN3O5hXE3gO6JWuBUZIG 95/SdlPXhGy6rjP9+edU1xxJF1JFCue35EyyQsoIYoY3pvPfqCXJIp/UROnPlr41ZbnUhnMIs1l8 Xq/H50+kOJrjAFU6S9CvL1c3Y/e8rS8NX3J+3/kfzcbVQ9dev6KoLXDFoVvWPj3WVPwlL0X8l+1f OLXPgrlzHkkV3Thp2DM3j1412uMwQqVJ9YqeZze2BFpuHWlPu+Cs5cdO3Xz2APxxecQsH1V1fvPF Y86+Cih6NVA0jdqYqAi32g9gQXeWCn2FoYJQX9xWTIqLSyLVkfMii4o3FIsD3XW+utCFvgtDTXKT 0eBs8l0SmidfbsxxXuG7IrS3+EP9I/9Hwb+7v/V/G/ys6HBxtjgYE6qcVZ5eQr3TFi50jhVmCR8V /Zs/aeqm18GLBIUjIG5Vb8ShBUoPadjUbK1Za9X43PynxmhUC+QDpicKnuOxQsz6eDslHo0m8LHY NaWBKopPbSm2qhGfi/cww6maSxKyF4Ntuxm34WOYL8b1eAzmMDWtKNFC5bRdRMkLM1LBzLTBLkoq mJEKpmFMSmHsVB99NA6wCS6WJoCD0eH9zzBQKFUsprNS0AJm7U+NzFiBPzaXnxNwLYtRSzwB1grY sOComyhRUsaBCduVX4R7Ptm+eNtlW1vszPcvvzSf1Ey6c9mzj1+57FlhT+e/7xhzx5tLMt9l3v8N vueVSbceeOvQawdAE43NfsUdBXkVwlPy+WA1juud2KlhOo2xCGQf74poUiDCa9jhlWQ6eomNXtJZ wMako5cYhR9497Wcjb6/qQ9dab7XcEXHxZHB7sH+Ce4J/mZ3s/8B8gB3v/GY+VhIl42gOo/M5eYJ V+qLjFbjCX2nskvdqes+fbX+GeEcJZc6Fzqvd3JODCLGXtGLza00Q7c2oM3oMDqGFOR0auinPkag 66UOmcmnkjCMr1RLF4OmwjTlhSLIZtg5n+EkxHAyIuItPSjhYqleIpKDxZ5UepLExKvUO1yzP29L A1ZyzN+0OJ8evRu0BNgPRxcfTx9dXJhTtGqrzKYj8Mc8EsBbI/ZT3kZWjYu6H13eB8UcV7et6Lvn P8r8Z/HXtzz31+KtweunrH36sZvm3Y5v9r9wEBdh9VlMVm19ODz/8t++8/4+pmOGAc4+zWW84En2 YyrhjaRRYwwxhL6evpGLyER1vGdCZDaZIcxUpnuaI3uL3xXec38c/Nz9uec7/z+CnzPO8xUXp0OU XUeGKO9KZ5FS4yzfQNLXGEmGGsM8IyIXqZON2cbn4pe+k/i4w8RezqGZTuBITbIQsCSnBaoxSlrO pGkesrBp2Vaz1WoBa1KayDGo5aKcYzGlRVnVEikFWYxhLeYkUIhbDgpxqzBLYFGT/jyKHWupq/QV 6aD0qZSVeIqiMRInRRnJMTktRXOkyNDG1JLEtI8UjNaM7T4T3zLqaGd3pmOp0nVHmEtA15/4jEa6 432pLAZhnEMY8Bz2/MRn3ICZ+69/78p5797YfE/Vjs7Ys1cue3zLNcsfXv3Q+lOPbsLcunHnEsfJ YcT19puvvvbR2/spzkaCFI0Cn3kBZxNsfzGKeMEOaxKalEnaTG6+sFCZqcneXN45A8ARezytFUVo Web6UDjpORHie7sGBntHznWNCp0bGeeaGhwfmeZaEJoWWS4u954gJwIm8mGn4feP9VHvivNFnBvM zSYxTT4cUSW0hzxNKbYgzfYCNwDcTeCOu93APX7bAK3L3C0jF5placO5OT2Dnq+UVdS0GdgIFdOp 0GSqhm7tc6maLcbFvmqzVLJLK2oKmIp1w1SEYSrHYBGGIzbrSzHVXSY2pUd1Hhltgid/oqXLbaNT nkcYczXVdbbU5fMV8+lNVIMuLrBYLqTrkeLMo8PxFFOi3CV7Kv+5++vMd9jz1/ewA5/+St1+8/T1 nR+RcfqAybesfApP9j/ajotB2Ou4PPNJ5kcztnXPHHz36sFzngAp4gYUtgrvID827KhHwc5gVbBX 0A4uCj6gP2g8Zcgho9xoC+4N8kEKj/JQcU2RbHC6M6JiL0l73DwnInWTB3uybpv3J3nEkbswm5bY 0XtADZueSEeKazYgHLQpmwRtA9gkb2CXM+O6hDIOqsyb2N/nQ4OefGjwG6Z22EQhS0QHb/kFZoY9 Ggi+hPegODqBVVSwwwtswCxycLuOmkePNuXMcZqnXGvlEiE8piUqkiiDhWQqrjCyRGcYp3G6YtUq nAY+WVxtJfpW00xMYBMQa1Sqeau9CWv7pk3u0I3LLpwaHtBn/JCDB7n717fMrxl2kes36rDmy9af ngUccV5mHPcNcEQUVeCFdrOmCZ5KLem5UBvqEZWiYFGllvJUJmq1fp4LtGGeyVKDNkc7qf7b6zgr UVl2TuKcsgvLNlRurpT6xfv1qK8cpg2LD+0xMT6xx1xpenx6j+bK1sqPyr6K/zPxXZnl94neDrKt vTzilpgmMWOoF9MjrWgvOoTAbCXX2n2ESMSpDi2J6KrPW52sVpOBwCE/Nv22v9nf6ucrAeRkUiUT a34m1vxdYs3PxJrfx47RlwSYWKNniXQ/J9b81Ci4gBK9f6kTJ1FJcekrzoPOT51ZJ1/srHeOAUXH OMYZorh1ltC7OVnUxMlkm5PJNmcwXbk0TsVbenQ38Xb8qPkzCdd55AR9L+QISzyn27r8VEiLnyZb MQOyDLiG5OScv29h+t3dTdjN2qr1Gbz02rUBB17W9pdjV/zxtpeufmLmXzb/zzcbn7h25Zbnrl6+ pSE0LtlnxpT+bbfiuo/vw3j9fa2n5/1wcPkzXMUf977y9m9f+y2NmKxBiKPZWB48bTfyAeF7wb+l bgszr5N8X24ot8fgWdNAf7DGL1u65eEEjJwRQfJoqp5U7Op+NVkF71Wwj+kYn83S38pZ6aEoUKhj YbFEOGbbKSF6nsJ8VApIxUNRolAFo9Hn0tQ5tn9iF5vqHs3CXP6afjVtvmM+ssi32dfmy/p4H/Ek c9OIJvThGH1/JQaUcxjxbO4l7wiftP2MS/lCoku3ycSTOXsQEcaWhJmco73Dx3abo2Hvf7AZxXQ3 C5E1s3dcmDlIPWXGnQ7RISUdoh7Ghgx8iegk3yoETJ1LhsmlmlsJi6FR9Fpr2q/bu+z5ke1Xzh97 Wx2YhN/f1fTYg52XkofXXDPh9ms7XwSeXAuIqmMZMhI6YF+i9KMjGKNsUDYrbcpe5VPlmCIhpVhZ pLQqm/JNh5WsohYrYGNJPOEUkbsOI1EQeVWUkgLiN/Gb+TZ+L3+YF/fyx3iC+Bh/CPZ4Pmcrk0l8 F9x4BjdepU/lmWTjC5KNL8Q3ecpEKoUhP1r+OfQW17GXZwBSuBBCoiS/uCXNEtsBKmvb29v5fxw8 eMrLp059BGI9+0hmHB7IxuxC79lDeSEpDOKrhdWC4JcFQeJ5wgtuhA2NcB6dtwRNoiPURCliOTeA RPf7gSuNpKpu0HCxVq+N0TiaumH3pyPKp3IwR0FjPqUWZZ6JTgelycwnYbytBd2e5+LDu3M142Ka sTbapMGyFlQ/ivoELFGta3xWdfUaU85lYjpk05mSTTWMFYcURjmKoC9tVXtx7j0EGuuUgMVXt2fm lPQr7t+vvfrce0fwX//xjz9es9Ex4i5+6qnN+0fNoPwKtMD9QHPGyDQ7LOZsK3GyOEXhnMa/hBMi pxRSpHPTdGqhohQqbE6fTfNN4q5SiUuMuVkU69gOVxmNah1rh61LYA1x1mDfBC0izwu82F8ZDqgQ e6oN6lXclepH3Gei9ISIE2JKSsq14gCl3hhjNPKNYoPUqFzLrxA2Kq+Jf+LfF4+IX0v/EX+UvS5V FTiOJ6IoKYoMO4osJyXRI0kix/NJQfUIgqoCwfIyBrIUaDBV05DKd2CnrQg8i66UyHQvHmPegZmb ht4ABpCWRCQJviLC9WgMcA7NjurNeJ9hHOWSuRglIxeTAMydQMw1QUHd+Ft8+KzuuGaoZvMdLSfY fEf6p9k7ME/9tTTjg6cxMeGsAHtzSAK0y3UcK/OxZWOkgouVmziiBAyaZgC+B9A/m8tTKotqFbmo qE6kmdFFtbB5d3uMbbbFc7N2jSzHowWl02yiT8zu3R5n6QjbfXTzyXazVsxt2J7ONtu0Qo4IzTGg j3J9zGPZ44OneTx1rKCTodsD9OJvt4Vzp+Omxlz0g07UMHlFX9hLYAk4FD/9dWYefuWTzMPXC3tO v4TbMss6Z5DiqzMXU7q8EYr+jF8/2yUwAcXS8voPyKXn1fTNbXv1zm1Lcul7dhLUjVMoFjYJnwr8 GCiOCVyxsEhoFbICD9JcJVxOwNM7MUHvBctmE8J7wc0k3aX9Dz9J+6Ju0j6H65w9JueNscKUTDZb mKTJyy40mj9TdlHhRUNHuZQ+zPboj0LmxnaW3JfToWIKbKYEfp2m7hwvZGLlKjRQbI/SjJokf4Q/ ovzN/3lMeE84ESN+OZZQAuGYwnGJaET0UpNCwmIiFDTVQ0m8Ibk5SZIgxxzJDRa2eOaxBZi3xsJ0 zGPz0EFa7K1BOlCLML+NiTGLBeisQg6CVcjlsjpwk60HkhvCOMxuF+66XZjdLkzz4Sx6uzDTkmHm eIcpLzHlHNbpjcOFyF+Y3s+HSHUiiQ8hTGMApBhR/uMY/xX9gv+YxEW+vAY+XbCRj9sepopzqHDk WLI02YGX7/i5BM7FZzqPdAvZdAv1wU4nm8hoAe8fjGdQPYyJLX/3fGKH7nGnPLoVxi7DW1DUedcF 8Otlk5J+9nofU9fMju6uuB/u88S8ZfcWX/fmQ0/vSEw9Z9Gv2xtmXLhqIJ+6e/SllzXs2bqrs4z8 5vJLB979WOe9ZPvy5WPvv7Pzw4LN9QXQiw9fa7sFTnSTLWaH+Rn3pfsYd8It8lTk1gHBrDDxfeah wOFANsDHZI/D43OBzYVFn6EaDt1RGmB2VoDZXBqztjRmbWld1pbGmEArYWdQCDNrS2PWFuz/mEOo puajcSdsJg41ZtBpGP600QHKdCFqeQWOBciiwOZAW2BvgA9wpNrrY7x5ot2y8smb/6vBpf7M4LK6 GVx8nhP32q6fG3Cj/eaJ7lPHwIXHmRF2Rmuapa2yFC/QwV1WmE+0FFVWJZUTzZQlOsLYqbrySKbp 3i1UCjMs56O43VC85pErP25+eKyptlfMP3/Jk3zq3q1DF43qc23nErL6igXn3vV2J3sfZEj2K74M sGigIJ6/y8vebHTT2QLmE1CWXEJrQXbAJalBfbh4vjxZbJRni3NlucYc6Bro6xsYao50jfQNDUwV pirjzSZXk298YIGwQJlhLnAt8M0IXIW9iigYF3MThYnqxfrl3Exhpnq5rvojvGSByPCUhpnvE2Zk IHW9Ci2xYE4+EFgIvbJKPn/rGHNJ8zlerLLXdpcma3pJGEmmFJM4qfenICNo+wgaSoC6oxTpDur2 sveuEIs1ogjDLwsh5LmWyR/E0pKRDbek4oCg3iEaUsi/pp/DnNmSbjrR1C3RpSs3jMZ72NzRBGGC cplwmcJT3URPcZv9AWkolx6AujtFQx675Xd/wb5r/nHrp5mju7evWb19x81rthM3Lrt9WeZvnQf+ cQOOYuPtt97+4+/eehM6tCYzl48DBl0oii+zb9fNnubZ5kiTr4+1xUhxrIeeKOrj7VN0XtGi2IaY PNA/MHyB/4Jwo3yxPtU/NTxPnq/PNRf454f3xt7xfBz4OPRO9IjnSPRwLBvzJfi0mfb25Qeaw/gL zCnm59o/ijKmZjk4X4SGzkVfxKEhR7D0kIpN1Vab1VaVjzEUxuz8xPoXufk7NVCYaC8YdF3Zu7kw ukppLcEm3ZdidzWpdiUR+t8j5oVAudktUG6eESg/8fNAOZvIAhHJAuXFw/sH8BmR8kKg/OdhchYn t2q7R8ndBaHq83oIdWjLLK4b9tY8NvCuOWsPzbvy02um3HGW9cSy5c88uXTJtsxc4eV148atz973 aObUrRcO7DzFPXZg/1vvvfXmB5QLz8/M5Q4DDk0Uwf3s2zWSJhWBQWQkWaGL9d764MjghujmqFDj rgnXR4e4h4QnuCeEp7unh5ujrdF3xfdcX4hf698EzB6kRE97a0lffQQZpk8hc8mH+l8Cn/m+Dn4R Pk2cmDc8oYgmOURPhAfE+R3ViMZXndh02s5mZ6uTj7JARJRhz8kCEc6uQISTBSKcLBDhZIqUhRJ8 FNbOXJ6+mDu9nkmPpdYv46uljJNZDEJiMQjJlzN8c/G6ouiZ0Yf/Jbbaebzul4hBLdjKx8H75cMN Z0RVKyvunfRy5ruF71z3u5ZHOuPPLl/yxNZlVz6amUvkQaPxWVjanLnxidtPDuaeO3Dgt6+/+/7r VMPdDKh5DbBioTfsQVVubPI4wdfwg/kJ/Cx+KS8qlqzIiuG2FANxMtYYSyBVKd8gY7kk5sZuUmL9 3z37LlvvB9vqpmhEJojOsChyzr3Yzcgf7Rq+/xfO/RGz6fhi+jYVBQ3Nb2COHDLfWONgadxNi+nb cDnyzUXUJFAUNz9yztz6iy8557zzBl3iifKph1vOH/hk2fD65sWd71Io1Ge/4rYBFHpxfvsavsRT MlC5QBlSOrlkZslK5XblptIn3M9U7uMMxR8K+HuNrHzfL4TJJELMPlgNTJWnKlPVqdpUfaoxT56n zFPnafP0eUZ7qr3MSROnSnv0K52iNmozUjPKlyaWlraW/kp9UL+r/N7Ku3s9pj6lP1r2WPmO1O9S vvKCJVpSqCQKldJCpTznHebPoZVEoVJaqBTRDGdXtHaKXJbUVT4US3l57ayiEA3dlQQr2exCsD44 JnhpcGvwYFB0BouDC4OfBvni4B1BEnwZcOMFumCxbttDTzdpGr+JD4Gjh03M3oTZ4fHV5GLgDqsG 47OmFl1eRIoiXonPTUGzwMQXheDDF7abIpiPnKUVh3CoNGi7AzV96OVVLF4byJWUW4I+SiPBGL0y GKNXBZnjGGTx7mAHuXi7VFoBl+6M1B6qwBX0KfSKikLuaEWBT6HyzS56UUWIPSpeVlHT3GdvH1Lf p7UP6UPj9qUokLN3GcnFclAG0U4rtAO0kvs2SazUyQSwk3XPGctLiJN2jMkN9qZHPsxY8mnBrQ32 zgfngcnzoph++MOEzeLR+anvdLql2/vI6dxMWJp+tKOFTX1TX4am7NFN17t2/pz1ZJf1jCYET2XK Ml2m2+TEEiMWRkq5FMZCTyiiHtiNOxJhVJIwdLmHGsblZYoqpvkwKjaLqJ2Ve8OOFSzLvSK9atUq 1E0c0fhPU9c3GcpSZWeRvjX9+v8iFRAWmv/MIqD12523XLNyed/kr17bOObcARV3Trj25SlWm75k 7sp5Pl9V+KZX7p0897VrD36Iz47MXzxzyNmJQLLPiFWjh68oL06ff83swPip4/snIkVutbT63JVT p2y66FnKp6XZ70mFsBH56Xt4Kn25LEXjHnvtc6HSGsQI64aKOeQzlbRTBdXNaU6zBJVgw5XUcVaS hypDm6VFUqu0QeIRWE6bpTZpr3RIElkqfT6n/jijIokmC7Lp2pw/lq/ks+xPMuqgNhnV/TS0kzfN claltIfMQwHcb9usnzmp7HNDnXXmESrhj9JMQirhrepq841cInHSn5s6ozMDVn+Lzgaw7Dpihi6s u+zyyptu2rFzpztdHn14k3nOzEfI9PVYujxz2/rOX42qDDH/HmTZYfqFXDxmNwrROSfw3EnM7aOJ 3MfsapenJu3GpbLbp2O3TwNhbgGYULUvGfBTdyLEfBU/81L8LhaW70o28TPx7e/yT/yefIA+Hw32 M4fTT/0Tg8Ij68d7/dg/OsTiAdQ1CR0LkUWhzaG2UDbEh/Sk0qU4FIyUmHJIOazwSkFxKF2KIx+N VlkMmiVisbgz800UFgxWRgfPCAnQoO8vnRDQICwzoC6nORgThXjTYTgNmg1IX8MGR4TXw8iQrVwI sKJiFehfuDY/q1mWYmFA/08v3XH1K9+75NExptauWVeMG3f7oPYH289fMKbvEnJX547beg8fN+GO taT21EeAnRCN4gN2VPxNPl/AL8hIlUUsqkhQZAEToZS9oVOV/viA+fEBIA2q7WhXwy/0FTAqsWpV Kt8Nq1YBN7NGpgUBSbcDtji/VWkoQ4nGa1A5FMzuVEqSNcgHBex9ZF9XflYNikHh1HugciWl1qK+ 6vlouDoZTyaNcoMyC88ic+W5ynJ0Fb6KrJCXK1epa/Aaspq7RVorr1N+g+5T7lSfRY+oL6MXpG3q G+h36kfoPfVb9Jl6Ch1XK2E4agD51HKUUvurY5CtKoLt8tUIQCo1ha8swXjo0BE1kW0nS0JFTIZS WNA2Zs5SqLBWIgi6RhOCPk4DbGA9kD6QRlU0tZPCx+6vSrKcVFSPoqiIIySZy9QUVBVMFpZ2KUqq wiEsVOlYL5Ft21ZaFaJ04PBOW2gViAA1W4kRG5do3/yJUtPRULCzqbMpFDh6pCn/mZeuuKJVe+Zr ZDSTLp+P9NMPNTUW0iDd1Rg/n7n8f44kiwPpb3dnruBTnTfNXjhxGVlLY+m5vMYXgDpcfFHhXUgX tUyZ9MklgYl5H+Nd9uEgnmU405oV03MH9rY7cpMCoFppzbLZvmpxGOlgDWHRCdAwdPYpDt3ChFd5 S81Hp3KCzqIfjjpgvn/AfJe9FpnPnWWjoz/KDGHgQA+u4Huo5ALrYut2i7NiDH80VSg/0XC4MBl/ zFaK4zVmpCgXt7ZfKC6t4UVdcYthJegSeMSLmqI5ZJeJ3JxHishhrQg82KRUIacdNaivNFAe5BjC DRdtaZQ8UhvsHG5d4LrYOd41X5ohz3atEK+Wlsq7xT3OXa5/i6eUcs0qR+VGmaPcWeaq8gxA/V1X yavl+7h79SfxFrJFe0LfiXaJexy/598XP1S+4r9yfuk6Lp5UIhp7x0RnpSnm0vSYSmelK0+2YdXh 5F3IkiU5KTmTDurGOSTOwHrS6Mi+b/enUsoA6qtgvpqBPW5R1ayUmrYm8uPVqdbl1kprnaVaKg+0 SNGRQ8zP05Sr0sercon65hG65LQ//IVtD8fSlyVBUVUZfBTVtCyQ7yN3CMgFNssIe5bqdMR+a0ly TLJcrrQgeQRBcgCek4bDYxgOGdydtCp74HKa05znFESw5OJlp6U7DNY9F8hx+t0HyjouJ30HS/Wc MA1MXzFvNTijAz9pq7ExKl6oXk9zXckkWxlj4YXW9RZNa59ka6aAm1mcmAPmenInPuE+MYuZRMFR x5uaAmDXwB9lsqbA/57PnOc6i5X/RTqz5DDr6ErrdB3ZVjyhod2I6THyUvYw2LSHkSN7qB31csZc QKMsB5blwY5sq5nA3j4+tE2in6OChviEkW3VLFFJzh7eJsVyra78m6L0ZZ5Du8AUhHuDtDq0XepF 77gdDSB7ck/qunnXdX52nZU9vEON8TH63bLG/BwDvdu7u1y1qBJWOq3g/in/NhfPpuzH3iKlAoXJ E7efJVVzZRwemXlxz1P1fPVTuzf1PXvX1kz7i0/1+AAEzANHrDfJFZ33vXWAzDr1EVm58/RBkDRO 0EP/BySNif+a10NeJ9ZEnigiEQ2gSCezyJ1VaUaU7Pst4RecLuwsCbJZDHtssHaK8x7+Hnmj437n XmGvuFd6y6k4bV9tiHMrXiNk9sUDtVX4dk2ucl3EN0qNWoPjXnyfep/2AunQf6+96Xjb/Ih7T/mj 8Rfzc9VVYC5NRy7LGTDAsKBvg9kOWnOKiBhIVYnIXhGlJAFiKJfKP0sUOUlWFCyKCk3hBnsM9LmB nU7D1MCoIIbG6aYqOolTNV9DrynETCLFg5DCEeM1AxtJnfPoOqcqCscRETwBXUfqGBd2jTCu00tU 5zRRuc5WQTO8YItjxVb2qajBtiPGXUdKxgAsR1gr9+e/V8eUBegK83Pz+FH21vtP9Mw+sJinVvqh RUS773SukRmV5krYUNKtk+vyRNHuCBTVauyN1aJavcRfy8FK97fHa032zoe3FpfEaxU7Unh1LN3I gqZsjggUTrWfqp7+dHaIK8NOfFNm498ePStSmdzxQeZOfOvHHw3MfE3KcebH4b3Oqz6V0Tv/gC9o zDTBuOKZcdw/gUZC+D95GilSPU5O4yJBp0vURLftcsY0W4/laSVYlQ59HAocCAVNumFOOlMb4R3O CHbSQSyI1JZ7Jju3qpxt2ICQWHmvGpMWkq64fEbAVaaV6WVGP72f0dex0dLKXeXu832NrkZ3o3eu a657rneFuMxYYV3tudp7s7HOWu9a777Fc5+6RXvJfNHa4/lG/dLzb6PT/NGTjUQLFOVza5Ew7xzi vMnJOYNd3c8FEVxdr4T0dzp1E2QlWA5Bj9uddKke2HHqIAyTmgpusOqmKeOaSG+AImaEVEVeiZBI B6nf6QRY2J4OMtHW6l22i1zqesVFXB34vF1OXIKGhlV6iEHLjum99DE6N1bP6kSHM3ZUOQE2pL49 HFsJghGA10m/GQZERN9fD5jHjwTpVy6PhgLmUVZDAeo4FChK7j6lSUlqDaMfkHoOkDYBkDYvIj37 FdKyX+HussaT/WRX/1q1pH+tA7hsp7fWyr982EjtZQQ2DJCPuyyX5dKfvcKRN2HoBxQTJdd7BlXW ne+3UoKWWbDv43RJcfqz9szl55b2Wjm5JjP7KbO8NDzfWcSXd268ctXKZWT+qd9vPa9xArVyykH2 vAt05cBbbcPVQd6QiQv3yb288QdbgQo+J8pmuvfZF0ClBylXqsxaXKuOwMPIMHmEMsaciieSifIU Zax5OZ5OpsvzlGvwUvka5VZ8s3yL8iM+Tj+jl8I95LRSKz8uf4Alyi0vmN4aAuIVjJB37QQ40mSg ohJZVZOYgPojmH5CjkwT0jBEdZqBct/iZNo87VBJB3a2gzIUxBfJxQghiYatWLC+xNjswMhhO5od rY5jDoHl+pfSQ46lSL0O460Ij0ELURZxiH0CBgWd5tI4FRs0Cpifu+6klSNpllHGPt6XrjM/Bxfx c5ZcmTc1Tcf+/KcpWpqYOQbY3NkDp2QalMlBT6awhL19L1AoUlDmPqbT0sje8qC67JPtTgqE/Oar F8K1iuwLn02Ns+3+WuZ2qb5a4oE15PtJsFT3xWKCvvaGpX7VcW85eWxJQ2YMN6Pz1YUr5uF/3MXJ 4l1XdV5yjfIAxfPl3Nf4bOENpKGlduod6TOJbJN+K5HvZfwr+WGZLJFvkMkkeSaY5TKWNQ7Jz0j0 471RzP0I5oaG6jAiXB2SBshlCLGXofTfrMhFUwBeNJANPnRn98/2InCi0eIW+OGWFpq24ZFyn/Bd +Wpx+uLKfn05/oc/Pr560Lgew32XTqBR6e3oFj7BnUQGAmcP98l/VhLR1wj8dPKwEGBNkXkL312W yex6IZNZ9u7Cpucve//ee9+77Hnu5OJ3F0MbJi8seWfxhZe0XXLv++/fCxsY/0/3/tmdyfwrfrrX mXdgX/YFg+yOO6u+GHips+7fclhm/ynhkc/KKuj2tV7bN5zc2jnbRLLO/lsPZlew66RzMqPRYBOd 3HryahPl27t+Rl8x30T/z0V+bSMfoEv4JcgL6wipCF0lTEYNeA2aQp5GK+nKFSGbfxYthnOfhv1z YbuHXgvnT4L1U1jrYJ0MayjfNgrWabBOoPtw7m56LdxjEb0P2y5BU+RitFCYnO2E590jvI5mwfoQ 1B/hP0NbxFq0APYfg+te4RHqT8+Ba+4Rn0b3QfuDcHw6tD0E2wbYfxjqU+G6Xvm6It2GgnQLqwjt PeA+t+bHW8a9ivrxS7J/g7E0wj0vgHU1PGMsbIfBOhLOccP2PFjX4NfRWvx69hE4Dlt0Izx/DW2H dUh+ez7c52Y4Xg/XlcL+jVAPQT9E2DphjcNaTp5FwEvoJdhWwfgvyo0b1tf/n/bOBLyq4uzj71nu uTfBkAUCAZLcC0kuS4RAEMImuYlJWKKyhCVBahACBaNiG1xqLVyKIii4oVRR2eqCRD8uiWIAvy9Y 6gIqWD9DW7VK3VpFi1K1RSSn/3fOnJvLSSBi7fM9z/dc4u+8Z+bMnJkz887MO0sMzedvDn8T8i/z 1Borj6WRIM3/BhnqcPNDyJiIvDlZ5mCcNpiCkNWgB5ikvkpX6heSgvK63/UhaQw0j8vpHXC+XkUX w60gn2Wup2gdu8FFghrzpP4gbdS+pGF4doOxFt9RhfIeBL6mHPVT6m9k0RLoVxHevxSsxzv/KvSh iqYg/QGQg/UPhQ4tB6uQ1lG7nLhs4F6Kep2MtL7lFoH4ZWAM6iUIruD8IP0cLnOud2Va83CE/QBh ZjLw7yrAt7NOchyOj3dlST3c3CJpM8KsRrkehtRBMufBRuiZBM9ewHu6AQOkgQHgQ7AZVIMRoBT0 QdqEdDWhr9AZ1k2hH9AN14soQ+RN6Kz1DetFfVptZpN8F6fT03iCqiU9+Z3cXlhnkZft9ru5TbHO 2FLod7XQ+7/xd7JOhSXann6ExnAeRBuEbtmS2x3yzO1hrTqVVkCugx4vY53l/NmSy4V1TZQJ2oSU oyK+daBoI5AaUYbU9WW2tMsiLOfTw3jnLGM2+pSNNFZfRGO1u2i2/jkVaX1pgGsg/PA9CBtSj9Bk zx4ajLqcAPf9Dnkf425SLnftwXfWojyb6CGU6U/0JrWX3qS4XLXmxy5S9rlq1cXivpV0ouyxnrFk Ip+drf/3QT3kqkWfWWt+4moyTXzP3dwm3EeUgcBnS/jXgSDo58lW7vNUKw3uqZRgEH0JFuoBGuEK UJ6+B/WTjH4ebQH+U11/pkZtNUavJvOPSpCCahMtdyfTZepa9GlISz1Eyxh+P+TVEXp0is45dcmW tr46Jff5Uqe8kAba3wHJB5KvwVfQo1LoZDceG7h/FuMD+miw3NJX85uwfu6jRyBvs/XToafVDv08 x6mXTinGFvTvdjtFPlba38/9I/dx3EdyP8f9jB3eKSPi36puhR5zP/wqzZDtupdkPPL4nmz76IdR 39NN0ygxHzOeMrdoSeYWIxf3fwAu8zF89/XhMbXcbJbjaV97LLX8qYM9jroG05WyP3tY9DfH6B4x jk4T+YsxttES1wnUO/pAkd+Nsg2iPJHvan0WynwdrcJ3dNNuQXuEP5jJZSLqgiiFxwUeE7V7Uc48 Fq2mZdpbsBc47mBKFONFPk1H3vcJP4ypLNnPNZ02G0coV5+KvnYPVXFd8XdwfrjuPddQnCcZ/UQT DdIfR5hkikW4jaIMAvSY0AuOWw2TCmXhnkNu6OzFCMPv2yTiBChJlsfDoixEfNgirMNcFninkUyT hT1xhDa4ptJ0tKFN7iBtgh1PaBdb8I5HEG8q5wXxuovx+l66BO1rBfqmFehzSOj/DPOEVovvuR79 OtCCKKNaSnEFUYbV4tuLdKuPvYXbj7aV/Kwjxr3oh9meuJdu1bOp2Kim1fBb7UI/iXRvg99NaL8D 0XZXIr5X9tuEtFfCn+Pmsy3DNgK3F3eAOhlBYQeQyAPbKUhf+5g2aeNpBfS4wHMvyuFm6g+VZqMx HQyyEO7FklUWwi/BkkpPLYF+wf7qYHodKXQgMnkM3akvpQX6NMrVBqHtJlJ//Xdoq8fpAS2eKvX9 9IDeQKvYrXeiPloI3/8UbEv2P0gT2V99He77aIY+CvFX0FV6JdVo26F7b1CsPg91jXiu26EnmYh/ DO+VKO/TDG0a2tZy3B83n+BwIo2nzOmMPpb6i3gRiLzaOPKsluKrxqNOkV++PyW/yGs4n3Ye28if +E5+L+JxGP0B/isU5tsgy5LNk9TVVAs2qm/SBdpF9DNli7kL5VriYGykWx+i3AgG6EPoGbAU9+dC /g/YZrlhuw2ht8DNePdzkPWG2HrAbKuQhrKE33pwH3jZfhYJp9OWfySuHuauU9xPY6wBypfmLsYZ HuU8FOkN1c83dzHQxfGMsYQ6u6+lzlpv+KcjnsPt6oH29DRlamT+o708nQn8GxhRjoHIb7TrA7LL d+DtCOljKceG75237wvqdwn4kSjfv1GypUPUUTlkvg05TTlECdo10EEAd3+4O9nladcT/NcIf0f9 QVeIy9zp73Q767U9t1pPlZHYehDWh7tpNKPnIzxwuj37aDRjPI9nz7d264+1wwzqp63jPEEHe7d2 GxOoN6NmIq/dOQ7aHAi7D6KPABxWxI+jMQy3XUZ9CvM1EH4+hIqZiHIdyuWqrbOe2/Vj14uzfpC/ gH6AxkH6IYdDlkGOt2Vkm3W2W6ef3Ze0FcbRNgae7p3/n0Db2Q9eBC/8p9NSCLoKEoDxNuyQfNiR TbBPLuHf2DiJvuTbHPAo+qEpkL+HH0bv5r4gDveJ8Psx5ENEJ77C/U/h32RhqnoP2ijtym7w2yHj euT7yqz4J14i+uZLsM2Kf2IruBz3XwCM5yf+BPkc5H0I/wni3QT5G+v5yUq4rwXPwn0E7itAOe7v hEyGPBd0AkmIv5Zhe6TVPPQHl23PP76rhM0yB/n08poX5I3OOcR3lnZ9tiOdcw27/tuTEWsGDmmV A+ZM78HuC0XOfc40x7El6rM5En2qeRI25TlsR7Mty/azsB+lFPM3YcciXaLOtmTbme1Xtp3ZfoXc JNYMXCI/U3meL/Ilx43IvlX5ktaDBNBDymqEOa72Ng+g74mHfn+FudHDDNwdwTQL8yDGrniMdY3o d7+CfBXuNMiv7DHN7ltb9bHtjGk/tPtsx8jvMabmSiodnM7fZphkHOMci8+W9sbu7z2Wn2aMjhyn /123Pc7bxIymXMYdMHcxTru0lR3Qjrs9O/ds3U6746zdDrvEdjtp9dype7Y90526h3G0u7OF5xb6 0y22v50HZzsOtzfpRhkVR4J+oI8cQzejv4D9b6YBjFHm3fBb7PmWcj1PUi7cTwOMm82fQVbxM8gN ympe3+a/ddX8S7gT9FdF2HJJVXv67NRbts+FfYgyE/3gnZx/ygEjQRLYDq6065rnkEj7jypGXZ7n 6jPMr/QDwGEDtiuH0E/Ak3DHwx2PvrizkYh+O0CP8Xo8ZCxkLPr3SS1rfOZJ4wYRZrxYW15EY9HP X6U38dqX+VuxptdM/P+35H2UZRhDvfY6HdzJvDbk9vF6idkg1+dmGccwDk7HeBjDYwfSnSb2hKp1 Xsc9RvdoHahIriF3tteSeX2KxytjAOLwOkbkOvL7NEifSUUgX7f2qaby+ov2odiruYXX3bWL6Vm5 vxWK3UrrY16k9Z4qKvEsEftNa7UHaRn8HnTfTg8a2WJ/Zao9rvKY2MbaH69ldg+vacpvdtoEIn8z 6UJej4lM147nKcFYekysQ1nrmO3YNhjjbwVV1n6F+XXb653mK3Ldc74c468Nj/nOdfqZNElbjHmf vSb7KOQhulRfDmQZO/Nip4VyOXk6W8i2TXA/Xaz1Wfs9vAbVKWIfrkSU88eivsZxnbni0Ibjuf7N nbq1P1eoX4/wKnXTjwJr7VHsz/HaMK9BMup6tNGr0Fagg/oasYd3kwRhzUdFvCusfTOjDOQjX/OQ zlbeO7Khm1swP9Cn0q0Csa5mblY7mzshf6q+LPYY4+VeYDd9Fep5lliXtvcEU/Q+Yt26jz4FoP7B z+DOFN8upSirAOLFY17H38hrcwOI8MyjjZRrpDKs+xkqcQegrx2oxFVPmdpC2C970Nelou7Go17j aZn2HqXrw2iOlkhVjFJiHlCOQMJSZ9RP4P9HyLvE36OdwXvC9r6atT5NJwT7YSsAuZfLzGXUrUpP uU9YIe/TrHv4DacdAvsdW+nRCBDOfA+cUO9B2oVUpTYgjY3IC9LREtD+HCDObEkfmc4YfTra2Klc 4ARxWeY4gT/LLCfSv7sT+LMsdAL/wjbycbpwp8vH6fz9TuDv/wHycbr3ZjiBf8YZ8lfqBP6lZ5GP 05VzphP4Z54hHxc7gf/Fznygf8I8tvkFzE2fgPyDHO8/hrwQEtrX/FvcY35hzpPuP8hwvwKY/5r3 A8yVzUIJ+jyT58C3QH4KMK82J7XQvA8y1TqHYadjrgH9wDQrLY7bvNtKWyDTbK634p98UuY3wt3c BXxkpSfS5r53F2QGWCfDr5Dphqy8N69pCc/P+RtFvFALpgYm47kXsqyF5qctzL2Q/wV4XfRF8JK8 T5flwd/8DL+rpV+gb8ReEe/tYKx2byUSY/bP6ULR5x48Zayy9qzfpy2ivzPR942iXCMOdshDVMh2 A/fhrrki/G2uKoxNBPtkmtjPq9YPk0t/nrq5PqRK/Soq0nbALh6D/hZpiH0ZvJv7bbY5tJV0ERB7 lWJPiPdOrqdbYp8S9ksCwnTW/4L83k+NmLOt4P0z7s/dA+C+E9+yia53/Zxu8FxJjcbnyGsTzcN4 5TUqabjrlzTWntsaV1KM6xzYBVJ2UGhOTCr8+WzCR1QUcwvsutdoIsosz047XA5u6gz/R631lWaU XDPq/ttscKHIM/ILO0zH3LqzfW7A9SOUSZXIz8Viz+lx0jFHJ9dRjN3jqI87BrZXDq2ISaGNxtf4 DgNpZUecF+B9+q3kd/+YBrluIb89dzc+QDlPoVhb8n6cvR4A222TPl/Yi0liX0uuB4Sl/Q7ebwvS Kj4r4bRrbDsqbFPINYLwmoP9PZA8foa/X8oIe8NaU9gD+zSZsnkfT6yJOKXMk9jH2wNdkvasu5HG uzXIR2mesZzKXBehXDpRmXsvJbnHUArbZ263sOuu5DHadRy2aBn5ofsXyPZ+HeC2NEa28UXw/z14 wmqP3L7YX7RN+J1cJ/0vBzeCBdZzfmYuse5PHrXeL57daIU/iXZo8h6cGrFW866FmIf4Iu1UeZZq eSvZsnfP+lPSrvyOa2jchvlMVRt7/E65BnK+7Yad9y7a6N2I6wOGbUc7pW6dT1lsSWEbsnxEyl+z rrGt55TO8yunO89yBjvWame2PPXciy0vldIfPpfTjow8J9MiTVO6O37XtTu55tbdlm2cP7DW5Fqk 0Wr+FClFnZAm7Vi238eLfX4+m3MGwme4fgkdOJVpDJ8naAsDIwnjvuJUpJ1/Wow7EA94vE7MvzPI 81IL8wHJEclmRlMwlwb6XU7MvwvaPl9XZDyEdIGnv4V7n4Ww/88AyoDcaMGeJCENHgvPCKwMxn1U cpuNaTJ2udvlaJcLvu0jfPf8cJ7t9OV7/916/Hfr5Yf67jPlPRJ5Rs+WfHbPaDPfqB/B3y3EWZqt 1ElioFx3g1qwX7KGQVvpzmeVtLnQp7nivGI4Tis9WI25KSPd8vyNYcCyc6dY7YDP/lhQRVvl455r 6Z+7t1VO4tyOZXt9iO+Ik2ds58m+LzNmIm2S52S93Ldg3OV2PlB/juadavOZZdZ82tyMcdKF8Imu RVSivmz+2nUD+oTPzZdcS2ALAKR1k2SfZKNl+5nb5DlIQ5wH3kqPR4K5bTrDYZBeDXhE2ttsx/7U ovkvln9Lvuy+V/snvuMEdRPnSwNifj1RX4A5/QLqph3Bc9gLvN+kXUYFPGZoQ2Fb8Zmb6+V5WV57 eAfSIg7lMlHbEtG++XwNn6sB4kwO19MLGAM4/Asivj2/7yPWl6rRj79FXnH2B8/EmR68g886sV2k YUbhmgC9mISwk8zfafdBjpX8E1yF/E6jBepN1F+bh/nwa7B3kuH/E7AQ9ymQ8aACPAiupUHC/wT0 5BuEB5oO9yuQLsztXfA7Llllwc/FfHsHVcEmrsL7rHBNIo6FQVXKb0RaVVoh3odwKmZKGiwKLVne G3h+M+I1WvN3Xlfg8OKZHSamJYzrMyqJnUclRiew0tzlKjB3KR/TKH0GJaJO48AQ1PUBOX9gO+og QGmZ6+HerzrPBdj75FK6nqQFrvOpv+sk7IO3oQeHaZTra3rAlU99jIkYx54g1qWRgOd28/g8sThL 3GQesNe+bYxySo55nsagDonPb9hSreVfHcD3ThXjkThLr7D1VmtZZOL8tNXWhJ3rLqJlaMclYKw8 9z3P2h+DDYq2p1vnVPvoj1CaZcfxHKoZpWVyeyhD3xBee2XJZ9pYt6QtiKjmE+rrPK8183ivQp3I 57VE3EuseanJ69X3AF6zfDBi/2kt83+9v6U69qFOt1/U3tmM9s5qtHKf5Z6K8+xGe2c52nU79lza 2y+DrrKNXIJxpdHYajbB/Qy4C/3rw4xOpinWRy17baXWAW17Eeag4yhTronyOmk6+q90fZVY019u vY86oW8qtNbmzW/l7zmI9VRem2O7VEsRvwfRXf5eA79/vFy/Fb83EV6nPY+mcl/LfaoYM/hsN+Zp 6G+quG9R99Fg9VurD1KaBMR9kViXLEQeC4UU92o/2acUUow6GN+yxkKLN/eJPqmj1WdphPc1cH+G 8dfqr9K07lb/pb5h9UHqOwhj8yX4hPdqxHz6WWvMaX5cjE3fWP2k6At5HRL34vdRrPlTPLdB/j2Y 9uwlaVvWOuRuW7ZnF8o4tTJO6/By7wZjSScxJr9IfXltIjzvIhoszkZ/JOYrY/GcbZAWO99ebxf1 hDqy9vYV57yA93O4bu05vbVu1vxGhKy0EOM0l+NfYJfFYty9UKSBPk7s99SYX8p88vykG/T0tvDc z57L2XMNopH6enpY+zFsoYF8JkmM989GzG8fZljP5C839TsLtkKrJkbwEkqmI0DfqO6y0NCXuvbA mlp3Br5ujeevFrHQuHOQVlwVUUfM3+OvJkrwEyXuIErCd3SCZnVeYZEMyz9lFFE3WHs9uhOl+izS MafvORR8QJThscgqsfB/2ja9fRZ9jxFlv0bU/yainGEw65C3XHzfeRgThrxDNPR1orxPiEbAsh2J seF8zEDyFxEVIL3Cb4iK7iQqRhmMG000fjbRhSi2izGmTEZ+p+B7pqOKyj+N8p+m4s4oUaK04tP/ LDMyo0SJEiVKlChRokSJEiVKlChRokSJEiVKlChRokSJEiVKlChRokSJEiVKlChRokSJEiVKlO+E wn+xiY7RKHqI3KRSAuXw/9VUn6+nkYvUnTRF61PvT/G+9qzWlw4DVetbl53m3an11tLqRnoDDVpG fVJybnxBf82Ht+WIqw/XhWAbaAQ6VWrp8E/AdQkIgm2gEbwGDCJc+akPLAQbwGF+oqVpqXU+b0JB b60b4nZDHuO1rnQUmEAjL645YAKoBHeADcAQ4dhnIVgCGsHn4klA61p392DkvWvdbULUX35FrnBe Zjln/kg466dXWPKiSZYsGmcFG2EFG3Se5T2g0JK9z7VkUlZukGVsXO6egi5aF3xkF2T8alwV9bcU ryjkpY1aMoWAqhnSJ6Al1Wf6czc0ajopmqopVEVec4+m1MUl5hbEqqZ6lJLIq/5N/cx6on5W3zEx d0PBePU92gYagaa+h58/q3+mJephLnNc88EG0AgOgqPAUA/j5138vKO+Q/HqnygH5INKsAE0gqPA rf4J1wT1bdYWceX7fKCqb+OaoL6Fz3oL13j1Tdy9qb6JrP1vXd7w3J3iJjtH3niz5E3XHvImqUtu g/p63fG+0Cg/ahoatVvrRaNpsNarLmuQt0FLqRu1wNugvl/vy/ZuLBiovkEhoCInbyDlN8gHJoJZ 4Gpg4O4Q7g5RENwJNoIQgJbhmgB86n7wCjhEA0EATAQe9bU6JNOgHqzzF3oLuqgH1BepK0r8VfUl IV9RXxDyZfV5IfdBpkPuV1+oS/dSQQc8J8RJgEyAzMFzl/pcfWaS1yxIVBtRdl5cc0A+mAAqwR3A UBvVXnVV3iS8ZDft9xBC1tHHQj5Kmz0UuNwb8F8ABfTxxT/ifNzhssG3wa8G/Gvvh5Mv/tvvxh1f /Detwh1f/DcsxR1f/Fdcizu++Ksuxx1f/DMqcccX/4QpuMOlQV3/TGZvb96EasVXEK9eh1K6DqV0 HUrpOtLV6/iHjuuctwfq+vVDia0LZPft5w3uUoLPKsHJSnCzEpyrBBcrwaVKcJQSvFQJZivBVCWY rgQDSnC3MgxFEVQCT53iHB5IUYL7leCTSrBGCfqVYJYSzFSCPiUv0KD2rBs3WIhiIeoLuNFBnj8a vU+82hMl2hM63xN9QiOuB4EpXAEE8vWyAndLZ9mrvl++5R4wIndhwVh1LyLuRTXspXeBjgraCzXa i5fsxQvicc0HlWAPOApMYCB0L2T8DnGNxzUH5INKsAQcBYbIzlGg0kKZxW0iYzky0xPYpe7FTy/8 9FR7BtISUhOyE8Zqd6Qq8enKhHQzXc2jLl2IKCnRk9igxO34R9w//xFHMQUx6u3qHZSGirhTyjvq jqd5G5T76vy7vQXJyq8oXYfWKcPJr2RBDqMa4R5CqR6W51GqWguZW5c6DdHi6/znencpHTnWDu/x 1A+8H6c2qLj9a+pu7+99DbpS522CT+0O7xupK737cho88HnW36BA7PKJoDtTh3mf3C+CLsWDdXXe xSx2eH+ROsZbnSoezLUeXFoDVyDeO9k/wzsW7ytKne0N1OCdO7z5qZd6R1mhhnCcHd6ByEK2ddsP me2bKhLNSBcvnJrXoMwPnOte6y53T3APdee6z3X3dHvdae4e7s6eJE+Cp6PnHE+sx+MxPLpH9ZCn c4N5OJDNf8Gws5Eg/jC6zldd3CeofBX//wX+e9UelcZTqJNWqpaWFSqloT1zqHS2L/R1WUaDEjtp RsiVUaiEkkqpdEphaFh2aYPbnBzKyy4NuSdeUr5dUW6vgG9IXdGg0JTyBsVkr5t7hJIuKN9JipJ4 8+oeLPvcvLqiglK6XJufkp80OnF4SVEbl1nyGvHH31NOuU8LrS0tKw9tTasI5fKNmVZRGlpT5ptZ vlM5pnxeXLRT+YJFRflObbRyrHgy+2ujiyoqShuUaSIc+ZQvEA4a84UI58HAzOHI50m3wq2zwmUh PsJlskC4mBjKEuGyYmJEOF3hcNtrMouLtmdmijBdfVQjwtR09UWG2Z+FMFlZIkyXIO0XYfZ3CXKY 0GgRJDUVQdJTRRClO6WKIKlKdxFkWkuQHBlkZTjISpGSprSESbXCxB22w8QdRpjs7/pvbmF2tlI/ smLOzOK5GcWzMornglmh266dnxIKzvb5ts+p4Ae+kOafNXvOfJaXzQ1VZMwtCs3JKPJtHzmzjccz +fHIjKLtNLN4Svn2mYG5RXUjAyOLMy4rqqgfM/G8vFPSWhlO67yJbbxsIr/sPE5rTF4bj/P48RhO K4/TyuO0xgTGiLRI6PjE8u0eKqy4YKYl69UOsdDXWT16VhR2Sbh6tFDekT1TFvfYBWtlC3XIrgid k1EYigP8qH9B/wJ+hDbFjzrCO14+Slk8smePXcoW+SgB3okZhZS96JqaayileEGR9V8N/sFr0TVc 4NY1u+Z0//CsOBS4rKhmEVFpqF9ZaSh/0ozy7W43fGfxJ4VG2H4dOhQ3mHsszwHwHMGemhYOyH6j 2C8mRgZsXf/XSCn+0m1Q3V2vBNKVRVRToYXSS6eo6AqmzMC3zpxRvgu2FA8PNRX4wBolW6mx3yGz bf3FdRb8zTaLrpF3siwWSWnFRJQau0jC/7iwssMltggvpH8BlocGGQplbmRzdHJlYW0KZW5kb2Jq CjM2IDAgb2JqCjw8L0ZvbnRCQm94Wy02NjQgLTMyNCAyMDAwIDEwMDVdL0NhcEhlaWdodCA3MTYv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250RmlsZTIgMzUgMCBSL1N0ZW1WIDgwL0Rlc2NlbnQgLTIx MC9GbGFncyAzMi9Gb250TmFtZS9KUFBRSkkrQXJpYWwvQXNjZW50IDcyOC9JdGFsaWNBbmdsZSAw Pj4KZW5kb2JqCjM3IDAgb2JqCjw8L0Jhc2VGb250L0pQUFFKSStBcmlhbC9DSURTeXN0ZW1JbmZv PDwvT3JkZXJpbmcoSWRlbnRpdHkpL1JlZ2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDA+Pi9XIFsz WzI3N10xMVszMzMgMzMzXTE1WzI3NyAzMzMgMjc3IDI3N10yMFs1NTYgNTU2IDU1Nl0yOVsyNzdd MzRbNTU2XTM2WzY2NiA2NjYgNzIyIDcyMiA2NjYgNjEwIDc3NyA3MjIgMjc3IDUwMF00N1s1NTYg ODMzIDcyMiA3NzcgNjY2XTUzWzcyMiA2NjYgNjEwIDcyMl01OFs5NDNdNjBbNjY2XTY2WzU1Nl02 OFs1NTYgNTU2IDUwMCA1NTYgNTU2IDI3NyA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2 IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc3IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwXTE4MlsyMjJd MzgwWzYwNF00MDRbNjA0XV0vVHlwZS9Gb250L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNj cmlwdG9yIDM2IDAgUi9EVyAxMDAwL0NJRFRvR0lETWFwL0lkZW50aXR5Pj4KZW5kb2JqCjM4IDAg b2JqCjw8L0xlbmd0aCA1NTkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJxdlM3K20AMRfd+ Ci9buog9I80kELRpKWTRH5q0dOuMx8HQOMZxFnn72rqpPqghB3ydEZoj0Obj4dNh6Ody8326pWOe y64f2infb48p5fKcL/1Q1K5s+zS/3pTp2ozFZjl8fN7nfD0M3a3Y78vNj+XjfZ6e5bvT6feH6n2x +Ta1eeqHy5KQ+/lrSY6PcfyTr3mYy6oQKdvcLaW+NOPX5prLjR58C0/PMZdO32t0kG5tvo9NylMz XHKxr5ZH9p+XR4o8tP99Dh6nzt3b370YXSUancXotoiSGN0OUSdGlzSqKzG6FlEtRpcROTG6DhGJ 0deIWIzeIQpi9B5RK0bfaORQWOlR3mlhkFDeaWGQUN5pYZBQ3kUxEiHaipEY0U6MFBA1YqSICD6V BKsuiZFg1bVipNeFOjESRHtVDBJE+1qMBNHeiZFgwnsxMqbtoVjJMOGhWMkw4dUByDDh1QHIMOEb MTKu7fV2IOOO5MTI6ItIjAETIhZjQF8UxBjQF0UxBvRFWzEG9EU7MQZMiBoxBrRKmI0yYEKUxBhe 3bdiDJjQ4tsYzog6MQYMjSsxBgyNdVxgwNDYiTFADnsxRgyNSYwRvpjFGOGLMUFlhC+OYozwxZig MsIX78QY4YsxVGWEL1ZTYIQvxpyVEb5YTYERvs7a0UpX1fqvOq5HlI6TKqx36+2US9TpOvu3t9bN ti5dW5TpMU3LDtXNrJty3ZH9kG15j7dxPVUuv+IvKH5lqgplbmRzdHJlYW0KZW5kb2JqCjMgMCBv YmoKPDwvRGVzY2VuZGFudEZvbnRzWzM3IDAgUl0vQmFzZUZvbnQvSlBQUUpJK0FyaWFsL1R5cGUv Rm9udC9FbmNvZGluZy9JZGVudGl0eS1IL1N1YnR5cGUvVHlwZTAvVG9Vbmljb2RlIDM4IDAgUj4+ CmVuZG9iago1IDAgb2JqCjw8L0lUWFQoMi4xLjYpL1R5cGUvUGFnZXMvQ291bnQgNi9LaWRzWzEg MCBSIDYgMCBSIDggMCBSIDEwIDAgUiAxMiAwIFIgMTUgMCBSXT4+CmVuZG9iagozOSAwIG9iago8 PC9OYW1lc1soaC4xZWk4N2ktbHhna3owKSAxNiAwIFIoaC4ycTJvOW0tOXRxYjI1KSAxNyAwIFIo aC4zYm41cmItZ3VzaGwzKSAxOCAwIFIoaC40ejRrczUtZ3RwaXZyKSAxOSAwIFIoaC44ZG12anUt dWdka3lyKSAyMCAwIFIoaC5hNjBhbm0tYWl5NTh2KSAyMSAwIFIoaC5heXN0bWEtNXJqeTR0KSAy MiAwIFIoaC5jemlkbzgtNnZnYWMxKSAyMyAwIFIoaC5meDk3dnktcGI3eGRsKSAyNCAwIFIoaC5o OTFlemYtdzBoeWl1KSAyNSAwIFIoaC5tamFjNmYta2xiMWp3KSAyNiAwIFIoaC5wZWh0NW0tbHA0 ZG15KSAyNyAwIFIoaC50MWZoM2otNmJiZTMzKSAyOCAwIFIoaC50bHFldmQtZnI0N3Y2KSAyOSAw IFIoaC53ZGFiYXYtdm1wY2V2KSAzMCAwIFJdPj4KZW5kb2JqCjQwIDAgb2JqCjw8L0Rlc3RzIDM5 IDAgUj4+CmVuZG9iago0MSAwIG9iago8PC9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1ML0xlbmd0 aCAyNzcwPj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyI+CjxyZGY6UkRG IHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+ CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcv ZGMvZWxlbWVudHMvMS4xLyI+PGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD48 L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6cGRm PSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj48cGRmOlByb2R1Y2VyPmlUZXh0IDIuMS42 IGJ5IDFUM1hUPC9wZGY6UHJvZHVjZXI+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSIiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyI+ PHhtcDpDcmVhdGVEYXRlPjIwMTEtMDUtMjRUMjA6MzM6MzAtMDc6MDA8L3htcDpDcmVhdGVEYXRl Pjx4bXA6TW9kaWZ5RGF0ZT4yMDExLTA1LTI0VDIwOjMzOjMwLTA3OjAwPC94bXA6TW9kaWZ5RGF0 ZT48eG1wOkNyZWF0b3JUb29sPkRhdmlzb3IgUHVibGlzaG9yIDYuMy40IGJ5IERhdmlzb3IgKGh0 dHA6Ly93d3cuZGF2aXNvci5jb20vKTwveG1wOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9u Pgo8L3JkZjpSREY+PC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/PgplbmRzdHJl YW0KZW5kb2JqCjQyIDAgb2JqCjw8L05hbWVzIDQwIDAgUi9UeXBlL0NhdGFsb2cvTWV0YWRhdGEg NDEgMCBSL1BhZ2VzIDUgMCBSPj4KZW5kb2JqCjQzIDAgb2JqCjw8L0NyZWF0b3IoRGF2aXNvciBQ dWJsaXNob3IgNi4zLjQgYnkgRGF2aXNvciBcKGh0dHA6Ly93d3cuZGF2aXNvci5jb20vXCkpL1By b2R1Y2VyKGlUZXh0IDIuMS42IGJ5IDFUM1hUKS9Nb2REYXRlKEQ6MjAxMTA1MjQyMDMzMzAtMDcn MDAnKS9DcmVhdGlvbkRhdGUoRDoyMDExMDUyNDIwMzMzMC0wNycwMCcpPj4KZW5kb2JqCnhyZWYK MCA0NAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMTE2MzggMDAwMDAgbiAKMDAwMDA2NjUzMCAw MDAwMCBuIAowMDAwMDkzODc0IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDA5NDAw MSAwMDAwMCBuIAowMDAwMDIxMjQ3IDAwMDAwIG4gCjAwMDAwMTE4MDQgMDAwMDAgbiAKMDAwMDAy ODgxMiAwMDAwMCBuIAowMDAwMDIxNDEzIDAwMDAwIG4gCjAwMDAwMzY1NjggMDAwMDAgbiAKMDAw MDAyODk3OCAwMDAwMCBuIAowMDAwMDQxOTg1IDAwMDAwIG4gCjAwMDAwMzY3MzYgMDAwMDAgbiAK MDAwMDA0MjE1MyAwMDAwMCBuIAowMDAwMDQzMzE3IDAwMDAwIG4gCjAwMDAwNDM0NzYgMDAwMDAg biAKMDAwMDA0MzUwNCAwMDAwMCBuIAowMDAwMDQzNTMyIDAwMDAwIG4gCjAwMDAwNDM1NjAgMDAw MDAgbiAKMDAwMDA0MzU4OCAwMDAwMCBuIAowMDAwMDQzNjE3IDAwMDAwIG4gCjAwMDAwNDM2NDYg MDAwMDAgbiAKMDAwMDA0MzY3NCAwMDAwMCBuIAowMDAwMDQzNzAyIDAwMDAwIG4gCjAwMDAwNDM3 MzEgMDAwMDAgbiAKMDAwMDA0Mzc2MCAwMDAwMCBuIAowMDAwMDQzNzg4IDAwMDAwIG4gCjAwMDAw NDM4MTYgMDAwMDAgbiAKMDAwMDA0Mzg0NCAwMDAwMCBuIAowMDAwMDQzODczIDAwMDAwIG4gCjAw MDAwNDM5MDIgMDAwMDAgbiAKMDAwMDA2NTQxMyAwMDAwMCBuIAowMDAwMDY1NjAyIDAwMDAwIG4g CjAwMDAwNjYwMDcgMDAwMDAgbiAKMDAwMDA2NjY2MiAwMDAwMCBuIAowMDAwMDkyNTY5IDAwMDAw IG4gCjAwMDAwOTI3NDkgMDAwMDAgbiAKMDAwMDA5MzI0NyAwMDAwMCBuIAowMDAwMDk0MDk3IDAw MDAwIG4gCjAwMDAwOTQ0ODYgMDAwMDAgbiAKMDAwMDA5NDUyMCAwMDAwMCBuIAowMDAwMDk3MzY2 IDAwMDAwIG4gCjAwMDAwOTc0NDEgMDAwMDAgbiAKdHJhaWxlcgo8PC9Sb290IDQyIDAgUi9JRCBb PGViNzQyNDZmZDQwNTUzOGE2ZWRmNTBhMTg0NmQzM2Q2PjxmZWNjNWM4OTVmYmZlZTM2NDM0NWM5 MDUzNTU0NmMyMD5dL0luZm8gNDMgMCBSL1NpemUgNDQ+PgpzdGFydHhyZWYKOTc2MzYKJSVFT0YK --005045017138bf72b104a41338fb-- From jbufu@janrain.com Tue May 24 23:46: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 2D56FE07CB for ; Tue, 24 May 2011 23:46:09 -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 bUXwzqSBNq5Q for ; Tue, 24 May 2011 23:46:08 -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 5E1D7E07CA for ; Tue, 24 May 2011 23:46:08 -0700 (PDT) Received: by qyk29 with SMTP id 29so2319008qyk.10 for ; Tue, 24 May 2011 23:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janrain.com; s=google; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ffkk4WeG7+TvOvRLFUArNzrf6iFSNHaZ4j8bH8cN1mM=; b=AAkx4kG+han0M+sZhcuEygyEP9SwpCM2dSsFXUO5H9ozGrDrQwPi1wYNCLQeeR5QIG YlpWoqRN4zxO8aJsaBsoRk7lErww/dJV0fLoKS7BGK8RP9RTNY7xZhgFnwfjBQQ+iD5Q XXNWCNFZAp4yOrK9DpZEOO2aHZx3Y0hweSd7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=janrain.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WB90Dr6XGcLSQc+Vq2pfGyfFCZSA8BZj+aN1j3v1pRE0fDztq21+dhP7j/Qt6SJcIx L7Yvk4HjZvEE6spp4HJqTK+E0W3iMcJtH7dU66nRwhT3yY/PfynkNL/HPeR35CYqaVEI VwjuK69vzniH414kOeljqIO/MzxVnOFDweuzk= Received: by 10.229.253.8 with SMTP id my8mr3491647qcb.236.1306305967750; Tue, 24 May 2011 23:46:07 -0700 (PDT) Received: from [10.1.10.22] (173-164-210-118-SFBA.hfc.comcastbusiness.net [173.164.210.118]) by mx.google.com with ESMTPS id s9sm5096866qco.24.2011.05.24.23.46.06 (version=SSLv3 cipher=OTHER); Tue, 24 May 2011 23:46:07 -0700 (PDT) Message-ID: <4DDCA5AD.5080203@janrain.com> Date: Tue, 24 May 2011 23:46:05 -0700 From: Johnny Bufu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Campbell References: <20110513222239.GA1...@paw.local> <877FD20D-A011-4B6D-B025-20E84F2C7...@hueniverse.com> <20110516171834.GE1...@paw.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] unauthenticated token requests X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 06:46:09 -0000 On 37-01--10 11:59 AM, Brian Campbell wrote: > Yeah, I had just sort of being going off the assumption that > client_id is required& client_secret is not but, looking at -15 > again, I agree that it's not entirely obvious. There's the text at > the end of section 3 that say allows for unauthenticated clients. > Then in 3.1 both client_id& client_secret are marked as required. > So, while it says unauthenticated clients are allowed, it's not fully > clear how they are supposed to work or what parameters they should > present. Agreed, this wasn't clear to me either. As someone else pointed out, client_id is introduced in section 3.1; at the same time the whole section 3.1 seems optional due to the MAY at its beginning, and supported by the MAY in section 3.2. Section 3's introduction is ambiguous, specifically this part: For readability purposes only, this specification is written under the assumption that the authorization server requires some form of client authentication. However, such language does not affect the authorization server's discretion in allowing unauthenticated client requests. The language here seems to overrule some of the RFC2119 MUSTs (sections 4.1.3, 4.3.2): The authorization server MUST: o Validate the client credentials But not others that an authentication server that wishes to allow unauthenticated clients may expect -- the client_id/client_secret not being REQUIRED. Johnny From paul.madsen@gmail.com Wed May 25 06:49: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 979F8E072C for ; Wed, 25 May 2011 06:49:58 -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 PtNTx-q8Q2j3 for ; Wed, 25 May 2011 06:49:57 -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 C0B9CE080F for ; Wed, 25 May 2011 06:49:57 -0700 (PDT) Received: by yic13 with SMTP id 13so3887613yic.31 for ; Wed, 25 May 2011 06:49:57 -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 :content-transfer-encoding; bh=/HgDuw7m4OMdKOpQ+s3ZNGH1zabAY7sgkZXOGewV1i8=; b=TrR1REeloff1exY6lraXoHf/vOCaDQYenHJxL1INpg1DNs2kYR3xWN5OBzwUXSW7Md /ZusV2BzSRKd4DKaAXUG3iedMkJlmYHflZdMQ9Yr5vBQFCyqvshZbofhZ7aj1ldt7Qg6 7OquCIFAsfkjpCnk/o5sXyxcmxMUwDVfLYlSg= 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:content-transfer-encoding; b=UYnyFsfBF8XBbBusVhuf7OVgBh8SqLA84+ugTEfDVmbcjp6oo+N9WUPTIUdR/I90S3 evWZf/sda4KXqZSTAe/l7KquwNu8N89nQZRD2erBwIrTMloKawYcNc7eAjlfm0A72LTc PCZN9hUH0zkiEdYqABqDJ+mXrowe/eVry1Wtg= Received: by 10.100.201.3 with SMTP id y3mr6284469anf.13.1306331397120; Wed, 25 May 2011 06:49:57 -0700 (PDT) Received: from pmadsen-mbp.local ([12.185.136.253]) by mx.google.com with ESMTPS id s16sm6259781anj.0.2011.05.25.06.49.53 (version=SSLv3 cipher=OTHER); Wed, 25 May 2011 06:49:54 -0700 (PDT) Message-ID: <4DDD0900.9030507@gmail.com> Date: Wed, 25 May 2011 09:49:52 -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: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 13:49:58 -0000 Mike/George, can you clarify in what sense must a client and RS agree on the format of a bearer token? Are they not opaque to the client, and so their internal format irrelevant to it? paul On 5/24/11 4:04 PM, Mike Jones wrote: > George, you are correct that resources and clients must agree upon the format of the bearer token to achieve interoperability. The means for achieving this agreement is out of the scope of this document. > > -- Mike > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, May 24, 2011 11:28 AM > To: George Fletcher > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] bearer token authorization header > > The "printable non-whitespace ASCII characters" represents the access token, which is supposed to be opaque. I don't think this affects libraries. > > Marius > > > > On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrote: >> Do I understand this correctly that each resource owner can define >> it's own format for the "printable non-whitespace ASCII characters"? >> It seems like that would make it difficult for clients to use standard >> libraries because the Authorization header format could be different >> on a per resource/host basis. >> >> Thanks, >> George >> >> On 5/23/11 3:10 PM, Mike Jones wrote: >> >> [snip] >> >> >> >> The fact that there is no escaping mechanism can potentially create >> problems. The list of allowed characters is spelled out, but what if >> some implementation uses other characters? Using a name value pair and >> proper escaping is much safer IMO. For example: >> >> Bearer token=dfgh76dfghdfg >> >> or >> >> Bearer token="dfgh76dfghdfg" >> >> >> >> The value above can be either a token or a quoted string. HTTP header >> parsers know how to parse tokens and quoted strings so an implementor >> has a better chance of doing it right. >> >> >> >> Mark Lentczner started a thread on this regard a few moths ago, James >> Manger replied and suggested something similar: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >> >> >> >> If it is too late to switch to a name/value pair, then I think we >> should at least clean up the references. >> >> The definition allows the access token to be any string of one or more >> printable non-whitespace ASCII characters. Thus, legal access token >> strings include ones like the ones you are asking for, such as: >> >> param="value" >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 09, 2011 10:32 AM >> To: OAuth WG; Mike Jones >> Cc: Mark Lentczner; Manger, James H >> Subject: bearer token authorization header >> >> >> >> I am working through version 04 of the Bearer Token draft: >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 >> >> >> >> Not sure how to interpret the authorization header grammar described >> in section 2.1. The intent seems to be for something like: >> >> Bearer dfgh76dfghdfg >> >> >> >> After the scheme name, "Bearer", there is a required whitespace >> followed by the actual token. The token is represented by a sequence >> of printable characters, no escaping. No spaces or other elements are >> allowed after the token. Is that correct? >> >> >> >> RWS is not defined, I assume it is the "required whitespace" from >> section >> 1.2.2 of: >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 >> >> >> >> There is a reference to RFC2617, but not sure why. That seems to imply >> that a list of values can be specified, which is not the case. >> >> >> >> The fact that there is no escaping mechanism can potentially create >> problems. The list of allowed characters is spelled out, but what if >> some implementation uses other characters? Using a name value pair and >> proper escaping is much safer IMO. For example: >> >> Bearer token=dfgh76dfghdfg >> >> or >> >> Bearer token="dfgh76dfghdfg" >> >> >> >> The value above can be either a token or a quoted string. HTTP header >> parsers know how to parse tokens and quoted strings so an implementor >> has a better chance of doing it right. >> >> >> >> Mark Lentczner started a thread on this regard a few moths ago, James >> Manger replied and suggested something similar: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >> >> >> >> If it is too late to switch to a name/value pair, then I think we >> should at least clean up the references. >> >> >> >> 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 bcampbell@pingidentity.com Wed May 25 06:54: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 D0394E074E for ; Wed, 25 May 2011 06:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 xCOZI5btScEU for ; Wed, 25 May 2011 06:54:40 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 2636EE0721 for ; Wed, 25 May 2011 06:54:38 -0700 (PDT) Received: from mail-vw0-f48.google.com ([209.85.212.48]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTd0KHgzkbUsu8dq4/u+UxFlAwVEA5rCF@postini.com; Wed, 25 May 2011 06:54:39 PDT Received: by mail-vw0-f48.google.com with SMTP id 7so8191209vws.21 for ; Wed, 25 May 2011 06:54:38 -0700 (PDT) Received: by 10.52.181.164 with SMTP id dx4mr4851608vdc.183.1306331678102; Wed, 25 May 2011 06:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.113.225 with HTTP; Wed, 25 May 2011 06:54:08 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 May 2011 07:54:08 -0600 Message-ID: To: Anthony Nadalin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 13:54:40 -0000 That is another way to approach it and I understand there has been some talk about that lately. While there are admittedly some commonalities between assertion based grants and an HTTP parameter based client authentication extension point, I personally think that lumping them together is unnecessarily confusing. It is also a more significant change and it seems like, at this point in the process, it might be better to aim for more concise and targeted changes. On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin wr= ote: > I think that this will be better moved into a separate document on assert= ions (were both authorization and authentication are talked about) and not = to include in 4.5.1 but would like to see a reference in 4.5.1 to the new d= ocument > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Brian Campbell > Sent: Tuesday, May 24, 2011 7:25 AM > To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsect= ion on assertions > > One of the action items out of yesterday's meeting was to draft some text= for a section 4.5.1 in core that defined the optional but recommended use = of an "assertion" parameter for extension grants where the use of a single = parameter to carry the grant/assertion was possible. =A0Below is a first cu= t at some proposed text that hopefully avoids some of the awkwardness that = EHL described in previous attempts to introduce such a parameter. =A0Commen= ts or edits or editorial improvements are, of course, welcome. =A0But I thi= nk this hopefully captures the intent of what was discussed yesterday (and = before). > > If we get some consensus to make this change, I think a couple of other a= ctions are implied. > > - The IANA assertion parameter registration request > (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4.1) > should be removed from the SAML draft and put into > http://tools.ietf.org/html/draft-ietf-oauth-v2 > > - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec wil= l change the parameter it uses from jwt to assertion and drop the registrat= ion request for jwt > (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4.1) > > > --- proposed text for sections 4.5 & 4.5.1 --- > > 4.5. Extensions > > =A0 The client uses an extension grant type by specifying the grant type > =A0 using an absolute URI (defined by the authorization server) as the > =A0 value of the "grant_type" parameter of the token endpoint, and by > =A0 adding any additional parameters necessary. > > =A0 If the access token request is valid and authorized, the > =A0 authorization server issues an access token and optional refresh > =A0 token as described in Section 5.1. =A0If the request failed client > =A0 authentication or is invalid, the authorization server returns an > =A0 error response as described in Section 5.2. > > 4.5.1 Assertion Based Extension Grants > > =A0If the value of the extension grant can be serialized into a single > =A0parameter, as is case with a number of assertion formats, it is > =A0RECOMMENDED that that a parameter named "assertion" be used to > =A0carry the value. > > =A0 assertion > =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding of th= e > =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization server = or > =A0 =A0 =A0 =A0 =A0 =A0 extension specification. > > =A0 For example, to request an access token using a SAML 2.0 assertion > =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client > =A0 makes the following HTTP request using transport-layer security (line > =A0 breaks are for display purposes only): > > =A0 POST /token HTTP/1.1 > =A0 Host: server.example.com > =A0 Content-Type: application/x-www-form-urlencoded > > =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F > =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM > =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > From tonynad@microsoft.com Wed May 25 10:07: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 46F8CE071B for ; Wed, 25 May 2011 10:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.333 X-Spam-Level: X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, 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 FcrcuxVIoL02 for ; Wed, 25 May 2011 10:07:48 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6357EE06ED for ; Wed, 25 May 2011 10:07:48 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 10:07:48 -0700 Received: from CH1EHSOBE016.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, 25 May 2011 10:07:47 -0700 Received: from mail199-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 May 2011 17:07:46 +0000 Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1-R.bigfish.com (Postfix) with ESMTP id 908BD1320089 for ; Wed, 25 May 2011 17:07:46 +0000 (UTC) X-SpamScore: -51 X-BigFish: PS-51(zzbb2cK9371O542M1418M1432N98dKzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail199-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=CH1PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1 (MessageSwitch) id 1306343266266794_7277; Wed, 25 May 2011 17:07:46 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail199-ch1.bigfish.com (Postfix) with ESMTP id 35CCD17F0055; Wed, 25 May 2011 17:07:46 +0000 (UTC) Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 25 May 2011 17:07:40 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.222]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.052; Wed, 25 May 2011 17:07:39 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: AQHMGuNOl7EkQhqD8kiarpjrGXDWA5Sdxeew Date: Wed, 25 May 2011 17:07:39 +0000 Message-ID: References: In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%PINGIDENTITY.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 Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 17:07:49 -0000 In our case they are tightly bound as the assertions (same assertion) will = be used for authentication and also to grant authorization as this is what = was in scope with WRAP, so not addressing the assertion authentication is a= n issue for us and I assume others also.=20 -----Original Message----- From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Wednesday, May 25, 2011 6:54 AM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subse= ction on assertions That is another way to approach it and I understand there has been some tal= k about that lately. While there are admittedly some commonalities between= assertion based grants and an HTTP parameter based client authentication e= xtension point, I personally think that lumping them together is unnecessarily confusing. It is also a more significant change and it seems like, at this point in the process, it migh= t be better to aim for more concise and targeted changes. On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin wr= ote: > I think that this will be better moved into a separate document on=20 > assertions (were both authorization and authentication are talked=20 > about) and not to include in 4.5.1 but would like to see a reference=20 > in 4.5.1 to the new document > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Brian Campbell > Sent: Tuesday, May 24, 2011 7:25 AM > To: oauth > Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1=20 > subsection on assertions > > One of the action items out of yesterday's meeting was to draft some text= for a section 4.5.1 in core that defined the optional but recommended use = of an "assertion" parameter for extension grants where the use of a single = parameter to carry the grant/assertion was possible. =A0Below is a first cu= t at some proposed text that hopefully avoids some of the awkwardness that = EHL described in previous attempts to introduce such a parameter. =A0Commen= ts or edits or editorial improvements are, of course, welcome. =A0But I thi= nk this hopefully captures the intent of what was discussed yesterday (and = before). > > If we get some consensus to make this change, I think a couple of other a= ctions are implied. > > - The IANA assertion parameter registration request > (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4 > .1) should be removed from the SAML draft and put into > http://tools.ietf.org/html/draft-ietf-oauth-v2 > > - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec=20 > will change the parameter it uses from jwt to assertion and drop the=20 > registration request for jwt > (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4. > 1) > > > --- proposed text for sections 4.5 & 4.5.1 --- > > 4.5. Extensions > > =A0 The client uses an extension grant type by specifying the grant type > =A0 using an absolute URI (defined by the authorization server) as the > =A0 value of the "grant_type" parameter of the token endpoint, and by > =A0 adding any additional parameters necessary. > > =A0 If the access token request is valid and authorized, the > =A0 authorization server issues an access token and optional refresh > =A0 token as described in Section 5.1. =A0If the request failed client > =A0 authentication or is invalid, the authorization server returns an > =A0 error response as described in Section 5.2. > > 4.5.1 Assertion Based Extension Grants > > =A0If the value of the extension grant can be serialized into a single > =A0parameter, as is case with a number of assertion formats, it is > =A0RECOMMENDED that that a parameter named "assertion" be used to > =A0carry the value. > > =A0 assertion > =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding of th= e > =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization server = or > =A0 =A0 =A0 =A0 =A0 =A0 extension specification. > > =A0 For example, to request an access token using a SAML 2.0 assertion > =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client > =A0 makes the following HTTP request using transport-layer security=20 > (line > =A0 breaks are for display purposes only): > > =A0 POST /token HTTP/1.1 > =A0 Host: server.example.com > =A0 Content-Type: application/x-www-form-urlencoded > > =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F > =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM > =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > From john@jkemp.net Wed May 25 10: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 6A53F130032 for ; Wed, 25 May 2011 10:10:39 -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 LBxMxPMfgY1E for ; Wed, 25 May 2011 10:10:38 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 9C297E070F for ; Wed, 25 May 2011 10:10:38 -0700 (PDT) Received: (qmail 15618 invoked by uid 0); 25 May 2011 17:10:38 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 25 May 2011 17:10:38 -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=axrlGV99BnIlfo9aeb0m4mJXwkx2GahKTeX11w3MQKO5bjp1cGs1S7L7ZUESksKp2/+S71i6DFDkXY+r6Rs/+r641BsL4hGAgW8YRMO53EkgwZOnFNBLpxtYz8XgLe2n; Received: from c-107-3-99-170.hsd1.vt.comcast.net ([107.3.99.170] helo=dmn.lonerganthomas.com) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QPHbR-0003iG-HL; Wed, 25 May 2011 11:10:37 -0600 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> Date: Wed, 25 May 2011 13:10:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 107.3.99.170 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 17:10:39 -0000 On May 24, 2011, at 4:04 PM, Mike Jones wrote: > George, you are correct that resources and clients must agree upon the = format of the bearer token to achieve interoperability. The means for = achieving this agreement is out of the scope of this document. I thought the means for achieving IOP was quite precisely described in = the production below (excerpted from 2.1 of = http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04): credentials =3D "Bearer" RWS access-token access-token =3D 1*( quoted-char / <"> ) quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" - John >=20 > -- Mike >=20 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Tuesday, May 24, 2011 11:28 AM > To: George Fletcher > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] bearer token authorization header >=20 > The "printable non-whitespace ASCII characters" represents the access = token, which is supposed to be opaque. I don't think this affects = libraries. >=20 > Marius >=20 >=20 >=20 > On Tue, May 24, 2011 at 10:24 AM, George Fletcher = wrote: >> Do I understand this correctly that each resource owner can define=20 >> it's own format for the "printable non-whitespace ASCII characters"?=20= >> It seems like that would make it difficult for clients to use = standard=20 >> libraries because the Authorization header format could be different=20= >> on a per resource/host basis. >>=20 >> Thanks, >> George >>=20 >> On 5/23/11 3:10 PM, Mike Jones wrote: >>=20 >> [snip] >>=20 >>=20 >>=20 >> The fact that there is no escaping mechanism can potentially create=20= >> problems. The list of allowed characters is spelled out, but what if=20= >> some implementation uses other characters? Using a name value pair = and=20 >> proper escaping is much safer IMO. For example: >>=20 >> Bearer token=3Ddfgh76dfghdfg >>=20 >> or >>=20 >> Bearer token=3D"dfgh76dfghdfg" >>=20 >>=20 >>=20 >> The value above can be either a token or a quoted string. HTTP header=20= >> parsers know how to parse tokens and quoted strings so an implementor=20= >> has a better chance of doing it right. >>=20 >>=20 >>=20 >> Mark Lentczner started a thread on this regard a few moths ago, James=20= >> Manger replied and suggested something similar: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>=20 >>=20 >>=20 >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >>=20 >> The definition allows the access token to be any string of one or = more=20 >> printable non-whitespace ASCII characters. Thus, legal access token=20= >> strings include ones like the ones you are asking for, such as: >>=20 >> param=3D"value" >>=20 >>=20 >>=20 >> -- Mike >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 09, 2011 10:32 AM >> To: OAuth WG; Mike Jones >> Cc: Mark Lentczner; Manger, James H >> Subject: bearer token authorization header >>=20 >>=20 >>=20 >> I am working through version 04 of the Bearer Token draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 >>=20 >>=20 >>=20 >> Not sure how to interpret the authorization header grammar described=20= >> in section 2.1. The intent seems to be for something like: >>=20 >> Bearer dfgh76dfghdfg >>=20 >>=20 >>=20 >> After the scheme name, "Bearer", there is a required whitespace=20 >> followed by the actual token. The token is represented by a sequence=20= >> of printable characters, no escaping. No spaces or other elements are=20= >> allowed after the token. Is that correct? >>=20 >>=20 >>=20 >> RWS is not defined, I assume it is the "required whitespace" from=20 >> section >> 1.2.2 of: >>=20 >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 >>=20 >>=20 >>=20 >> There is a reference to RFC2617, but not sure why. That seems to = imply=20 >> that a list of values can be specified, which is not the case. >>=20 >>=20 >>=20 >> The fact that there is no escaping mechanism can potentially create=20= >> problems. The list of allowed characters is spelled out, but what if=20= >> some implementation uses other characters? Using a name value pair = and=20 >> proper escaping is much safer IMO. For example: >>=20 >> Bearer token=3Ddfgh76dfghdfg >>=20 >> or >>=20 >> Bearer token=3D"dfgh76dfghdfg" >>=20 >>=20 >>=20 >> The value above can be either a token or a quoted string. HTTP header=20= >> parsers know how to parse tokens and quoted strings so an implementor=20= >> has a better chance of doing it right. >>=20 >>=20 >>=20 >> Mark Lentczner started a thread on this regard a few moths ago, James=20= >> Manger replied and suggested something similar: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>=20 >>=20 >>=20 >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >>=20 >>=20 >>=20 >> Marius >>=20 >>=20 >>=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 From Michael.Jones@microsoft.com Wed May 25 10:13: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 0F667E068C for ; Wed, 25 May 2011 10:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.799 X-Spam-Level: X-Spam-Status: No, score=-10.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 3TZgbKqBBg2t for ; Wed, 25 May 2011 10:13:03 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 248FE130053 for ; Wed, 25 May 2011 10:13:03 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 10:13:02 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0289.008; Wed, 25 May 2011 10:13:02 -0700 From: Mike Jones To: Paul Madsen , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] bearer token authorization header Thread-Index: AQHMDm8eraLFxPaXk06szRXCsxzqaJSa20EggAHsNACAABGYAP//pZSwgAGfFwD//8LyIA== Date: Wed, 25 May 2011 17:13:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394338100BE8@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDD0900.9030507@gmail.com> In-Reply-To: <4DDD0900.9030507@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 17:13:04 -0000 You're correct that I misspoke. The Authorization Server and the Resource = Server must agree on the format of the token. Yes, it's opaque to the clie= nt. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Wednesday, May 25, 2011 6:50 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] bearer token authorization header Mike/George, can you clarify in what sense must a client and RS agree on th= e format of a bearer token? Are they not opaque to the client, and so their= internal format irrelevant to it? paul On 5/24/11 4:04 PM, Mike Jones wrote: > George, you are correct that resources and clients must agree upon the fo= rmat of the bearer token to achieve interoperability. The means for achiev= ing this agreement is out of the scope of this document. > > -- Mike > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, May 24, 2011 11:28 AM > To: George Fletcher > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] bearer token authorization header > > The "printable non-whitespace ASCII characters" represents the access tok= en, which is supposed to be opaque. I don't think this affects libraries. > > Marius > > > > On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrot= e: >> Do I understand this correctly that each resource owner can define=20 >> it's own format for the "printable non-whitespace ASCII characters"? >> It seems like that would make it difficult for clients to use=20 >> standard libraries because the Authorization header format could be=20 >> different on a per resource/host basis. >> >> Thanks, >> George >> >> On 5/23/11 3:10 PM, Mike Jones wrote: >> >> [snip] >> >> >> >> The fact that there is no escaping mechanism can potentially create=20 >> problems. The list of allowed characters is spelled out, but what if=20 >> some implementation uses other characters? Using a name value pair=20 >> and proper escaping is much safer IMO. For example: >> >> Bearer token=3Ddfgh76dfghdfg >> >> or >> >> Bearer token=3D"dfgh76dfghdfg" >> >> >> >> The value above can be either a token or a quoted string. HTTP header=20 >> parsers know how to parse tokens and quoted strings so an implementor=20 >> has a better chance of doing it right. >> >> >> >> Mark Lentczner started a thread on this regard a few moths ago, James=20 >> Manger replied and suggested something similar: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >> >> >> >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >> >> The definition allows the access token to be any string of one or=20 >> more printable non-whitespace ASCII characters. Thus, legal access=20 >> token strings include ones like the ones you are asking for, such as: >> >> param=3D"value" >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 09, 2011 10:32 AM >> To: OAuth WG; Mike Jones >> Cc: Mark Lentczner; Manger, James H >> Subject: bearer token authorization header >> >> >> >> I am working through version 04 of the Bearer Token draft: >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 >> >> >> >> Not sure how to interpret the authorization header grammar described=20 >> in section 2.1. The intent seems to be for something like: >> >> Bearer dfgh76dfghdfg >> >> >> >> After the scheme name, "Bearer", there is a required whitespace=20 >> followed by the actual token. The token is represented by a sequence=20 >> of printable characters, no escaping. No spaces or other elements are=20 >> allowed after the token. Is that correct? >> >> >> >> RWS is not defined, I assume it is the "required whitespace" from=20 >> section >> 1.2.2 of: >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 >> >> >> >> There is a reference to RFC2617, but not sure why. That seems to=20 >> imply that a list of values can be specified, which is not the case. >> >> >> >> The fact that there is no escaping mechanism can potentially create=20 >> problems. The list of allowed characters is spelled out, but what if=20 >> some implementation uses other characters? Using a name value pair=20 >> and proper escaping is much safer IMO. For example: >> >> Bearer token=3Ddfgh76dfghdfg >> >> or >> >> Bearer token=3D"dfgh76dfghdfg" >> >> >> >> The value above can be either a token or a quoted string. HTTP header=20 >> parsers know how to parse tokens and quoted strings so an implementor=20 >> has a better chance of doing it right. >> >> >> >> Mark Lentczner started a thread on this regard a few moths ago, James=20 >> Manger replied and suggested something similar: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >> >> >> >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >> >> >> >> 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 Michael.Jones@microsoft.com Wed May 25 10:15: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 0D7FE130053 for ; Wed, 25 May 2011 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.765 X-Spam-Level: X-Spam-Status: No, score=-10.765 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 JbJm-i1DQC0f for ; Wed, 25 May 2011 10:15:29 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 32A79E068C for ; Wed, 25 May 2011 10:15:29 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 10:15:28 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Wed, 25 May 2011 10:15:28 -0700 From: Mike Jones To: John Kemp Thread-Topic: [OAUTH-WG] bearer token authorization header Thread-Index: AQHMDm8eraLFxPaXk06szRXCsxzqaJSa20EggAHsNACAABGYAP//pZSwgAHXK4D//4uqkA== Date: Wed, 25 May 2011 17:15:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.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.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 17:15:30 -0000 What you quoted below was the acceptable syntax. The Authorization Server = and the Resource Server still need to agree upon the semantics of the beare= r token exchanged. -- Mike -----Original Message----- From: John Kemp [mailto:john@jkemp.net]=20 Sent: Wednesday, May 25, 2011 10:11 AM To: Mike Jones Cc: Marius Scurtescu; George Fletcher; OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header On May 24, 2011, at 4:04 PM, Mike Jones wrote: > George, you are correct that resources and clients must agree upon the fo= rmat of the bearer token to achieve interoperability. The means for achiev= ing this agreement is out of the scope of this document. I thought the means for achieving IOP was quite precisely described in the = production below (excerpted from 2.1 of http://tools.ietf.org/html/draft-ie= tf-oauth-v2-bearer-04): credentials =3D "Bearer" RWS access-token access-token =3D 1*( quoted-char / <"> ) quoted-char =3D "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" - John >=20 > -- Mike >=20 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, May 24, 2011 11:28 AM > To: George Fletcher > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] bearer token authorization header >=20 > The "printable non-whitespace ASCII characters" represents the access tok= en, which is supposed to be opaque. I don't think this affects libraries. >=20 > Marius >=20 >=20 >=20 > On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrot= e: >> Do I understand this correctly that each resource owner can define=20 >> it's own format for the "printable non-whitespace ASCII characters"? >> It seems like that would make it difficult for clients to use=20 >> standard libraries because the Authorization header format could be=20 >> different on a per resource/host basis. >>=20 >> Thanks, >> George >>=20 >> On 5/23/11 3:10 PM, Mike Jones wrote: >>=20 >> [snip] >>=20 >>=20 >>=20 >> The fact that there is no escaping mechanism can potentially create=20 >> problems. The list of allowed characters is spelled out, but what if=20 >> some implementation uses other characters? Using a name value pair=20 >> and proper escaping is much safer IMO. For example: >>=20 >> Bearer token=3Ddfgh76dfghdfg >>=20 >> or >>=20 >> Bearer token=3D"dfgh76dfghdfg" >>=20 >>=20 >>=20 >> The value above can be either a token or a quoted string. HTTP header=20 >> parsers know how to parse tokens and quoted strings so an implementor=20 >> has a better chance of doing it right. >>=20 >>=20 >>=20 >> Mark Lentczner started a thread on this regard a few moths ago, James=20 >> Manger replied and suggested something similar: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>=20 >>=20 >>=20 >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >>=20 >> The definition allows the access token to be any string of one or=20 >> more printable non-whitespace ASCII characters. Thus, legal access=20 >> token strings include ones like the ones you are asking for, such as: >>=20 >> param=3D"value" >>=20 >>=20 >>=20 >> -- Mike >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 09, 2011 10:32 AM >> To: OAuth WG; Mike Jones >> Cc: Mark Lentczner; Manger, James H >> Subject: bearer token authorization header >>=20 >>=20 >>=20 >> I am working through version 04 of the Bearer Token draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 >>=20 >>=20 >>=20 >> Not sure how to interpret the authorization header grammar described=20 >> in section 2.1. The intent seems to be for something like: >>=20 >> Bearer dfgh76dfghdfg >>=20 >>=20 >>=20 >> After the scheme name, "Bearer", there is a required whitespace=20 >> followed by the actual token. The token is represented by a sequence=20 >> of printable characters, no escaping. No spaces or other elements are=20 >> allowed after the token. Is that correct? >>=20 >>=20 >>=20 >> RWS is not defined, I assume it is the "required whitespace" from=20 >> section >> 1.2.2 of: >>=20 >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 >>=20 >>=20 >>=20 >> There is a reference to RFC2617, but not sure why. That seems to=20 >> imply that a list of values can be specified, which is not the case. >>=20 >>=20 >>=20 >> The fact that there is no escaping mechanism can potentially create=20 >> problems. The list of allowed characters is spelled out, but what if=20 >> some implementation uses other characters? Using a name value pair=20 >> and proper escaping is much safer IMO. For example: >>=20 >> Bearer token=3Ddfgh76dfghdfg >>=20 >> or >>=20 >> Bearer token=3D"dfgh76dfghdfg" >>=20 >>=20 >>=20 >> The value above can be either a token or a quoted string. HTTP header=20 >> parsers know how to parse tokens and quoted strings so an implementor=20 >> has a better chance of doing it right. >>=20 >>=20 >>=20 >> Mark Lentczner started a thread on this regard a few moths ago, James=20 >> Manger replied and suggested something similar: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>=20 >>=20 >>=20 >> If it is too late to switch to a name/value pair, then I think we=20 >> should at least clean up the references. >>=20 >>=20 >>=20 >> Marius >>=20 >>=20 >>=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 From bcampbell@pingidentity.com Wed May 25 12:22: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 BF2B21300B8 for ; Wed, 25 May 2011 12:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 Dmyz7Q09cbEy for ; Wed, 25 May 2011 12:22:48 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 641AD130077 for ; Wed, 25 May 2011 12:22:48 -0700 (PDT) Received: from mail-qw0-f41.google.com ([209.85.216.41]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTd1XB+kc1GxFGY32Q+0sVyiPpWpgU4Uy@postini.com; Wed, 25 May 2011 12:22:48 PDT Received: by qwa26 with SMTP id 26so25916qwa.0 for ; Wed, 25 May 2011 12:22:47 -0700 (PDT) Received: by 10.224.26.211 with SMTP id f19mr4222319qac.328.1306351367283; Wed, 25 May 2011 12:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.148 with HTTP; Wed, 25 May 2011 12:22:17 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 25 May 2011 13:22:17 -0600 Message-ID: To: Anthony Nadalin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 19:22:49 -0000 It's not exactly clear to me what that means. Near the end of the interim meeting on Monday there was a specific discussion that resulted in a TODO item to draft a 4.5.1 subsection. That's what I've done here and I believe it captures the intent discussed at the meeting. I've written a small proposal for specific text to be included in the core specification and described the subsequent changes (simplifications actually) that would follow in companion specification. I've made a specific and actionable proposal. I'm happy to discuss the merits of the proposal and if the WG should accept it or not. If you feel that your proposal of a separate document is more appropriate, I'd suggest you actually write such a document and describe how it impacts existing drafts so that it can be reviewed and discussed. My understanding (Chairs, correct me if I'm wrong) is that such a document would need to be accepted as a working group item in order to be referenced from draft-ietf-oauth-v2 or used/referenced by draft-ietf-oauth-saml2. On Wed, May 25, 2011 at 11:07 AM, Anthony Nadalin w= rote: > In our case they are tightly bound as the assertions (same assertion) wil= l be used for authentication and also to grant authorization as this is wha= t was in scope with WRAP, so not addressing the assertion authentication is= an issue for us and I assume others also. > > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, May 25, 2011 6:54 AM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 sub= section on assertions > > That is another way to approach it and I understand there has been some t= alk about that lately. =A0While there are admittedly some commonalities bet= ween assertion based grants and an HTTP parameter based client authenticati= on extension point, I personally think that > lumping them together is unnecessarily confusing. =A0 It is also a more > significant change and it seems like, at this point in the process, it mi= ght be better to aim for more concise and targeted changes. > > > On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin = wrote: >> I think that this will be better moved into a separate document on >> assertions (were both authorization and authentication are talked >> about) and not to include in 4.5.1 but would like to see a reference >> in 4.5.1 to the new document >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Tuesday, May 24, 2011 7:25 AM >> To: oauth >> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 >> subsection on assertions >> >> One of the action items out of yesterday's meeting was to draft some tex= t for a section 4.5.1 in core that defined the optional but recommended use= of an "assertion" parameter for extension grants where the use of a single= parameter to carry the grant/assertion was possible. =A0Below is a first c= ut at some proposed text that hopefully avoids some of the awkwardness that= EHL described in previous attempts to introduce such a parameter. =A0Comme= nts or edits or editorial improvements are, of course, welcome. =A0But I th= ink this hopefully captures the intent of what was discussed yesterday (and= before). >> >> If we get some consensus to make this change, I think a couple of other = actions are implied. >> >> - The IANA assertion parameter registration request >> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-4 >> .1) should be removed from the SAML draft and put into >> http://tools.ietf.org/html/draft-ietf-oauth-v2 >> >> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec >> will change the parameter it uses from jwt to assertion and drop the >> registration request for jwt >> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4. >> 1) >> >> >> --- proposed text for sections 4.5 & 4.5.1 --- >> >> 4.5. Extensions >> >> =A0 The client uses an extension grant type by specifying the grant type >> =A0 using an absolute URI (defined by the authorization server) as the >> =A0 value of the "grant_type" parameter of the token endpoint, and by >> =A0 adding any additional parameters necessary. >> >> =A0 If the access token request is valid and authorized, the >> =A0 authorization server issues an access token and optional refresh >> =A0 token as described in Section 5.1. =A0If the request failed client >> =A0 authentication or is invalid, the authorization server returns an >> =A0 error response as described in Section 5.2. >> >> 4.5.1 Assertion Based Extension Grants >> >> =A0If the value of the extension grant can be serialized into a single >> =A0parameter, as is case with a number of assertion formats, it is >> =A0RECOMMENDED that that a parameter named "assertion" be used to >> =A0carry the value. >> >> =A0 assertion >> =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding of t= he >> =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization server= or >> =A0 =A0 =A0 =A0 =A0 =A0 extension specification. >> >> =A0 For example, to request an access token using a SAML 2.0 assertion >> =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client >> =A0 makes the following HTTP request using transport-layer security >> (line >> =A0 breaks are for display purposes only): >> >> =A0 POST /token HTTP/1.1 >> =A0 Host: server.example.com >> =A0 Content-Type: application/x-www-form-urlencoded >> >> =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F >> =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM >> =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > > > From bcampbell@pingidentity.com Wed May 25 14:12: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 830D3E06E5 for ; Wed, 25 May 2011 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.024, 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 wdTOCV4Zw3yQ for ; Wed, 25 May 2011 14:12:41 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9DE0724 for ; Wed, 25 May 2011 14:12:40 -0700 (PDT) Received: from mail-qw0-f47.google.com ([209.85.216.47]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTd1wxzme5EMAk6jPB/0SPdKSm/hKxrso@postini.com; Wed, 25 May 2011 14:12:40 PDT Received: by mail-qw0-f47.google.com with SMTP id 5so71906qwh.20 for ; Wed, 25 May 2011 14:12:39 -0700 (PDT) Received: by 10.224.26.211 with SMTP id f19mr21725qac.328.1306357959158; Wed, 25 May 2011 14:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.148 with HTTP; Wed, 25 May 2011 14:12:09 -0700 (PDT) From: Brian Campbell Date: Wed, 25 May 2011 15:12:09 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] treatment of client_id in extension grant_types? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 21:12:41 -0000 Currently (draft -16) client_id is listed as a required parameter for access token request to the token endpoint for all grant types except for extensions. In section 3 there is some disposition of the use of client_id as a means of identification and then, in 3.2, a requirement that client authentication mechanisms must "define a mapping between the client identifier and the credentials used to authenticate." Does this imply that, if client authentication is done at the token endpoint for any extension grant, that the client_id parameter is also required? If so, perhaps it could be made more explicit somewhere in section 3 or section 5. I remember that there was some consensus a while back that client identification/authentication should be optional for the extensions, and that makes sense. But when authentication is done, it seems like it should be consistent with the way the other grants do it - that allows for implementations to have a cleaner separation between client authentication and grant processing. From tonynad@microsoft.com Wed May 25 15:03: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 ECD4EE06A3 for ; Wed, 25 May 2011 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.333 X-Spam-Level: X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, 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 nSq9x9zKwRef for ; Wed, 25 May 2011 15:03:37 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id F0C70E0680 for ; Wed, 25 May 2011 15:03:36 -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; Wed, 25 May 2011 15:03:36 -0700 Received: from CH1EHSOBE005.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 25 May 2011 15:03:36 -0700 Received: from mail133-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 May 2011 22:03:35 +0000 Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1-R.bigfish.com (Postfix) with ESMTP id 74D41A480DB for ; Wed, 25 May 2011 22:03:35 +0000 (UTC) X-SpamScore: -48 X-BigFish: PS-48(zz9371O542M1418M1432N98dKzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail133-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=CH1PRD0302HT004.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1 (MessageSwitch) id 13063610158371_30795; Wed, 25 May 2011 22:03:35 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail133-ch1.bigfish.com (Postfix) with ESMTP id E94AF3D804E; Wed, 25 May 2011 22:03:34 +0000 (UTC) Received: from CH1PRD0302HT004.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, 25 May 2011 22:03:31 +0000 Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.33]) by CH1PRD0302HT004.namprd03.prod.outlook.com ([10.28.29.123]) with mapi id 14.01.0225.052; Wed, 25 May 2011 22:03:30 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: AQHMGuNOl7EkQhqD8kiarpjrGXDWA5SdxeewgAAmcICAAAdtAA== Date: Wed, 25 May 2011 22:03:29 +0000 Message-ID: References: In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%PINGIDENTITY.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: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 25 May 2011 22:03:38 -0000 So the separate document was already discussed in the design team and in th= e meeting on Monday, the action item was given to look at creating a separa= te document for assertion covering authentication and authorization. -----Original Message----- From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Wednesday, May 25, 2011 12:22 PM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subse= ction on assertions It's not exactly clear to me what that means. Near the end of the interim meeting on Monday there was a specific discussi= on that resulted in a TODO item to draft a 4.5.1 subsection. That's what I've done here and I believe it captures the intent discussed a= t the meeting. I've written a small proposal for specific text to be inclu= ded in the core specification and described the subsequent changes (simplif= ications actually) that would follow in companion specification. I've made a specific and actionable proposal. I'm happy to discuss the mer= its of the proposal and if the WG should accept it or not. If you feel that your proposal of a separate document is more appropriate, = I'd suggest you actually write such a document and describe how it impacts = existing drafts so that it can be reviewed and discussed. My understanding = (Chairs, correct me if I'm wrong) is that such a document would need to be = accepted as a working group item in order to be referenced from draft-ietf-= oauth-v2 or used/referenced by draft-ietf-oauth-saml2. On Wed, May 25, 2011 at 11:07 AM, Anthony Nadalin w= rote: > In our case they are tightly bound as the assertions (same assertion) wil= l be used for authentication and also to grant authorization as this is wha= t was in scope with WRAP, so not addressing the assertion authentication is= an issue for us and I assume others also. > > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, May 25, 2011 6:54 AM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1=20 > subsection on assertions > > That is another way to approach it and I understand there has been=20 > some talk about that lately. =A0While there are admittedly some=20 > commonalities between assertion based grants and an HTTP parameter based = client authentication extension point, I personally think that lumping them= together is unnecessarily confusing. =A0 It is also a more significant cha= nge and it seems like, at this point in the process, it might be better to = aim for more concise and targeted changes. > > > On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin = wrote: >> I think that this will be better moved into a separate document on=20 >> assertions (were both authorization and authentication are talked >> about) and not to include in 4.5.1 but would like to see a reference=20 >> in 4.5.1 to the new document >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Brian Campbell >> Sent: Tuesday, May 24, 2011 7:25 AM >> To: oauth >> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1=20 >> subsection on assertions >> >> One of the action items out of yesterday's meeting was to draft some tex= t for a section 4.5.1 in core that defined the optional but recommended use= of an "assertion" parameter for extension grants where the use of a single= parameter to carry the grant/assertion was possible. =A0Below is a first c= ut at some proposed text that hopefully avoids some of the awkwardness that= EHL described in previous attempts to introduce such a parameter. =A0Comme= nts or edits or editorial improvements are, of course, welcome. =A0But I th= ink this hopefully captures the intent of what was discussed yesterday (and= before). >> >> If we get some consensus to make this change, I think a couple of other = actions are implied. >> >> - The IANA assertion parameter registration request >> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section- >> 4 >> .1) should be removed from the SAML draft and put into >> http://tools.ietf.org/html/draft-ietf-oauth-v2 >> >> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec=20 >> will change the parameter it uses from jwt to assertion and drop the=20 >> registration request for jwt=20 >> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4. >> 1) >> >> >> --- proposed text for sections 4.5 & 4.5.1 --- >> >> 4.5. Extensions >> >> =A0 The client uses an extension grant type by specifying the grant=20 >> type >> =A0 using an absolute URI (defined by the authorization server) as the >> =A0 value of the "grant_type" parameter of the token endpoint, and by >> =A0 adding any additional parameters necessary. >> >> =A0 If the access token request is valid and authorized, the >> =A0 authorization server issues an access token and optional refresh >> =A0 token as described in Section 5.1. =A0If the request failed client >> =A0 authentication or is invalid, the authorization server returns an >> =A0 error response as described in Section 5.2. >> >> 4.5.1 Assertion Based Extension Grants >> >> =A0If the value of the extension grant can be serialized into a single >> =A0parameter, as is case with a number of assertion formats, it is >> =A0RECOMMENDED that that a parameter named "assertion" be used to >> =A0carry the value. >> >> =A0 assertion >> =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding of t= he >> =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization server= or >> =A0 =A0 =A0 =A0 =A0 =A0 extension specification. >> >> =A0 For example, to request an access token using a SAML 2.0 assertion >> =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client >> =A0 makes the following HTTP request using transport-layer security=20 >> (line >> =A0 breaks are for display purposes only): >> >> =A0 POST /token HTTP/1.1 >> =A0 Host: server.example.com >> =A0 Content-Type: application/x-www-form-urlencoded >> >> =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F >> =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM >> =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > > > From igor.faynberg@alcatel-lucent.com Wed May 25 15:39: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 5D928E0823 for ; Wed, 25 May 2011 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 WU2fzxGNXuIH for ; Wed, 25 May 2011 15:39:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 596B3E07FE for ; Wed, 25 May 2011 15:39:47 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p4PMdkTK022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2011 17:39:46 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4PMdjvh004202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 May 2011 17:39:46 -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 p4PMdioU026321; Wed, 25 May 2011 17:39:44 -0500 (CDT) Message-ID: <4DDD8530.5010605@alcatel-lucent.com> Date: Wed, 25 May 2011 18:39:44 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Campbell 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id in extension grant_types? 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: Wed, 25 May 2011 22:39:50 -0000 Brian Campbell wrote: > Currently (draft -16) client_id is listed as a required parameter for > access token request to the token endpoint for all grant types except > for extensions. In section 3 there is some disposition of the use of > client_id as a means of identification and then, in 3.2, a requirement > that client authentication mechanisms must "define a mapping between > the client identifier and the credentials used to authenticate." > > Does this imply that, if client authentication is done at the token > endpoint for any extension grant, that the client_id parameter is also > required? This is the only way I would interpret that. > If so, perhaps it could be made more explicit somewhere in > section 3 or section 5. I remember that there was some consensus a > while back that client identification/authentication should be > optional for the extensions, and that makes sense. But when > authentication is done, it seems like it should be consistent with the > way the other grants do it - that allows for implementations to have a > cleaner separation between client authentication and grant processing. > +1! To piggy-back, I remember a query from Peter on the definition of client_id (or rather absence of it), and Brian's response, and then another note form Peter on character choice. What is the follow-up plan? It looks to me like something that absolutely ought to be fixed in 2.0. Igor > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Wed May 25 20: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 C7D9DE06DD for ; Wed, 25 May 2011 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Vl4Sk5Xii6 for ; Wed, 25 May 2011 20:22: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 39881E06BD for ; Wed, 25 May 2011 20:22:30 -0700 (PDT) Received: (qmail 13294 invoked from network); 26 May 2011 03:22:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 May 2011 03:22:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 25 May 2011 20:22:24 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Brian Campbell Date: Wed, 25 May 2011 20:22:06 -0700 Thread-Topic: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions Thread-Index: AQHMGuNOl7EkQhqD8kiarpjrGXDWA5SdxeewgAAmcICAAAdtAIAAfYlQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583C9D1D@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 Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions X-BeenThere: oauth@ietf.org X-Mailman-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, 26 May 2011 03:22:32 -0000 We are taking multiple paths trying to find the best balance. There is an effort to draft a new document describing client authentication= using assertions. That effort seems to expand to encompass all assertion r= elated business. I'm supportive of that approach. This document may or may = not swallow the SAML bearer document - I don't have an opinion on that. There is another effort to take a narrow approach and to simply move the co= mmon fragment (the 'assertion' parameter) out of the SAML bearer spec and b= ack into v2. I'm also supportive of that approach. This is the proposed tex= t listed below. How can I be supportive of both? Well, both sounds promising and will produ= ce a useful document structure. However, as someone who has no intention of= using assertions of any kind with OAuth, I can't really say which will mak= e developers' life easier.=20 EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Wednesday, May 25, 2011 3:03 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > subsection on assertions >=20 > So the separate document was already discussed in the design team and in > the meeting on Monday, the action item was given to look at creating a > separate document for assertion covering authentication and authorization= . >=20 > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, May 25, 2011 12:22 PM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > subsection on assertions >=20 > It's not exactly clear to me what that means. >=20 > Near the end of the interim meeting on Monday there was a specific > discussion that resulted in a TODO item to draft a 4.5.1 subsection. > That's what I've done here and I believe it captures the intent discussed= at > the meeting. I've written a small proposal for specific text to be inclu= ded in > the core specification and described the subsequent changes (simplificati= ons > actually) that would follow in companion specification. >=20 > I've made a specific and actionable proposal. I'm happy to discuss the m= erits > of the proposal and if the WG should accept it or not. >=20 > If you feel that your proposal of a separate document is more appropriate= , > I'd suggest you actually write such a document and describe how it impact= s > existing drafts so that it can be reviewed and discussed. My understandin= g > (Chairs, correct me if I'm wrong) is that such a document would need to b= e > accepted as a working group item in order to be referenced from draft-iet= f- > oauth-v2 or used/referenced by draft-ietf-oauth-saml2. >=20 > On Wed, May 25, 2011 at 11:07 AM, Anthony Nadalin > wrote: > > In our case they are tightly bound as the assertions (same assertion) w= ill be > used for authentication and also to grant authorization as this is what w= as in > scope with WRAP, so not addressing the assertion authentication is an iss= ue > for us and I assume others also. > > > > -----Original Message----- > > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > > Sent: Wednesday, May 25, 2011 6:54 AM > > To: Anthony Nadalin > > Cc: oauth > > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > > subsection on assertions > > > > That is another way to approach it and I understand there has been > > some talk about that lately. =A0While there are admittedly some > > commonalities between assertion based grants and an HTTP parameter > based client authentication extension point, I personally think that lump= ing > them together is unnecessarily confusing. =A0 It is also a more significa= nt change > and it seems like, at this point in the process, it might be better to ai= m for > more concise and targeted changes. > > > > > > On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin > wrote: > >> I think that this will be better moved into a separate document on > >> assertions (were both authorization and authentication are talked > >> about) and not to include in 4.5.1 but would like to see a reference > >> in 4.5.1 to the new document > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Tuesday, May 24, 2011 7:25 AM > >> To: oauth > >> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 > >> subsection on assertions > >> > >> One of the action items out of yesterday's meeting was to draft some t= ext > for a section 4.5.1 in core that defined the optional but recommended use= of > an "assertion" parameter for extension grants where the use of a single > parameter to carry the grant/assertion was possible. =A0Below is a first = cut at > some proposed text that hopefully avoids some of the awkwardness that > EHL described in previous attempts to introduce such a > parameter. =A0Comments or edits or editorial improvements are, of course, > welcome. =A0But I think this hopefully captures the intent of what was > discussed yesterday (and before). > >> > >> If we get some consensus to make this change, I think a couple of othe= r > actions are implied. > >> > >> - The IANA assertion parameter registration request > >> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section- > >> 4 > >> .1) should be removed from the SAML draft and put into > >> http://tools.ietf.org/html/draft-ietf-oauth-v2 > >> > >> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec > >> will change the parameter it uses from jwt to assertion and drop the > >> registration request for jwt > >> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4. > >> 1) > >> > >> > >> --- proposed text for sections 4.5 & 4.5.1 --- > >> > >> 4.5. Extensions > >> > >> =A0 The client uses an extension grant type by specifying the grant > >> type > >> =A0 using an absolute URI (defined by the authorization server) as the > >> =A0 value of the "grant_type" parameter of the token endpoint, and by > >> =A0 adding any additional parameters necessary. > >> > >> =A0 If the access token request is valid and authorized, the > >> =A0 authorization server issues an access token and optional refresh > >> =A0 token as described in Section 5.1. =A0If the request failed client > >> =A0 authentication or is invalid, the authorization server returns an > >> =A0 error response as described in Section 5.2. > >> > >> 4.5.1 Assertion Based Extension Grants > >> > >> =A0If the value of the extension grant can be serialized into a single > >> =A0parameter, as is case with a number of assertion formats, it is > >> =A0RECOMMENDED that that a parameter named "assertion" be used to > >> =A0carry the value. > >> > >> =A0 assertion > >> =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding of= the > >> =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization serv= er or > >> =A0 =A0 =A0 =A0 =A0 =A0 extension specification. > >> > >> =A0 For example, to request an access token using a SAML 2.0 assertion > >> =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client > >> =A0 makes the following HTTP request using transport-layer security > >> (line > >> =A0 breaks are for display purposes only): > >> > >> =A0 POST /token HTTP/1.1 > >> =A0 Host: server.example.com > >> =A0 Content-Type: application/x-www-form-urlencoded > >> > >> =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0% > 2F > >> =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUt > M > >> =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> > > > > > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Thu May 26 08:30: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 2BA5FE068D for ; Thu, 26 May 2011 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 8bZOULs4KKBj for ; Thu, 26 May 2011 08:30:33 -0700 (PDT) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0C6E0655 for ; Thu, 26 May 2011 08:30:33 -0700 (PDT) Received: from mtaout-ma05.r1000.mx.aol.com (mtaout-ma05.r1000.mx.aol.com [172.29.41.5]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4QFU2oR013017; Thu, 26 May 2011 11:30:02 -0400 Received: from palantir.local (unknown [10.181.183.168]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 39ECFE0000A7; Thu, 26 May 2011 11:30:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1306423802; bh=b/deeTBxYHNfY/tlC//Cce8xh820JpVxNiIUXHPoL1E=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=xt33H3yNAR93Wl61pDEwwEFDfBaIUekeG4FKoSzsynC3Sxl30IaqG0ku5KOcsni3N Z0uy88Z6iYJTh8zOS0KmhtY13/3DSdoKGpOYWy2keFfBkqf9C6CwAHOQajr3aEoaHE XaSYUzmholo6wib/xE7OJZB8UDde07Wnd3tkgkeU= Message-ID: <4DDE71F9.3090301@aol.com> Date: Thu, 26 May 2011 11:30:01 -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: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com> <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000308020104070500030704" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:464879552:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29054dde71fa5832 X-AOL-IP: 10.181.183.168 Cc: OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 26 May 2011 15:30:35 -0000 This is a multi-part message in MIME format. --------------000308020104070500030704 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit So just to make sure that I'm clear... The following is ok... The AS and RO decide that the token will be comprised of both a name and value part. So the whole token looks like 'token=asfd2353fasdfa235q54rdasf'. From the protocol perspective, the access token is the entire string, even if it looks like to the developer that only the 'asfd2353fasdfa235q54rdasf' part is the token. As a developer I find this confusing, but I think I now understand why the 'token=asfd2353fasdfa235q54rdasf' is legal. The key is that the client has to treat the response from the AS as opaque (as Paul mentioned) and just put it in the Authorization header as 'Authorization: Bearer " regardless of what the resulting header looks like. Thanks, George On 5/25/11 1:15 PM, Mike Jones wrote: > What you quoted below was the acceptable syntax. The Authorization Server and the Resource Server still need to agree upon the semantics of the bearer token exchanged. > > -- Mike > > -----Original Message----- > From: John Kemp [mailto:john@jkemp.net] > Sent: Wednesday, May 25, 2011 10:11 AM > To: Mike Jones > Cc: Marius Scurtescu; George Fletcher; OAuth WG > Subject: Re: [OAUTH-WG] bearer token authorization header > > On May 24, 2011, at 4:04 PM, Mike Jones wrote: > >> George, you are correct that resources and clients must agree upon the format of the bearer token to achieve interoperability. The means for achieving this agreement is out of the scope of this document. > I thought the means for achieving IOP was quite precisely described in the production below (excerpted from 2.1 of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04): > > credentials = "Bearer" RWS access-token > > access-token = 1*( quoted-char /<"> ) > > quoted-char = "!" / "#" / "$" / "%" / "&" / "'" / "(" > / ")" / "*" / "+" / "-" / "." / "/" / DIGIT > / ":" / "<" / "=" /">" / "?" / "@" / ALPHA > / "[" / "]" / "^" / "_" / "`" / "{" / "|" > / "}" / "~" / "\" / "," / ";" > > - John > >> -- Mike >> >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, May 24, 2011 11:28 AM >> To: George Fletcher >> Cc: Mike Jones; OAuth WG >> Subject: Re: [OAUTH-WG] bearer token authorization header >> >> The "printable non-whitespace ASCII characters" represents the access token, which is supposed to be opaque. I don't think this affects libraries. >> >> Marius >> >> >> >> On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrote: >>> Do I understand this correctly that each resource owner can define >>> it's own format for the "printable non-whitespace ASCII characters"? >>> It seems like that would make it difficult for clients to use >>> standard libraries because the Authorization header format could be >>> different on a per resource/host basis. >>> >>> Thanks, >>> George >>> >>> On 5/23/11 3:10 PM, Mike Jones wrote: >>> >>> [snip] >>> >>> >>> >>> The fact that there is no escaping mechanism can potentially create >>> problems. The list of allowed characters is spelled out, but what if >>> some implementation uses other characters? Using a name value pair >>> and proper escaping is much safer IMO. For example: >>> >>> Bearer token=dfgh76dfghdfg >>> >>> or >>> >>> Bearer token="dfgh76dfghdfg" >>> >>> >>> >>> The value above can be either a token or a quoted string. HTTP header >>> parsers know how to parse tokens and quoted strings so an implementor >>> has a better chance of doing it right. >>> >>> >>> >>> Mark Lentczner started a thread on this regard a few moths ago, James >>> Manger replied and suggested something similar: >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>> >>> >>> >>> If it is too late to switch to a name/value pair, then I think we >>> should at least clean up the references. >>> >>> The definition allows the access token to be any string of one or >>> more printable non-whitespace ASCII characters. Thus, legal access >>> token strings include ones like the ones you are asking for, such as: >>> >>> param="value" >>> >>> >>> >>> -- Mike >>> >>> >>> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Monday, May 09, 2011 10:32 AM >>> To: OAuth WG; Mike Jones >>> Cc: Mark Lentczner; Manger, James H >>> Subject: bearer token authorization header >>> >>> >>> >>> I am working through version 04 of the Bearer Token draft: >>> >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 >>> >>> >>> >>> Not sure how to interpret the authorization header grammar described >>> in section 2.1. The intent seems to be for something like: >>> >>> Bearer dfgh76dfghdfg >>> >>> >>> >>> After the scheme name, "Bearer", there is a required whitespace >>> followed by the actual token. The token is represented by a sequence >>> of printable characters, no escaping. No spaces or other elements are >>> allowed after the token. Is that correct? >>> >>> >>> >>> RWS is not defined, I assume it is the "required whitespace" from >>> section >>> 1.2.2 of: >>> >>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13 >>> >>> >>> >>> There is a reference to RFC2617, but not sure why. That seems to >>> imply that a list of values can be specified, which is not the case. >>> >>> >>> >>> The fact that there is no escaping mechanism can potentially create >>> problems. The list of allowed characters is spelled out, but what if >>> some implementation uses other characters? Using a name value pair >>> and proper escaping is much safer IMO. For example: >>> >>> Bearer token=dfgh76dfghdfg >>> >>> or >>> >>> Bearer token="dfgh76dfghdfg" >>> >>> >>> >>> The value above can be either a token or a quoted string. HTTP header >>> parsers know how to parse tokens and quoted strings so an implementor >>> has a better chance of doing it right. >>> >>> >>> >>> Mark Lentczner started a thread on this regard a few moths ago, James >>> Manger replied and suggested something similar: >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html >>> >>> >>> >>> If it is too late to switch to a name/value pair, then I think we >>> should at least clean up the references. >>> >>> >>> >>> 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 --------------000308020104070500030704 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 7bit So just to make sure that I'm clear... The following is ok...
    The AS and RO decide that the token will be comprised of both a name and value part. So the whole token looks like 'token=asfd2353fasdfa235q54rdasf'. From the protocol perspective, the access token is the entire string, even if it looks like to the developer that only the 'asfd2353fasdfa235q54rdasf' part is the token. As a developer I find this confusing, but I think I now understand why the 'token=asfd2353fasdfa235q54rdasf' is legal.

    The key is that the client has to treat the response from the AS as opaque (as Paul mentioned) and just put it in the Authorization header as 'Authorization: Bearer <token>" regardless of what the resulting header looks like.

    Thanks,
    George

    On 5/25/11 1:15 PM, Mike Jones wrote: 
    What you quoted below was the acceptable syntax.  The Authorization Server and the Resource Server still need to agree upon the semantics of the bearer token exchanged.

                -- Mike

-----Original Message-----
From: John Kemp [mailto:john@jkemp.net] 
Sent: Wednesday, May 25, 2011 10:11 AM
To: Mike Jones
Cc: Marius Scurtescu; George Fletcher; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header

On May 24, 2011, at 4:04 PM, Mike Jones wrote:


    George, you are correct that resources and clients must agree upon the format of the bearer token to achieve interoperability.  The means for achieving this agreement is out of the scope of this document.

    I thought the means for achieving IOP was quite precisely described in the production below (excerpted from 2.1 of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):

   credentials    = "Bearer" RWS access-token

   access-token   = 1*( quoted-char / <"> )

   quoted-char    =   "!" / "#" / "$" / "%" / "&" / "'" / "("
                    / ")" / "*" / "+" / "-" / "." / "/" / DIGIT
                    / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
                    / "[" / "]" / "^" / "_" / "`" / "{" / "|"
                    / "}" / "~" / "\" / "," / ";"

- John


                  -- Mike

-----Original Message-----
From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Tuesday, May 24, 2011 11:28 AM
To: George Fletcher
Cc: Mike Jones; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header

The "printable non-whitespace ASCII characters" represents the access token, which is supposed to be opaque. I don't think this affects libraries.

Marius



On Tue, May 24, 2011 at 10:24 AM, George Fletcher <gffletch@aol.com> wrote:

    Do I understand this correctly that each resource owner can define 
it's own format for the "printable non-whitespace ASCII characters"?
It seems like that would make it difficult for clients to use 
standard libraries because the Authorization header format could be 
different on a per resource/host basis.

Thanks,
George

On 5/23/11 3:10 PM, Mike Jones wrote:

[snip]



The fact that there is no escaping mechanism can potentially create 
problems. The list of allowed characters is spelled out, but what if 
some implementation uses other characters? Using a name value pair 
and proper escaping is much safer IMO. For example:

Bearer token=dfgh76dfghdfg

or

Bearer token="dfgh76dfghdfg"



The value above can be either a token or a quoted string. HTTP header 
parsers know how to parse tokens and quoted strings so an implementor 
has a better chance of doing it right.



Mark Lentczner started a thread on this regard a few moths ago, James 
Manger replied and suggested something similar:

http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html



If it is too late to switch to a name/value pair, then I think we 
should at least clean up the references.

The definition allows the access token to be any string of one or 
more printable non-whitespace ASCII characters.  Thus, legal access 
token strings include ones like the ones you are asking for, such as:

               param="value"



                                                            -- Mike



-----Original Message-----
From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Monday, May 09, 2011 10:32 AM
To: OAuth WG; Mike Jones
Cc: Mark Lentczner; Manger, James H
Subject: bearer token authorization header



I am working through version 04 of the Bearer Token draft:

http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04



Not sure how to interpret the authorization header grammar described 
in section 2.1. The intent seems to be for something like:

Bearer dfgh76dfghdfg



After the scheme name, "Bearer", there is a required whitespace 
followed by the actual token. The token is represented by a sequence 
of printable characters, no escaping. No spaces or other elements are 
allowed after the token. Is that correct?



RWS is not defined, I assume it is the "required whitespace" from 
section
1.2.2 of:

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13



There is a reference to RFC2617, but not sure why. That seems to 
imply that a list of values can be specified, which is not the case.



The fact that there is no escaping mechanism can potentially create 
problems. The list of allowed characters is spelled out, but what if 
some implementation uses other characters? Using a name value pair 
and proper escaping is much safer IMO. For example:

Bearer token=dfgh76dfghdfg

or

Bearer token="dfgh76dfghdfg"



The value above can be either a token or a quoted string. HTTP header 
parsers know how to parse tokens and quoted strings so an implementor 
has a better chance of doing it right.



Mark Lentczner started a thread on this regard a few moths ago, James 
Manger replied and suggested something similar:

http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html



If it is too late to switch to a name/value pair, then I think we 
should at least clean up the references.



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

    
    
    
  


--------------000308020104070500030704--

From mscurtescu@google.com  Thu May 26 09:16: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 95981E074C for ; Thu, 26 May 2011 09:16:13 -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 k4NhQWUFfbub for ; Thu, 26 May 2011 09:16:12 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 47F80E0747 for ; Thu, 26 May 2011 09:16:12 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p4QGGADF021127 for ; Thu, 26 May 2011 09:16:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306426571; bh=KUoNnLdLevASqkrFnaamTXG2WSQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cFTO6/DP8tG9MzjoieAr04JGYfwR44i5hSL+PSoj1BYjPy5zLBq4LmlWIWAbHpiXj olMzT50OG5Yus/6Hch9Jw==
Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by hpaq3.eem.corp.google.com with ESMTP id p4QGFwpw010388 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 26 May 2011 09:16:04 -0700
Received: by ywo7 with SMTP id 7so532402ywo.39 for ; Thu, 26 May 2011 09:15:58 -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=+SwW8bdawFRx0AkEbWBr/5mDBNZXbkfgff5mJwxajH4=; b=DxyRC1IrOVUh2zG3cDzhkCHUzPay7Mgcw9TN2xL7ZhRSup9xV5kqVJsVR//DLkOyK8 fJJbvVLPwZviVNI5w8Sw==
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=P4v/PPr6iH0DXosOczIbik+PWcqvho2P6S21827GzqcXd4lpRLjFblFEoYfvjPU/Ts 6pcwFEG+HEYPLKr98yLQ==
Received: by 10.101.95.1 with SMTP id x1mr762020anl.35.1306426558183; Thu, 26 May 2011 09:15:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.166.6 with HTTP; Thu, 26 May 2011 09:15:38 -0700 (PDT)
In-Reply-To: <4DDE71F9.3090301@aol.com>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com>  <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDE71F9.3090301@aol.com>
From: Marius Scurtescu 
Date: Thu, 26 May 2011 09:15:38 -0700
Message-ID: 
To: George Fletcher 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] bearer token authorization header
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 May 2011 16:16:13 -0000

Maybe I created some confusion. Earlier in the thread I was wondering
why isn't the part after the scheme name a list of name/value pairs.
If it was, then the authorization header would look like:

Bearer token=asfd2353fasdfa235q54rdasf

and the actual token would be just asfd2353fasdfa235q54rdasf, and it
should be encoded as a quoted string if it contained special
characters.

But this is not what the spec currently say. The part after the scheme
name is simply the token, no encoding or names or lists. Also, the
spec defines the set of legal characters that can show up in a token
(this limits what tokens can an AS issue). With the current spec the
header would look like:

Bearer asfd2353fasdfa235q54rdasf

The = character is a legal character inside a token, and it has no
special meaning.

I hope this helps, and I hope I got it right,
Marius



On Thu, May 26, 2011 at 8:30 AM, George Fletcher  wrote:
> So just to make sure that I'm clear... The following is ok...
>
> The AS and RO decide that the token will be comprised of both a name and
> value part. So the whole token looks like 'token=asfd2353fasdfa235q54rdasf'.
> From the protocol perspective, the access token is the entire string, even
> if it looks like to the developer that only the 'asfd2353fasdfa235q54rdasf'
> part is the token. As a developer I find this confusing, but I think I now
> understand why the 'token=asfd2353fasdfa235q54rdasf' is legal.
>
> The key is that the client has to treat the response from the AS as opaque
> (as Paul mentioned) and just put it in the Authorization header as
> 'Authorization: Bearer " regardless of what the resulting header
> looks like.
>
> Thanks,
> George
>
> On 5/25/11 1:15 PM, Mike Jones wrote:
>
> What you quoted below was the acceptable syntax.  The Authorization Server
> and the Resource Server still need to agree upon the semantics of the bearer
> token exchanged.
>
>                 -- Mike
>
> -----Original Message-----
> From: John Kemp [mailto:john@jkemp.net]
> Sent: Wednesday, May 25, 2011 10:11 AM
> To: Mike Jones
> Cc: Marius Scurtescu; George Fletcher; OAuth WG
> Subject: Re: [OAUTH-WG] bearer token authorization header
>
> On May 24, 2011, at 4:04 PM, Mike Jones wrote:
>
> George, you are correct that resources and clients must agree upon the
> format of the bearer token to achieve interoperability.  The means for
> achieving this agreement is out of the scope of this document.
>
> I thought the means for achieving IOP was quite precisely described in the
> production below (excerpted from 2.1 of
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):
>
>    credentials    = "Bearer" RWS access-token
>
>    access-token   = 1*( quoted-char / <"> )
>
>    quoted-char    =   "!" / "#" / "$" / "%" / "&" / "'" / "("
>                     / ")" / "*" / "+" / "-" / "." / "/" / DIGIT
>                     / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA
>                     / "[" / "]" / "^" / "_" / "`" / "{" / "|"
>                     / "}" / "~" / "\" / "," / ";"
>
> - John
>
>               -- Mike
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Tuesday, May 24, 2011 11:28 AM
> To: George Fletcher
> Cc: Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] bearer token authorization header
>
> The "printable non-whitespace ASCII characters" represents the access token,
> which is supposed to be opaque. I don't think this affects libraries.
>
> Marius
>
>
>
> On Tue, May 24, 2011 at 10:24 AM, George Fletcher  wrote:
>
> Do I understand this correctly that each resource owner can define
> it's own format for the "printable non-whitespace ASCII characters"?
> It seems like that would make it difficult for clients to use
> standard libraries because the Authorization header format could be
> different on a per resource/host basis.
>
> Thanks,
> George
>
> On 5/23/11 3:10 PM, Mike Jones wrote:
>
> [snip]
>
>
>
> The fact that there is no escaping mechanism can potentially create
> problems. The list of allowed characters is spelled out, but what if
> some implementation uses other characters? Using a name value pair
> and proper escaping is much safer IMO. For example:
>
> Bearer token=dfgh76dfghdfg
>
> or
>
> Bearer token="dfgh76dfghdfg"
>
>
>
> The value above can be either a token or a quoted string. HTTP header
> parsers know how to parse tokens and quoted strings so an implementor
> has a better chance of doing it right.
>
>
>
> Mark Lentczner started a thread on this regard a few moths ago, James
> Manger replied and suggested something similar:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>
>
>
> If it is too late to switch to a name/value pair, then I think we
> should at least clean up the references.
>
> The definition allows the access token to be any string of one or
> more printable non-whitespace ASCII characters.  Thus, legal access
> token strings include ones like the ones you are asking for, such as:
>
>                param="value"
>
>
>
>                                                             -- Mike
>
>
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Monday, May 09, 2011 10:32 AM
> To: OAuth WG; Mike Jones
> Cc: Mark Lentczner; Manger, James H
> Subject: bearer token authorization header
>
>
>
> I am working through version 04 of the Bearer Token draft:
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
>
>
>
> Not sure how to interpret the authorization header grammar described
> in section 2.1. The intent seems to be for something like:
>
> Bearer dfgh76dfghdfg
>
>
>
> After the scheme name, "Bearer", there is a required whitespace
> followed by the actual token. The token is represented by a sequence
> of printable characters, no escaping. No spaces or other elements are
> allowed after the token. Is that correct?
>
>
>
> RWS is not defined, I assume it is the "required whitespace" from
> section
> 1.2.2 of:
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13
>
>
>
> There is a reference to RFC2617, but not sure why. That seems to
> imply that a list of values can be specified, which is not the case.
>
>
>
> The fact that there is no escaping mechanism can potentially create
> problems. The list of allowed characters is spelled out, but what if
> some implementation uses other characters? Using a name value pair
> and proper escaping is much safer IMO. For example:
>
> Bearer token=dfgh76dfghdfg
>
> or
>
> Bearer token="dfgh76dfghdfg"
>
>
>
> The value above can be either a token or a quoted string. HTTP header
> parsers know how to parse tokens and quoted strings so an implementor
> has a better chance of doing it right.
>
>
>
> Mark Lentczner started a thread on this regard a few moths ago, James
> Manger replied and suggested something similar:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>
>
>
> If it is too late to switch to a name/value pair, then I think we
> should at least clean up the references.
>
>
>
> 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 Michael.Jones@microsoft.com  Thu May 26 09: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 58E38E0711 for ; Thu, 26 May 2011 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.742
X-Spam-Level: 
X-Spam-Status: No, score=-10.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 97unSQq+yOCe for ; Thu, 26 May 2011 09:20:22 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 1100CE06E1 for ; Thu, 26 May 2011 09:20:22 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 09:20:21 -0700
Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0289.008; Thu, 26 May 2011 09:20:21 -0700
From: Mike Jones 
To: Marius Scurtescu , George Fletcher 
Thread-Topic: [OAUTH-WG] bearer token authorization header
Thread-Index: AQHMDm8eraLFxPaXk06szRXCsxzqaJSa20EggAHsNACAABGYAP//pZSwgAHXK4D//4uqkIAB6pKAgAAMvwD//4vqwA==
Date: Thu, 26 May 2011 16:20:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394338102223@TK5EX14MBXC203.redmond.corp.microsoft.com>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com>  <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDE71F9.3090301@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.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] bearer token authorization header
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 May 2011 16:20:23 -0000

You got it right. :-)

-----Original Message-----
From: Marius Scurtescu [mailto:mscurtescu@google.com]=20
Sent: Thursday, May 26, 2011 9:16 AM
To: George Fletcher
Cc: Mike Jones; John Kemp; OAuth WG
Subject: Re: [OAUTH-WG] bearer token authorization header

Maybe I created some confusion. Earlier in the thread I was wondering why i=
sn't the part after the scheme name a list of name/value pairs.
If it was, then the authorization header would look like:

Bearer token=3Dasfd2353fasdfa235q54rdasf

and the actual token would be just asfd2353fasdfa235q54rdasf, and it should=
 be encoded as a quoted string if it contained special characters.

But this is not what the spec currently say. The part after the scheme name=
 is simply the token, no encoding or names or lists. Also, the spec defines=
 the set of legal characters that can show up in a token (this limits what =
tokens can an AS issue). With the current spec the header would look like:

Bearer asfd2353fasdfa235q54rdasf

The =3D character is a legal character inside a token, and it has no specia=
l meaning.

I hope this helps, and I hope I got it right, Marius



On Thu, May 26, 2011 at 8:30 AM, George Fletcher  wrote:
> So just to make sure that I'm clear... The following is ok...
>
> The AS and RO decide that the token will be comprised of both a name=20
> and value part. So the whole token looks like 'token=3Dasfd2353fasdfa235q=
54rdasf'.
> From the protocol perspective, the access token is the entire string,=20
> even if it looks like to the developer that only the 'asfd2353fasdfa235q5=
4rdasf'
> part is the token. As a developer I find this confusing, but I think I=20
> now understand why the 'token=3Dasfd2353fasdfa235q54rdasf' is legal.
>
> The key is that the client has to treat the response from the AS as=20
> opaque (as Paul mentioned) and just put it in the Authorization header=20
> as
> 'Authorization: Bearer " regardless of what the resulting=20
> header looks like.
>
> Thanks,
> George
>
> On 5/25/11 1:15 PM, Mike Jones wrote:
>
> What you quoted below was the acceptable syntax.  The Authorization=20
> Server and the Resource Server still need to agree upon the semantics=20
> of the bearer token exchanged.
>
>                 -- Mike
>
> -----Original Message-----
> From: John Kemp [mailto:john@jkemp.net]
> Sent: Wednesday, May 25, 2011 10:11 AM
> To: Mike Jones
> Cc: Marius Scurtescu; George Fletcher; OAuth WG
> Subject: Re: [OAUTH-WG] bearer token authorization header
>
> On May 24, 2011, at 4:04 PM, Mike Jones wrote:
>
> George, you are correct that resources and clients must agree upon the=20
> format of the bearer token to achieve interoperability.  The means for=20
> achieving this agreement is out of the scope of this document.
>
> I thought the means for achieving IOP was quite precisely described in=20
> the production below (excerpted from 2.1 of
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):
>
>    credentials    =3D "Bearer" RWS access-token
>
>    access-token   =3D 1*( quoted-char / <"> )
>
>    quoted-char    =3D   "!" / "#" / "$" / "%" / "&" / "'" / "("
>                     / ")" / "*" / "+" / "-" / "." / "/" / DIGIT
>                     / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA
>                     / "[" / "]" / "^" / "_" / "`" / "{" / "|"
>                     / "}" / "~" / "\" / "," / ";"
>
> - John
>
>               -- Mike
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Tuesday, May 24, 2011 11:28 AM
> To: George Fletcher
> Cc: Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] bearer token authorization header
>
> The "printable non-whitespace ASCII characters" represents the access=20
> token, which is supposed to be opaque. I don't think this affects librari=
es.
>
> Marius
>
>
>
> On Tue, May 24, 2011 at 10:24 AM, George Fletcher  wrot=
e:
>
> Do I understand this correctly that each resource owner can define=20
> it's own format for the "printable non-whitespace ASCII characters"?
> It seems like that would make it difficult for clients to use standard=20
> libraries because the Authorization header format could be different=20
> on a per resource/host basis.
>
> Thanks,
> George
>
> On 5/23/11 3:10 PM, Mike Jones wrote:
>
> [snip]
>
>
>
> The fact that there is no escaping mechanism can potentially create=20
> problems. The list of allowed characters is spelled out, but what if=20
> some implementation uses other characters? Using a name value pair and=20
> proper escaping is much safer IMO. For example:
>
> Bearer token=3Ddfgh76dfghdfg
>
> or
>
> Bearer token=3D"dfgh76dfghdfg"
>
>
>
> The value above can be either a token or a quoted string. HTTP header=20
> parsers know how to parse tokens and quoted strings so an implementor=20
> has a better chance of doing it right.
>
>
>
> Mark Lentczner started a thread on this regard a few moths ago, James=20
> Manger replied and suggested something similar:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>
>
>
> If it is too late to switch to a name/value pair, then I think we=20
> should at least clean up the references.
>
> The definition allows the access token to be any string of one or more=20
> printable non-whitespace ASCII characters.  Thus, legal access token=20
> strings include ones like the ones you are asking for, such as:
>
>                param=3D"value"
>
>
>
>                                                             -- Mike
>
>
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Monday, May 09, 2011 10:32 AM
> To: OAuth WG; Mike Jones
> Cc: Mark Lentczner; Manger, James H
> Subject: bearer token authorization header
>
>
>
> I am working through version 04 of the Bearer Token draft:
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
>
>
>
> Not sure how to interpret the authorization header grammar described=20
> in section 2.1. The intent seems to be for something like:
>
> Bearer dfgh76dfghdfg
>
>
>
> After the scheme name, "Bearer", there is a required whitespace=20
> followed by the actual token. The token is represented by a sequence=20
> of printable characters, no escaping. No spaces or other elements are=20
> allowed after the token. Is that correct?
>
>
>
> RWS is not defined, I assume it is the "required whitespace" from=20
> section
> 1.2.2 of:
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13
>
>
>
> There is a reference to RFC2617, but not sure why. That seems to imply=20
> that a list of values can be specified, which is not the case.
>
>
>
> The fact that there is no escaping mechanism can potentially create=20
> problems. The list of allowed characters is spelled out, but what if=20
> some implementation uses other characters? Using a name value pair and=20
> proper escaping is much safer IMO. For example:
>
> Bearer token=3Ddfgh76dfghdfg
>
> or
>
> Bearer token=3D"dfgh76dfghdfg"
>
>
>
> The value above can be either a token or a quoted string. HTTP header=20
> parsers know how to parse tokens and quoted strings so an implementor=20
> has a better chance of doing it right.
>
>
>
> Mark Lentczner started a thread on this regard a few moths ago, James=20
> Manger replied and suggested something similar:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>
>
>
> If it is too late to switch to a name/value pair, then I think we=20
> should at least clean up the references.
>
>
>
> 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 tonynad@microsoft.com  Thu May 26 09:42: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 251B2E070A for ; Thu, 26 May 2011 09:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level: 
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=0.067,  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 4PjmhxqhRBum for ; Thu, 26 May 2011 09:42:10 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 152F5E06D6 for ; Thu, 26 May 2011 09:42:10 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 09:42:09 -0700
Received: from TX2EHSOBE008.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 26 May 2011 09:42:09 -0700
Received: from mail44-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 May 2011 16:42:08 +0000
Received: from mail44-tx2 (localhost.localdomain [127.0.0.1])	by mail44-tx2-R.bigfish.com (Postfix) with ESMTP id 80D1ABA80A7	for ; Thu, 26 May 2011 16:42:08 +0000 (UTC)
X-SpamScore: -2
X-BigFish: PS-2(zzzzdafM1202h1082kzz8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail44-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=CH1PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail44-tx2 (localhost.localdomain [127.0.0.1]) by mail44-tx2 (MessageSwitch) id 1306428128139258_21573; Thu, 26 May 2011 16:42:08 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.241])	by mail44-tx2.bigfish.com (Postfix) with ESMTP id 1706B1A28057	for ; Thu, 26 May 2011 16:42:08 +0000 (UTC)
Received: from CH1PRD0302HT008.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 26 May 2011 16:42:06 +0000
Received: from CH1PRD0302MB115.namprd03.prod.outlook.com ([169.254.1.72]) by CH1PRD0302HT008.namprd03.prod.outlook.com ([10.28.29.127]) with mapi id 14.01.0225.052; Thu, 26 May 2011 16:42:05 +0000
From: Anthony Nadalin 
To: "OAuth WG (oauth@ietf.org)" 
Thread-Topic: Redirect Issues
Thread-Index: Acwbwr3m+oMUybmwQjCxojIzhpKjFw==
Date: Thu, 26 May 2011 16:42:05 +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.69]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723110306CH1PRD0302MB115_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT008.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: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
Subject: [OAUTH-WG] Redirect Issues
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 May 2011 16:42:11 -0000

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

The OAuth spec is somewhat silent about how a resource provider should perf=
orm a redirect as there are many ways to accomplish the redirect. We also d=
iscovered that since the HTTP specifications were somewhat vague on fragmen=
ts that some HTTP client implementations strip the fragment, we have the ca=
se in our implementation of WinINET.

So would like to propose that wording be added in 2.1.1 to the effect that =
"There are many ways to perform the redirection and the fact that some HTTP=
 client implementations strip the fragment so take this into consideration =
when choosing a redirect technology." It might be also good to add an examp=
le of a different style redirect as I believe all the samples use 302 .



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









    

    The OAuth spec is somewhat silent about how a resour=
ce provider should perform a redirect as there are many ways to accomplish =
the redirect. We also discovered that since the HTTP specifications were so=
mewhat vague on fragments that some
 HTTP client implementations strip the fragment, we have the case in our im=
plementation of WinINET.
    

     
    

    So would like to propose that wording be added in 2.=
1.1 to the effect that “There are many ways to perform the redirectio=
n and the fact that some HTTP client implementations strip the fragment so =
take this into consideration when choosing
 a redirect technology.” It might be also good to add an example of a=
 different style redirect as I believe all the samples use 302 .=

    

     
    

     
    

    



--_000_B26C1EF377CB694EAB6BDDC8E624B6E723110306CH1PRD0302MB115_--

From igor.faynberg@alcatel-lucent.com  Thu May 26 09:56: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 8D2C8130028 for ; Thu, 26 May 2011 09:56:30 -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 b+cNeBniFC+c for ; Thu, 26 May 2011 09:56:30 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E01E3130019 for ; Thu, 26 May 2011 09:56:29 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p4QGuT5h011893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 May 2011 11:56:29 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4QGuSmQ017427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 May 2011 11:56:29 -0500
Received: from [135.244.38.106] (faynberg.lra.lucent.com [135.244.38.106]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4QGuSA3014604; Thu, 26 May 2011 11:56:28 -0500 (CDT)
Message-ID: <4DDE863B.2080400@alcatel-lucent.com>
Date: Thu, 26 May 2011 12:56:27 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Anthony Nadalin 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Cc: "OAuth WG \(oauth@ietf.org\)" 
Subject: Re: [OAUTH-WG] Redirect Issues
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, 26 May 2011 16:56:30 -0000

Actually, I would go even further: Provide a list of different ways of 
redirecting and address each of them, or at least each class of 
redirects with the same characteristics.

Igor

Anthony Nadalin wrote:
>
> The OAuth spec is somewhat silent about how a resource provider should 
> perform a redirect as there are many ways to accomplish the redirect. 
> We also discovered that since the HTTP specifications were somewhat 
> vague on fragments that some HTTP client implementations strip the 
> fragment, we have the case in our implementation of WinINET.
>
> So would like to propose that wording be added in 2.1.1 to the effect 
> that “There are many ways to perform the redirection and the fact that 
> some HTTP client implementations strip the fragment so take this into 
> consideration when choosing a redirect technology.” It might be also 
> good to add an example of a different style redirect as I believe all 
> the samples use 302 .
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>   

From bcampbell@pingidentity.com  Thu May 26 14:08: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 BB98EE07A9 for ; Thu, 26 May 2011 14:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level: 
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 XP27gWdpyk5k for ; Thu, 26 May 2011 14:08:31 -0700 (PDT)
Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 4B04EE0694 for ; Thu, 26 May 2011 14:08:30 -0700 (PDT)
Received: from mail-qw0-f49.google.com ([209.85.216.49]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTd7BS44fZAxDiyPHhWHZ5U4e95ybPs9N@postini.com; Thu, 26 May 2011 14:08:31 PDT
Received: by mail-qw0-f49.google.com with SMTP id 2so976377qwi.8 for ; Thu, 26 May 2011 14:08:27 -0700 (PDT)
Received: by 10.224.26.211 with SMTP id f19mr1043288qac.328.1306444106056; Thu, 26 May 2011 14:08:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.11.148 with HTTP; Thu, 26 May 2011 14:07:56 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583C9D1D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:       <90C41DD21FB7C64BB94121FBBC2E723447583C9D1D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Brian Campbell 
Date: Thu, 26 May 2011 15:07:56 -0600
Message-ID: 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 May 2011 21:08:32 -0000

A new document describing client authentication using assertions via
HTTP parameters that *does not* expand to encompass all assertion
related business, I believe, will also produce a useful document
structure.  At the same time it introduces fewer changes, while still
arriving at the same functionality, to documents that I thought were
being pushed towards last call.  It just seems to me that that option
should be on the table as well.  Just because two things both use the
word "assertion" doesn't necessarily mean they belong together.


On Wed, May 25, 2011 at 9:22 PM, Eran Hammer-Lahav  wr=
ote:
> We are taking multiple paths trying to find the best balance.
>
> There is an effort to draft a new document describing client authenticati=
on using assertions. That effort seems to expand to encompass all assertion=
 related business. I'm supportive of that approach. This document may or ma=
y not swallow the SAML bearer document - I don't have an opinion on that.
>
> There is another effort to take a narrow approach and to simply move the =
common fragment (the 'assertion' parameter) out of the SAML bearer spec and=
 back into v2. I'm also supportive of that approach. This is the proposed t=
ext listed below.
>
> How can I be supportive of both? Well, both sounds promising and will pro=
duce a useful document structure. However, as someone who has no intention =
of using assertions of any kind with OAuth, I can't really say which will m=
ake developers' life easier.
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Anthony Nadalin
>> Sent: Wednesday, May 25, 2011 3:03 PM
>> To: Brian Campbell
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
>> subsection on assertions
>>
>> So the separate document was already discussed in the design team and in
>> the meeting on Monday, the action item was given to look at creating a
>> separate document for assertion covering authentication and authorizatio=
n.
>>
>> -----Original Message-----
>> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>> Sent: Wednesday, May 25, 2011 12:22 PM
>> To: Anthony Nadalin
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
>> subsection on assertions
>>
>> It's not exactly clear to me what that means.
>>
>> Near the end of the interim meeting on Monday there was a specific
>> discussion that resulted in a TODO item to draft a 4.5.1 subsection.
>> That's what I've done here and I believe it captures the intent discusse=
d at
>> the meeting. =A0I've written a small proposal for specific text to be in=
cluded in
>> the core specification and described the subsequent changes (simplificat=
ions
>> actually) that would follow in companion specification.
>>
>> I've made a specific and actionable proposal. =A0I'm happy to discuss th=
e merits
>> of the proposal and if the WG should accept it or not.
>>
>> If you feel that your proposal of a separate document is more appropriat=
e,
>> I'd suggest you actually write such a document and describe how it impac=
ts
>> existing drafts so that it can be reviewed and discussed. My understandi=
ng
>> (Chairs, correct me if I'm wrong) is that such a document would need to =
be
>> accepted as a working group item in order to be referenced from draft-ie=
tf-
>> oauth-v2 or used/referenced by draft-ietf-oauth-saml2.
>>
>> On Wed, May 25, 2011 at 11:07 AM, Anthony Nadalin
>>  wrote:
>> > In our case they are tightly bound as the assertions (same assertion) =
will be
>> used for authentication and also to grant authorization as this is what =
was in
>> scope with WRAP, so not addressing the assertion authentication is an is=
sue
>> for us and I assume others also.
>> >
>> > -----Original Message-----
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>> > Sent: Wednesday, May 25, 2011 6:54 AM
>> > To: Anthony Nadalin
>> > Cc: oauth
>> > Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
>> > subsection on assertions
>> >
>> > That is another way to approach it and I understand there has been
>> > some talk about that lately. =A0While there are admittedly some
>> > commonalities between assertion based grants and an HTTP parameter
>> based client authentication extension point, I personally think that lum=
ping
>> them together is unnecessarily confusing. =A0 It is also a more signific=
ant change
>> and it seems like, at this point in the process, it might be better to a=
im for
>> more concise and targeted changes.
>> >
>> >
>> > On Tue, May 24, 2011 at 1:01 PM, Anthony Nadalin
>>  wrote:
>> >> I think that this will be better moved into a separate document on
>> >> assertions (were both authorization and authentication are talked
>> >> about) and not to include in 4.5.1 but would like to see a reference
>> >> in 4.5.1 to the new document
>> >>
>> >> -----Original Message-----
>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >> Behalf Of Brian Campbell
>> >> Sent: Tuesday, May 24, 2011 7:25 AM
>> >> To: oauth
>> >> Subject: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
>> >> subsection on assertions
>> >>
>> >> One of the action items out of yesterday's meeting was to draft some =
text
>> for a section 4.5.1 in core that defined the optional but recommended us=
e of
>> an "assertion" parameter for extension grants where the use of a single
>> parameter to carry the grant/assertion was possible. =A0Below is a first=
 cut at
>> some proposed text that hopefully avoids some of the awkwardness that
>> EHL described in previous attempts to introduce such a
>> parameter. =A0Comments or edits or editorial improvements are, of course=
,
>> welcome. =A0But I think this hopefully captures the intent of what was
>> discussed yesterday (and before).
>> >>
>> >> If we get some consensus to make this change, I think a couple of oth=
er
>> actions are implied.
>> >>
>> >> - The IANA assertion parameter registration request
>> >> (http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04#section-
>> >> 4
>> >> .1) should be removed from the SAML draft and put into
>> >> http://tools.ietf.org/html/draft-ietf-oauth-v2
>> >>
>> >> - The http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 spec
>> >> will change the parameter it uses from jwt to assertion and drop the
>> >> registration request for jwt
>> >> (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00#section-4=
.
>> >> 1)
>> >>
>> >>
>> >> --- proposed text for sections 4.5 & 4.5.1 ---
>> >>
>> >> 4.5. Extensions
>> >>
>> >> =A0 The client uses an extension grant type by specifying the grant
>> >> type
>> >> =A0 using an absolute URI (defined by the authorization server) as th=
e
>> >> =A0 value of the "grant_type" parameter of the token endpoint, and by
>> >> =A0 adding any additional parameters necessary.
>> >>
>> >> =A0 If the access token request is valid and authorized, the
>> >> =A0 authorization server issues an access token and optional refresh
>> >> =A0 token as described in Section 5.1. =A0If the request failed clien=
t
>> >> =A0 authentication or is invalid, the authorization server returns an
>> >> =A0 error response as described in Section 5.2.
>> >>
>> >> 4.5.1 Assertion Based Extension Grants
>> >>
>> >> =A0If the value of the extension grant can be serialized into a singl=
e
>> >> =A0parameter, as is case with a number of assertion formats, it is
>> >> =A0RECOMMENDED that that a parameter named "assertion" be used to
>> >> =A0carry the value.
>> >>
>> >> =A0 assertion
>> >> =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion. The format and encoding o=
f the
>> >> =A0 =A0 =A0 =A0 =A0 =A0 assertion is defined by the authorization ser=
ver or
>> >> =A0 =A0 =A0 =A0 =A0 =A0 extension specification.
>> >>
>> >> =A0 For example, to request an access token using a SAML 2.0 assertio=
n
>> >> =A0 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the clien=
t
>> >> =A0 makes the following HTTP request using transport-layer security
>> >> (line
>> >> =A0 breaks are for display purposes only):
>> >>
>> >> =A0 POST /token HTTP/1.1
>> >> =A0 Host: server.example.com
>> >> =A0 Content-Type: application/x-www-form-urlencoded
>> >>
>> >> =A0 grant_type=3Dhttp%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%
>> 2F
>> >> =A0 bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUt
>> M
>> >> =A0 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
>> >> _______________________________________________
>> >> 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 wmills@yahoo-inc.com  Thu May 26 19:22: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 01AFFE069D for ; Thu, 26 May 2011 19:22:57 -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 1Bf3L7GRRj0Q for ; Thu, 26 May 2011 19:22:56 -0700 (PDT)
Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with SMTP id 84085E066C for ; Thu, 26 May 2011 19:22:55 -0700 (PDT)
Received: from [98.139.212.144] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 02:22:52 -0000
Received: from [98.139.212.199] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2011 02:22:52 -0000
Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 27 May 2011 02:22:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 266920.59039.bm@omp1008.mail.bf1.yahoo.com
Received: (qmail 23959 invoked by uid 60001); 27 May 2011 02:22:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306462971; bh=PupNaaeQbmfY5W06q90yz8v+Vsb6H86wHTr7mZtsjQ4=; 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=duwOTnUAhKdx6LTUcsUtnzg1ZggJRYfk37gNKcS5Hq4KGjSTcMjcamCyHSssK76G/6VBbBg/hyaY4dchOtEe+fNGI4H/EK/Zsl1Y+tGpVPnm0CoLUSIUa9dAQUNm9xDFKMcniLtrkYY3ca72qLlxrdyW/oSnGDO+5j1utApOgJ8=
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=pbYf6+7H9WBm0G2ZcesQVaJSDTfkkKZSo835r5c8MVEgvwJ4R73KbUNlGZ8jdf0reLmpuc5YBL8fCzuEPNcqMt6Gi7qrlbsIB0qCmUWWgyaLlh5JaLc/IYmThRKOdEpxWlzrHjuI26CsHNWMZvRU+ZyZptkbXJqHl9w5mJaGuc8=;
X-YMail-OSG: ulHUuZUVM1mWfsYA6UKKvI1HHn1vUx6hFoFv0WpEnH8XytF qXnymz.6mNBrkZZx0qBXFUUqR0br4I4Z3xTtkbVhUj9F6JRCui_Eev9CcwaB VD5zkkP3BTwzngSWrJzl_ldFRoEDU4hRybQDT08j1uhfcQAytB8gN6qogG8t qw0.dJYXeT.UtRRETWtwMXjNWHmFEoTpAGXMbMNoO4hyt06TY9DtCWjAmcV5 WX2L1TvFf_cWAxABGDkGlVVsDmd7Qh83TmvVL1XjkHpuKkxWD7mGwYNkqcEO S6WvTpn_W3W8KPZJ2GBu.fYeiGVahGCcBZh8lUvfPdPIphyhT93E0lpJmvN. mv0iugb9F7awt19_sczOV_bFcmPJYp4wPcfzOFwbtTYOQGY0fZNfxgT4NsPl yOWwl3w--
Received: from [216.145.52.206] by web31804.mail.mud.yahoo.com via HTTP; Thu, 26 May 2011 19:22:51 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References:  <4E1F6AAD24975D4BA5B1680429673943380F6B84@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDBE9E4.7080904@aol.com>  <4E1F6AAD24975D4BA5B1680429673943380FDC35@TK5EX14MBXC203.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B168042967394338100C15@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DDE71F9.3090301@aol.com> 
Message-ID: <1306462971.23946.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Thu, 26 May 2011 19:22:51 -0700 (PDT)
From: "William J. Mills" 
To: Marius Scurtescu , George Fletcher 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1422192848-1306462971=:23946"
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] bearer token authorization header
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, 27 May 2011 02:22:58 -0000

--0-1422192848-1306462971=:23946
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, in fact one could get annoyingly confusing with tokens here and have..=
.=0A=0AAuthorization: bearer token=3D"asfd2353fasdfa235q54rdasf",plaintext=
=3D"JSON_GOES_HERE",oauth_signature=3D"mysig"=0A=0Aand the token would be =
=0A=0A=0A=A0=A0=A0=A0 token=3D"asfd2353fasdfa235q54rdasf",plaintext=3D"JSON=
_GOES_HERE",oauth_signature=3D"mysig"=0A=0A=0A=0A__________________________=
______=0AFrom: Marius Scurtescu =0ATo: George Fletch=
er =0ACc: OAuth WG =0ASent: Thursday, May=
 26, 2011 9:15 AM=0ASubject: Re: [OAUTH-WG] bearer token authorization head=
er=0A=0AMaybe I created some confusion. Earlier in the thread I was wonderi=
ng=0Awhy isn't the part after the scheme name a list of name/value pairs.=
=0AIf it was, then the authorization header would look like:=0A=0ABearer to=
ken=3Dasfd2353fasdfa235q54rdasf=0A=0Aand the actual token would be just asf=
d2353fasdfa235q54rdasf, and it=0Ashould be encoded as a quoted string if it=
 contained special=0Acharacters.=0A=0ABut this is not what the spec current=
ly say. The part after the scheme=0Aname is simply the token, no encoding o=
r names or lists. Also, the=0Aspec defines the set of legal characters that=
 can show up in a token=0A(this limits what tokens can an AS issue). With t=
he current spec the=0Aheader would look like:=0A=0ABearer asfd2353fasdfa235=
q54rdasf=0A=0AThe =3D character is a legal character inside a token, and it=
 has no=0Aspecial meaning.=0A=0AI hope this helps, and I hope I got it righ=
t,=0AMarius=0A=0A=0A=0AOn Thu, May 26, 2011 at 8:30 AM, George Fletcher  wrote:=0A> So just to make sure that I'm clear... The follo=
wing is ok...=0A>=0A> The AS and RO decide that the token will be comprised=
 of both a name and=0A> value part. So the whole token looks like 'token=3D=
asfd2353fasdfa235q54rdasf'.=0A> From the protocol perspective, the access t=
oken is the entire string, even=0A> if it looks like to the developer that =
only the 'asfd2353fasdfa235q54rdasf'=0A> part is the token. As a developer =
I find this confusing, but I think I now=0A> understand why the 'token=3Das=
fd2353fasdfa235q54rdasf' is legal.=0A>=0A> The key is that the client has t=
o treat the response from the AS as opaque=0A> (as Paul mentioned) and just=
 put it in the Authorization header as=0A> 'Authorization: Bearer " =
regardless of what the resulting header=0A> looks like.=0A>=0A> Thanks,=0A>=
 George=0A>=0A> On 5/25/11 1:15 PM, Mike Jones wrote:=0A>=0A> What you quot=
ed below was the acceptable syntax.=A0 The Authorization Server=0A> and the=
 Resource Server still need to agree upon the semantics of the bearer=0A> t=
oken exchanged.=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  -- Mike=0A>=0A> ---=
--Original Message-----=0A> From: John Kemp [mailto:john@jkemp.net]=0A> Sen=
t: Wednesday, May 25, 2011 10:11 AM=0A> To: Mike Jones=0A> Cc: Marius Scurt=
escu; George Fletcher; OAuth WG=0A> Subject: Re: [OAUTH-WG] bearer token au=
thorization header=0A>=0A> On May 24, 2011, at 4:04 PM, Mike Jones wrote:=
=0A>=0A> George, you are correct that resources and clients must agree upon=
 the=0A> format of the bearer token to achieve interoperability.=A0 The mea=
ns for=0A> achieving this agreement is out of the scope of this document.=
=0A>=0A> I thought the means for achieving IOP was quite precisely describe=
d in the=0A> production below (excerpted from 2.1 of=0A> http://tools.ietf.=
org/html/draft-ietf-oauth-v2-bearer-04):=0A>=0A>=A0 =A0 credentials=A0 =A0 =
=3D "Bearer" RWS access-token=0A>=0A>=A0 =A0 access-token=A0  =3D 1*( quote=
d-char / <"> )=0A>=0A>=A0 =A0 quoted-char=A0 =A0 =3D=A0  "!" / "#" / "$" / =
"%" / "&" / "'" / "("=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  / ")" / "=
*" / "+" / "-" / "." / "/" / DIGIT=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0  / ":" / "<" / "=3D" / ">" / "?" / "@" / ALPHA=0A>=A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0  / "[" / "]" / "^" / "_" / "`" / "{" / "|"=0A>=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0  / "}" / "~" / "\" / "," / ";"=0A>=0A> - Jo=
hn=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0  -- Mike=0A>=0A> -----Original Messag=
e-----=0A> From: Marius Scurtescu [mailto:mscurtescu@google.com]=0A> Sent: =
Tuesday, May 24, 2011 11:28 AM=0A> To: George Fletcher=0A> Cc: Mike Jones; =
OAuth WG=0A> Subject: Re: [OAUTH-WG] bearer token authorization header=0A>=
=0A> The "printable non-whitespace ASCII characters" represents the access =
token,=0A> which is supposed to be opaque. I don't think this affects libra=
ries.=0A>=0A> Marius=0A>=0A>=0A>=0A> On Tue, May 24, 2011 at 10:24 AM, Geor=
ge Fletcher  wrote:=0A>=0A> Do I understand this correctl=
y that each resource owner can define=0A> it's own format for the "printabl=
e non-whitespace ASCII characters"?=0A> It seems like that would make it di=
fficult for clients to use=0A> standard libraries because the Authorization=
 header format could be=0A> different on a per resource/host basis.=0A>=0A>=
 Thanks,=0A> George=0A>=0A> On 5/23/11 3:10 PM, Mike Jones wrote:=0A>=0A> [=
snip]=0A>=0A>=0A>=0A> The fact that there is no escaping mechanism can pote=
ntially create=0A> problems. The list of allowed characters is spelled out,=
 but what if=0A> some implementation uses other characters? Using a name va=
lue pair=0A> and proper escaping is much safer IMO. For example:=0A>=0A> Be=
arer token=3Ddfgh76dfghdfg=0A>=0A> or=0A>=0A> Bearer token=3D"dfgh76dfghdfg=
"=0A>=0A>=0A>=0A> The value above can be either a token or a quoted string.=
 HTTP header=0A> parsers know how to parse tokens and quoted strings so an =
implementor=0A> has a better chance of doing it right.=0A>=0A>=0A>=0A> Mark=
 Lentczner started a thread on this regard a few moths ago, James=0A> Mange=
r replied and suggested something similar:=0A>=0A> http://www.ietf.org/mail=
-archive/web/oauth/current/msg04671.html=0A>=0A>=0A>=0A> If it is too late =
to switch to a name/value pair, then I think we=0A> should at least clean u=
p the references.=0A>=0A> The definition allows the access token to be any =
string of one or=0A> more printable non-whitespace ASCII characters.=A0 Thu=
s, legal access=0A> token strings include ones like the ones you are asking=
 for, such as:=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 param=3D"value"=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> -----Original Message-----=0A> From: Marius Scurtescu [mailto:mscu=
rtescu@google.com]=0A> Sent: Monday, May 09, 2011 10:32 AM=0A> To: OAuth WG=
; Mike Jones=0A> Cc: Mark Lentczner; Manger, James H=0A> Subject: bearer to=
ken authorization header=0A>=0A>=0A>=0A> I am working through version 04 of=
 the Bearer Token draft:=0A>=0A> http://tools.ietf.org/html/draft-ietf-oaut=
h-v2-bearer-04=0A>=0A>=0A>=0A> Not sure how to interpret the authorization =
header grammar described=0A> in section 2.1. The intent seems to be for som=
ething like:=0A>=0A> Bearer dfgh76dfghdfg=0A>=0A>=0A>=0A> After the scheme =
name, "Bearer", there is a required whitespace=0A> followed by the actual t=
oken. The token is represented by a sequence=0A> of printable characters, n=
o escaping. No spaces or other elements are=0A> allowed after the token. Is=
 that correct?=0A>=0A>=0A>=0A> RWS is not defined, I assume it is the "requ=
ired whitespace" from=0A> section=0A> 1.2.2 of:=0A>=0A> http://tools.ietf.o=
rg/html/draft-ietf-httpbis-p1-messaging-13=0A>=0A>=0A>=0A> There is a refer=
ence to RFC2617, but not sure why. That seems to=0A> imply that a list of v=
alues can be specified, which is not the case.=0A>=0A>=0A>=0A> The fact tha=
t there is no escaping mechanism can potentially create=0A> problems. The l=
ist of allowed characters is spelled out, but what if=0A> some implementati=
on uses other characters? Using a name value pair=0A> and proper escaping i=
s much safer IMO. For example:=0A>=0A> Bearer token=3Ddfgh76dfghdfg=0A>=0A>=
 or=0A>=0A> Bearer token=3D"dfgh76dfghdfg"=0A>=0A>=0A>=0A> The value above =
can be either a token or a quoted string. HTTP header=0A> parsers know how =
to parse tokens and quoted strings so an implementor=0A> has a better chanc=
e of doing it right.=0A>=0A>=0A>=0A> Mark Lentczner started a thread on thi=
s regard a few moths ago, James=0A> Manger replied and suggested something =
similar:=0A>=0A> http://www.ietf.org/mail-archive/web/oauth/current/msg0467=
1.html=0A>=0A>=0A>=0A> If it is too late to switch to a name/value pair, th=
en I think we=0A> should at least clean up the references.=0A>=0A>=0A>=0A> =
Marius=0A>=0A>=0A>=0A> _______________________________________________=0A> =
OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/list=
info/oauth=0A>=0A>=0A> _______________________________________________=0A> =
OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/list=
info/oauth=0A>=0A_______________________________________________=0AOAuth ma=
iling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--0-1422192848-1306462971=:23946
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


    Yes, in fact one could get annoyingly confusing with tokens here and have=
...

    Authorization: beare=
r token=3D"asfd2353fasdfa235q54rdasf",plaintext=3D"JSON=
_GOES_HERE",oauth_signature=3D"mysig"

    and the toke=
n would be 

         token=3D"asfd2353fasdfa235q54rdasf",plaintext=3D"JSON_GOES_HERE",oauth_=
signature=3D"mysig"=0A

    =0A
    =0A

    From: Marius Scurtescu <mscurtescu=
@google.com>
    To: Geo=
rge Fletcher <gffletch@aol.com>
    Cc: OAuth WG <oauth@ietf.org>
    Sent: Thursday, May 26, 2011 9:15 AM
    Subject: Re: [OAUTH-WG] bearer to=
ken authorization header

    =0AMaybe I created some confusion. E=
arlier in the thread I was wondering
    why isn't the part after the scheme=
 name a list of name/value pairs.
    If it was, then the authorization head=
er would look like:

    Bearer token=3Dasfd2353fasdfa235q54rdasf

    =
and the actual token would be just asfd2353fasdfa235q54rdasf, and it
    sho=
uld be encoded as a quoted string if it contained special
    characters.
    But this is not what the spec currently say. The part after the scheme=

    name is simply the token, no encoding or names or lists. Also, the
    s=
pec defines the set of legal characters that can show up in a token
    (thi=
s limits what tokens can an AS issue). With the current spec the
    header =
would look like:

    Bearer asfd2353fasdfa235q54rdasf

    The =3D cha=
racter is a legal character inside a token, and it has no
    special meanin=
g.

    I hope this helps, and I hope I got it right,
    Marius


    On Thu, May 26, 2011 at 8:30 AM,
 George Fletcher <gffletch@aol.com> wrote:
    > So just to make s=
ure that I'm clear... The following is ok...
    >
    > The AS and RO =
decide that the token will be comprised of both a name and
    > value pa=
rt. So the whole token looks like 'token=3Dasfd2353fasdfa235q54rdasf'.
    &=
gt; From the protocol perspective, the access token is the entire string, e=
ven
    > if it looks like to the developer that only the 'asfd2353fasdfa=
235q54rdasf'
    > part is the token. As a developer I find this confusin=
g, but I think I now
    > understand why the 'token=3Dasfd2353fasdfa235q=
54rdasf' is legal.
    >
    > The key is that the client has to treat =
the response from the AS as opaque
    > (as Paul mentioned) and just put=
 it in the Authorization header as
    > 'Authorization: Bearer <token=
>" regardless of what the resulting header
    > looks
 like.
    >
    > Thanks,
    > George
    >
    > On 5/25/11 1:=
15 PM, Mike Jones wrote:
    >
    > What you quoted below was the acce=
ptable syntax.  The Authorization Server
    > and the Resource Serv=
er still need to agree upon the semantics of the bearer
    > token excha=
nged.
    >
    >               =
;  -- Mike
    >
    > -----Original Message-----
    > From: John Ke=
mp [mailto:john@jkemp.net]
    > Sent: Wednesday, May 25, 2011 10:11 AM
    &=
gt; To: Mike Jones
    > Cc: Marius Scurtescu; George Fletcher; OAuth WG<=
br>> Subject: Re: [OAUTH-WG] bearer token authorization header
    >> On May 24, 2011, at 4:04 PM, Mike Jones wrote:
    >
    > Georg=
e, you are correct that resources and clients must agree upon the
    > f=
ormat of the bearer token to achieve interoperability.  The means
 for
    > achieving this agreement is out of the scope of this document.=

    >
    > I thought the means for achieving IOP was quite precisely =
described in the
    > production below (excerpted from 2.1 of
    > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04):<=
br>>
    >    credentials    =3D "Bearer" RWS acce=
ss-token
    >
    >    access-token   =3D 1*( quoted-ch=
ar / <"> )
    >
    >    quoted-char    =3D&=
nbsp;  "!" / "#" / "$" / "%" / "&" / "'" / "("
    >    &nb=
sp;                / ")" / "*" / "+" / "=
-" / "." / "/" / DIGIT
    >            &nb=
sp;        / ":" / "<" / "=3D" / ">" / "?" / "@" / ALP=
HA
    >                  &n=
bsp;  /
 "[" / "]" / "^" / "_" / "`" / "{" / "|"
    >       =
              / "}" / "~" / "\" / "," / ";">
    > - John
    >
    >          &nb=
sp;    -- Mike
    >
    > -----Original Message-----
    > From=
: Marius Scurtescu [mailto:mscurtescu@google.com]
    > Sent: =
Tuesday, May 24, 2011 11:28 AM
    > To: George Fletcher
    > Cc: Mike=
 Jones; OAuth WG
    > Subject: Re: [OAUTH-WG] bearer token authorization=
 header
    >
    > The "printable non-whitespace ASCII characters" rep=
resents the access token,
    > which is supposed to be opaque. I don't t=
hink this affects libraries.
    >
    > Marius
    >
    >
    >=

    > On Tue, May 24, 2011 at 10:24 AM, George Fletcher <gffletch@aol.com> wrote:
    >> Do I understand this correctly that each resource owner can define> it's own format for the "printable non-whitespace ASCII characters"?=

    > It seems like that would make it difficult for clients to use
    &=
gt; standard libraries because the Authorization header format could be
    =
> different on a per resource/host basis.
    >
    > Thanks,
    >=
; George
    >
    > On 5/23/11 3:10 PM, Mike Jones wrote:
    >
    &=
gt; [snip]
    >
    >
    >
    > The fact that there is no escapi=
ng mechanism can potentially create
    > problems. The list of allowed c=
haracters is spelled out, but what if
    > some implementation uses othe=
r characters? Using a name value pair
    > and proper escaping is much s=
afer IMO. For example:
    >
    > Bearer token=3Ddfgh76dfghdfg
    >=

    > or
    >
    > Bearer
 token=3D"dfgh76dfghdfg"
    >
    >
    >
    > The value above ca=
n be either a token or a quoted string. HTTP header
    > parsers know ho=
w to parse tokens and quoted strings so an implementor
    > has a better=
 chance of doing it right.
    >
    >
    >
    > Mark Lentczner s=
tarted a thread on this regard a few moths ago, James
    > Manger replie=
d and suggested something similar:
    >
    > http://www.ietf.org/mail=
-archive/web/oauth/current/msg04671.html
    >
    >
    >
    > If=
 it is too late to switch to a name/value pair, then I think we
    > sho=
uld at least clean up the references.
    >
    > The definition allows=
 the access token to be any string of one or
    > more printable non-whi=
tespace ASCII characters.  Thus, legal access
    > token strings in=
clude ones like the ones you are asking for, such as:
    >
    > =
              
 param=3D"value"
    >
    >
    >
    >       =
                     &nbs=
p;                     &n=
bsp;          -- Mike
    >
    >
    >
    > -=
----Original Message-----
    > From: Marius Scurtescu [mailto:msc=
urtescu@google.com]
    > Sent: Monday, May 09, 2011 10:32 AM
    >=
 To: OAuth WG; Mike Jones
    > Cc: Mark Lentczner; Manger, James H
    &g=
t; Subject: bearer token authorization header
    >
    >
    >
    &g=
t; I am working through version 04 of the Bearer Token draft:
    >
    &g=
t; http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
    >
    >=

    >
    > Not sure how to interpret the authorization header grammar=
 described
    > in section 2.1. The intent seems to be for something
 like:
    >
    > Bearer dfgh76dfghdfg
    >
    >
    >
    >=
 After the scheme name, "Bearer", there is a required whitespace
    > fo=
llowed by the actual token. The token is represented by a sequence
    > =
of printable characters, no escaping. No spaces or other elements are
    &g=
t; allowed after the token. Is that correct?
    >
    >
    >
    >=
; RWS is not defined, I assume it is the "required whitespace" from
    >=
 section
    > 1.2.2 of:
    >
    > http://tools.ietf.org/html/draft=
-ietf-httpbis-p1-messaging-13
    >
    >
    >
    > There is a re=
ference to RFC2617, but not sure why. That seems to
    > imply that a li=
st of values can be specified, which is not the case.
    >
    >
    &g=
t;
    > The fact that there is no escaping mechanism can potentially cre=
ate
    > problems. The list of allowed characters is spelled out, but wh=
at if
    > some implementation uses other characters? Using a
 name value pair
    > and proper escaping is much safer IMO. For example=
:
    >
    > Bearer token=3Ddfgh76dfghdfg
    >
    > or
    >> Bearer token=3D"dfgh76dfghdfg"
    >
    >
    >
    > The v=
alue above can be either a token or a quoted string. HTTP header
    > pa=
rsers know how to parse tokens and quoted strings so an implementor
    >=
 has a better chance of doing it right.
    >
    >
    >
    > Mar=
k Lentczner started a thread on this regard a few moths ago, James
    > =
Manger replied and suggested something similar:
    >
    > http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
    >
    >
    >
    > If it is too late to switch to a name/va=
lue pair, then I think we
    > should at least clean up the references.<=
br>>
    >
    >
    > Marius
    >
    >
    >
    >
 _______________________________________________
    > OAuth mailing list=

    >     OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth=

    >
    >
    > _______________________________________________> OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/m=
ailman/listinfo/oauth
    >
    ______________________________________=
_________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailm=
an/listinfo/oauth


    
--0-1422192848-1306462971=:23946--

From eran@hueniverse.com  Fri May 27 08:04: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 4ACF4E0713 for ; Fri, 27 May 2011 08:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.728
X-Spam-Level: 
X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 co-Af7GxTcv8 for ; Fri, 27 May 2011 08:04:37 -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 AE778E06F8 for ; Fri, 27 May 2011 08:04:37 -0700 (PDT)
Received: (qmail 3781 invoked from network); 27 May 2011 15:04:35 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 May 2011 15:04:35 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 27 May 2011 08:04:35 -0700
From: Eran Hammer-Lahav 
To: "igor.faynberg@alcatel-lucent.com" 
Date: Fri, 27 May 2011 08:04:26 -0700
Thread-Topic: [OAUTH-WG] Redirect Issues
Thread-Index: Acwcf2QArK3Q2aE4TUW8zjlk7AoHpQ==
Message-ID: <43D0A626-E12D-4C20-AF40-52BD30FDD833@hueniverse.com>
References:  <4DDE863B.2080400@alcatel-lucent.com>
In-Reply-To: <4DDE863B.2080400@alcatel-lucent.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "OAuth WG \(oauth@ietf.org\)" 
Subject: Re: [OAUTH-WG] Redirect Issues
X-BeenThere: oauth@ietf.org
X-Mailman-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, 27 May 2011 15:04:38 -0000

VGhhdCdzIG5ldmVyIGdvaW5nIHRvIGJlIGNvbXBsZXRlIGFuZCB3aWxsIGJlIG91dCBvZiBkYXRl
IGJlZm9yZSB0aGUgUkZDIGlzIG91dC4gQW5vdGhlciBleGFtcGxlIGlzIGEgZ29vZCBpZGVhLiAN
Cg0KRUhMDQoNCk9uIE1heSAyNiwgMjAxMSwgYXQgMTA6MTAsICJJZ29yIEZheW5iZXJnIiA8aWdv
ci5mYXluYmVyZ0BhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+IEFjdHVhbGx5LCBJIHdv
dWxkIGdvIGV2ZW4gZnVydGhlcjogUHJvdmlkZSBhIGxpc3Qgb2YgZGlmZmVyZW50IHdheXMgb2Yg
DQo+IHJlZGlyZWN0aW5nIGFuZCBhZGRyZXNzIGVhY2ggb2YgdGhlbSwgb3IgYXQgbGVhc3QgZWFj
aCBjbGFzcyBvZiANCj4gcmVkaXJlY3RzIHdpdGggdGhlIHNhbWUgY2hhcmFjdGVyaXN0aWNzLg0K
PiANCj4gSWdvcg0KPiANCj4gQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KPj4gDQo+PiBUaGUgT0F1
dGggc3BlYyBpcyBzb21ld2hhdCBzaWxlbnQgYWJvdXQgaG93IGEgcmVzb3VyY2UgcHJvdmlkZXIg
c2hvdWxkIA0KPj4gcGVyZm9ybSBhIHJlZGlyZWN0IGFzIHRoZXJlIGFyZSBtYW55IHdheXMgdG8g
YWNjb21wbGlzaCB0aGUgcmVkaXJlY3QuIA0KPj4gV2UgYWxzbyBkaXNjb3ZlcmVkIHRoYXQgc2lu
Y2UgdGhlIEhUVFAgc3BlY2lmaWNhdGlvbnMgd2VyZSBzb21ld2hhdCANCj4+IHZhZ3VlIG9uIGZy
YWdtZW50cyB0aGF0IHNvbWUgSFRUUCBjbGllbnQgaW1wbGVtZW50YXRpb25zIHN0cmlwIHRoZSAN
Cj4+IGZyYWdtZW50LCB3ZSBoYXZlIHRoZSBjYXNlIGluIG91ciBpbXBsZW1lbnRhdGlvbiBvZiBX
aW5JTkVULg0KPj4gDQo+PiBTbyB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCB3b3JkaW5nIGJl
IGFkZGVkIGluIDIuMS4xIHRvIHRoZSBlZmZlY3QgDQo+PiB0aGF0IOKAnFRoZXJlIGFyZSBtYW55
IHdheXMgdG8gcGVyZm9ybSB0aGUgcmVkaXJlY3Rpb24gYW5kIHRoZSBmYWN0IHRoYXQgDQo+PiBz
b21lIEhUVFAgY2xpZW50IGltcGxlbWVudGF0aW9ucyBzdHJpcCB0aGUgZnJhZ21lbnQgc28gdGFr
ZSB0aGlzIGludG8gDQo+PiBjb25zaWRlcmF0aW9uIHdoZW4gY2hvb3NpbmcgYSByZWRpcmVjdCB0
ZWNobm9sb2d5LuKAnSBJdCBtaWdodCBiZSBhbHNvIA0KPj4gZ29vZCB0byBhZGQgYW4gZXhhbXBs
ZSBvZiBhIGRpZmZlcmVudCBzdHlsZSByZWRpcmVjdCBhcyBJIGJlbGlldmUgYWxsIA0KPj4gdGhl
IHNhbXBsZXMgdXNlIDMwMiAuDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gT0F1dGggbWFp
bGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KPj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9y
Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

From Michael.Jones@microsoft.com  Fri May 27 14:08: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 33E9FE0746 for ; Fri, 27 May 2011 14:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.723
X-Spam-Level: 
X-Spam-Status: No, score=-10.723 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 XjLZ+STQ0PjQ for ; Fri, 27 May 2011 14:08:27 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 325AEE0711 for ; Fri, 27 May 2011 14:08:27 -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; Fri, 27 May 2011 14:08:26 -0700
Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.57]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0289.008; Fri, 27 May 2011 14:08:26 -0700
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Question on action item to make RedirectURI optional
Thread-Index: Acwcsi+yhhFkBPRtRnyKZ3zOMHAQgw==
Date: Fri, 27 May 2011 21:08:25 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.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.74]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394338105183TK5EX14MBXC203r_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 27 May 2011 21:08:28 -0000

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

The minutes from the special meeting included:

TODO: Eran to add extensibility language for this based on requirements.

-    "RedirectURI" should be optional

TODO: Eran to send mail to the list proposing language changes to either ch=
ange this from REQUIRED to OPTIONAL and add clarifying language, or leave a=
s required and add a pre-defined value for "we're not actually using this".
Is this proposed change just limited to section 4.5?  It seems to make sens=
e to have redirect_uri  be optional in section 4.1.3 as well (access token =
request using grant_type authorization code).  Since this request is made d=
irectly from the client to the authorization server, I don't see why this w=
ould be required.  For at least some implementations of the 3-legged flow, =
it would make sense to not have this be a requirement.

Comments?

                                                                Thanks,
                                                                -- Mike


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









    

    The minutes from the s=
pecial meeting included:
    

     
    

    
TODO: Eran to add extensibility language for this based on requiremen=
ts.
    

    
-    "RedirectURI" should be optional
    

    
TODO: Eran to send mail to the list proposing language changes to either ch=
ange this from REQUIRED to OPTIONAL and add clarifying language, or leave a=
s required and add a pre-defined value for "we're not actually using t=
his".    =

    

    Is this proposed chang=
e just limited to section 4.5?  It seems to make sense to have redirec=
t_uri  be optional in section 4.1.3 as well (access token request usin=
g grant_type authorization code).  Since this
 request is made directly from the client to the authorization server, I do=
n’t see why this would be required.  For at least some implement=
ations of the 3-legged flow, it would make sense to not have this be a requ=
irement.
    

     
    

    Comments?
    

     
    

       &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;          Thanks,=

    

       &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;          -- Mike=

    

     
    

    



--_000_4E1F6AAD24975D4BA5B168042967394338105183TK5EX14MBXC203r_--

From torsten@lodderstedt.net  Sat May 28 04:44: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 CC7B4E0745 for ; Sat, 28 May 2011 04:44:11 -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 Eo1lJMaC2Z1e for ; Sat, 28 May 2011 04:44:07 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 08A77E073C for ; Sat, 28 May 2011 04:44:05 -0700 (PDT)
Received: from [79.253.58.62] (helo=[192.168.71.27]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QQHw3-000886-Fn; Sat, 28 May 2011 13:44:03 +0200
Message-ID: <4DE0E011.5030107@lodderstedt.net>
Date: Sat, 28 May 2011 13:44:17 +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: Mike Jones 
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------000109080908050107010705"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 28 May 2011 11:44:11 -0000

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

wrt section 4.1.3
The redirect_uri parameter should at least be required if the authz 
server sent the authorization code to a redirect_uri passed in by the 
client into the authorization request.
In this case, the authorization server must bind this uri to the authz 
code and require the client to pass the same uri to the tokens endpoint 
again. This way, the authz server is able to detect authorization code 
theft by an intermediary server (which would need to use a different uri 
than the legitimate client).

regards,
Torsten.

Am 27.05.2011 23:08, schrieb Mike Jones:
>
> The minutes from the special meeting included:
>
> TODO: Eran to add extensibility language for this based on requirements.
>
> -    "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".
>
> Is this proposed change just limited to section 4.5?  It seems to make 
> sense to have redirect_uri  be optional in section 4.1.3 as well 
> (access token request using grant_type authorization code).  Since 
> this request is made directly from the client to the authorization 
> server, I don't see why this would be required.  For at least some 
> implementations of the 3-legged flow, it would make sense to not have 
> this be a requirement.
>
> Comments?
>
>                                                                 Thanks,
>
>                                                                 -- Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



  
    
  
  
    wrt section 4.1.3
    
    The redirect_uri parameter should at least be required if the authz
    server sent the authorization code to a redirect_uri passed in by
    the client into the authorization request.
    
    In this case, the authorization server must bind this uri to the
    authz code and require the client to pass the same uri to the tokens
    endpoint again. This way, the authz server is able to detect
    authorization code theft by an intermediary server (which would need
    to use a different uri than the legitimate client).
    
    
    
    regards,
    
    Torsten.
    
    
    
    Am 27.05.2011 23:08, schrieb Mike Jones:
    
    
      
      
      
      
    
        
    The
            minutes from the special meeting included:
    
        
     
    
        
    
          TODO: Eran to add extensibility
            language for this based on requirements.
    
            
    
            -    "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".
    
        
    Is
            this proposed change just limited to section 4.5?  It seems
            to make sense to have redirect_uri  be optional in section
            4.1.3 as well (access token request using grant_type
            authorization code).  Since this request is made directly
            from the client to the authorization server, I don’t see why
            this would be required.  For at least some implementations
            of the 3-legged flow, it would make sense to not have this
            be a requirement.
    
        
     
    
        
    Comments?
    
        
     
    
        
                                                                   
            Thanks,
    
        
                                                                   
            -- Mike
    
        
     
    
      
    
      
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
  


--------------000109080908050107010705--

From d.tangren@gmail.com  Sat May 28 08:47: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 8113AE06BC for ; Sat, 28 May 2011 08:47:18 -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=[AWL=-0.000, 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 5YTX9bkHvt8g for ; Sat, 28 May 2011 08:47:17 -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 9363AE0664 for ; Sat, 28 May 2011 08:47:17 -0700 (PDT)
Received: by iyn15 with SMTP id 15so3424392iyn.31 for ; Sat, 28 May 2011 08:47: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:from:date :message-id:subject:to:cc:content-type; bh=+VMwABIgl0Zb08hVv5NQUOuKXqUY32TrFEHKrgq5+48=; b=aQ6Ar/tbJxv089+7lZcRYfNgvpZz3K+DEOiB5LPB6aq8+u4WaFCwtexZ9csdkrNrAr MgUTu8a4dsK7lFFkUCZfXBuhICRLTyjNJwyIUATUk0fd+x4yGpbAH4Z61q7YNOQyeQ7B IfDxu4gjOqy82Bi5a35vD8N2hMnmr6SD9MUoE=
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=QSbi/y9GfBg3Y33V+53i+D37lBbutVKyITgmZb85bb+8g9780NiA0Rc4W0E99hkU4F 2K3KoLZsIYReSRXA7IQf6tF3883qK9VjzKV2fAYRG/a4He9IesWXsiZr2fnhnUvGb9wx 792jP/vWdaFk8yzj/+axwo+3E7lLyD1ev+bQA=
Received: by 10.42.150.73 with SMTP id z9mr5976594icv.392.1306597637028; Sat, 28 May 2011 08:47:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Sat, 28 May 2011 08:46:57 -0700 (PDT)
In-Reply-To: <4DE0E011.5030107@lodderstedt.net>
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com> <4DE0E011.5030107@lodderstedt.net>
From: Doug Tangren 
Date: Sat, 28 May 2011 11:46:57 -0400
Message-ID: 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=90e6ba6e8ecc04fc4804a457f84d
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 28 May 2011 15:47:18 -0000

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

It's easiest to remember that the redirect_uri in a access token request
must be an exact match as the one passed into the auth code request

If the pre-registered redirect_uri is http://foo.com/authed

an authorization code request's redirect_uri may be
http://foo.com/authed/bar

In the access token request for the returned code, the redirect_uri must be
http://foo.com/authed/bar



-Doug Tangren
http://lessis.me


On Sat, May 28, 2011 at 7:44 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> server

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


    It's easiest to remember that the redirect_uri in a access token r=
equest must be an exact match as the one passed into the auth code request<=
/div>

    If the pre-registered redirect_uri is http://foo.com/authed
    



    an authorization code request's redirect_uri may be=
 http://foo.com/authed/bar=C2=A0<=
/div>

    In the access token request for the returned code,=
 the redirect_uri must be=C2=A0http:/=
/foo.com/authed/bar=C2=A0
    





    -Doug Tangren
    http://lessis.me
    


    On Sat, May 28, 2011 at 7:44 AM, Torsten=
 Lodderstedt <torsten@lodderstedt.net> wrote:
    

server

    

--90e6ba6e8ecc04fc4804a457f84d--

From recordond@gmail.com  Sat May 28 09:30: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 8DEDCE0719 for ; Sat, 28 May 2011 09:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level: 
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372,  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 RQuWQJnhtU6e for ; Sat, 28 May 2011 09:30:10 -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 DA312E070B for ; Sat, 28 May 2011 09:30:09 -0700 (PDT)
Received: by vws12 with SMTP id 12so2490264vws.31 for ; Sat, 28 May 2011 09:30:09 -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=CaVQ4Jt9z0Kd74A1LckT4z8ePbnC+YqiZzhjnQwi2p8=; b=EquuCFaZ9+VgBSxJyWvP51Sk1FNvBy8pAaxaNsTzhyEPEtfKwSSjRg3ZIdAwQi80xY GPZktgnbtpGFjRs6IU75PjGNZ9bv86saX00F4OdDurx9unzR1wYkCvNY5hyv80T/zzN0 wN4rHFdVtPGe9X7+co4cMCcOQkull6fZG2YOc=
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=RnYnaTsovTLxCNJsCI5m3KfA+/VoZbpB276gfUhh/NRGTC6mfuKvnkGlatxen/UmFc b41DtHHI07H1NI7QlpO8UYDlfOuMx6QrY/p1i/eOaSVt+erza8NIPzFzRmJVBaqUEihX GeWVeUMtmQuIAHYi92F2z7va/TShN5NN4F/xk=
MIME-Version: 1.0
Received: by 10.52.76.198 with SMTP id m6mr3006598vdw.0.1306600207165; Sat, 28 May 2011 09:30:07 -0700 (PDT)
Received: by 10.52.158.202 with HTTP; Sat, 28 May 2011 09:30:07 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>
Date: Sat, 28 May 2011 09:30:07 -0700
Message-ID: 
From: David Recordon 
To: Mike Jones , Doug Tangren , "oauth@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: paul Tarjan 
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, 28 May 2011 16:30:10 -0000

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
>
>

From recordond@gmail.com  Sat May 28 09: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 AACC2E0715 for ; Sat, 28 May 2011 09:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.351
X-Spam-Level: 
X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248,  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 SCTUI9L36301 for ; Sat, 28 May 2011 09:40:43 -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 E4C43E070B for ; Sat, 28 May 2011 09:40:42 -0700 (PDT)
Received: by vxg33 with SMTP id 33so2498204vxg.31 for ; Sat, 28 May 2011 09:40:42 -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:cc :content-type; bh=8vnlcTMuzTcP2/xAQrflJaItEG1tm0d+Js8Qw4D/XaI=; b=shGC4K8B4E+/2S/GI2CH7tUMaGIi/sSHVyzjzTod/XQIGD13h9Ne6rajOhCYweeyRi a/gttvVPoSkKNN8uhNj1EP5SEmrOQPtQbb49ffw/ruASEttZ8AZqLmFygsm6sVVByhtP gn3j7Vstzz4YRK+USk5K51Wyail7wSim2gc+s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=OGttVZqBXQ0b2WRprWd3p/FtfBJ5HvIuDs23GYoiUtr/betcpYUgJOdIaUIMeIeiMz xLHL+aFUt0rJY4Sy/COZLcy4qWjlnPW9E8QnWjgYZ6cRlXIYQvrqq1M4EX2tZM59ZntR uvv6Um0+44EbukMz3ymLNvseQKnNvkBjQeQAY=
MIME-Version: 1.0
Received: by 10.52.32.102 with SMTP id h6mr2441331vdi.34.1306600842248; Sat, 28 May 2011 09:40:42 -0700 (PDT)
Received: by 10.52.158.202 with HTTP; Sat, 28 May 2011 09:40:42 -0700 (PDT)
Date: Sat, 28 May 2011 09:40:42 -0700
Message-ID: 
From: David Recordon 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Cc: paul Tarjan 
Subject: [OAUTH-WG] Referencing client_secret when making requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 28 May 2011 16:40:43 -0000

In sections 4.1.3, 4.3.2, 4.4.2 and 6 there's a list of parameters
included within the request and then the sentence, "The client
includes its authentication credentials as described in Section 3."
Reading through the spec yesterday afternoon with Paul, we first
thought that client_secret was removed from these requests between
drafts 10 and 16. This is because the list of parameters is quite
obvious but this sentence referencing section 3 sort of just blends
in.

We'd propose changing this sentence to read, "The client includes its
authentication credentials as described in Section 3. Commonly the
client_secret parameter."

Goal being that client_secret is exposed within each section
describing how to make a request in a way that holds true for most
usage but doesn't make it more confusing for clients working with SAML
(or other client authentication credentials).

--David

From d.tangren@gmail.com  Sat May 28 10:14: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 D6459E0725 for ; Sat, 28 May 2011 10:14: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=[AWL=-0.000, 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 w3r3JqeyCXJv for ; Sat, 28 May 2011 10:14:54 -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 CAB59E070C for ; Sat, 28 May 2011 10:14:53 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3422850iwn.31 for ; Sat, 28 May 2011 10:14:53 -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=i+LfiYtlUrKJH3PlMGjZ410tP1X2STv7dpsW+nS3Ing=; b=vB9PBIHqh9JpzBHld3EHPAwZBLg5OfW2DokgF2DsLIIJHGNMeqfvWRTZTyZK053g8p yj2fsVAYCa0gTCZCgdDnOBafQBtleH0n5K9ZVOd8n8ZHsomWaimd/m4nk5mICaXioIot kXP2RBaJkfq04wBcnZuQc6+JL08k6/+4mP9Ec=
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=Ph2sUgsf33kc8x2lfjHoua3rkLohn0awaOTMH6VQa17lA7oCAcMldNX893B9d1vkii Wo+sRExEYfA9EvdYWhyA18iNiWXqcaRTK0BRAu4sCMyt3zenXTbvFqlk3/UpZbuAGmpp NUv+f3i+VH3m8bUgzaMx1OzsoTU+Whb19+IoA=
Received: by 10.42.145.130 with SMTP id f2mr6281236icv.325.1306602893080; Sat, 28 May 2011 10:14:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Sat, 28 May 2011 10:14:33 -0700 (PDT)
In-Reply-To: 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> 
From: Doug Tangren 
Date: Sat, 28 May 2011 13:14:33 -0400
Message-ID: 
To: David Recordon 
Content-Type: multipart/alternative; boundary=90e6ba6134ac4df91204a4593166
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: Sat, 28 May 2011 17:14:54 -0000

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

-Doug Tangren
http://lessis.me


On Sat, May 28, 2011 at 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.
>
>
I still agree it's confusing. It also depends on which resource server token
type handling you choose. If you were going to choose
mac token types, the access_token is actually named "id" [1] in the
authorization header though its oauth2 binding suggestions the auth server
returns it as a parameter named "access_token" [2]

[1]:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-3.1
[2]:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-5.1


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.
>
>
I feel the same. My company actually needs a way to distinguish between
oauth1 [3] and oauth2 [4] because we are currently supporting both. We are
currently inspecting requests using "oauth_token" to identify oauth1
requests and "access_token" to identify oauth2 requests.

Until things get a little more finalized in the resource server specs, my
company just accepts an access_token param instead of adopting mac or bearer
drafts. Once they get finalized people will probably feel more comfortable
developing consistent oauth2 client libraries. I've seen both mac and bearer
drafts completely change parameter names. I'm waiting for those to become
stable before building something on top of them.

 It seems facebook has currently adopted the "access_token" parameter name
and foursquare has adopted the "oauth_token" parameter for oauth2. That
makes it difficult for people to build consistent client libraries when
providers choose different naming schemes for the same protocol.



[3]: http://www.meetup.com/meetup_api/auth/#oauth
[4]: http://www.meetup.com/meetup_api/auth/#oauth2

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


    -Doug Tangren
    http://lessis.me
    


    On Sat, May 28, 2011 at 12:30 PM, David =
Recordon <recor=
dond@gmail.com> 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 acces=
s
    
token into a field named bearer_token.
    


    I still agree it's confusing. It a=
lso depends on which resource server token type handling you choose. If you=
 were going to choose
    mac token types, the access_token is actual=
ly named "id" [1] in the authorization header though its oauth2 b=
inding suggestions the auth server returns it as a parameter named "ac=
cess_token" [2]
    



    




    
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<=
br>
developers will have never heard of a bearer token.
    


    I feel the same. My company actually n=
eeds a way to distinguish between oauth1 [3] and oauth2 [4] because we are =
currently supporting both. We are currently inspecting requests using "=
;oauth_token" to identify oauth1 requests and "access_token"=
 to identify oauth2 requests.
    



    Until things get a little more=C2=A0finalized in the re=
source server specs,=C2=A0my company just accepts an access_token param ins=
tead of adopting mac or bearer drafts. Once they get finalized people will =
probably feel more comfortable developing consistent oauth2 client librarie=
s. I've seen both mac and bearer drafts completely change parameter nam=
es. I'm waiting for those to become stable before building something on=
 top of them.
    



    =C2=A0It seems facebook has currently adopted the "=
;access_token" parameter name and foursquare has adopted the "oau=
th_token" parameter for oauth2. That makes it difficult for people to =
build consistent client libraries when providers choose different naming sc=
hemes for the same protocol.
    


    =C2=A0


    

--90e6ba6134ac4df91204a4593166--

From recordond@gmail.com  Sat May 28 10:20: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 D5CA2E0771 for ; Sat, 28 May 2011 10:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.413
X-Spam-Level: 
X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186,  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 BoMinPXwTUUJ for ; Sat, 28 May 2011 10:20:25 -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 433C5E076B for ; Sat, 28 May 2011 10:20:25 -0700 (PDT)
Received: by vxg33 with SMTP id 33so2514580vxg.31 for ; Sat, 28 May 2011 10:20:24 -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=HeBUNREVRQPaOy8ugboLJ8LTHdt28F+QWe/Y7blZO4I=; b=IiTroqtOPyFrwK7RVqj8WLoSt0oO/0x5HCizK5lTghv8r3OcdOGieIq5KoMQIdGtw1 wABQDBpLlxwxZD3xoUjGzJbThyF4qDOYBVNywzX0Aq0BPyFfRIopecRU5qjzmM2wi4oc lH89pNwDsHe9RqonoZF2/EmW+EfqCdCDLj63c=
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=nPpnz393Onf+C7Ss917W+Xe61vFePklg/Xt4j2sW3O4jW3XCGys7CPjO6B9fWzhJ8C /sgRb63iJxBNvz3Zarlp8km9P774dLElgPRmXMoelTJ7Rmr5YS3RdMARET6oLUSA13zR uSXnaYex80/J/Q6UZoKIlb9C7qu9qZS9t2TdM=
MIME-Version: 1.0
Received: by 10.52.176.136 with SMTP id ci8mr4495906vdc.234.1306603224272; Sat, 28 May 2011 10:20:24 -0700 (PDT)
Received: by 10.52.158.202 with HTTP; Sat, 28 May 2011 10:20:24 -0700 (PDT)
In-Reply-To: 
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com>  
Date: Sat, 28 May 2011 10:20:24 -0700
Message-ID: 
From: David Recordon 
To: 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: Sat, 28 May 2011 17:20:31 -0000

Facebook accepts both access_token and oauth_token today but only
documents access_token. I imagine we'll continue doing the same with
bearer_token until it gets sorted out a bit more. Thus we'd document
access_token but note that oauth_token and bearer_token will also
work. :-\


On Sat, May 28, 2011 at 10:14 AM, Doug Tangren  wrote:
>
> -Doug Tangren
> http://lessis.me
>
>
> On Sat, May 28, 2011 at 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.
>>
>
> I still agree it's confusing. It also depends on which resource server to=
ken
> type handling you choose. If you were going to choose
> mac token types, the access_token is actually named "id" [1] in the
> authorization header though its oauth2 binding suggestions the auth serve=
r
> returns it as a parameter named "access_token" [2]
> [1]:=A0http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#sect=
ion-3.1
> [2]:=A0http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#sect=
ion-5.1
>
>> 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.
>>
>
> I feel the same. My company actually needs a way to distinguish between
> oauth1 [3] and oauth2 [4] because we are currently supporting both. We ar=
e
> currently inspecting requests using "oauth_token" to identify oauth1
> requests and "access_token" to identify oauth2 requests.
> Until things get a little more=A0finalized in the resource server specs,=
=A0my
> company just accepts an access_token param instead of adopting mac or bea=
rer
> drafts. Once they get finalized people will probably feel more comfortabl=
e
> developing consistent oauth2 client libraries. I've seen both mac and bea=
rer
> drafts completely change parameter names. I'm waiting for those to become
> stable before building something on top of them.
> =A0It seems facebook has currently adopted the "access_token" parameter n=
ame
> and foursquare has adopted the "oauth_token" parameter for oauth2. That
> makes it difficult for people to build consistent client libraries when
> providers choose different naming schemes for the same protocol.
>
>
> [3]:=A0http://www.meetup.com/meetup_api/auth/#oauth
> [4]:=A0http://www.meetup.com/meetup_api/auth/#oauth2
>

From d.tangren@gmail.com  Sat May 28 11: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 57FF1E06EF for ; Sat, 28 May 2011 11:25:30 -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 SIn+qiAIQLjo for ; Sat, 28 May 2011 11:25:29 -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 9845CE0655 for ; Sat, 28 May 2011 11:25:29 -0700 (PDT)
Received: by iyn15 with SMTP id 15so3529124iyn.31 for ; Sat, 28 May 2011 11:25:29 -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=pz7vH1Z2AoqViySuXNA+bySwETJm/2BpGhevywjxslk=; b=ABC8G7RX0inkoPg3zf2mS/P+PEjgJT9GpUfxfe1aKuPDzsd5w4gbqG6ulr0UDGDsPu Hezm01miI5/PmxmcH9AQmZBr2Em6LpOm5NvJslZlfqPEEqRTOcXzbBoww4Fm0dmlUVbD hr8Pzr7rnXc4jA7Y9vXML2Yq8UFom6pHyhr8Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=XSg82cCt4V/L6E7QJg+OhvRSlcniGio1cW4FXqbsdTZoVYrvrAX2nZGhKvzAhF0Sq0 QxNoVQMujpi6uLNrdVFm4LFX4NrQoN+IJOj1CNkvAEnHTaVwtpI5ADSVAlMmEvu2UmjT 2Cys3BEdnklwWbo5gFL3ZbpO1gasb0q4NXG3c=
Received: by 10.42.136.129 with SMTP id u1mr4287906ict.459.1306607129062; Sat, 28 May 2011 11:25:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Sat, 28 May 2011 11:25:09 -0700 (PDT)
From: Doug Tangren 
Date: Sat, 28 May 2011 14:25:09 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=90e6ba613594c9ec0b04a45a2da6
Subject: [OAUTH-WG] draft 16 notes on 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: Sat, 28 May 2011 18:25:30 -0000

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

I just re-read draft 16 on this memorial day weekend :)

1. I had a comment on the suggested use of the authorization code flow for
native clients [1].

Section 10.9 on auth code transmission [2] suggests users of the auth code
flow should implement tls on it's redirect uri. This makes sense for web
servers which may register something like "https://foo.com/i/got/authed" but
may not be possible on native clients.

It's a common practice for android clients, for instance, to open a browser
window to authorize a user via `Intent` and then register their redirect_uri
to be a custom scheme registered with their android `activity`, something
like "myapp://i/got/authed".

2. With regards to resource owner creds flow security consideration
mentioned [3], it really feels like this is dodging the whole idea of oauth
asking for authorization on the site owning the resources.

Is this mainly meant for `official` apps developed by the site owning the
resource?
Otherwise, it feels like its no different than ye old basic http auth and
gimme your login and password and trust me not to store them.

[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9
[2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9
[3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12


-Doug Tangren
http://lessis.me

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


    I just re-read draft 16 on this memorial day weekend :)

    =

    1. I had a comment on the suggested use of the authorization cod=
e flow for native clients [1].

    Section 10.9 on aut=
h code transmission [2] suggests users of the auth code flow should impleme=
nt tls on it's redirect uri. This makes sense for web servers which may=
 register something like "htt=
ps://foo.com/i/got/authed" but may not be possible on native clien=
ts.=C2=A0
    



    It's a common practice for android clients, for ins=
tance, to open a browser window to authorize a user via `Intent` and then r=
egister their redirect_uri to be a custom scheme registered with their andr=
oid `activity`, something like "myapp://i/got/authed".
    



    2. With regards to resource owner creds flow security c=
onsideration mentioned [3], it really feels like this is dodging the whole =
idea of oauth asking for authorization on the site owning the resources.



    Is this mainly meant for `official` apps developed by t=
he site owning the resource?
    Otherwise, it feels like its no diff=
erent than ye old basic http auth and gimme your login and password and tru=
st me not to store them.
    



    




    -Doug Tangren
    http://lessis.me
    



--90e6ba613594c9ec0b04a45a2da6--

From torsten@lodderstedt.net  Sun May 29 06:06: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 BA28BE06FD for ; Sun, 29 May 2011 06:06:56 -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 W1-q3K5Qp+dA for ; Sun, 29 May 2011 06:06:55 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6EE06B6 for ; Sun, 29 May 2011 06:06:54 -0700 (PDT)
Received: from [79.253.30.159] (helo=[192.168.71.27]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QQfhl-0003GS-04; Sun, 29 May 2011 15:06:53 +0200
Message-ID: <4DE244EC.8080506@lodderstedt.net>
Date: Sun, 29 May 2011 15:06:52 +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: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090301090705070904060005"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft 16 notes on 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: Sun, 29 May 2011 13:06:56 -0000

This is a multi-part message in MIME format.
--------------090301090705070904060005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



Am 28.05.2011 20:25, schrieb Doug Tangren:
> I just re-read draft 16 on this memorial day weekend :)
>
> 1. I had a comment on the suggested use of the authorization code flow 
> for native clients [1].
>
> Section 10.9 on auth code transmission [2] suggests users of the auth 
> code flow should implement tls on it's redirect uri. This makes sense 
> for web servers which may register something like 
> "https://foo.com/i/got/authed" but may not be possible on native clients.

It makes sense for all flows where the redirect_uri referes to a server 
resource. This holds true for web servers acting as OAuth client as well 
as any server-based resource used by other clients to obtain the 
authorization code. This should be clarified.

>
> It's a common practice for android clients, for instance, to open a 
> browser window to authorize a user via `Intent` and then register 
> their redirect_uri to be a custom scheme registered with their android 
> `activity`, something like "myapp://i/got/authed".

As pointed out by e.g. Marius in some postings, there are other 
techniques as well. Some of them are based on server resources the 
native app relies on.

>
> 2. With regards to resource owner creds flow security consideration 
> mentioned [3], it really feels like this is dodging the whole idea of 
> oauth asking for authorization on the site owning the resources.

The section clearly states our preference to use other grant types.

    "The authorization server and client SHOULD minimize use of this grant
    type and utilize other grant types whenever possible."

Apart from that, I would not limit OAuth 2.0 to "just" delegated 
authorization via end-user authorization. In my opinion, OAuth 2.0 is a 
generic token issuance framework. Such tokens can be issued based on 
delegation flows but also based on direct authentication on the tokens 
endpoint. Other examples of reasonable credentials are assertions of all 
kind. We at Deutsche Telekom also added a custom grant type to directly 
authenticate users based on their SIM card.

What I like the most, OAuth 2.0 combines the user involvement of OAuth 
1.0 with architectural properties of Kerberos (trusted third-party 
authentication, scalability). Moreover, it is based on and integrated 
with HTTP(S) and allows to use different token formats (and even designs).

>
> Is this mainly meant for `official` apps developed by the site owning 
> the resource?

We use it for our own apps. Here, the decision to use web-based flows or 
username/password is typically met by product managers.

> Otherwise, it feels like its no different than ye old basic http auth 
> and gimme your login and password and trust me not to store them.

It clearly has the security advantages that refresh tokens instead of 
passwords are stored in order to provide a convenient login experience. 
The scope of such a token can (and must) be much less powerful than a 
password.

regards,
Torsten.

>
> [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9
> [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9
> [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12
>
>
> -Doug Tangren
> http://lessis.me
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------090301090705070904060005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
    
    
    
    Am 28.05.2011 20:25, schrieb Doug Tangren:
    
    
      
    I just re-read draft 16 on this memorial day weekend :)
    
      

    
      
    
      
    1. I had a comment on the suggested use of the authorization
        code flow for native clients [1].
    
      

    
      
    
      
    Section 10.9 on auth code transmission [2] suggests users of
        the auth code flow should implement tls on it's redirect uri.
        This makes sense for web servers which may register something
        like "https://foo.com/i/got/authed"
        but may not be possible on native clients. 
    
      
    
    
    
    
    
    It makes sense for all flows where the redirect_uri referes to a
    server resource. This holds true for web servers acting as OAuth
    client as well as any server-based resource used by other clients to
    obtain the authorization code. This should be clarified.
    
    
    
    
    
      

    
      
    
      
    It's a common practice for android clients, for instance, to
        open a browser window to authorize a user via `Intent` and then
        register their redirect_uri to be a custom scheme registered
        with their android `activity`, something like
        "myapp://i/got/authed".
    
    
    
    
    
    As pointed out by e.g. Marius in some postings, there are other
    techniques as well. Some of them are based on server resources the
    native app relies on.
    
    
    
    
    
      

    
      
    
      
    2. With regards to resource owner creds flow security
        consideration mentioned [3], it really feels like this is
        dodging the whole idea of oauth asking for authorization on the
        site owning the resources.
    
    
    
    
    
    The section clearly states our preference to use other grant types.
    
    
    
    
       "The authorization server and client SHOULD minimize use of this
    grant
    
       type and utilize other grant types whenever possible."
    
    
    
    Apart from that, I would not limit OAuth 2.0 to "just" delegated
    authorization via end-user authorization. In my opinion, OAuth 2.0
    is a generic token issuance framework. Such tokens can be issued
    based on delegation flows but also based on direct authentication on
    the tokens endpoint. Other examples of reasonable credentials are
    assertions of all kind. We at Deutsche Telekom also added a custom
    grant type to directly authenticate users based on their SIM card.
    
    
    
    What I like the most, OAuth 2.0 combines the user involvement of
    OAuth 1.0 with architectural properties of Kerberos (trusted
    third-party authentication, scalability). Moreover, it is based on
    and integrated with HTTP(S) and allows to use different token
    formats (and even designs).
    
    
    
    
    
      

    
      
    
      
    Is this mainly meant for `official` apps developed by the
        site owning the resource?
    
    
    
    
    
    We use it for our own apps. Here, the decision to use web-based
    flows or username/password is typically met by product managers.
    
    
    
    
    
      
    Otherwise, it feels like its no different than ye old basic
        http auth and gimme your login and password and trust me not to
        store them.
    
    
    
    
    
    It clearly has the security advantages that refresh tokens instead
    of passwords are stored in order to provide a convenient login
    experience. The scope of such a token can (and must) be much less
    powerful than a password.
    
    
    
    regards,
    
    Torsten.
    
    
    
    
    
      

    
      
    
      
      
      
      

    
      
    
      
    
      -Doug Tangren
    
      http://lessis.me
    
      
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
  


--------------090301090705070904060005--

From eran@hueniverse.com  Sun May 29 09:17: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 5607DE066A for ; Sun, 29 May 2011 09:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level: 
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 e3+nPREhKty4 for ; Sun, 29 May 2011 09:17:30 -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 7D902E0662 for ; Sun, 29 May 2011 09:17:30 -0700 (PDT)
Received: (qmail 15888 invoked from network); 29 May 2011 16:17:29 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 May 2011 16:17:29 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 29 May 2011 09:17:09 -0700
From: Eran Hammer-Lahav 
To: David Recordon , OAuth WG 
Date: Sun, 29 May 2011 09:16:48 -0700
Thread-Topic: [OAUTH-WG] Referencing client_secret when making requests
Thread-Index: AcwdVgT/GIFQMznxRh+6Ul4cdNZcvAAxbG7A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA19D@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: paul Tarjan 
Subject: Re: [OAUTH-WG] Referencing client_secret when making requests
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 May 2011 16:17:32 -0000

We can add it as an example. Instead of 'Commonly', 'For example, using'.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of David Recordon
> Sent: Saturday, May 28, 2011 9:41 AM
> To: OAuth WG
> Cc: paul Tarjan
> Subject: [OAUTH-WG] Referencing client_secret when making requests
>=20
> In sections 4.1.3, 4.3.2, 4.4.2 and 6 there's a list of parameters includ=
ed within
> the request and then the sentence, "The client includes its authenticatio=
n
> credentials as described in Section 3."
> Reading through the spec yesterday afternoon with Paul, we first thought
> that client_secret was removed from these requests between drafts 10 and
> 16. This is because the list of parameters is quite obvious but this sent=
ence
> referencing section 3 sort of just blends in.
>=20
> We'd propose changing this sentence to read, "The client includes its
> authentication credentials as described in Section 3. Commonly the
> client_secret parameter."
>=20
> Goal being that client_secret is exposed within each section describing h=
ow
> to make a request in a way that holds true for most usage but doesn't mak=
e
> it more confusing for clients working with SAML (or other client
> authentication credentials).
>=20
> --David
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Sun May 29 09:21: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 9D924E06BC for ; Sun, 29 May 2011 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level: 
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 5KGHSYRNjIAv for ; Sun, 29 May 2011 09:21:23 -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 27DFFE0662 for ; Sun, 29 May 2011 09:21:23 -0700 (PDT)
Received: (qmail 18133 invoked from network); 29 May 2011 16:21:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 May 2011 16:21:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 29 May 2011 09:20:50 -0700
From: Eran Hammer-Lahav 
To: Mike Jones , "oauth@ietf.org" 
Date: Sun, 29 May 2011 09:20:28 -0700
Thread-Topic: Question on action item to make RedirectURI optional
Thread-Index: Acwcsi+yhhFkBPRtRnyKZ3zOMHAQgwBafbTw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA19E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394338105183@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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447583CA19EP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 May 2011 16:21:25 -0000

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

This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is must =
match the location actually used by the server to deliver the code to (rega=
rdless of whether the redirection uri was registered or included explicitly=
 with the request).

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
ike Jones
Sent: Friday, May 27, 2011 2:08 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Question on action item to make RedirectURI optional

The minutes from the special meeting included:

TODO: Eran to add extensibility language for this based on requirements.

-    "RedirectURI" should be optional

TODO: Eran to send mail to the list proposing language changes to either ch=
ange this from REQUIRED to OPTIONAL and add clarifying language, or leave a=
s required and add a pre-defined value for "we're not actually using this".
Is this proposed change just limited to section 4.5?  It seems to make sens=
e to have redirect_uri  be optional in section 4.1.3 as well (access token =
request using grant_type authorization code).  Since this request is made d=
irectly from the client to the authorization server, I don't see why this w=
ould be required.  For at least some implementations of the 3-legged flow, =
it would make sense to not have this be a requirement.

Comments?

                                                                Thanks,
                                                                -- Mike


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


    This applies to 4.1.1 and 4.2.1 only. It must be required in =
4.1.3 is must match the location actually used by the server to deliver the=
 code to (regardless of whether the redirection uri was registered or inclu=
ded explicitly with the request).
     
    EHL
     
    From: oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org] On Behalf Of Mike Jones
    Sent: Friday, May =
27, 2011 2:08 PM
    To: oauth@ietf.org
    Subject: [OAUTH-WG]=
 Question on action item to make RedirectURI optional
    =

     
    =
The minutes from the special meeting included=
:
    <=
o:p> 
    TODO: Eran to add =
extensibility language for this based on requirements.

    -  =
  "RedirectURI" should be optional

    TODO: Eran to send=
 mail to the list proposing language changes to either change this from REQ=
UIRED to OPTIONAL and add clarifying language, or leave as required and add=
 a pre-defined value for "we're not actually using this".    <=
span style=3D'font-size:10.0pt;color:#1F497D'>
    Is this proposed change just li=
mited to section 4.5?  It seems to make sense to have redirect_uri &nb=
sp;be optional in section 4.1.3 as well (access token request using grant_t=
ype authorization code).  Since this request is made directly from the=
 client to the authorization server, I don’t see why this would be re=
quired.  For at least some implementations of the 3-legged flow, it wo=
uld make sense to not have this be a requirement.
     
    =

    Comments?
     =

      &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           Thanks,
    &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;             =
-- Mike
     
    =

--_000_90C41DD21FB7C64BB94121FBBC2E723447583CA19EP3PW5EX1MB01E_--

From torsten@lodderstedt.net  Sun May 29 09:41: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 2FE57E0713 for ; Sun, 29 May 2011 09:41:37 -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 rVE9YStAYubK for ; Sun, 29 May 2011 09:41:35 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id 42F20E06C0 for ; Sun, 29 May 2011 09:41:34 -0700 (PDT)
Received: from [79.253.30.159] (helo=[192.168.71.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QQj3U-0000Q2-Hg; Sun, 29 May 2011 18:41:33 +0200
Message-ID: <4DE2773A.10306@lodderstedt.net>
Date: Sun, 29 May 2011 18:41:30 +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 
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA19E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA19E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------040105010208090509010102"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 May 2011 16:41:37 -0000

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

why must the redirect_uri be validated if it is pre-registered and not 
included in the authorization request?

regards,
Torsten.

Am 29.05.2011 18:20, schrieb Eran Hammer-Lahav:
>
> This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is 
> must match the location actually used by the server to deliver the 
> code to (regardless of whether the redirection uri was registered or 
> included explicitly with the request).
>
> EHL
>
> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *Mike Jones
> *Sent:* Friday, May 27, 2011 2:08 PM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Question on action item to make RedirectURI optional
>
> The minutes from the special meeting included:
>
> TODO: Eran to add extensibility language for this based on requirements.
>
> -    "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".
>
> Is this proposed change just limited to section 4.5?  It seems to make 
> sense to have redirect_uri  be optional in section 4.1.3 as well 
> (access token request using grant_type authorization code).  Since 
> this request is made directly from the client to the authorization 
> server, I don't see why this would be required.  For at least some 
> implementations of the 3-legged flow, it would make sense to not have 
> this be a requirement.
>
> Comments?
>
>                                                                 Thanks,
>
>                                                                 -- Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



  
    
    
  
  
    why must the redirect_uri be validated if it is pre-registered and
    not included in the authorization request?
    
    
    
    regards,
    
    Torsten.
    
    
    
    Am 29.05.2011 18:20, schrieb Eran Hammer-Lahav:
    
    
      
      
      
      
    
        
    This
            applies to 4.1.1 and 4.2.1 only. It must be required in
            4.1.3 is must match the location actually used by the server
            to deliver the code to (regardless of whether the
            redirection uri was registered or included explicitly with
            the request).
    
        
     
    
        
    EHL
    
        
     
    
        
    
          
    
            
    
              
    From:
                  oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                  On Behalf Of Mike Jones
    
                  Sent: Friday, May 27, 2011 2:08 PM
    
                  To: oauth@ietf.org
    
                  Subject: [OAUTH-WG] Question on action item to
                  make RedirectURI optional
    
            
    
          
    
          
     
    
          
    The
              minutes from the special meeting included:
    
          
     
    
          
    TODO:
              Eran to add extensibility language for this based on
              requirements.
    
              
    
              -    "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".
    
          
    Is
              this proposed change just limited to section 4.5?  It
              seems to make sense to have redirect_uri  be optional in
              section 4.1.3 as well (access token request using
              grant_type authorization code).  Since this request is
              made directly from the client to the authorization server,
              I don’t see why this would be required.  For at least some
              implementations of the 3-legged flow, it would make sense
              to not have this be a requirement.
    
          
     
    
          
    Comments?
    
          
     
    
          
                                                                   
              Thanks,
    
          
                                                                   
              -- Mike
    
          
     
    
        
    
      
    
      
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
  


--------------040105010208090509010102--

From d.tangren@gmail.com  Sun May 29 10:46: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 48187E0664 for ; Sun, 29 May 2011 10:46:36 -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 l63cFKEzOhMK for ; Sun, 29 May 2011 10:46:35 -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 EF7D8E06A8 for ; Sun, 29 May 2011 10:46:34 -0700 (PDT)
Received: by iyn15 with SMTP id 15so4366373iyn.31 for ; Sun, 29 May 2011 10:46: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=gr0A7s+069iKQj6krjs18sFHJ/Df1GOmxP+qkPNCTLI=; b=pWjAt3KAKxVjek6t8x7mn9Cp1cFJ8xD5rDH+RZtjF4fVvOPbU19eecBUzkv7s/a2Hs U8rO2Aj0Ht+qONPAngK4SJMeFCE7rij6uoFVh6PzEjG0QsAwo3vBwDbZ+S+d8Cb1VVlK opk+3SJo2fPiiqwUJiAa8RKNmBQ0zPVzIXM8c=
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=S+s1F5bLhvltWDPqZeg3xRW5ueEcIrNhoX2KzsnAo2JTSFFkhfleUtUvofo3lz6DrK 1k+nmxArrXeZ5uWkLqFzugGG/UcJPQcSvKwHgF2dPzKW9nWWncdQz03gIX5was0Htgkc mUOfR1iHwjCwxvwjQbaIKhEyFP02Q3/LVP6R0=
Received: by 10.42.158.136 with SMTP id h8mr6354741icx.57.1306691193047; Sun, 29 May 2011 10:46:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Sun, 29 May 2011 10:46:13 -0700 (PDT)
In-Reply-To: <4DE2773A.10306@lodderstedt.net>
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA19E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE2773A.10306@lodderstedt.net>
From: Doug Tangren 
Date: Sun, 29 May 2011 13:46:13 -0400
Message-ID: 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=90e6ba6e8adc648c5104a46dc059
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 May 2011 17:46:36 -0000

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

-Doug Tangren
http://lessis.me


On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>  why must the redirect_uri be validated if it is pre-registered and not
> included in the authorization request?
>

I think the preregistered redirect_uri may only require the core components
of where the user will be redirected to after authorization


  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.  If a redirection URI was registered,
   the authorization server MUST compare any redirection URI received at
   the authorization endpoint with the registered URI.


- http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1


What you pre-register determines how you would match the provided
requests' redirect_uris.


It's explicitly required for an explicit location to redirect to on a
request by request basis.

The exact match in 4.1.3 is required to have a binding between the
first and second request in the auth code flow.


I think the idea behind a pre-registered redirect_uri was to limit
where credentials will be sent to after authorization.

In oauth1 someone could supply a redirection "callback" to a
completely different for every request.

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


    -Doug Tangren
    http://lessis.me
    


    On Sun, May 29, 2011 at 12:41 PM, Torste=
n Lodderstedt <torsten@lodderstedt.net> wrote:
    



 =20
   =20
   =20
 =20
  
    
    why must the redirect_uri be validated if it is pre-registered and
    not included in the authorization request?
    <=
br>
    I think the preregistered redirect_uri may only require the c=
ore components of where the user will be redirected to after authorization<=
/div>




      The authorization s=
erver SHOULD require the client to pre-register
   their redirection URI or at least certain components such as the
   scheme, host, port and path.  If a redirection URI was registered,
   the authorization server MUST compare any redirection URI received at
   the authorization endpoint with the registered URI.

    
- http:=
//tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1
    



    
What=
 you pre-register determines how you would match the provided requests'=
 redirect_uris.
    

    It's explicitly required f=
or an explicit location to redirect to on a request by request basis.
    


    The exact match in 4.1.3 is required to =
have a binding between the first and second request in the auth code flow.<=
/font>
    



    
I th=
ink the idea behind a pre-registered redirect_uri was to limit where creden=
tials will be sent to after authorization.
    
In o=
auth1 someone could supply a redirection "callback" to a complete=
ly different for every request.
    

--90e6ba6e8adc648c5104a46dc059--

From torsten@lodderstedt.net  Sun May 29 11:20: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 6F430E06CF for ; Sun, 29 May 2011 11:20:11 -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 TluuHyUDWdLD for ; Sun, 29 May 2011 11:20:10 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by ietfa.amsl.com (Postfix) with ESMTP id 906E6E0681 for ; Sun, 29 May 2011 11:20:10 -0700 (PDT)
Received: from [79.253.30.159] (helo=[192.168.71.31]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1QQkas-0007JK-6q; Sun, 29 May 2011 20:20:08 +0200
References: <4E1F6AAD24975D4BA5B168042967394338105183@TK5EX14MBXC203.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA19E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE2773A.10306@lodderstedt.net> 
User-Agent: K-9 Mail for Android
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----YAPARY7MKQJQL7A4J1EI3LCY2P61GU"
From: Torsten Lodderstedt 
Date: Sun, 29 May 2011 20:19:54 +0200
To: Doug Tangren 
Message-ID: 
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Question on action item to make RedirectURI optional
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 May 2011 18:20:11 -0000

------YAPARY7MKQJQL7A4J1EI3LCY2P61GU
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

we need to distinguish (1) the registration of a redirect uri template for the purpose of validating the actual redirect uri of an authorization transaction and the (2) registration of the redirect uri to be used in all authorization requests of a client. In the later case, there is no need for the pass a redirect uri with every authz request.

Is OAuth supposed to support (2)?

regards,
Torsten.



Doug Tangren  schrieb:


-Doug Tangren
http://lessis.me


On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt  wrote:

why must the redirect_uri be validated if it is pre-registered and not included in the authorization request?


I think the preregistered redirect_uri may only require the core components of where the user will be redirected to after authorization



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. If a redirection URI was registered, the authorization server MUST compare any redirection URI received at the authorization endpoint with the registered URI.
- http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1 
What you pre-register determines how you would match the provided requests' redirect_uris. 
It's explicitly required for an explicit location to redirect to on a request by request basis. The exact match in 4.1.3 is required to have a binding between the first and second request in the auth code flow. 
I think the idea behind a pre-registered redirect_uri was to limit where credentials will be sent to after authorization. In oauth1 someone could supply a redirection "callback" to a completely different for every request.


------YAPARY7MKQJQL7A4J1EI3LCY2P61GU
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit


we need to distinguish (1) the registration of a redirect uri template for the purpose of validating the actual redirect uri of an authorization transaction and the (2) registration of the redirect uri to be used in all authorization requests of a client. In the later case, there is no need for the pass a redirect uri with every authz request.
    

    
Is OAuth supposed to support (2)?
    

    
regards,
    
Torsten.


    

    
Doug Tangren <d.tangren@gmail.com> schrieb:
    

    -Doug Tangren
    http://lessis.me
    


    On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    



  
    
    
  
  
    
    why must the redirect_uri be validated if it is pre-registered and
    not included in the authorization request?

    I think the preregistered redirect_uri may only require the core components of where the user will be redirected to after authorization
    




      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.  If a redirection URI was registered,
   the authorization server MUST compare any redirection URI received at
   the authorization endpoint with the registered URI.

    
- http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1
    



    
What you pre-register determines how you would match the provided requests' redirect_uris.
    

    It's explicitly required for an explicit location to redirect to on a request by request basis.
    


    The exact match in 4.1.3 is required to have a binding between the first and second request in the auth code flow.
    



    
I think the idea behind a pre-registered redirect_uri was to limit where credentials will be sent to after authorization.
    
In oauth1 someone could supply a redirection "callback" to a completely different for every request.
    

    
------YAPARY7MKQJQL7A4J1EI3LCY2P61GU--


From peter.wolanin@acquia.com  Sun May 29 18:53: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 22059E0768 for ; Sun, 29 May 2011 18:53:03 -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 hW3Yvv3jlExZ for ; Sun, 29 May 2011 18:53:02 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with SMTP id 4D3C4E0684 for ; Sun, 29 May 2011 18:53:00 -0700 (PDT)
Received: from mail-ww0-f54.google.com ([74.125.82.54]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTeL4eyJ/IY+pIfjzVX4J6y5BiTYVWjrl@postini.com; Sun, 29 May 2011 18:53:01 PDT
Received: by wwd20 with SMTP id 20so3866720wwd.35 for ; Sun, 29 May 2011 18:52:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.254.37 with SMTP id g37mr4263659wes.36.1306720378351; Sun, 29 May 2011 18:52:58 -0700 (PDT)
Received: by 10.216.16.142 with HTTP; Sun, 29 May 2011 18:52:58 -0700 (PDT)
In-Reply-To: <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org>
References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org>
Date: Sun, 29 May 2011 21:52:58 -0400
Message-ID: 
From: Peter Wolanin 
To: Skylar Woodward 
Content-Type: text/plain; charset=UTF-8
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: Mon, 30 May 2011 01:53:03 -0000

I am also concerned by the fragility of using
time-since-credentials-issued, and also the added complexity of
specifying this construction.

I think it would be preferable to always require a timestamp as part
of the authorization header, and maybe even include in the spec a
maximum time difference between client and server (e.g. 900 seconds)
that can be tolerated.  This makes generating the nonce easier also,
since the value need to longer be unique over all time.

We have such rules in place for an HMAC-based authentication system we
use.  Once in a while a client has a local clock so far out of sync
that there is an issue, but it's rare.

-Peter

On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward  wrote:
> Resending to the list from my subscribed account...
>
> Begin forwarded message:
>
>> From: Skylar Woodward 
>> Date: May 23, 2011 6:14:00 PM PDT
>> To: Skylar Woodward 
>> Cc: Eran Hammer-Lahav , OAuth WG 
>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>
>> So after discussing this today and reflecting on it a bit, I would sugge=
st that nonce simply be the "unique value" (as it is so named) without furt=
her requirements. It might be suggested that this be composed of an random+=
timestamp (not age) value, but that seems more of a MAY or "recommended" pr=
actice. If the expectation is that very few if any providers would actually=
 check the timestamp (or moreover, the nonce itself), why add terminology i=
n the draft that requires it? Developers are doing extra housekeeping (and =
perhaps for a perceived benefit) but with no payoff or added security.
>>
>> I'm sending this feedback based on having implemented the v3-5 changes l=
ast night (for both client credentials and requests w/ access tokens). Afte=
r the changes, the nonce creation is now the most complicated part of the n=
ormalized request string and yet these changes offer the least benefit. Wha=
t's most important is that nonces are unique on each request for an ID.
>>
>> There are issues with age as well:
>>
>> - As Bill mentioned, if the client stores the issue time based on receip=
t, then the internal clock changes (presumably w/o knowledge of the softwar=
e storing the dates) then time will also fail. Assuming that a user with a =
bad clock (of by hours or more) will never fix it and actually encourages b=
ad user behavior (don't fix your clock or Twitterbot will stop working!). T=
hough we say that timezones won't bring about the situation of changed cloc=
k, I'd be to differ. Many users aren't savvy enough to change time zone, bu=
t just adjust the time to local time anyway. Users who are more likely to g=
et it right already have auto clock sync enabled (via web, mobile, etc.)
>>
>> - What if the token wasn't originally issued programmatically? In this c=
ase, the issue time has to be obtained from the server and stored on the cl=
ient then you have the same problem as with a timestamp - the client clock =
is not sync'd to the server clock and there is no adjustment. You want this=
 to apply to uses outside of just OAuth, but now requiring the client to be=
 able to determine an issue time based on when it receives an HTTP request =
necessarily limits the types of token flows for which this can be used.
>>
>> - It's one more detail to store. Hardly an issue for a developer, but it=
 is inelegant. It's like having a double ID. Yet it's not an ID, it is actu=
ally more of a recording of "my personal clock offset value" but obfuscated=
 several times over (one for each token) as issue_date.
>>
>> - This implementation assumes software programs use the computer interna=
l clock exclusively for timestamp. A robust program that is dependent on ac=
curate timestamps would ping the origin server (or similar trusted time aut=
hority) to ask it the current time. Then it could store a "my device clock =
offset" value for the lifetime of the program execution. All requests needi=
ng timestamp would be adjusted accordingly. For age, if the clock is change=
d since the stored issue_date, the problem can't be corrected in this manne=
r. Thus, a significant advantage for timestamp.
>>
>> All in all, this seems like a misguided but well-intentioned attempt to =
get around end-user issues of mis-set clocks. It feels like a hack and it c=
ertainly isn't a foolproof solution. The more I think about the implication=
s of the age parameter, the less I like it. Timestamp has been used for man=
y years in the industry and with reasonable success in relevant application=
s. If we change to a new way of trying to sync on time I think we run a gre=
ater risk of stumbling upon unforeseen issues, such as those outlined above=
.
>>
>> I recommend the requirement of an age (or timestamp for that matter) be =
dropped from the nonce construction. For providers that deem it valuable, t=
imestamp can be an optional value (either as part of the nonce or the overa=
ll header, as before).
>>
>> skylar
>>
>>
>>
>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>
>>> You may have noticed, on page 8 the host is listed as "example.net" - s=
hould be example.com, I believe. =C2=A0(draft v5)
>>>
>>> All in all, I'm in support of the changes in v2. Certainly addresses my=
 hesitations from v2.
>>>
>>> skylar
>>>
>>>
>>> On May 9, 2011, at 12:36 PM, 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
>>>>
>>>> While this document has moved to the Apps-Discuss mailing list for the=
 time being, I wanted to give a quick update to those who have been followi=
ng this draft which originated on this list.
>>>>
>>>> The major changes since -02 are:
>>>>
>>>> * Removed OAuth terminology and association. The draft is now a genera=
l purpose HTTP authentication scheme. It does include an OAuth 2.0 binding =
which is described in less than a page. One suggestion would be to move sec=
tion 5.1 into the OAuth specification and drop all the OAuth 2.0 text from =
the MAC draft.
>>>>
>>>> * Added 'Set-Cookie' extension for using MAC with session cookies.
>>>>
>>>> * Removed request URI query normalization. The new draft uses the raw =
request URI unchanged.
>>>>
>>>> * Replaced timestamps with credentials age to remove the need for cloc=
k sync.
>>>>
>>>> * Added a placeholder for extension, allowing random text to be includ=
ed in the request and MAC.
>>>>
>>>> * Added issuer attribute for identifying the source of the credentials=
 as an additional protection.
>>>>
>>>> Draft -04 is not compatible with previous drafts.
>>>>
>>>> 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
>



--=20
Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac=
quia. Inc.
peter.wolanin@acquia.com : 978-296-5247

"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"

From eran@hueniverse.com  Sun May 29 22: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 84729E068E for ; Sun, 29 May 2011 22:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111,  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 HX6G2cSmJTc0 for ; Sun, 29 May 2011 22:55: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 192D2E0674 for ; Sun, 29 May 2011 22:55:23 -0700 (PDT)
Received: (qmail 32377 invoked from network); 30 May 2011 05:55:23 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 May 2011 05:55:21 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 29 May 2011 22:55:21 -0700
From: Eran Hammer-Lahav 
To: Peter Wolanin , Skylar Woodward 
Date: Sun, 29 May 2011 22:54:57 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwebFsMUi2IYSIETiit9m2WaVm7nwAIS04w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org> 
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
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: Mon, 30 May 2011 05:55:27 -0000

QW55IGtpbmQgb2YgY2xvY2sgc3luYyByZXF1aXJlbWVudCBmb3IgdXNlci1hZ2VudHMgKGJhc2lj
YWxseSwgaG9tZSBkZXNrdG9wcykgaXQgY29tcGxldGVseSBpbXByYWN0aWNhbC4gVGhlIGFkZGVk
IGNvbXBsZXhpdHkgcGFsZXMgaW4gY29tcGFyaXNvbiB0byB0aGUgZGlmZmljdWx0eSBvZiB0cnlp
bmcgdG8gdXNlIHRpbWVzdGFtcHMgYW5kIGFueSBraW5kIG9mIGNsb2NrIHN5bmMuIE5vIHdpbmRv
dyB3aWxsIGJlIGJpZyBlbm91Z2ggYXMgZXhwZXJpZW5jZSBzaG93cyBzb21lIHVzZXJzIGhhdmUg
Y2xvc2VzIHRoYXQgYXJlIG9mZiBieSBtb3JlIHRoYW4gYW4gaG91ciBhbmQgYSBoYWxmLg0KDQpU
aGUgaXNzdWUgaGVyZSBpcyB3aG8gaXMgdGhpcyBiZWluZyBvcHRpbWl6ZWQgZm9yLiBTZXJ2ZXIt
dG8tc2VydmVyIGNvbW11bmljYXRpb24gc2hvdWxkIHNpbXBseSB1c2UgVExTIGZvciBwcml2YWN5
IGFuZCBNSVRNIHByb3RlY3Rpb24gb24gdG9wIG9mIE1BQyBpbnN0ZWFkIG9mIHVzaW5nIG5vbmNl
cyB0byBwcmV2ZW50IHJlcGxheS4gVGhlIHdob2xlIHBvaW50IG9mIHRoaXMga2luZCBvZiByZXBs
YXkgcHJvdGVjdGlvbiBpcyB3aGVuIFRMUyBpcyBub3QgYXZhaWxhYmxlLg0KDQpJIHRoaW5rIGEg
YmV0dGVyIGFwcHJvYWNoIGlzIHRvIHNpbXBseSBtYWtlIGNoZWNraW5nIHRoZSBub25jZSBvcHRp
b25hbCB3aGVuIFRMUyBpcyB1c2VkLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFBldGVyIFdvbGFuaW4NCj4gU2VudDogU3VuZGF5
LCBNYXkgMjksIDIwMTEgNjo1MyBQTQ0KPiBUbzogU2t5bGFyIFdvb2R3YXJkDQo+IENjOiBPQXV0
aCBXRw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGd2Q6IGlzc3VlcyB3aXRoIHRva2VuIGFn
ZSBlbGVtZW50IC0gTUFDIHRva2VuDQo+IA0KPiBJIGFtIGFsc28gY29uY2VybmVkIGJ5IHRoZSBm
cmFnaWxpdHkgb2YgdXNpbmcgdGltZS1zaW5jZS1jcmVkZW50aWFscy1pc3N1ZWQsDQo+IGFuZCBh
bHNvIHRoZSBhZGRlZCBjb21wbGV4aXR5IG9mIHNwZWNpZnlpbmcgdGhpcyBjb25zdHJ1Y3Rpb24u
DQo+IA0KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIHByZWZlcmFibGUgdG8gYWx3YXlzIHJlcXVpcmUg
YSB0aW1lc3RhbXAgYXMgcGFydCBvZiB0aGUNCj4gYXV0aG9yaXphdGlvbiBoZWFkZXIsIGFuZCBt
YXliZSBldmVuIGluY2x1ZGUgaW4gdGhlIHNwZWMgYSBtYXhpbXVtIHRpbWUNCj4gZGlmZmVyZW5j
ZSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIChlLmcuIDkwMCBzZWNvbmRzKSB0aGF0IGNhbiBi
ZQ0KPiB0b2xlcmF0ZWQuICBUaGlzIG1ha2VzIGdlbmVyYXRpbmcgdGhlIG5vbmNlIGVhc2llciBh
bHNvLCBzaW5jZSB0aGUgdmFsdWUgbmVlZA0KPiB0byBsb25nZXIgYmUgdW5pcXVlIG92ZXIgYWxs
IHRpbWUuDQo+IA0KPiBXZSBoYXZlIHN1Y2ggcnVsZXMgaW4gcGxhY2UgZm9yIGFuIEhNQUMtYmFz
ZWQgYXV0aGVudGljYXRpb24gc3lzdGVtIHdlDQo+IHVzZS4gIE9uY2UgaW4gYSB3aGlsZSBhIGNs
aWVudCBoYXMgYSBsb2NhbCBjbG9jayBzbyBmYXIgb3V0IG9mIHN5bmMgdGhhdCB0aGVyZSBpcyBh
bg0KPiBpc3N1ZSwgYnV0IGl0J3MgcmFyZS4NCj4gDQo+IC1QZXRlcg0KPiANCj4gT24gTW9uLCBN
YXkgMjMsIDIwMTEgYXQgOToxNiBQTSwgU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJAa2l2YS5vcmc+
DQo+IHdyb3RlOg0KPiA+IFJlc2VuZGluZyB0byB0aGUgbGlzdCBmcm9tIG15IHN1YnNjcmliZWQg
YWNjb3VudC4uLg0KPiA+DQo+ID4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+ID4NCj4gPj4g
RnJvbTogU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJAbGFydy5jb20+DQo+ID4+IERhdGU6IE1heSAy
MywgMjAxMSA2OjE0OjAwIFBNIFBEVA0KPiA+PiBUbzogU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJA
a2l2YS5vcmc+DQo+ID4+IENjOiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNv
bT4sIE9BdXRoIFdHDQo+ID4+IDxvYXV0aEBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gaXNzdWVzIHdpdGggdG9rZW4gYWdlIGVsZW1lbnQgLSBNQUMgdG9rZW4NCj4gPj4N
Cj4gPj4gU28gYWZ0ZXIgZGlzY3Vzc2luZyB0aGlzIHRvZGF5IGFuZCByZWZsZWN0aW5nIG9uIGl0
IGEgYml0LCBJIHdvdWxkIHN1Z2dlc3QgdGhhdA0KPiBub25jZSBzaW1wbHkgYmUgdGhlICJ1bmlx
dWUgdmFsdWUiIChhcyBpdCBpcyBzbyBuYW1lZCkgd2l0aG91dCBmdXJ0aGVyDQo+IHJlcXVpcmVt
ZW50cy4gSXQgbWlnaHQgYmUgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZSBjb21wb3NlZCBvZiBhbg0K
PiByYW5kb20rdGltZXN0YW1wIChub3QgYWdlKSB2YWx1ZSwgYnV0IHRoYXQgc2VlbXMgbW9yZSBv
ZiBhIE1BWSBvcg0KPiAicmVjb21tZW5kZWQiIHByYWN0aWNlLiBJZiB0aGUgZXhwZWN0YXRpb24g
aXMgdGhhdCB2ZXJ5IGZldyBpZiBhbnkgcHJvdmlkZXJzDQo+IHdvdWxkIGFjdHVhbGx5IGNoZWNr
IHRoZSB0aW1lc3RhbXAgKG9yIG1vcmVvdmVyLCB0aGUgbm9uY2UgaXRzZWxmKSwgd2h5IGFkZA0K
PiB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQgdGhhdCByZXF1aXJlcyBpdD8gRGV2ZWxvcGVycyBh
cmUgZG9pbmcgZXh0cmENCj4gaG91c2VrZWVwaW5nIChhbmQgcGVyaGFwcyBmb3IgYSBwZXJjZWl2
ZWQgYmVuZWZpdCkgYnV0IHdpdGggbm8gcGF5b2ZmIG9yDQo+IGFkZGVkIHNlY3VyaXR5Lg0KPiA+
Pg0KPiA+PiBJJ20gc2VuZGluZyB0aGlzIGZlZWRiYWNrIGJhc2VkIG9uIGhhdmluZyBpbXBsZW1l
bnRlZCB0aGUgdjMtNSBjaGFuZ2VzDQo+IGxhc3QgbmlnaHQgKGZvciBib3RoIGNsaWVudCBjcmVk
ZW50aWFscyBhbmQgcmVxdWVzdHMgdy8gYWNjZXNzIHRva2VucykuIEFmdGVyDQo+IHRoZSBjaGFu
Z2VzLCB0aGUgbm9uY2UgY3JlYXRpb24gaXMgbm93IHRoZSBtb3N0IGNvbXBsaWNhdGVkIHBhcnQg
b2YgdGhlDQo+IG5vcm1hbGl6ZWQgcmVxdWVzdCBzdHJpbmcgYW5kIHlldCB0aGVzZSBjaGFuZ2Vz
IG9mZmVyIHRoZSBsZWFzdCBiZW5lZml0Lg0KPiBXaGF0J3MgbW9zdCBpbXBvcnRhbnQgaXMgdGhh
dCBub25jZXMgYXJlIHVuaXF1ZSBvbiBlYWNoIHJlcXVlc3QgZm9yIGFuIElELg0KPiA+Pg0KPiA+
PiBUaGVyZSBhcmUgaXNzdWVzIHdpdGggYWdlIGFzIHdlbGw6DQo+ID4+DQo+ID4+IC0gQXMgQmls
bCBtZW50aW9uZWQsIGlmIHRoZSBjbGllbnQgc3RvcmVzIHRoZSBpc3N1ZSB0aW1lIGJhc2VkIG9u
DQo+ID4+IHJlY2VpcHQsIHRoZW4gdGhlIGludGVybmFsIGNsb2NrIGNoYW5nZXMgKHByZXN1bWFi
bHkgdy9vIGtub3dsZWRnZSBvZg0KPiA+PiB0aGUgc29mdHdhcmUgc3RvcmluZyB0aGUgZGF0ZXMp
IHRoZW4gdGltZSB3aWxsIGFsc28gZmFpbC4gQXNzdW1pbmcNCj4gPj4gdGhhdCBhIHVzZXIgd2l0
aCBhIGJhZCBjbG9jayAob2YgYnkgaG91cnMgb3IgbW9yZSkgd2lsbCBuZXZlciBmaXggaXQNCj4g
Pj4gYW5kIGFjdHVhbGx5IGVuY291cmFnZXMgYmFkIHVzZXIgYmVoYXZpb3IgKGRvbid0IGZpeCB5
b3VyIGNsb2NrIG9yDQo+ID4+IFR3aXR0ZXJib3Qgd2lsbCBzdG9wIHdvcmtpbmchKS4gVGhvdWdo
IHdlIHNheSB0aGF0IHRpbWV6b25lcyB3b24ndA0KPiA+PiBicmluZyBhYm91dCB0aGUgc2l0dWF0
aW9uIG9mIGNoYW5nZWQgY2xvY2ssIEknZCBiZSB0byBkaWZmZXIuIE1hbnkNCj4gPj4gdXNlcnMg
YXJlbid0IHNhdnZ5IGVub3VnaCB0byBjaGFuZ2UgdGltZSB6b25lLCBidXQganVzdCBhZGp1c3Qg
dGhlDQo+ID4+IHRpbWUgdG8gbG9jYWwgdGltZSBhbnl3YXkuIFVzZXJzIHdobyBhcmUgbW9yZSBs
aWtlbHkgdG8gZ2V0IGl0IHJpZ2h0DQo+ID4+IGFscmVhZHkgaGF2ZSBhdXRvIGNsb2NrIHN5bmMg
ZW5hYmxlZCAodmlhIHdlYiwgbW9iaWxlLCBldGMuKQ0KPiA+Pg0KPiA+PiAtIFdoYXQgaWYgdGhl
IHRva2VuIHdhc24ndCBvcmlnaW5hbGx5IGlzc3VlZCBwcm9ncmFtbWF0aWNhbGx5PyBJbiB0aGlz
IGNhc2UsDQo+IHRoZSBpc3N1ZSB0aW1lIGhhcyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoZSBzZXJ2
ZXIgYW5kIHN0b3JlZCBvbiB0aGUgY2xpZW50DQo+IHRoZW4geW91IGhhdmUgdGhlIHNhbWUgcHJv
YmxlbSBhcyB3aXRoIGEgdGltZXN0YW1wIC0gdGhlIGNsaWVudCBjbG9jayBpcyBub3QNCj4gc3lu
YydkIHRvIHRoZSBzZXJ2ZXIgY2xvY2sgYW5kIHRoZXJlIGlzIG5vIGFkanVzdG1lbnQuIFlvdSB3
YW50IHRoaXMgdG8gYXBwbHkNCj4gdG8gdXNlcyBvdXRzaWRlIG9mIGp1c3QgT0F1dGgsIGJ1dCBu
b3cgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gYmUgYWJsZSB0bw0KPiBkZXRlcm1pbmUgYW4gaXNz
dWUgdGltZSBiYXNlZCBvbiB3aGVuIGl0IHJlY2VpdmVzIGFuIEhUVFAgcmVxdWVzdA0KPiBuZWNl
c3NhcmlseSBsaW1pdHMgdGhlIHR5cGVzIG9mIHRva2VuIGZsb3dzIGZvciB3aGljaCB0aGlzIGNh
biBiZSB1c2VkLg0KPiA+Pg0KPiA+PiAtIEl0J3Mgb25lIG1vcmUgZGV0YWlsIHRvIHN0b3JlLiBI
YXJkbHkgYW4gaXNzdWUgZm9yIGEgZGV2ZWxvcGVyLCBidXQgaXQgaXMNCj4gaW5lbGVnYW50LiBJ
dCdzIGxpa2UgaGF2aW5nIGEgZG91YmxlIElELiBZZXQgaXQncyBub3QgYW4gSUQsIGl0IGlzIGFj
dHVhbGx5IG1vcmUgb2YgYQ0KPiByZWNvcmRpbmcgb2YgIm15IHBlcnNvbmFsIGNsb2NrIG9mZnNl
dCB2YWx1ZSIgYnV0IG9iZnVzY2F0ZWQgc2V2ZXJhbCB0aW1lcw0KPiBvdmVyIChvbmUgZm9yIGVh
Y2ggdG9rZW4pIGFzIGlzc3VlX2RhdGUuDQo+ID4+DQo+ID4+IC0gVGhpcyBpbXBsZW1lbnRhdGlv
biBhc3N1bWVzIHNvZnR3YXJlIHByb2dyYW1zIHVzZSB0aGUgY29tcHV0ZXINCj4gaW50ZXJuYWwg
Y2xvY2sgZXhjbHVzaXZlbHkgZm9yIHRpbWVzdGFtcC4gQSByb2J1c3QgcHJvZ3JhbSB0aGF0IGlz
IGRlcGVuZGVudA0KPiBvbiBhY2N1cmF0ZSB0aW1lc3RhbXBzIHdvdWxkIHBpbmcgdGhlIG9yaWdp
biBzZXJ2ZXIgKG9yIHNpbWlsYXIgdHJ1c3RlZCB0aW1lDQo+IGF1dGhvcml0eSkgdG8gYXNrIGl0
IHRoZSBjdXJyZW50IHRpbWUuIFRoZW4gaXQgY291bGQgc3RvcmUgYSAibXkgZGV2aWNlIGNsb2Nr
DQo+IG9mZnNldCIgdmFsdWUgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgcHJvZ3JhbSBleGVjdXRp
b24uIEFsbCByZXF1ZXN0cyBuZWVkaW5nDQo+IHRpbWVzdGFtcCB3b3VsZCBiZSBhZGp1c3RlZCBh
Y2NvcmRpbmdseS4gRm9yIGFnZSwgaWYgdGhlIGNsb2NrIGlzIGNoYW5nZWQNCj4gc2luY2UgdGhl
IHN0b3JlZCBpc3N1ZV9kYXRlLCB0aGUgcHJvYmxlbSBjYW4ndCBiZSBjb3JyZWN0ZWQgaW4gdGhp
cyBtYW5uZXIuDQo+IFRodXMsIGEgc2lnbmlmaWNhbnQgYWR2YW50YWdlIGZvciB0aW1lc3RhbXAu
DQo+ID4+DQo+ID4+IEFsbCBpbiBhbGwsIHRoaXMgc2VlbXMgbGlrZSBhIG1pc2d1aWRlZCBidXQg
d2VsbC1pbnRlbnRpb25lZCBhdHRlbXB0IHRvIGdldA0KPiBhcm91bmQgZW5kLXVzZXIgaXNzdWVz
IG9mIG1pcy1zZXQgY2xvY2tzLiBJdCBmZWVscyBsaWtlIGEgaGFjayBhbmQgaXQgY2VydGFpbmx5
DQo+IGlzbid0IGEgZm9vbHByb29mIHNvbHV0aW9uLiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IHRo
ZSBpbXBsaWNhdGlvbnMgb2YgdGhlIGFnZQ0KPiBwYXJhbWV0ZXIsIHRoZSBsZXNzIEkgbGlrZSBp
dC4gVGltZXN0YW1wIGhhcyBiZWVuIHVzZWQgZm9yIG1hbnkgeWVhcnMgaW4gdGhlDQo+IGluZHVz
dHJ5IGFuZCB3aXRoIHJlYXNvbmFibGUgc3VjY2VzcyBpbiByZWxldmFudCBhcHBsaWNhdGlvbnMu
IElmIHdlIGNoYW5nZSB0bw0KPiBhIG5ldyB3YXkgb2YgdHJ5aW5nIHRvIHN5bmMgb24gdGltZSBJ
IHRoaW5rIHdlIHJ1biBhIGdyZWF0ZXIgcmlzayBvZiBzdHVtYmxpbmcNCj4gdXBvbiB1bmZvcmVz
ZWVuIGlzc3Vlcywgc3VjaCBhcyB0aG9zZSBvdXRsaW5lZCBhYm92ZS4NCj4gPj4NCj4gPj4gSSBy
ZWNvbW1lbmQgdGhlIHJlcXVpcmVtZW50IG9mIGFuIGFnZSAob3IgdGltZXN0YW1wIGZvciB0aGF0
IG1hdHRlcikNCj4gYmUgZHJvcHBlZCBmcm9tIHRoZSBub25jZSBjb25zdHJ1Y3Rpb24uIEZvciBw
cm92aWRlcnMgdGhhdCBkZWVtIGl0DQo+IHZhbHVhYmxlLCB0aW1lc3RhbXAgY2FuIGJlIGFuIG9w
dGlvbmFsIHZhbHVlIChlaXRoZXIgYXMgcGFydCBvZiB0aGUgbm9uY2Ugb3INCj4gdGhlIG92ZXJh
bGwgaGVhZGVyLCBhcyBiZWZvcmUpLg0KPiA+Pg0KPiA+PiBza3lsYXINCj4gPj4NCj4gPj4NCj4g
Pj4NCj4gPj4gT24gTWF5IDIzLCAyMDExLCBhdCAyOjExIEFNLCBTa3lsYXIgV29vZHdhcmQgd3Jv
dGU6DQo+ID4+DQo+ID4+PiBZb3UgbWF5IGhhdmUgbm90aWNlZCwgb24gcGFnZSA4IHRoZSBob3N0
IGlzIGxpc3RlZCBhcyAiZXhhbXBsZS5uZXQiDQo+ID4+PiAtIHNob3VsZCBiZSBleGFtcGxlLmNv
bSwgSSBiZWxpZXZlLiDCoChkcmFmdCB2NSkNCj4gPj4+DQo+ID4+PiBBbGwgaW4gYWxsLCBJJ20g
aW4gc3VwcG9ydCBvZiB0aGUgY2hhbmdlcyBpbiB2Mi4gQ2VydGFpbmx5IGFkZHJlc3NlcyBteQ0K
PiBoZXNpdGF0aW9ucyBmcm9tIHYyLg0KPiA+Pj4NCj4gPj4+IHNreWxhcg0KPiA+Pj4NCj4gPj4+
DQo+ID4+PiBPbiBNYXkgOSwgMjAxMSwgYXQgMTI6MzYgUE0sIEVyYW4gSGFtbWVyLUxhaGF2IHdy
b3RlOg0KPiA+Pj4NCj4gPj4+PiAoUGxlYXNlIGRpc2N1c3MgdGhpcyBkcmFmdCBvbiB0aGUgQXBw
cy1EaXNjdXNzDQo+ID4+Pj4gPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gbWFpbGluZyBsaXN0KQ0K
PiA+Pj4+DQo+ID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFtbWVyLW9h
dXRoLXYyLW1hYy10b2tlbg0KPiA+Pj4+DQo+ID4+Pj4gV2hpbGUgdGhpcyBkb2N1bWVudCBoYXMg
bW92ZWQgdG8gdGhlIEFwcHMtRGlzY3VzcyBtYWlsaW5nIGxpc3QgZm9yIHRoZQ0KPiB0aW1lIGJl
aW5nLCBJIHdhbnRlZCB0byBnaXZlIGEgcXVpY2sgdXBkYXRlIHRvIHRob3NlIHdobyBoYXZlIGJl
ZW4NCj4gZm9sbG93aW5nIHRoaXMgZHJhZnQgd2hpY2ggb3JpZ2luYXRlZCBvbiB0aGlzIGxpc3Qu
DQo+ID4+Pj4NCj4gPj4+PiBUaGUgbWFqb3IgY2hhbmdlcyBzaW5jZSAtMDIgYXJlOg0KPiA+Pj4+
DQo+ID4+Pj4gKiBSZW1vdmVkIE9BdXRoIHRlcm1pbm9sb2d5IGFuZCBhc3NvY2lhdGlvbi4gVGhl
IGRyYWZ0IGlzIG5vdyBhDQo+IGdlbmVyYWwgcHVycG9zZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNj
aGVtZS4gSXQgZG9lcyBpbmNsdWRlIGFuIE9BdXRoIDIuMA0KPiBiaW5kaW5nIHdoaWNoIGlzIGRl
c2NyaWJlZCBpbiBsZXNzIHRoYW4gYSBwYWdlLiBPbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0bw0K
PiBtb3ZlIHNlY3Rpb24gNS4xIGludG8gdGhlIE9BdXRoIHNwZWNpZmljYXRpb24gYW5kIGRyb3Ag
YWxsIHRoZSBPQXV0aCAyLjAgdGV4dA0KPiBmcm9tIHRoZSBNQUMgZHJhZnQuDQo+ID4+Pj4NCj4g
Pj4+PiAqIEFkZGVkICdTZXQtQ29va2llJyBleHRlbnNpb24gZm9yIHVzaW5nIE1BQyB3aXRoIHNl
c3Npb24gY29va2llcy4NCj4gPj4+Pg0KPiA+Pj4+ICogUmVtb3ZlZCByZXF1ZXN0IFVSSSBxdWVy
eSBub3JtYWxpemF0aW9uLiBUaGUgbmV3IGRyYWZ0IHVzZXMgdGhlDQo+IHJhdyByZXF1ZXN0IFVS
SSB1bmNoYW5nZWQuDQo+ID4+Pj4NCj4gPj4+PiAqIFJlcGxhY2VkIHRpbWVzdGFtcHMgd2l0aCBj
cmVkZW50aWFscyBhZ2UgdG8gcmVtb3ZlIHRoZSBuZWVkIGZvcg0KPiBjbG9jayBzeW5jLg0KPiA+
Pj4+DQo+ID4+Pj4gKiBBZGRlZCBhIHBsYWNlaG9sZGVyIGZvciBleHRlbnNpb24sIGFsbG93aW5n
IHJhbmRvbSB0ZXh0IHRvIGJlDQo+IGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IGFuZCBNQUMuDQo+
ID4+Pj4NCj4gPj4+PiAqIEFkZGVkIGlzc3VlciBhdHRyaWJ1dGUgZm9yIGlkZW50aWZ5aW5nIHRo
ZSBzb3VyY2Ugb2YgdGhlIGNyZWRlbnRpYWxzIGFzDQo+IGFuIGFkZGl0aW9uYWwgcHJvdGVjdGlv
bi4NCj4gPj4+Pg0KPiA+Pj4+IERyYWZ0IC0wNCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHByZXZp
b3VzIGRyYWZ0cy4NCj4gPj4+Pg0KPiA+Pj4+IEVITA0KPiA+Pj4+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0
DQo+ID4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+Pg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCj4gPg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBQZXRlciBNLiBXb2xhbmluLCBQ
aC5ELiDCoCDCoCDCoDogTW9tZW50dW0gU3BlY2lhbGlzdCzCoCBBY3F1aWEuIEluYy4NCj4gcGV0
ZXIud29sYW5pbkBhY3F1aWEuY29tIDogOTc4LTI5Ni01MjQ3DQo+IA0KPiAiR2V0IGEgZnJlZSwg
aG9zdGVkIERydXBhbCA3IHNpdGU6IGh0dHA6Ly93d3cuZHJ1cGFsZ2FyZGVucy5jb20iDQo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQo=

From skylar@kiva.org  Mon May 30 00: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 EE1F2E077C for ; Mon, 30 May 2011 00:04:07 -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 EaI6CP0uBqtL for ; Mon, 30 May 2011 00:04:01 -0700 (PDT)
Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 52A47E0773 for ; Mon, 30 May 2011 00:03:59 -0700 (PDT)
Received: from mail-wy0-f170.google.com ([74.125.82.170]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTeNBXp8V8uhbNt0JIT6Yx+5nBGIPLUWh@postini.com; Mon, 30 May 2011 00:04:00 PDT
Received: by wyb34 with SMTP id 34so4921187wyb.1 for ; Mon, 30 May 2011 00:03:57 -0700 (PDT)
Received: by 10.216.152.170 with SMTP id d42mr4929609wek.39.1306739037629; Mon, 30 May 2011 00:03:57 -0700 (PDT)
Received: from [78.250.140.221] ([78.250.140.221]) by mx.google.com with ESMTPS id 74sm2289489wem.17.2011.05.30.00.03.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 00:03:56 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Skylar Woodward 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 30 May 2011 09:03:54 +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>
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: Mon, 30 May 2011 07:04:08 -0000

But see, now you are specializing the use of MAC token even more - now =
it's becoming a service mainly for user-agents on home desktops? This is =
further for the original goal of making MAC as flexible is possible. In =
this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.

Sarcasm aside, my point is that timestamp is just as good as your offset =
technique and is more: reliable, straightforward, flexible.

User agents that care about creating robust behavior for home desktops =
or mobiles (presumably of users and OS not yet sophisticated enough to =
check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.

Please change the spec back to using timestamp rather than age.

I'd also like to hear a convincing argument from the Mozilla co-authors =
about why they think that age is more resilient than the above (I =
believe it is not) and further more why they would find the above =
unattractive or difficult to implement in a modern user-agent.

Thanks,
skylar

... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... -.- =
-.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
skylar woodward
Kiva Developer Program  /  build.kiva.org  /  @buildkiva


On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:

> Any kind of clock sync requirement for user-agents (basically, home =
desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>=20
> The issue here is who is this being optimized for. Server-to-server =
communication should simply use TLS for privacy and MITM protection on =
top of MAC instead of using nonces to prevent replay. The whole point of =
this kind of replay protection is when TLS is not available.
>=20
> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>=20
> EHL
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Peter Wolanin
>> Sent: Sunday, May 29, 2011 6:53 PM
>> To: Skylar Woodward
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>=20
>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>> and also the added complexity of specifying this construction.
>>=20
>> I think it would be preferable to always require a timestamp as part =
of the
>> authorization header, and maybe even include in the spec a maximum =
time
>> difference between client and server (e.g. 900 seconds) that can be
>> tolerated.  This makes generating the nonce easier also, since the =
value need
>> to longer be unique over all time.
>>=20
>> We have such rules in place for an HMAC-based authentication system =
we
>> use.  Once in a while a client has a local clock so far out of sync =
that there is an
>> issue, but it's rare.
>>=20
>> -Peter
>>=20
>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>> wrote:
>>> Resending to the list from my subscribed account...
>>>=20
>>> Begin forwarded message:
>>>=20
>>>> From: Skylar Woodward 
>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>> To: Skylar Woodward 
>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>> 
>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>=20
>>>> So after discussing this today and reflecting on it a bit, I would =
suggest that
>> nonce simply be the "unique value" (as it is so named) without =
further
>> requirements. It might be suggested that this be composed of an
>> random+timestamp (not age) value, but that seems more of a MAY or
>> "recommended" practice. If the expectation is that very few if any =
providers
>> would actually check the timestamp (or moreover, the nonce itself), =
why add
>> terminology in the draft that requires it? Developers are doing extra
>> housekeeping (and perhaps for a perceived benefit) but with no payoff =
or
>> added security.
>>>>=20
>>>> I'm sending this feedback based on having implemented the v3-5 =
changes
>> last night (for both client credentials and requests w/ access =
tokens). After
>> the changes, the nonce creation is now the most complicated part of =
the
>> normalized request string and yet these changes offer the least =
benefit.
>> What's most important is that nonces are unique on each request for =
an ID.
>>>>=20
>>>> There are issues with age as well:
>>>>=20
>>>> - As Bill mentioned, if the client stores the issue time based on
>>>> receipt, then the internal clock changes (presumably w/o knowledge =
of
>>>> the software storing the dates) then time will also fail. Assuming
>>>> that a user with a bad clock (of by hours or more) will never fix =
it
>>>> and actually encourages bad user behavior (don't fix your clock or
>>>> Twitterbot will stop working!). Though we say that timezones won't
>>>> bring about the situation of changed clock, I'd be to differ. Many
>>>> users aren't savvy enough to change time zone, but just adjust the
>>>> time to local time anyway. Users who are more likely to get it =
right
>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>=20
>>>> - What if the token wasn't originally issued programmatically? In =
this case,
>> the issue time has to be obtained from the server and stored on the =
client
>> then you have the same problem as with a timestamp - the client clock =
is not
>> sync'd to the server clock and there is no adjustment. You want this =
to apply
>> to uses outside of just OAuth, but now requiring the client to be =
able to
>> determine an issue time based on when it receives an HTTP request
>> necessarily limits the types of token flows for which this can be =
used.
>>>>=20
>>>> - It's one more detail to store. Hardly an issue for a developer, =
but it is
>> inelegant. It's like having a double ID. Yet it's not an ID, it is =
actually more of a
>> recording of "my personal clock offset value" but obfuscated several =
times
>> over (one for each token) as issue_date.
>>>>=20
>>>> - This implementation assumes software programs use the computer
>> internal clock exclusively for timestamp. A robust program that is =
dependent
>> on accurate timestamps would ping the origin server (or similar =
trusted time
>> authority) to ask it the current time. Then it could store a "my =
device clock
>> offset" value for the lifetime of the program execution. All requests =
needing
>> timestamp would be adjusted accordingly. For age, if the clock is =
changed
>> since the stored issue_date, the problem can't be corrected in this =
manner.
>> Thus, a significant advantage for timestamp.
>>>>=20
>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>> around end-user issues of mis-set clocks. It feels like a hack and it =
certainly
>> isn't a foolproof solution. The more I think about the implications =
of the age
>> parameter, the less I like it. Timestamp has been used for many years =
in the
>> industry and with reasonable success in relevant applications. If we =
change to
>> a new way of trying to sync on time I think we run a greater risk of =
stumbling
>> upon unforeseen issues, such as those outlined above.
>>>>=20
>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>> be dropped from the nonce construction. For providers that deem it
>> valuable, timestamp can be an optional value (either as part of the =
nonce or
>> the overall header, as before).
>>>>=20
>>>> skylar
>>>>=20
>>>>=20
>>>>=20
>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>=20
>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>> - should be example.com, I believe.  (draft v5)
>>>>>=20
>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>> hesitations from v2.
>>>>>=20
>>>>> skylar
>>>>>=20
>>>>>=20
>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>=20
>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>  mailing list)
>>>>>>=20
>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>=20
>>>>>> While this document has moved to the Apps-Discuss mailing list =
for the
>> time being, I wanted to give a quick update to those who have been
>> following this draft which originated on this list.
>>>>>>=20
>>>>>> The major changes since -02 are:
>>>>>>=20
>>>>>> * Removed OAuth terminology and association. The draft is now a
>> general purpose HTTP authentication scheme. It does include an OAuth =
2.0
>> binding which is described in less than a page. One suggestion would =
be to
>> move section 5.1 into the OAuth specification and drop all the OAuth =
2.0 text
>> from the MAC draft.
>>>>>>=20
>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>=20
>>>>>> * Removed request URI query normalization. The new draft uses the
>> raw request URI unchanged.
>>>>>>=20
>>>>>> * Replaced timestamps with credentials age to remove the need for
>> clock sync.
>>>>>>=20
>>>>>> * Added a placeholder for extension, allowing random text to be
>> included in the request and MAC.
>>>>>>=20
>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>> an additional protection.
>>>>>>=20
>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>=20
>>>>>> EHL
>>>>>> _______________________________________________
>>>>>> 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
>>>=20
>>=20
>>=20
>>=20
>> --
>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
>> peter.wolanin@acquia.com : 978-296-5247
>>=20
>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From ietf@adambarth.com  Mon May 30 00:08: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 8F277E077E for ; Mon, 30 May 2011 00:08:41 -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 uuO2T80R6rUO for ; Mon, 30 May 2011 00:08:40 -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 23EC8E06EC for ; Mon, 30 May 2011 00:08:40 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1899088gyf.31 for ; Mon, 30 May 2011 00:08:39 -0700 (PDT)
Received: by 10.150.207.8 with SMTP id e8mr3808975ybg.139.1306739318570; Mon, 30 May 2011 00:08:38 -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 19sm3139343anx.10.2011.05.30.00.08.36 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 00:08:36 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1928617ywp.31 for ; Mon, 30 May 2011 00:08:36 -0700 (PDT)
Received: by 10.91.195.29 with SMTP id x29mr3928361agp.97.1306739316161; Mon, 30 May 2011 00:08:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.35.6 with HTTP; Mon, 30 May 2011 00:08:06 -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> 
From: Adam Barth 
Date: Mon, 30 May 2011 00:08:06 -0700
Message-ID: 
To: Skylar Woodward 
Content-Type: text/plain; charset=windows-1252
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: Mon, 30 May 2011 07:08:41 -0000

I can't speak for Mozilla, but I can tell you that many folks don't
have synchronized clocks, for a wide variety of reasons.  I guess I
don't really understand why you view age as problematic.  You
reference "fragility of using time-since-credentials-issued" but you
don't say what exactly is fragile about it.  There's nothing
particularly complex about age, especially when using the monotonic
clock provided by all modern operating systems.

Adam


On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wrote:
> But see, now you are specializing the use of MAC token even more - now it=
's becoming a service mainly for user-agents on home desktops? This is furt=
her for the original goal of making MAC as flexible is possible. In this ca=
se you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEM=
ENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>
> Sarcasm aside, my point is that timestamp is just as good as your offset =
technique and is more: reliable, straightforward, flexible.
>
> User agents that care about creating robust behavior for home desktops or=
 mobiles (presumably of users and OS not yet sophisticated enough to check =
network time on their own) should be advised to do clock correction on thei=
r own (by pinging a time service) and trusting the device clock alone.
>
> Please change the spec back to using timestamp rather than age.
>
> I'd also like to hear a convincing argument from the Mozilla co-authors a=
bout why they think that age is more resilient than the above (I believe it=
 is not) and further more why they would find the above unattractive or dif=
ficult to implement in a modern user-agent.
>
> Thanks,
> skylar
>
> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... -.- -=
.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
> skylar woodward
> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiva
>
>
> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>
>> Any kind of clock sync requirement for user-agents (basically, home desk=
tops) it completely impractical. The added complexity pales in comparison t=
o the difficulty of trying to use timestamps and any kind of clock sync. No=
 window will be big enough as experience shows some users have closes that =
are off by more than an hour and a half.
>>
>> The issue here is who is this being optimized for. Server-to-server comm=
unication should simply use TLS for privacy and MITM protection on top of M=
AC instead of using nonces to prevent replay. The whole point of this kind =
of replay protection is when TLS is not available.
>>
>> I think a better approach is to simply make checking the nonce optional =
when TLS is used.
>>
>> EHL
>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of Peter Wolanin
>>> Sent: Sunday, May 29, 2011 6:53 PM
>>> To: Skylar Woodward
>>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>>
>>> I am also concerned by the fragility of using time-since-credentials-is=
sued,
>>> and also the added complexity of specifying this construction.
>>>
>>> I think it would be preferable to always require a timestamp as part of=
 the
>>> authorization header, and maybe even include in the spec a maximum time
>>> difference between client and server (e.g. 900 seconds) that can be
>>> tolerated. =A0This makes generating the nonce easier also, since the va=
lue need
>>> to longer be unique over all time.
>>>
>>> We have such rules in place for an HMAC-based authentication system we
>>> use. =A0Once in a while a client has a local clock so far out of sync t=
hat there is an
>>> issue, but it's rare.
>>>
>>> -Peter
>>>
>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>> wrote:
>>>> Resending to the list from my subscribed account...
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Skylar Woodward 
>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>> To: Skylar Woodward 
>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>> 
>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>>
>>>>> So after discussing this today and reflecting on it a bit, I would su=
ggest that
>>> nonce simply be the "unique value" (as it is so named) without further
>>> requirements. It might be suggested that this be composed of an
>>> random+timestamp (not age) value, but that seems more of a MAY or
>>> "recommended" practice. If the expectation is that very few if any prov=
iders
>>> would actually check the timestamp (or moreover, the nonce itself), why=
 add
>>> terminology in the draft that requires it? Developers are doing extra
>>> housekeeping (and perhaps for a perceived benefit) but with no payoff o=
r
>>> added security.
>>>>>
>>>>> I'm sending this feedback based on having implemented the v3-5 change=
s
>>> last night (for both client credentials and requests w/ access tokens).=
 After
>>> the changes, the nonce creation is now the most complicated part of the
>>> normalized request string and yet these changes offer the least benefit=
.
>>> What's most important is that nonces are unique on each request for an =
ID.
>>>>>
>>>>> There are issues with age as well:
>>>>>
>>>>> - As Bill mentioned, if the client stores the issue time based on
>>>>> receipt, then the internal clock changes (presumably w/o knowledge of
>>>>> the software storing the dates) then time will also fail. Assuming
>>>>> that a user with a bad clock (of by hours or more) will never fix it
>>>>> and actually encourages bad user behavior (don't fix your clock or
>>>>> Twitterbot will stop working!). Though we say that timezones won't
>>>>> bring about the situation of changed clock, I'd be to differ. Many
>>>>> users aren't savvy enough to change time zone, but just adjust the
>>>>> time to local time anyway. Users who are more likely to get it right
>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>
>>>>> - What if the token wasn't originally issued programmatically? In thi=
s case,
>>> the issue time has to be obtained from the server and stored on the cli=
ent
>>> then you have the same problem as with a timestamp - the client clock i=
s not
>>> sync'd to the server clock and there is no adjustment. You want this to=
 apply
>>> to uses outside of just OAuth, but now requiring the client to be able =
to
>>> determine an issue time based on when it receives an HTTP request
>>> necessarily limits the types of token flows for which this can be used.
>>>>>
>>>>> - It's one more detail to store. Hardly an issue for a developer, but=
 it is
>>> inelegant. It's like having a double ID. Yet it's not an ID, it is actu=
ally more of a
>>> recording of "my personal clock offset value" but obfuscated several ti=
mes
>>> over (one for each token) as issue_date.
>>>>>
>>>>> - This implementation assumes software programs use the computer
>>> internal clock exclusively for timestamp. A robust program that is depe=
ndent
>>> on accurate timestamps would ping the origin server (or similar trusted=
 time
>>> authority) to ask it the current time. Then it could store a "my device=
 clock
>>> offset" value for the lifetime of the program execution. All requests n=
eeding
>>> timestamp would be adjusted accordingly. For age, if the clock is chang=
ed
>>> since the stored issue_date, the problem can't be corrected in this man=
ner.
>>> Thus, a significant advantage for timestamp.
>>>>>
>>>>> All in all, this seems like a misguided but well-intentioned attempt =
to get
>>> around end-user issues of mis-set clocks. It feels like a hack and it c=
ertainly
>>> isn't a foolproof solution. The more I think about the implications of =
the age
>>> parameter, the less I like it. Timestamp has been used for many years i=
n the
>>> industry and with reasonable success in relevant applications. If we ch=
ange to
>>> a new way of trying to sync on time I think we run a greater risk of st=
umbling
>>> upon unforeseen issues, such as those outlined above.
>>>>>
>>>>> I recommend the requirement of an age (or timestamp for that matter)
>>> be dropped from the nonce construction. For providers that deem it
>>> valuable, timestamp can be an optional value (either as part of the non=
ce or
>>> the overall header, as before).
>>>>>
>>>>> skylar
>>>>>
>>>>>
>>>>>
>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>
>>>>>> You may have noticed, on page 8 the host is listed as "example.net"
>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>
>>>>>> All in all, I'm in support of the changes in v2. Certainly addresses=
 my
>>> hesitations from v2.
>>>>>>
>>>>>> skylar
>>>>>>
>>>>>>
>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>
>>>>>>> While this document has moved to the Apps-Discuss mailing list for =
the
>>> time being, I wanted to give a quick update to those who have been
>>> following this draft which originated on this list.
>>>>>>>
>>>>>>> The major changes since -02 are:
>>>>>>>
>>>>>>> * Removed OAuth terminology and association. The draft is now a
>>> general purpose HTTP authentication scheme. It does include an OAuth 2.=
0
>>> binding which is described in less than a page. One suggestion would be=
 to
>>> move section 5.1 into the OAuth specification and drop all the OAuth 2.=
0 text
>>> from the MAC draft.
>>>>>>>
>>>>>>> * Added 'Set-Cookie' extension for using MAC with session cookies.
>>>>>>>
>>>>>>> * Removed request URI query normalization. The new draft uses the
>>> raw request URI unchanged.
>>>>>>>
>>>>>>> * Replaced timestamps with credentials age to remove the need for
>>> clock sync.
>>>>>>>
>>>>>>> * Added a placeholder for extension, allowing random text to be
>>> included in the request and MAC.
>>>>>>>
>>>>>>> * Added issuer attribute for identifying the source of the credenti=
als as
>>> an additional protection.
>>>>>>>
>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>
>>>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0Acquia. In=
c.
>>> peter.wolanin@acquia.com : 978-296-5247
>>>
>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>> _______________________________________________
>>> 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 skylar@kiva.org  Mon May 30 23:19: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 77C5AE06D4 for ; Mon, 30 May 2011 23:19:27 -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 D4p1UKBYfhbC for ; Mon, 30 May 2011 23:19:26 -0700 (PDT)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 534BBE06BE for ; Mon, 30 May 2011 23:19:24 -0700 (PDT)
Received: from mail-ww0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTeSIawYLaoaX5MQKBmNARZzpAMml3j1c@postini.com; Mon, 30 May 2011 23:19:25 PDT
Received: by wwb39 with SMTP id 39so3557751wwb.18 for ; Mon, 30 May 2011 23:19:22 -0700 (PDT)
Received: by 10.227.201.142 with SMTP id fa14mr5651794wbb.48.1306822762468; Mon, 30 May 2011 23:19:22 -0700 (PDT)
Received: from [78.250.136.59] ([78.250.136.59]) by mx.google.com with ESMTPS id fw15sm3510588wbb.44.2011.05.30.23.19.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 23:19:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Skylar Woodward 
In-Reply-To: 
Date: Tue, 31 May 2011 08:19:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org>
References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org>  <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@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: Tue, 31 May 2011 06:19:27 -0000

I don't think you read my first message on the topic (or I wrote too =
much).

Age is fragile because if the clock changes between issue_date and the =
time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:

1) the client is able to guess the issue_date the server is using based =
on the time the credential was issued
2) the client system clock doesn't change between issue date and =
submission time.

Timestamp has neither of these issues because the client can always =
inquire about network time and can effectively correct for inaccuracies =
in the device timekeeping system.

Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the =
client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:

	local_offset =3D current_server_time - current_device_time
	age =3D current_device_time - (server_issue_date-local_offset)

Since the protocol doesn't currently allow for server_issue_date to be =
given with tokens, thus age currently can't have the resilience that =
timestamp does. It also forces servers to issue new tokens on demand =
just to make the convoluted age system work (rather than reuse existing =
valid tokens). Or, you have to modify the protocol to add =
server_issue_date and current_server_time into the token-issue exchange =
- eg, more complexity.

Timestamp is simpler, proven, it and it has a solution for your use case =
of unsyncronized clocks.

skylar


On May 30, 2011, at 9:08 AM, Adam Barth wrote:

> I can't speak for Mozilla, but I can tell you that many folks don't
> have synchronized clocks, for a wide variety of reasons.  I guess I
> don't really understand why you view age as problematic.  You
> reference "fragility of using time-since-credentials-issued" but you
> don't say what exactly is fragile about it.  There's nothing
> particularly complex about age, especially when using the monotonic
> clock provided by all modern operating systems.
>=20
> Adam
>=20
>=20
> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  =
wrote:
>> But see, now you are specializing the use of MAC token even more - =
now it's becoming a service mainly for user-agents on home desktops? =
This is further for the original goal of making MAC as flexible is =
possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>=20
>> Sarcasm aside, my point is that timestamp is just as good as your =
offset technique and is more: reliable, straightforward, flexible.
>>=20
>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>=20
>> Please change the spec back to using timestamp rather than age.
>>=20
>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>=20
>> Thanks,
>> skylar
>>=20
>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... =
-.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>> skylar woodward
>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>=20
>>=20
>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>=20
>>> Any kind of clock sync requirement for user-agents (basically, home =
desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>>>=20
>>> The issue here is who is this being optimized for. Server-to-server =
communication should simply use TLS for privacy and MITM protection on =
top of MAC instead of using nonces to prevent replay. The whole point of =
this kind of replay protection is when TLS is not available.
>>>=20
>>> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>>>=20
>>> EHL
>>>=20
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>> Of Peter Wolanin
>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>> To: Skylar Woodward
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>>>=20
>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>> and also the added complexity of specifying this construction.
>>>>=20
>>>> I think it would be preferable to always require a timestamp as =
part of the
>>>> authorization header, and maybe even include in the spec a maximum =
time
>>>> difference between client and server (e.g. 900 seconds) that can be
>>>> tolerated.  This makes generating the nonce easier also, since the =
value need
>>>> to longer be unique over all time.
>>>>=20
>>>> We have such rules in place for an HMAC-based authentication system =
we
>>>> use.  Once in a while a client has a local clock so far out of sync =
that there is an
>>>> issue, but it's rare.
>>>>=20
>>>> -Peter
>>>>=20
>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>> wrote:
>>>>> Resending to the list from my subscribed account...
>>>>>=20
>>>>> Begin forwarded message:
>>>>>=20
>>>>>> From: Skylar Woodward 
>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>> To: Skylar Woodward 
>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>> 
>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>>>=20
>>>>>> So after discussing this today and reflecting on it a bit, I =
would suggest that
>>>> nonce simply be the "unique value" (as it is so named) without =
further
>>>> requirements. It might be suggested that this be composed of an
>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>> "recommended" practice. If the expectation is that very few if any =
providers
>>>> would actually check the timestamp (or moreover, the nonce itself), =
why add
>>>> terminology in the draft that requires it? Developers are doing =
extra
>>>> housekeeping (and perhaps for a perceived benefit) but with no =
payoff or
>>>> added security.
>>>>>>=20
>>>>>> I'm sending this feedback based on having implemented the v3-5 =
changes
>>>> last night (for both client credentials and requests w/ access =
tokens). After
>>>> the changes, the nonce creation is now the most complicated part of =
the
>>>> normalized request string and yet these changes offer the least =
benefit.
>>>> What's most important is that nonces are unique on each request for =
an ID.
>>>>>>=20
>>>>>> There are issues with age as well:
>>>>>>=20
>>>>>> - As Bill mentioned, if the client stores the issue time based on
>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>> that a user with a bad clock (of by hours or more) will never fix =
it
>>>>>> and actually encourages bad user behavior (don't fix your clock =
or
>>>>>> Twitterbot will stop working!). Though we say that timezones =
won't
>>>>>> bring about the situation of changed clock, I'd be to differ. =
Many
>>>>>> users aren't savvy enough to change time zone, but just adjust =
the
>>>>>> time to local time anyway. Users who are more likely to get it =
right
>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>=20
>>>>>> - What if the token wasn't originally issued programmatically? In =
this case,
>>>> the issue time has to be obtained from the server and stored on the =
client
>>>> then you have the same problem as with a timestamp - the client =
clock is not
>>>> sync'd to the server clock and there is no adjustment. You want =
this to apply
>>>> to uses outside of just OAuth, but now requiring the client to be =
able to
>>>> determine an issue time based on when it receives an HTTP request
>>>> necessarily limits the types of token flows for which this can be =
used.
>>>>>>=20
>>>>>> - It's one more detail to store. Hardly an issue for a developer, =
but it is
>>>> inelegant. It's like having a double ID. Yet it's not an ID, it is =
actually more of a
>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>> over (one for each token) as issue_date.
>>>>>>=20
>>>>>> - This implementation assumes software programs use the computer
>>>> internal clock exclusively for timestamp. A robust program that is =
dependent
>>>> on accurate timestamps would ping the origin server (or similar =
trusted time
>>>> authority) to ask it the current time. Then it could store a "my =
device clock
>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>> timestamp would be adjusted accordingly. For age, if the clock is =
changed
>>>> since the stored issue_date, the problem can't be corrected in this =
manner.
>>>> Thus, a significant advantage for timestamp.
>>>>>>=20
>>>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>>>> around end-user issues of mis-set clocks. It feels like a hack and =
it certainly
>>>> isn't a foolproof solution. The more I think about the implications =
of the age
>>>> parameter, the less I like it. Timestamp has been used for many =
years in the
>>>> industry and with reasonable success in relevant applications. If =
we change to
>>>> a new way of trying to sync on time I think we run a greater risk =
of stumbling
>>>> upon unforeseen issues, such as those outlined above.
>>>>>>=20
>>>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>>>> be dropped from the nonce construction. For providers that deem it
>>>> valuable, timestamp can be an optional value (either as part of the =
nonce or
>>>> the overall header, as before).
>>>>>>=20
>>>>>> skylar
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>=20
>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>=20
>>>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>>>> hesitations from v2.
>>>>>>>=20
>>>>>>> skylar
>>>>>>>=20
>>>>>>>=20
>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>=20
>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>  mailing list)
>>>>>>>>=20
>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>=20
>>>>>>>> While this document has moved to the Apps-Discuss mailing list =
for the
>>>> time being, I wanted to give a quick update to those who have been
>>>> following this draft which originated on this list.
>>>>>>>>=20
>>>>>>>> The major changes since -02 are:
>>>>>>>>=20
>>>>>>>> * Removed OAuth terminology and association. The draft is now a
>>>> general purpose HTTP authentication scheme. It does include an =
OAuth 2.0
>>>> binding which is described in less than a page. One suggestion =
would be to
>>>> move section 5.1 into the OAuth specification and drop all the =
OAuth 2.0 text
>>>> from the MAC draft.
>>>>>>>>=20
>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>>>=20
>>>>>>>> * Removed request URI query normalization. The new draft uses =
the
>>>> raw request URI unchanged.
>>>>>>>>=20
>>>>>>>> * Replaced timestamps with credentials age to remove the need =
for
>>>> clock sync.
>>>>>>>>=20
>>>>>>>> * Added a placeholder for extension, allowing random text to be
>>>> included in the request and MAC.
>>>>>>>>=20
>>>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>>>> an additional protection.
>>>>>>>>=20
>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>=20
>>>>>>>> EHL
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>=20
>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>> _______________________________________________
>>>> 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
>>=20


From ietf@adambarth.com  Tue May 31 00:48: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 63BACE0742 for ; Tue, 31 May 2011 00:48:26 -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 t2HdumaGV-RB for ; Tue, 31 May 2011 00:48:25 -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 D1EF8E06DC for ; Tue, 31 May 2011 00:48:24 -0700 (PDT)
Received: by ywp31 with SMTP id 31so2352469ywp.31 for ; Tue, 31 May 2011 00:48:24 -0700 (PDT)
Received: by 10.90.58.36 with SMTP id g36mr777793aga.30.1306828102819; Tue, 31 May 2011 00:48:22 -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 c21sm3811763ana.24.2011.05.31.00.48.21 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 00:48:21 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2322865gyf.31 for ; Tue, 31 May 2011 00:48:20 -0700 (PDT)
Received: by 10.91.126.12 with SMTP id d12mr4658883agn.98.1306828100684; Tue, 31 May 2011 00:48:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 00:47:50 -0700 (PDT)
In-Reply-To: <923870FE-C1C5-4213-AF2F-496E469D0C6E@kiva.org>
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>
From: Adam Barth 
Date: Tue, 31 May 2011 00:47:50 -0700
Message-ID: 
To: Skylar Woodward 
Content-Type: text/plain; charset=windows-1252
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: Tue, 31 May 2011 07:48:26 -0000

Timestamps don't work when the client doesn't have a synchronized
clock.  It's true that a client could synchronize its clock with the
network, but our implementation experience is that many clients don't
for a variety of reasons.  That means that age better because, you
know, it works.

Adam


On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  wrote:
> I don't think you read my first message on the topic (or I wrote too much=
).
>
> Age is fragile because if the clock changes between issue_date and the ti=
me of submission, it will fail. We know many people don't have synchronized=
 clocks, but using age only solves this problem if two assumptions hold tru=
e:
>
> 1) the client is able to guess the issue_date the server is using based o=
n the time the credential was issued
> 2) the client system clock doesn't change between issue date and submissi=
on time.
>
> Timestamp has neither of these issues because the client can always inqui=
re about network time and can effectively correct for inaccuracies in the d=
evice timekeeping system.
>
> Regarding the first assumption, this fails when a token might be re-issue=
d between devices. An example is that we use MAC token for the client crede=
ntials, which are issued when a developer registers an application. The cli=
ent has no way of determining on its own when the value was actually issued=
 (unless we communicate that on the developer website and force users to em=
bed that with client_id, which adds usability issues of users copying and e=
ntering string date values correctly). The same is actually true for all of=
 our OAuth access tokens because we reissue tokens to the same client_id if=
 they were previously issued and are still valid. (The client would thus th=
ink the issue_date was now() when if fact it was the time of the first issu=
e for client_id+scope+grantor_id). Thus, age is really just a convoluted wa=
y of trying to communicate the device system offset:
>
> =A0 =A0 =A0 =A0local_offset =3D current_server_time - current_device_time
> =A0 =A0 =A0 =A0age =3D current_device_time - (server_issue_date-local_off=
set)
>
> Since the protocol doesn't currently allow for server_issue_date to be gi=
ven with tokens, thus age currently can't have the resilience that timestam=
p does. It also forces servers to issue new tokens on demand just to make t=
he convoluted age system work (rather than reuse existing valid tokens). Or=
, you have to modify the protocol to add server_issue_date and current_serv=
er_time into the token-issue exchange - eg, more complexity.
>
> Timestamp is simpler, proven, it and it has a solution for your use case =
of unsyncronized clocks.
>
> skylar
>
>
> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>
>> I can't speak for Mozilla, but I can tell you that many folks don't
>> have synchronized clocks, for a wide variety of reasons. =A0I guess I
>> don't really understand why you view age as problematic. =A0You
>> reference "fragility of using time-since-credentials-issued" but you
>> don't say what exactly is fragile about it. =A0There's nothing
>> particularly complex about age, especially when using the monotonic
>> clock provided by all modern operating systems.
>>
>> Adam
>>
>>
>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wrot=
e:
>>> But see, now you are specializing the use of MAC token even more - now =
it's becoming a service mainly for user-agents on home desktops? This is fu=
rther for the original goal of making MAC as flexible is possible. In this =
case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_REPLAC=
EMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>
>>> Sarcasm aside, my point is that timestamp is just as good as your offse=
t technique and is more: reliable, straightforward, flexible.
>>>
>>> User agents that care about creating robust behavior for home desktops =
or mobiles (presumably of users and OS not yet sophisticated enough to chec=
k network time on their own) should be advised to do clock correction on th=
eir own (by pinging a time service) and trusting the device clock alone.
>>>
>>> Please change the spec back to using timestamp rather than age.
>>>
>>> I'd also like to hear a convincing argument from the Mozilla co-authors=
 about why they think that age is more resilient than the above (I believe =
it is not) and further more why they would find the above unattractive or d=
ifficult to implement in a modern user-agent.
>>>
>>> Thanks,
>>> skylar
>>>
>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... -.-=
 -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>> skylar woodward
>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiva
>>>
>>>
>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>
>>>> Any kind of clock sync requirement for user-agents (basically, home de=
sktops) it completely impractical. The added complexity pales in comparison=
 to the difficulty of trying to use timestamps and any kind of clock sync. =
No window will be big enough as experience shows some users have closes tha=
t are off by more than an hour and a half.
>>>>
>>>> The issue here is who is this being optimized for. Server-to-server co=
mmunication should simply use TLS for privacy and MITM protection on top of=
 MAC instead of using nonces to prevent replay. The whole point of this kin=
d of replay protection is when TLS is not available.
>>>>
>>>> I think a better approach is to simply make checking the nonce optiona=
l when TLS is used.
>>>>
>>>> EHL
>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal=
f
>>>>> Of Peter Wolanin
>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>> To: Skylar Woodward
>>>>> Cc: OAuth WG
>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC toke=
n
>>>>>
>>>>> I am also concerned by the fragility of using time-since-credentials-=
issued,
>>>>> and also the added complexity of specifying this construction.
>>>>>
>>>>> I think it would be preferable to always require a timestamp as part =
of the
>>>>> authorization header, and maybe even include in the spec a maximum ti=
me
>>>>> difference between client and server (e.g. 900 seconds) that can be
>>>>> tolerated. =A0This makes generating the nonce easier also, since the =
value need
>>>>> to longer be unique over all time.
>>>>>
>>>>> We have such rules in place for an HMAC-based authentication system w=
e
>>>>> use. =A0Once in a while a client has a local clock so far out of sync=
 that there is an
>>>>> issue, but it's rare.
>>>>>
>>>>> -Peter
>>>>>
>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>> wrote:
>>>>>> Resending to the list from my subscribed account...
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: Skylar Woodward 
>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>> To: Skylar Woodward 
>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>> 
>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>>>>
>>>>>>> So after discussing this today and reflecting on it a bit, I would =
suggest that
>>>>> nonce simply be the "unique value" (as it is so named) without furthe=
r
>>>>> requirements. It might be suggested that this be composed of an
>>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>>> "recommended" practice. If the expectation is that very few if any pr=
oviders
>>>>> would actually check the timestamp (or moreover, the nonce itself), w=
hy add
>>>>> terminology in the draft that requires it? Developers are doing extra
>>>>> housekeeping (and perhaps for a perceived benefit) but with no payoff=
 or
>>>>> added security.
>>>>>>>
>>>>>>> I'm sending this feedback based on having implemented the v3-5 chan=
ges
>>>>> last night (for both client credentials and requests w/ access tokens=
). After
>>>>> the changes, the nonce creation is now the most complicated part of t=
he
>>>>> normalized request string and yet these changes offer the least benef=
it.
>>>>> What's most important is that nonces are unique on each request for a=
n ID.
>>>>>>>
>>>>>>> There are issues with age as well:
>>>>>>>
>>>>>>> - As Bill mentioned, if the client stores the issue time based on
>>>>>>> receipt, then the internal clock changes (presumably w/o knowledge =
of
>>>>>>> the software storing the dates) then time will also fail. Assuming
>>>>>>> that a user with a bad clock (of by hours or more) will never fix i=
t
>>>>>>> and actually encourages bad user behavior (don't fix your clock or
>>>>>>> Twitterbot will stop working!). Though we say that timezones won't
>>>>>>> bring about the situation of changed clock, I'd be to differ. Many
>>>>>>> users aren't savvy enough to change time zone, but just adjust the
>>>>>>> time to local time anyway. Users who are more likely to get it righ=
t
>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>
>>>>>>> - What if the token wasn't originally issued programmatically? In t=
his case,
>>>>> the issue time has to be obtained from the server and stored on the c=
lient
>>>>> then you have the same problem as with a timestamp - the client clock=
 is not
>>>>> sync'd to the server clock and there is no adjustment. You want this =
to apply
>>>>> to uses outside of just OAuth, but now requiring the client to be abl=
e to
>>>>> determine an issue time based on when it receives an HTTP request
>>>>> necessarily limits the types of token flows for which this can be use=
d.
>>>>>>>
>>>>>>> - It's one more detail to store. Hardly an issue for a developer, b=
ut it is
>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it is ac=
tually more of a
>>>>> recording of "my personal clock offset value" but obfuscated several =
times
>>>>> over (one for each token) as issue_date.
>>>>>>>
>>>>>>> - This implementation assumes software programs use the computer
>>>>> internal clock exclusively for timestamp. A robust program that is de=
pendent
>>>>> on accurate timestamps would ping the origin server (or similar trust=
ed time
>>>>> authority) to ask it the current time. Then it could store a "my devi=
ce clock
>>>>> offset" value for the lifetime of the program execution. All requests=
 needing
>>>>> timestamp would be adjusted accordingly. For age, if the clock is cha=
nged
>>>>> since the stored issue_date, the problem can't be corrected in this m=
anner.
>>>>> Thus, a significant advantage for timestamp.
>>>>>>>
>>>>>>> All in all, this seems like a misguided but well-intentioned attemp=
t to get
>>>>> around end-user issues of mis-set clocks. It feels like a hack and it=
 certainly
>>>>> isn't a foolproof solution. The more I think about the implications o=
f the age
>>>>> parameter, the less I like it. Timestamp has been used for many years=
 in the
>>>>> industry and with reasonable success in relevant applications. If we =
change to
>>>>> a new way of trying to sync on time I think we run a greater risk of =
stumbling
>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>
>>>>>>> I recommend the requirement of an age (or timestamp for that matter=
)
>>>>> be dropped from the nonce construction. For providers that deem it
>>>>> valuable, timestamp can be an optional value (either as part of the n=
once or
>>>>> the overall header, as before).
>>>>>>>
>>>>>>> skylar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>
>>>>>>>> You may have noticed, on page 8 the host is listed as "example.net=
"
>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>>>
>>>>>>>> All in all, I'm in support of the changes in v2. Certainly address=
es my
>>>>> hesitations from v2.
>>>>>>>>
>>>>>>>> skylar
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>>>
>>>>>>>>> While this document has moved to the Apps-Discuss mailing list fo=
r the
>>>>> time being, I wanted to give a quick update to those who have been
>>>>> following this draft which originated on this list.
>>>>>>>>>
>>>>>>>>> The major changes since -02 are:
>>>>>>>>>
>>>>>>>>> * Removed OAuth terminology and association. The draft is now a
>>>>> general purpose HTTP authentication scheme. It does include an OAuth =
2.0
>>>>> binding which is described in less than a page. One suggestion would =
be to
>>>>> move section 5.1 into the OAuth specification and drop all the OAuth =
2.0 text
>>>>> from the MAC draft.
>>>>>>>>>
>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session cookies=
.
>>>>>>>>>
>>>>>>>>> * Removed request URI query normalization. The new draft uses the
>>>>> raw request URI unchanged.
>>>>>>>>>
>>>>>>>>> * Replaced timestamps with credentials age to remove the need for
>>>>> clock sync.
>>>>>>>>>
>>>>>>>>> * Added a placeholder for extension, allowing random text to be
>>>>> included in the request and MAC.
>>>>>>>>>
>>>>>>>>> * Added issuer attribute for identifying the source of the creden=
tials as
>>>>> an additional protection.
>>>>>>>>>
>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0Acquia. =
Inc.
>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>
>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>>> _______________________________________________
>>>>> 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 skylar@kiva.org  Tue May 31 01:04: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 9FC5AE077E for ; Tue, 31 May 2011 01:04: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 sn6yMpqtQ8HM for ; Tue, 31 May 2011 01:04:09 -0700 (PDT)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id A7FF4E0773 for ; Tue, 31 May 2011 01:04:06 -0700 (PDT)
Received: from mail-wy0-f173.google.com ([74.125.82.173]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTeSg9YC7UpsYJpCpe/57HGboliQNo7NK@postini.com; Tue, 31 May 2011 01:04:06 PDT
Received: by wyb42 with SMTP id 42so4409483wyb.18 for ; Tue, 31 May 2011 01:04:04 -0700 (PDT)
Received: by 10.227.55.6 with SMTP id s6mr5710124wbg.112.1306829044096; Tue, 31 May 2011 01:04:04 -0700 (PDT)
Received: from [78.250.136.59] ([78.250.136.59]) by mx.google.com with ESMTPS id o38sm3563286wba.20.2011.05.31.01.04.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 01:04:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Skylar Woodward 
In-Reply-To: 
Date: Tue, 31 May 2011 10:04:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org>
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> 
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: Tue, 31 May 2011 08:04:12 -0000

It seems we're failing to communicate. Or you're not understanding my =
use cases. Age doesn't "just" work. It only works for a limited number =
of uses cases that must include all of yours - and it is brittle at =
that. It doesn't work for any of our uses cases (where the client can't =
know issue_date w/o the server telling it - in which case we have the =
equivalent problem as timestamp).

If you'd like to talk this out over Skype I'm happy to do that, so I can =
help you understand why age doesn't work.



On May 31, 2011, at 9:47 AM, Adam Barth wrote:

> Timestamps don't work when the client doesn't have a synchronized
> clock.  It's true that a client could synchronize its clock with the
> network, but our implementation experience is that many clients don't
> for a variety of reasons.  That means that age better because, you
> know, it works.
>=20
> Adam
>=20
>=20
> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  =
wrote:
>> I don't think you read my first message on the topic (or I wrote too =
much).
>>=20
>> Age is fragile because if the clock changes between issue_date and =
the time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:
>>=20
>> 1) the client is able to guess the issue_date the server is using =
based on the time the credential was issued
>> 2) the client system clock doesn't change between issue date and =
submission time.
>>=20
>> Timestamp has neither of these issues because the client can always =
inquire about network time and can effectively correct for inaccuracies =
in the device timekeeping system.
>>=20
>> Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the =
client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:
>>=20
>>        local_offset =3D current_server_time - current_device_time
>>        age =3D current_device_time - (server_issue_date-local_offset)
>>=20
>> Since the protocol doesn't currently allow for server_issue_date to =
be given with tokens, thus age currently can't have the resilience that =
timestamp does. It also forces servers to issue new tokens on demand =
just to make the convoluted age system work (rather than reuse existing =
valid tokens). Or, you have to modify the protocol to add =
server_issue_date and current_server_time into the token-issue exchange =
- eg, more complexity.
>>=20
>> Timestamp is simpler, proven, it and it has a solution for your use =
case of unsyncronized clocks.
>>=20
>> skylar
>>=20
>>=20
>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>=20
>>> I can't speak for Mozilla, but I can tell you that many folks don't
>>> have synchronized clocks, for a wide variety of reasons.  I guess I
>>> don't really understand why you view age as problematic.  You
>>> reference "fragility of using time-since-credentials-issued" but you
>>> don't say what exactly is fragile about it.  There's nothing
>>> particularly complex about age, especially when using the monotonic
>>> clock provided by all modern operating systems.
>>>=20
>>> Adam
>>>=20
>>>=20
>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  =
wrote:
>>>> But see, now you are specializing the use of MAC token even more - =
now it's becoming a service mainly for user-agents on home desktops? =
This is further for the original goal of making MAC as flexible is =
possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>>>=20
>>>> Sarcasm aside, my point is that timestamp is just as good as your =
offset technique and is more: reliable, straightforward, flexible.
>>>>=20
>>>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>>>=20
>>>> Please change the spec back to using timestamp rather than age.
>>>>=20
>>>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>>>=20
>>>> Thanks,
>>>> skylar
>>>>=20
>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... =
-.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>> skylar woodward
>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>=20
>>>>=20
>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>=20
>>>>> Any kind of clock sync requirement for user-agents (basically, =
home desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>>>>>=20
>>>>> The issue here is who is this being optimized for. =
Server-to-server communication should simply use TLS for privacy and =
MITM protection on top of MAC instead of using nonces to prevent replay. =
The whole point of this kind of replay protection is when TLS is not =
available.
>>>>>=20
>>>>> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>>>>>=20
>>>>> EHL
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>>>> Of Peter Wolanin
>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>> To: Skylar Woodward
>>>>>> Cc: OAuth WG
>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>>>>>=20
>>>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>>>> and also the added complexity of specifying this construction.
>>>>>>=20
>>>>>> I think it would be preferable to always require a timestamp as =
part of the
>>>>>> authorization header, and maybe even include in the spec a =
maximum time
>>>>>> difference between client and server (e.g. 900 seconds) that can =
be
>>>>>> tolerated.  This makes generating the nonce easier also, since =
the value need
>>>>>> to longer be unique over all time.
>>>>>>=20
>>>>>> We have such rules in place for an HMAC-based authentication =
system we
>>>>>> use.  Once in a while a client has a local clock so far out of =
sync that there is an
>>>>>> issue, but it's rare.
>>>>>>=20
>>>>>> -Peter
>>>>>>=20
>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward =

>>>>>> wrote:
>>>>>>> Resending to the list from my subscribed account...
>>>>>>>=20
>>>>>>> Begin forwarded message:
>>>>>>>=20
>>>>>>>> From: Skylar Woodward 
>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>> To: Skylar Woodward 
>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>> 
>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC =
token
>>>>>>>>=20
>>>>>>>> So after discussing this today and reflecting on it a bit, I =
would suggest that
>>>>>> nonce simply be the "unique value" (as it is so named) without =
further
>>>>>> requirements. It might be suggested that this be composed of an
>>>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>>>> "recommended" practice. If the expectation is that very few if =
any providers
>>>>>> would actually check the timestamp (or moreover, the nonce =
itself), why add
>>>>>> terminology in the draft that requires it? Developers are doing =
extra
>>>>>> housekeeping (and perhaps for a perceived benefit) but with no =
payoff or
>>>>>> added security.
>>>>>>>>=20
>>>>>>>> I'm sending this feedback based on having implemented the v3-5 =
changes
>>>>>> last night (for both client credentials and requests w/ access =
tokens). After
>>>>>> the changes, the nonce creation is now the most complicated part =
of the
>>>>>> normalized request string and yet these changes offer the least =
benefit.
>>>>>> What's most important is that nonces are unique on each request =
for an ID.
>>>>>>>>=20
>>>>>>>> There are issues with age as well:
>>>>>>>>=20
>>>>>>>> - As Bill mentioned, if the client stores the issue time based =
on
>>>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>>>> that a user with a bad clock (of by hours or more) will never =
fix it
>>>>>>>> and actually encourages bad user behavior (don't fix your clock =
or
>>>>>>>> Twitterbot will stop working!). Though we say that timezones =
won't
>>>>>>>> bring about the situation of changed clock, I'd be to differ. =
Many
>>>>>>>> users aren't savvy enough to change time zone, but just adjust =
the
>>>>>>>> time to local time anyway. Users who are more likely to get it =
right
>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>=20
>>>>>>>> - What if the token wasn't originally issued programmatically? =
In this case,
>>>>>> the issue time has to be obtained from the server and stored on =
the client
>>>>>> then you have the same problem as with a timestamp - the client =
clock is not
>>>>>> sync'd to the server clock and there is no adjustment. You want =
this to apply
>>>>>> to uses outside of just OAuth, but now requiring the client to be =
able to
>>>>>> determine an issue time based on when it receives an HTTP request
>>>>>> necessarily limits the types of token flows for which this can be =
used.
>>>>>>>>=20
>>>>>>>> - It's one more detail to store. Hardly an issue for a =
developer, but it is
>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it =
is actually more of a
>>>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>>>> over (one for each token) as issue_date.
>>>>>>>>=20
>>>>>>>> - This implementation assumes software programs use the =
computer
>>>>>> internal clock exclusively for timestamp. A robust program that =
is dependent
>>>>>> on accurate timestamps would ping the origin server (or similar =
trusted time
>>>>>> authority) to ask it the current time. Then it could store a "my =
device clock
>>>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>>>> timestamp would be adjusted accordingly. For age, if the clock is =
changed
>>>>>> since the stored issue_date, the problem can't be corrected in =
this manner.
>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>=20
>>>>>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>>>>>> around end-user issues of mis-set clocks. It feels like a hack =
and it certainly
>>>>>> isn't a foolproof solution. The more I think about the =
implications of the age
>>>>>> parameter, the less I like it. Timestamp has been used for many =
years in the
>>>>>> industry and with reasonable success in relevant applications. If =
we change to
>>>>>> a new way of trying to sync on time I think we run a greater risk =
of stumbling
>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>=20
>>>>>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>>>>>> be dropped from the nonce construction. For providers that deem =
it
>>>>>> valuable, timestamp can be an optional value (either as part of =
the nonce or
>>>>>> the overall header, as before).
>>>>>>>>=20
>>>>>>>> skylar
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>=20
>>>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>=20
>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>>>>>> hesitations from v2.
>>>>>>>>>=20
>>>>>>>>> skylar
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>=20
>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>  mailing list)
>>>>>>>>>>=20
>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>>>=20
>>>>>>>>>> While this document has moved to the Apps-Discuss mailing =
list for the
>>>>>> time being, I wanted to give a quick update to those who have =
been
>>>>>> following this draft which originated on this list.
>>>>>>>>>>=20
>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>=20
>>>>>>>>>> * Removed OAuth terminology and association. The draft is now =
a
>>>>>> general purpose HTTP authentication scheme. It does include an =
OAuth 2.0
>>>>>> binding which is described in less than a page. One suggestion =
would be to
>>>>>> move section 5.1 into the OAuth specification and drop all the =
OAuth 2.0 text
>>>>>> from the MAC draft.
>>>>>>>>>>=20
>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>>>>>=20
>>>>>>>>>> * Removed request URI query normalization. The new draft uses =
the
>>>>>> raw request URI unchanged.
>>>>>>>>>>=20
>>>>>>>>>> * Replaced timestamps with credentials age to remove the need =
for
>>>>>> clock sync.
>>>>>>>>>>=20
>>>>>>>>>> * Added a placeholder for extension, allowing random text to =
be
>>>>>> included in the request and MAC.
>>>>>>>>>>=20
>>>>>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>>>>>> an additional protection.
>>>>>>>>>>=20
>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>=20
>>>>>>>>>> EHL
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>=20
>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>>>> _______________________________________________
>>>>>> 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
>>>>=20
>>=20
>>=20


From ietf@adambarth.com  Tue May 31 01:31: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 D3FECE064A for ; Tue, 31 May 2011 01:31:17 -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=[AWL=-0.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 iRSWyV9t1T3l for ; Tue, 31 May 2011 01:31:16 -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 33C9CE0733 for ; Tue, 31 May 2011 01:31:16 -0700 (PDT)
Received: by ywp31 with SMTP id 31so2364174ywp.31 for ; Tue, 31 May 2011 01:31:15 -0700 (PDT)
Received: by 10.236.31.37 with SMTP id l25mr7015556yha.390.1306830675665; Tue, 31 May 2011 01:31:15 -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 e48sm3158885yhk.14.2011.05.31.01.31.14 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 01:31:14 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2334655gyf.31 for ; Tue, 31 May 2011 01:31:14 -0700 (PDT)
Received: by 10.91.208.29 with SMTP id k29mr4695980agq.71.1306830674154; Tue, 31 May 2011 01:31:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 01:30:44 -0700 (PDT)
In-Reply-To: <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.org>
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>
From: Adam Barth 
Date: Tue, 31 May 2011 01:30:44 -0700
Message-ID: 
To: Skylar Woodward 
Content-Type: text/plain; charset=windows-1252
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: Tue, 31 May 2011 08:31:17 -0000

I'm not sure we need a Skype call.  Can you explain the trouble caused
by age clearly?  I didn't understand your previous explanation.  The
more concrete you can be, the better.

Thanks,
Adam


On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  wrote:
> It seems we're failing to communicate. Or you're not understanding my use=
 cases. Age doesn't "just" work. It only works for a limited number of uses=
 cases that must include all of yours - and it is brittle at that. It doesn=
't work for any of our uses cases (where the client can't know issue_date w=
/o the server telling it - in which case we have the equivalent problem as =
timestamp).
>
> If you'd like to talk this out over Skype I'm happy to do that, so I can =
help you understand why age doesn't work.
>
>
>
> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>
>> Timestamps don't work when the client doesn't have a synchronized
>> clock. =A0It's true that a client could synchronize its clock with the
>> network, but our implementation experience is that many clients don't
>> for a variety of reasons. =A0That means that age better because, you
>> know, it works.
>>
>> Adam
>>
>>
>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  wrot=
e:
>>> I don't think you read my first message on the topic (or I wrote too mu=
ch).
>>>
>>> Age is fragile because if the clock changes between issue_date and the =
time of submission, it will fail. We know many people don't have synchroniz=
ed clocks, but using age only solves this problem if two assumptions hold t=
rue:
>>>
>>> 1) the client is able to guess the issue_date the server is using based=
 on the time the credential was issued
>>> 2) the client system clock doesn't change between issue date and submis=
sion time.
>>>
>>> Timestamp has neither of these issues because the client can always inq=
uire about network time and can effectively correct for inaccuracies in the=
 device timekeeping system.
>>>
>>> Regarding the first assumption, this fails when a token might be re-iss=
ued between devices. An example is that we use MAC token for the client cre=
dentials, which are issued when a developer registers an application. The c=
lient has no way of determining on its own when the value was actually issu=
ed (unless we communicate that on the developer website and force users to =
embed that with client_id, which adds usability issues of users copying and=
 entering string date values correctly). The same is actually true for all =
of our OAuth access tokens because we reissue tokens to the same client_id =
if they were previously issued and are still valid. (The client would thus =
think the issue_date was now() when if fact it was the time of the first is=
sue for client_id+scope+grantor_id). Thus, age is really just a convoluted =
way of trying to communicate the device system offset:
>>>
>>> =A0 =A0 =A0 =A0local_offset =3D current_server_time - current_device_ti=
me
>>> =A0 =A0 =A0 =A0age =3D current_device_time - (server_issue_date-local_o=
ffset)
>>>
>>> Since the protocol doesn't currently allow for server_issue_date to be =
given with tokens, thus age currently can't have the resilience that timest=
amp does. It also forces servers to issue new tokens on demand just to make=
 the convoluted age system work (rather than reuse existing valid tokens). =
Or, you have to modify the protocol to add server_issue_date and current_se=
rver_time into the token-issue exchange - eg, more complexity.
>>>
>>> Timestamp is simpler, proven, it and it has a solution for your use cas=
e of unsyncronized clocks.
>>>
>>> skylar
>>>
>>>
>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>
>>>> I can't speak for Mozilla, but I can tell you that many folks don't
>>>> have synchronized clocks, for a wide variety of reasons. =A0I guess I
>>>> don't really understand why you view age as problematic. =A0You
>>>> reference "fragility of using time-since-credentials-issued" but you
>>>> don't say what exactly is fragile about it. =A0There's nothing
>>>> particularly complex about age, especially when using the monotonic
>>>> clock provided by all modern operating systems.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wr=
ote:
>>>>> But see, now you are specializing the use of MAC token even more - no=
w it's becoming a service mainly for user-agents on home desktops? This is =
further for the original goal of making MAC as flexible is possible. In thi=
s case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_REPL=
ACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>>>
>>>>> Sarcasm aside, my point is that timestamp is just as good as your off=
set technique and is more: reliable, straightforward, flexible.
>>>>>
>>>>> User agents that care about creating robust behavior for home desktop=
s or mobiles (presumably of users and OS not yet sophisticated enough to ch=
eck network time on their own) should be advised to do clock correction on =
their own (by pinging a time service) and trusting the device clock alone.
>>>>>
>>>>> Please change the spec back to using timestamp rather than age.
>>>>>
>>>>> I'd also like to hear a convincing argument from the Mozilla co-autho=
rs about why they think that age is more resilient than the above (I believ=
e it is not) and further more why they would find the above unattractive or=
 difficult to implement in a modern user-agent.
>>>>>
>>>>> Thanks,
>>>>> skylar
>>>>>
>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ... -=
.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>> skylar woodward
>>>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiva
>>>>>
>>>>>
>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> Any kind of clock sync requirement for user-agents (basically, home =
desktops) it completely impractical. The added complexity pales in comparis=
on to the difficulty of trying to use timestamps and any kind of clock sync=
. No window will be big enough as experience shows some users have closes t=
hat are off by more than an hour and a half.
>>>>>>
>>>>>> The issue here is who is this being optimized for. Server-to-server =
communication should simply use TLS for privacy and MITM protection on top =
of MAC instead of using nonces to prevent replay. The whole point of this k=
ind of replay protection is when TLS is not available.
>>>>>>
>>>>>> I think a better approach is to simply make checking the nonce optio=
nal when TLS is used.
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh=
alf
>>>>>>> Of Peter Wolanin
>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>> To: Skylar Woodward
>>>>>>> Cc: OAuth WG
>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC to=
ken
>>>>>>>
>>>>>>> I am also concerned by the fragility of using time-since-credential=
s-issued,
>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>
>>>>>>> I think it would be preferable to always require a timestamp as par=
t of the
>>>>>>> authorization header, and maybe even include in the spec a maximum =
time
>>>>>>> difference between client and server (e.g. 900 seconds) that can be
>>>>>>> tolerated. =A0This makes generating the nonce easier also, since th=
e value need
>>>>>>> to longer be unique over all time.
>>>>>>>
>>>>>>> We have such rules in place for an HMAC-based authentication system=
 we
>>>>>>> use. =A0Once in a while a client has a local clock so far out of sy=
nc that there is an
>>>>>>> issue, but it's rare.
>>>>>>>
>>>>>>> -Peter
>>>>>>>
>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>>>> wrote:
>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>>> From: Skylar Woodward 
>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>> To: Skylar Woodward 
>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>> 
>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>>>>>>
>>>>>>>>> So after discussing this today and reflecting on it a bit, I woul=
d suggest that
>>>>>>> nonce simply be the "unique value" (as it is so named) without furt=
her
>>>>>>> requirements. It might be suggested that this be composed of an
>>>>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>>>>> "recommended" practice. If the expectation is that very few if any =
providers
>>>>>>> would actually check the timestamp (or moreover, the nonce itself),=
 why add
>>>>>>> terminology in the draft that requires it? Developers are doing ext=
ra
>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no payo=
ff or
>>>>>>> added security.
>>>>>>>>>
>>>>>>>>> I'm sending this feedback based on having implemented the v3-5 ch=
anges
>>>>>>> last night (for both client credentials and requests w/ access toke=
ns). After
>>>>>>> the changes, the nonce creation is now the most complicated part of=
 the
>>>>>>> normalized request string and yet these changes offer the least ben=
efit.
>>>>>>> What's most important is that nonces are unique on each request for=
 an ID.
>>>>>>>>>
>>>>>>>>> There are issues with age as well:
>>>>>>>>>
>>>>>>>>> - As Bill mentioned, if the client stores the issue time based on
>>>>>>>>> receipt, then the internal clock changes (presumably w/o knowledg=
e of
>>>>>>>>> the software storing the dates) then time will also fail. Assumin=
g
>>>>>>>>> that a user with a bad clock (of by hours or more) will never fix=
 it
>>>>>>>>> and actually encourages bad user behavior (don't fix your clock o=
r
>>>>>>>>> Twitterbot will stop working!). Though we say that timezones won'=
t
>>>>>>>>> bring about the situation of changed clock, I'd be to differ. Man=
y
>>>>>>>>> users aren't savvy enough to change time zone, but just adjust th=
e
>>>>>>>>> time to local time anyway. Users who are more likely to get it ri=
ght
>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>
>>>>>>>>> - What if the token wasn't originally issued programmatically? In=
 this case,
>>>>>>> the issue time has to be obtained from the server and stored on the=
 client
>>>>>>> then you have the same problem as with a timestamp - the client clo=
ck is not
>>>>>>> sync'd to the server clock and there is no adjustment. You want thi=
s to apply
>>>>>>> to uses outside of just OAuth, but now requiring the client to be a=
ble to
>>>>>>> determine an issue time based on when it receives an HTTP request
>>>>>>> necessarily limits the types of token flows for which this can be u=
sed.
>>>>>>>>>
>>>>>>>>> - It's one more detail to store. Hardly an issue for a developer,=
 but it is
>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it is =
actually more of a
>>>>>>> recording of "my personal clock offset value" but obfuscated severa=
l times
>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>
>>>>>>>>> - This implementation assumes software programs use the computer
>>>>>>> internal clock exclusively for timestamp. A robust program that is =
dependent
>>>>>>> on accurate timestamps would ping the origin server (or similar tru=
sted time
>>>>>>> authority) to ask it the current time. Then it could store a "my de=
vice clock
>>>>>>> offset" value for the lifetime of the program execution. All reques=
ts needing
>>>>>>> timestamp would be adjusted accordingly. For age, if the clock is c=
hanged
>>>>>>> since the stored issue_date, the problem can't be corrected in this=
 manner.
>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>
>>>>>>>>> All in all, this seems like a misguided but well-intentioned atte=
mpt to get
>>>>>>> around end-user issues of mis-set clocks. It feels like a hack and =
it certainly
>>>>>>> isn't a foolproof solution. The more I think about the implications=
 of the age
>>>>>>> parameter, the less I like it. Timestamp has been used for many yea=
rs in the
>>>>>>> industry and with reasonable success in relevant applications. If w=
e change to
>>>>>>> a new way of trying to sync on time I think we run a greater risk o=
f stumbling
>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>
>>>>>>>>> I recommend the requirement of an age (or timestamp for that matt=
er)
>>>>>>> be dropped from the nonce construction. For providers that deem it
>>>>>>> valuable, timestamp can be an optional value (either as part of the=
 nonce or
>>>>>>> the overall header, as before).
>>>>>>>>>
>>>>>>>>> skylar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>
>>>>>>>>>> You may have noticed, on page 8 the host is listed as "example.n=
et"
>>>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>>>>>
>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly addre=
sses my
>>>>>>> hesitations from v2.
>>>>>>>>>>
>>>>>>>>>> skylar
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>>>>>
>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing list =
for the
>>>>>>> time being, I wanted to give a quick update to those who have been
>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>
>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>
>>>>>>>>>>> * Removed OAuth terminology and association. The draft is now a
>>>>>>> general purpose HTTP authentication scheme. It does include an OAut=
h 2.0
>>>>>>> binding which is described in less than a page. One suggestion woul=
d be to
>>>>>>> move section 5.1 into the OAuth specification and drop all the OAut=
h 2.0 text
>>>>>>> from the MAC draft.
>>>>>>>>>>>
>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session cooki=
es.
>>>>>>>>>>>
>>>>>>>>>>> * Removed request URI query normalization. The new draft uses t=
he
>>>>>>> raw request URI unchanged.
>>>>>>>>>>>
>>>>>>>>>>> * Replaced timestamps with credentials age to remove the need f=
or
>>>>>>> clock sync.
>>>>>>>>>>>
>>>>>>>>>>> * Added a placeholder for extension, allowing random text to be
>>>>>>> included in the request and MAC.
>>>>>>>>>>>
>>>>>>>>>>> * Added issuer attribute for identifying the source of the cred=
entials as
>>>>>>> an additional protection.
>>>>>>>>>>>
>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0Acquia=
. Inc.
>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>
>>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>>>>> _______________________________________________
>>>>>>> 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 skylar@kiva.org  Tue May 31 01:46: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 B47C0E06C9 for ; Tue, 31 May 2011 01:46:52 -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 hm2c6leR0tlc for ; Tue, 31 May 2011 01:46:51 -0700 (PDT)
Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 1EE93E06BD for ; Tue, 31 May 2011 01:46:50 -0700 (PDT)
Received: from mail-ww0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTeSq+bDh+cBOfg9XmgfPKskVlhF5O5/L@postini.com; Tue, 31 May 2011 01:46:50 PDT
Received: by wwb39 with SMTP id 39so3825350wwb.30 for ; Tue, 31 May 2011 01:46:48 -0700 (PDT)
Received: by 10.227.164.202 with SMTP id f10mr5876946wby.92.1306831607270; Tue, 31 May 2011 01:46:47 -0700 (PDT)
Received: from [78.250.136.59] ([78.250.136.59]) by mx.google.com with ESMTPS id en1sm3586685wbb.35.2011.05.31.01.46.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 01:46:46 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Skylar Woodward 
In-Reply-To: 
Date: Tue, 31 May 2011 10:46:44 +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> 
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: Tue, 31 May 2011 08:46:52 -0000

First we should agree on a common understanding of the spec. The reason =
why age works with unsynchronized clocks is that the client determines =
issue_date based on the time when it receives the token over the wire. =
This depends on the server and client both recording time this way and =
for the transmission of the token to be be not longer than the margin of =
error for validating age. Are we agreed on this understanding?

The easiest case for me to explain here is client credentials because I =
have to assume you've built and registered a Twitter app at some point =
(or similar OAuth 1.0a app). You registered your app on the site and =
were issued a client_id and client_secret (called consumer_key and =
consumer_secret in 1.0). You then embedded these values in your client =
(they were not issued programmatically to your app). Assuming the MAC =
token algorithm is used then for establishing client identity =
(originally one of the uses we, the working group, hoped MAC would =
cover) how then will your client determine issue date?

After we can establish where you're at on the two above points I'll =
continue with the explanation. But as a preview, the next points would =
be:

- If issue_date comes form the server, how is it translated to the =
client?
- If you use a server provided issue_date, how do you then translate =
that a value relative to the local unsyncronized clock?
- If your answer to that is to also provide the current server time to =
the client so the offset on the server provided issue_date can be =
calculated what is the difference between all of these values and just =
using timestamp?

So don't get wrapped up in those 3 questions until we establish your =
contextual understanding of the first two paragraphs. Feel free to also =
respond to me off the list so we don't trouble everyone else with us =
getting on the same page (the reason, I thought, why a Skype call would =
be more efficient and painless). I do think my explainations all have =
been very clear thus far. There must be a contextual confusion that is =
keeping us from a common understanding of the terminology or the use =
cases.

skylar


On May 31, 2011, at 10:30 AM, Adam Barth wrote:

> I'm not sure we need a Skype call.  Can you explain the trouble caused
> by age clearly?  I didn't understand your previous explanation.  The
> more concrete you can be, the better.
>=20
> Thanks,
> Adam
>=20
>=20
> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  =
wrote:
>> It seems we're failing to communicate. Or you're not understanding my =
use cases. Age doesn't "just" work. It only works for a limited number =
of uses cases that must include all of yours - and it is brittle at =
that. It doesn't work for any of our uses cases (where the client can't =
know issue_date w/o the server telling it - in which case we have the =
equivalent problem as timestamp).
>>=20
>> If you'd like to talk this out over Skype I'm happy to do that, so I =
can help you understand why age doesn't work.
>>=20
>>=20
>>=20
>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>=20
>>> Timestamps don't work when the client doesn't have a synchronized
>>> clock.  It's true that a client could synchronize its clock with the
>>> network, but our implementation experience is that many clients =
don't
>>> for a variety of reasons.  That means that age better because, you
>>> know, it works.
>>>=20
>>> Adam
>>>=20
>>>=20
>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  =
wrote:
>>>> I don't think you read my first message on the topic (or I wrote =
too much).
>>>>=20
>>>> Age is fragile because if the clock changes between issue_date and =
the time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:
>>>>=20
>>>> 1) the client is able to guess the issue_date the server is using =
based on the time the credential was issued
>>>> 2) the client system clock doesn't change between issue date and =
submission time.
>>>>=20
>>>> Timestamp has neither of these issues because the client can always =
inquire about network time and can effectively correct for inaccuracies =
in the device timekeeping system.
>>>>=20
>>>> Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the =
client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:
>>>>=20
>>>>        local_offset =3D current_server_time - current_device_time
>>>>        age =3D current_device_time - =
(server_issue_date-local_offset)
>>>>=20
>>>> Since the protocol doesn't currently allow for server_issue_date to =
be given with tokens, thus age currently can't have the resilience that =
timestamp does. It also forces servers to issue new tokens on demand =
just to make the convoluted age system work (rather than reuse existing =
valid tokens). Or, you have to modify the protocol to add =
server_issue_date and current_server_time into the token-issue exchange =
- eg, more complexity.
>>>>=20
>>>> Timestamp is simpler, proven, it and it has a solution for your use =
case of unsyncronized clocks.
>>>>=20
>>>> skylar
>>>>=20
>>>>=20
>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>=20
>>>>> I can't speak for Mozilla, but I can tell you that many folks =
don't
>>>>> have synchronized clocks, for a wide variety of reasons.  I guess =
I
>>>>> don't really understand why you view age as problematic.  You
>>>>> reference "fragility of using time-since-credentials-issued" but =
you
>>>>> don't say what exactly is fragile about it.  There's nothing
>>>>> particularly complex about age, especially when using the =
monotonic
>>>>> clock provided by all modern operating systems.
>>>>>=20
>>>>> Adam
>>>>>=20
>>>>>=20
>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward =
 wrote:
>>>>>> But see, now you are specializing the use of MAC token even more =
- now it's becoming a service mainly for user-agents on home desktops? =
This is further for the original goal of making MAC as flexible is =
possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>>>>>=20
>>>>>> Sarcasm aside, my point is that timestamp is just as good as your =
offset technique and is more: reliable, straightforward, flexible.
>>>>>>=20
>>>>>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>>>>>=20
>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>=20
>>>>>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>>>>>=20
>>>>>> Thanks,
>>>>>> skylar
>>>>>>=20
>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 =
... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>> skylar woodward
>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>=20
>>>>>>=20
>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>=20
>>>>>>> Any kind of clock sync requirement for user-agents (basically, =
home desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>>>>>>>=20
>>>>>>> The issue here is who is this being optimized for. =
Server-to-server communication should simply use TLS for privacy and =
MITM protection on top of MAC instead of using nonces to prevent replay. =
The whole point of this kind of replay protection is when TLS is not =
available.
>>>>>>>=20
>>>>>>> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>>>>>>>=20
>>>>>>> EHL
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>>>>>>>> Of Peter Wolanin
>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>> To: Skylar Woodward
>>>>>>>> Cc: OAuth WG
>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - =
MAC token
>>>>>>>>=20
>>>>>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>>=20
>>>>>>>> I think it would be preferable to always require a timestamp as =
part of the
>>>>>>>> authorization header, and maybe even include in the spec a =
maximum time
>>>>>>>> difference between client and server (e.g. 900 seconds) that =
can be
>>>>>>>> tolerated.  This makes generating the nonce easier also, since =
the value need
>>>>>>>> to longer be unique over all time.
>>>>>>>>=20
>>>>>>>> We have such rules in place for an HMAC-based authentication =
system we
>>>>>>>> use.  Once in a while a client has a local clock so far out of =
sync that there is an
>>>>>>>> issue, but it's rare.
>>>>>>>>=20
>>>>>>>> -Peter
>>>>>>>>=20
>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward =

>>>>>>>> wrote:
>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>=20
>>>>>>>>> Begin forwarded message:
>>>>>>>>>=20
>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>> 
>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC =
token
>>>>>>>>>>=20
>>>>>>>>>> So after discussing this today and reflecting on it a bit, I =
would suggest that
>>>>>>>> nonce simply be the "unique value" (as it is so named) without =
further
>>>>>>>> requirements. It might be suggested that this be composed of an
>>>>>>>> random+timestamp (not age) value, but that seems more of a MAY =
or
>>>>>>>> "recommended" practice. If the expectation is that very few if =
any providers
>>>>>>>> would actually check the timestamp (or moreover, the nonce =
itself), why add
>>>>>>>> terminology in the draft that requires it? Developers are doing =
extra
>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no =
payoff or
>>>>>>>> added security.
>>>>>>>>>>=20
>>>>>>>>>> I'm sending this feedback based on having implemented the =
v3-5 changes
>>>>>>>> last night (for both client credentials and requests w/ access =
tokens). After
>>>>>>>> the changes, the nonce creation is now the most complicated =
part of the
>>>>>>>> normalized request string and yet these changes offer the least =
benefit.
>>>>>>>> What's most important is that nonces are unique on each request =
for an ID.
>>>>>>>>>>=20
>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>=20
>>>>>>>>>> - As Bill mentioned, if the client stores the issue time =
based on
>>>>>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>>>>>> that a user with a bad clock (of by hours or more) will never =
fix it
>>>>>>>>>> and actually encourages bad user behavior (don't fix your =
clock or
>>>>>>>>>> Twitterbot will stop working!). Though we say that timezones =
won't
>>>>>>>>>> bring about the situation of changed clock, I'd be to differ. =
Many
>>>>>>>>>> users aren't savvy enough to change time zone, but just =
adjust the
>>>>>>>>>> time to local time anyway. Users who are more likely to get =
it right
>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>=20
>>>>>>>>>> - What if the token wasn't originally issued =
programmatically? In this case,
>>>>>>>> the issue time has to be obtained from the server and stored on =
the client
>>>>>>>> then you have the same problem as with a timestamp - the client =
clock is not
>>>>>>>> sync'd to the server clock and there is no adjustment. You want =
this to apply
>>>>>>>> to uses outside of just OAuth, but now requiring the client to =
be able to
>>>>>>>> determine an issue time based on when it receives an HTTP =
request
>>>>>>>> necessarily limits the types of token flows for which this can =
be used.
>>>>>>>>>>=20
>>>>>>>>>> - It's one more detail to store. Hardly an issue for a =
developer, but it is
>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it =
is actually more of a
>>>>>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>=20
>>>>>>>>>> - This implementation assumes software programs use the =
computer
>>>>>>>> internal clock exclusively for timestamp. A robust program that =
is dependent
>>>>>>>> on accurate timestamps would ping the origin server (or similar =
trusted time
>>>>>>>> authority) to ask it the current time. Then it could store a =
"my device clock
>>>>>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>>>>>> timestamp would be adjusted accordingly. For age, if the clock =
is changed
>>>>>>>> since the stored issue_date, the problem can't be corrected in =
this manner.
>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>=20
>>>>>>>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>>>>>>>> around end-user issues of mis-set clocks. It feels like a hack =
and it certainly
>>>>>>>> isn't a foolproof solution. The more I think about the =
implications of the age
>>>>>>>> parameter, the less I like it. Timestamp has been used for many =
years in the
>>>>>>>> industry and with reasonable success in relevant applications. =
If we change to
>>>>>>>> a new way of trying to sync on time I think we run a greater =
risk of stumbling
>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>=20
>>>>>>>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>>>>>>>> be dropped from the nonce construction. For providers that deem =
it
>>>>>>>> valuable, timestamp can be an optional value (either as part of =
the nonce or
>>>>>>>> the overall header, as before).
>>>>>>>>>>=20
>>>>>>>>>> skylar
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>=20
>>>>>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>=20
>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>>>>>>>> hesitations from v2.
>>>>>>>>>>>=20
>>>>>>>>>>> skylar
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>=20
>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>>>>>=20
>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing =
list for the
>>>>>>>> time being, I wanted to give a quick update to those who have =
been
>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>=20
>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is =
now a
>>>>>>>> general purpose HTTP authentication scheme. It does include an =
OAuth 2.0
>>>>>>>> binding which is described in less than a page. One suggestion =
would be to
>>>>>>>> move section 5.1 into the OAuth specification and drop all the =
OAuth 2.0 text
>>>>>>>> from the MAC draft.
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Removed request URI query normalization. The new draft =
uses the
>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the =
need for
>>>>>>>> clock sync.
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Added a placeholder for extension, allowing random text =
to be
>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>=20
>>>>>>>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>>>>>>>> an additional protection.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>=20
>>>>>>>>>>>> EHL
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. =
Inc.
>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>=20
>>>>>>>> "Get a free, hosted Drupal 7 site: =
http://www.drupalgardens.com"
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>=20
>>>>=20
>>>>=20
>>=20
>>=20


From phil.hunt@oracle.com  Tue May 31 08:46: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 515A6E0701 for ; Tue, 31 May 2011 08:46:40 -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 yh2MrlmaGk1A for ; Tue, 31 May 2011 08:46:35 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 677D2E0677 for ; Tue, 31 May 2011 08:46:35 -0700 (PDT)
Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4VFkSJj031964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 15:46:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4VFkQfG001936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 15:46:27 GMT
Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4VFkLXe030300; Tue, 31 May 2011 10:46:21 -0500
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 May 2011 08:46:18 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Phil Hunt 
In-Reply-To: 
Date: Tue, 31 May 2011 08:46:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F3B49AB-FAB0-4ECD-A796-1C3D1112515F@oracle.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>  
To: Skylar Woodward 
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet22.oracle.com [66.248.204.30]
X-CT-RefId: str=0001.0A090209.4DE50D57.00DE:SCFSTAT5015188,ss=1,fgs=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: Tue, 31 May 2011 15:46:40 -0000

Skylar,

So your perspective is the issue-date calculations depend on client =
knowing the time of the server (not always true - hence the problem).

But that, "Age" assumes the client knows the receipt date of the token =
and that we are assuming transmission time is negligible compared to =
allowed age.

It seems that the latter would work for most cases with a moderate age =
times, but may not work at extremes such as where the transfer time of =
token is for some reason not reliable (e.g. because it is OOB), there =
are intermediaries, or where timelines are very tight in high security =
scenarios (the client must use token within seconds).

I can see valid use cases for both date and age. Is it possible to =
support both methods in the specification where selected at the =
discretion of the issuer?  I can't see a case where the server would =
want to give the option to a client regarding age vs. date. It seems to =
me the conditions of the resource server would determine what will be =
issued.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-05-31, at 1:46 AM, Skylar Woodward wrote:

> First we should agree on a common understanding of the spec. The =
reason why age works with unsynchronized clocks is that the client =
determines issue_date based on the time when it receives the token over =
the wire. This depends on the server and client both recording time this =
way and for the transmission of the token to be be not longer than the =
margin of error for validating age. Are we agreed on this understanding?
>=20
> The easiest case for me to explain here is client credentials because =
I have to assume you've built and registered a Twitter app at some point =
(or similar OAuth 1.0a app). You registered your app on the site and =
were issued a client_id and client_secret (called consumer_key and =
consumer_secret in 1.0). You then embedded these values in your client =
(they were not issued programmatically to your app). Assuming the MAC =
token algorithm is used then for establishing client identity =
(originally one of the uses we, the working group, hoped MAC would =
cover) how then will your client determine issue date?
>=20
> After we can establish where you're at on the two above points I'll =
continue with the explanation. But as a preview, the next points would =
be:
>=20
> - If issue_date comes form the server, how is it translated to the =
client?
> - If you use a server provided issue_date, how do you then translate =
that a value relative to the local unsyncronized clock?
> - If your answer to that is to also provide the current server time to =
the client so the offset on the server provided issue_date can be =
calculated what is the difference between all of these values and just =
using timestamp?
>=20
> So don't get wrapped up in those 3 questions until we establish your =
contextual understanding of the first two paragraphs. Feel free to also =
respond to me off the list so we don't trouble everyone else with us =
getting on the same page (the reason, I thought, why a Skype call would =
be more efficient and painless). I do think my explainations all have =
been very clear thus far. There must be a contextual confusion that is =
keeping us from a common understanding of the terminology or the use =
cases.
>=20
> skylar
>=20
>=20
> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>=20
>> I'm not sure we need a Skype call.  Can you explain the trouble =
caused
>> by age clearly?  I didn't understand your previous explanation.  The
>> more concrete you can be, the better.
>>=20
>> Thanks,
>> Adam
>>=20
>>=20
>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  =
wrote:
>>> It seems we're failing to communicate. Or you're not understanding =
my use cases. Age doesn't "just" work. It only works for a limited =
number of uses cases that must include all of yours - and it is brittle =
at that. It doesn't work for any of our uses cases (where the client =
can't know issue_date w/o the server telling it - in which case we have =
the equivalent problem as timestamp).
>>>=20
>>> If you'd like to talk this out over Skype I'm happy to do that, so I =
can help you understand why age doesn't work.
>>>=20
>>>=20
>>>=20
>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>=20
>>>> Timestamps don't work when the client doesn't have a synchronized
>>>> clock.  It's true that a client could synchronize its clock with =
the
>>>> network, but our implementation experience is that many clients =
don't
>>>> for a variety of reasons.  That means that age better because, you
>>>> know, it works.
>>>>=20
>>>> Adam
>>>>=20
>>>>=20
>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  =
wrote:
>>>>> I don't think you read my first message on the topic (or I wrote =
too much).
>>>>>=20
>>>>> Age is fragile because if the clock changes between issue_date and =
the time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:
>>>>>=20
>>>>> 1) the client is able to guess the issue_date the server is using =
based on the time the credential was issued
>>>>> 2) the client system clock doesn't change between issue date and =
submission time.
>>>>>=20
>>>>> Timestamp has neither of these issues because the client can =
always inquire about network time and can effectively correct for =
inaccuracies in the device timekeeping system.
>>>>>=20
>>>>> Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the =
client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:
>>>>>=20
>>>>>       local_offset =3D current_server_time - current_device_time
>>>>>       age =3D current_device_time - =
(server_issue_date-local_offset)
>>>>>=20
>>>>> Since the protocol doesn't currently allow for server_issue_date =
to be given with tokens, thus age currently can't have the resilience =
that timestamp does. It also forces servers to issue new tokens on =
demand just to make the convoluted age system work (rather than reuse =
existing valid tokens). Or, you have to modify the protocol to add =
server_issue_date and current_server_time into the token-issue exchange =
- eg, more complexity.
>>>>>=20
>>>>> Timestamp is simpler, proven, it and it has a solution for your =
use case of unsyncronized clocks.
>>>>>=20
>>>>> skylar
>>>>>=20
>>>>>=20
>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>=20
>>>>>> I can't speak for Mozilla, but I can tell you that many folks =
don't
>>>>>> have synchronized clocks, for a wide variety of reasons.  I guess =
I
>>>>>> don't really understand why you view age as problematic.  You
>>>>>> reference "fragility of using time-since-credentials-issued" but =
you
>>>>>> don't say what exactly is fragile about it.  There's nothing
>>>>>> particularly complex about age, especially when using the =
monotonic
>>>>>> clock provided by all modern operating systems.
>>>>>>=20
>>>>>> Adam
>>>>>>=20
>>>>>>=20
>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward =
 wrote:
>>>>>>> But see, now you are specializing the use of MAC token even more =
- now it's becoming a service mainly for user-agents on home desktops? =
This is further for the original goal of making MAC as flexible is =
possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>>>>>>=20
>>>>>>> Sarcasm aside, my point is that timestamp is just as good as =
your offset technique and is more: reliable, straightforward, flexible.
>>>>>>>=20
>>>>>>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>>>>>>=20
>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>=20
>>>>>>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> skylar
>>>>>>>=20
>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 =
... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>> skylar woodward
>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>=20
>>>>>>>=20
>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>=20
>>>>>>>> Any kind of clock sync requirement for user-agents (basically, =
home desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>>>>>>>>=20
>>>>>>>> The issue here is who is this being optimized for. =
Server-to-server communication should simply use TLS for privacy and =
MITM protection on top of MAC instead of using nonces to prevent replay. =
The whole point of this kind of replay protection is when TLS is not =
available.
>>>>>>>>=20
>>>>>>>> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>>>>>>>>=20
>>>>>>>> EHL
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf
>>>>>>>>> Of Peter Wolanin
>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>> To: Skylar Woodward
>>>>>>>>> Cc: OAuth WG
>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - =
MAC token
>>>>>>>>>=20
>>>>>>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>>>=20
>>>>>>>>> I think it would be preferable to always require a timestamp =
as part of the
>>>>>>>>> authorization header, and maybe even include in the spec a =
maximum time
>>>>>>>>> difference between client and server (e.g. 900 seconds) that =
can be
>>>>>>>>> tolerated.  This makes generating the nonce easier also, since =
the value need
>>>>>>>>> to longer be unique over all time.
>>>>>>>>>=20
>>>>>>>>> We have such rules in place for an HMAC-based authentication =
system we
>>>>>>>>> use.  Once in a while a client has a local clock so far out of =
sync that there is an
>>>>>>>>> issue, but it's rare.
>>>>>>>>>=20
>>>>>>>>> -Peter
>>>>>>>>>=20
>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward =

>>>>>>>>> wrote:
>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>=20
>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>=20
>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>> 
>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC =
token
>>>>>>>>>>>=20
>>>>>>>>>>> So after discussing this today and reflecting on it a bit, I =
would suggest that
>>>>>>>>> nonce simply be the "unique value" (as it is so named) without =
further
>>>>>>>>> requirements. It might be suggested that this be composed of =
an
>>>>>>>>> random+timestamp (not age) value, but that seems more of a MAY =
or
>>>>>>>>> "recommended" practice. If the expectation is that very few if =
any providers
>>>>>>>>> would actually check the timestamp (or moreover, the nonce =
itself), why add
>>>>>>>>> terminology in the draft that requires it? Developers are =
doing extra
>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no =
payoff or
>>>>>>>>> added security.
>>>>>>>>>>>=20
>>>>>>>>>>> I'm sending this feedback based on having implemented the =
v3-5 changes
>>>>>>>>> last night (for both client credentials and requests w/ access =
tokens). After
>>>>>>>>> the changes, the nonce creation is now the most complicated =
part of the
>>>>>>>>> normalized request string and yet these changes offer the =
least benefit.
>>>>>>>>> What's most important is that nonces are unique on each =
request for an ID.
>>>>>>>>>>>=20
>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>=20
>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time =
based on
>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>>>>>>> that a user with a bad clock (of by hours or more) will =
never fix it
>>>>>>>>>>> and actually encourages bad user behavior (don't fix your =
clock or
>>>>>>>>>>> Twitterbot will stop working!). Though we say that timezones =
won't
>>>>>>>>>>> bring about the situation of changed clock, I'd be to =
differ. Many
>>>>>>>>>>> users aren't savvy enough to change time zone, but just =
adjust the
>>>>>>>>>>> time to local time anyway. Users who are more likely to get =
it right
>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>=20
>>>>>>>>>>> - What if the token wasn't originally issued =
programmatically? In this case,
>>>>>>>>> the issue time has to be obtained from the server and stored =
on the client
>>>>>>>>> then you have the same problem as with a timestamp - the =
client clock is not
>>>>>>>>> sync'd to the server clock and there is no adjustment. You =
want this to apply
>>>>>>>>> to uses outside of just OAuth, but now requiring the client to =
be able to
>>>>>>>>> determine an issue time based on when it receives an HTTP =
request
>>>>>>>>> necessarily limits the types of token flows for which this can =
be used.
>>>>>>>>>>>=20
>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a =
developer, but it is
>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, =
it is actually more of a
>>>>>>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>=20
>>>>>>>>>>> - This implementation assumes software programs use the =
computer
>>>>>>>>> internal clock exclusively for timestamp. A robust program =
that is dependent
>>>>>>>>> on accurate timestamps would ping the origin server (or =
similar trusted time
>>>>>>>>> authority) to ask it the current time. Then it could store a =
"my device clock
>>>>>>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>>>>>>> timestamp would be adjusted accordingly. For age, if the clock =
is changed
>>>>>>>>> since the stored issue_date, the problem can't be corrected in =
this manner.
>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>=20
>>>>>>>>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>>>>>>>>> around end-user issues of mis-set clocks. It feels like a hack =
and it certainly
>>>>>>>>> isn't a foolproof solution. The more I think about the =
implications of the age
>>>>>>>>> parameter, the less I like it. Timestamp has been used for =
many years in the
>>>>>>>>> industry and with reasonable success in relevant applications. =
If we change to
>>>>>>>>> a new way of trying to sync on time I think we run a greater =
risk of stumbling
>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>=20
>>>>>>>>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>>>>>>>>> be dropped from the nonce construction. For providers that =
deem it
>>>>>>>>> valuable, timestamp can be an optional value (either as part =
of the nonce or
>>>>>>>>> the overall header, as before).
>>>>>>>>>>>=20
>>>>>>>>>>> skylar
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>=20
>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>=20
>>>>>>>>>>>> skylar
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing =
list for the
>>>>>>>>> time being, I wanted to give a quick update to those who have =
been
>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is =
now a
>>>>>>>>> general purpose HTTP authentication scheme. It does include an =
OAuth 2.0
>>>>>>>>> binding which is described in less than a page. One suggestion =
would be to
>>>>>>>>> move section 5.1 into the OAuth specification and drop all the =
OAuth 2.0 text
>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Removed request URI query normalization. The new draft =
uses the
>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the =
need for
>>>>>>>>> clock sync.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text =
to be
>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>>>>>>>>> an additional protection.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> EHL
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. =
Inc.
>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>=20
>>>>>>>>> "Get a free, hosted Drupal 7 site: =
http://www.drupalgardens.com"
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From wwwrun@ietfa.amsl.com  Tue May 31 09:42:35 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 5C8BDE0789; Tue, 31 May 2011 09:42:35 -0700 (PDT)
From: IESG Secretary 
To: IETF Announcement list 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20110531164235.5C8BDE0789@ietfa.amsl.com>
Date: Tue, 31 May 2011 09:42:35 -0700 (PDT)
Cc: barryleiba@computer.org, oauth@ietf.org
Subject: [OAUTH-WG] WG Review: Recharter of Open Authentication Protocol (oauth)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: iesg@ietf.org
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2011 16:42:36 -0000

A modified charter has been submitted for the Open Authentication 
Protocol (oauth) working group in the Security Area of the IETF.  The 
IESG has not made any determination as yet.  The modified charter is 
provided below for informational purposes only.  Please send your 
comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 7, 
2011.

Web Authorization Protocol Working Group (oauth)
-----------------------
Last modified: 2011-05-11

Current Status: Active Working Group

Chairs: Barry Leiba 
        Hannes Tschofenig 
        Blaine Cook 
Area Director: Stephen Farrell   
Tech 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 cmortimore@salesforce.com  Tue May 31 10:36: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 D1E24E068E for ; Tue, 31 May 2011 10:36:38 -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 JOYNQA1W6CYQ for ; Tue, 31 May 2011 10:36:36 -0700 (PDT)
Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by ietfa.amsl.com (Postfix) with SMTP id 17539E0662 for ; Tue, 31 May 2011 10:36:35 -0700 (PDT)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKTeUnIxJ7+KQ0QdJee8EUDyxyDIna9cmk@postini.com; Tue, 31 May 2011 10:36:36 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 31 May 2011 10:36:34 -0700
From: Chuck Mortimore 
To: "oauth@ietf.org" 
Date: Tue, 31 May 2011 10:36:33 -0700
Thread-Topic: Updated text for Native Apps
Thread-Index: AcwfuUhXW2Le+9y8kkuEJ9o0yOMTnA==
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_CA0A75311A8ECcmortimoresalesforcecom_"
MIME-Version: 1.0
Subject: [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: Tue, 31 May 2011 17:36:39 -0000

--_000_CA0A75311A8ECcmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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_CA0A75311A8ECcmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Updated text for Native Apps


Minor updates f=
or section 9 based upon feedback from the list
    

    
-cmort
    

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

    

    
9. =A0Native 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). =A0Na=
tive applications require special consideration related to security, platfo=
rm capabilities, and overall end-user experience. =A0The following are exam=
ples of how native applications may utilize OAuth:
    

    
=A0=A0=A0o =A0Initiate an Authorization Request using an external user-agen=
t: The native application can capture the response from the authorization s=
erver using a variety of techniques such as the use of a redirection URI id=
entifying a custom URI scheme (registered with the operating system to invo=
ke the native application as handler), manual copy-and-paste, running a loc=
al webserver, browser plug-ins, or by providing a redirection URI identifyi=
ng a server-hosted resource under the native application's control, which i=
n turn makes the response available to the native application.
    
=A0=A0=A0o =A0Initiate an Authorization Request using an embedded user-agen=
t: =A0The native application obtains the response by directly communicating=
 with the embedded user-agent. =A0Techniques include monitoring state chang=
es 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:
    

    
=A0=A0=A0o =A0External user-agents may improve completion rate as the end-u=
ser may already have an active session with the authorization server removi=
ng the need to re-authenticate, and provide a familiar user-agent user expe=
rience. =A0The end-user may also rely on extensions or add-ons to assist wi=
th authentication (e.g. password managers or 2-factor device reader).
    
=A0=A0=A0o =A0Embedded user-agents may offer an improved end-user flow, as =
they remove the need to switch context and open new windows.=A0
    
=A0=A0=A0o =A0Embedded user-agents pose a security challenge because end-us=
ers are authenticating in an unidentified window without access to the visu=
al protections offered by many user-agents. =A0Embedded user-agents educate=
 end-user to trust unidentified requests for authentication (making phishin=
g attacks easier to execute).
    

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

    
=A0=A0=A0o =A0Native applications that use the authorization code grant typ=
e flow SHOULD do so without client password credentials, due to their inabi=
lity to keep those credentials confidential.
    
=A0=A0=A0o =A0Native applications that use the implicit grant type may offe=
r optimized performance in some scenarios due to reduced network requests
=A0=A0=A0o =A0The implicit grant type does not return a refresh token  =
;
    

    

    

    
    




--_000_CA0A75311A8ECcmortimoresalesforcecom_--

From cmortimore@salesforce.com  Tue May 31 10:41: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 1BCBBE085C; Tue, 31 May 2011 10:41:45 -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 05n4Gv7pKwEq; Tue, 31 May 2011 10:41:39 -0700 (PDT)
Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by ietfa.amsl.com (Postfix) with SMTP id E1B31E06F2; Tue, 31 May 2011 10:41:38 -0700 (PDT)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKTeUoUuQPN7O+1BfukMVs1JxW8gDL3JLq@postini.com; Tue, 31 May 2011 10:41:39 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Tue, 31 May 2011 10:41:38 -0700
From: Chuck Mortimore 
To: "torsten@lodderstedt.net" , "oauth-bounces@ietf.org" , "oauth@ietf.org" 
Date: Tue, 31 May 2011 10:41:36 -0700
Thread-Topic: AW: [OAUTH-WG] Text for Native Applications
Thread-Index: AcwanNhKifkGqGdoQhCNNs9A5DQgqwFHSSkN
Message-ID: 
In-Reply-To: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CA0A76601A8F3cmortimoresalesforcecom_"
MIME-Version: 1.0
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: Tue, 31 May 2011 17:41:45 -0000

--_000_CA0A76601A8F3cmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Updated in language I just sent out - thanks.

On that note, we currently return refresh_token using the implicit grant ty=
pe under certain controlled circumstances.   Facebook in turn uses the impl=
icit grant type, and simply issues long term access_tokens.

Are there any strong objections to adding optional support for referesh_tok=
en on the implicit grant along with security considerations?

-cmort


On 5/24/11 10:30 PM, "torsten@lodderstedt.net"  wr=
ote:

Hi Chuck,

one of the advantages of the authz code grant type is refresh token support=
. I would suggest to mention this in the comparision with the implicit gran=
t type.

regards,
Torsten.
Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland

-----Original Message-----
From: Chuck Mortimore 
Sender: oauth-bounces@ietf.org
Date: Tue, 24 May 2011 17:30:05
To: oauth@ietf.org
Subject: [OAUTH-WG] Text for Native Applications

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



--_000_CA0A76601A8F3cmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: AW: [OAUTH-WG] Text for Native Applications


Updated in lang=
uage I just sent out – thanks.
    

    
On that note, we currently return refresh_token using the implicit grant ty=
pe under certain controlled circumstances.   Facebook in turn use=
s the implicit grant type, and simply issues long term access_tokens.  =
;  
    

    
Are there any strong objections to adding optional support for referesh_tok=
en on the implicit grant along with security considerations?
    

    
-cmort 
    

    

    
On 5/24/11 10:30 PM, "torsten@lodd=
erstedt.net" <torsten@lodde=
rstedt.net> wrote:
    

    

    Hi Chuck,
    

    
one of the advantages of the authz code grant type is refresh token support=
. I would suggest to mention this in the comparision with the implicit gran=
t type.
    

    
regards,
    
Torsten.
    
Gesendet mit BlackBerry® Webmail von Telekom Deutschland 
    

    
-----Original Message-----
    
From: Chuck Mortimore <cmortimore@=
salesforce.com>
    
Sender: oauth-bounces@ietf.org
    
Date: Tue, 24 May 2011 17:30:05
    
To: oauth@ietf.org<oauth@ietf.or=
g>
    
Subject: [OAUTH-WG] Text for Native Applications
    

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

    

    

    




--_000_CA0A76601A8F3cmortimoresalesforcecom_--

From d.tangren@gmail.com  Tue May 31 11:00: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 8DA16E0796; Tue, 31 May 2011 11:00:59 -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 tWeOTX1r220N; Tue, 31 May 2011 11:00:58 -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 AC417E06D9; Tue, 31 May 2011 11:00:58 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6306340iwn.31 for ; Tue, 31 May 2011 11:00:58 -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=opCnJ0w9Vkhij7+ibE0JOQ6BOAMfA97pjG20Y8/RsSE=; b=tyYee3keTkKzyLn65zYGPl/uD1YOwdaw+LbS6H/Pjtxtot1+pj7wxrPE5G6ZHXNL9m Nf4f5WByAKUg0aqkBYuBSnITJGlzJFvFLKZhi/9ZbYG05QuUOmXGthS+5aaGGHX7CLh5 Q7pbd1PZl/Tx4Oxp9XvEnejze7FkwDuBbaDHk=
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=B+XLQ13MIONl0Jiq8O4RfVF/PRAW3rdOzwq6vP9EMyn13Hls9Sh+tvnzxApp+NGOlX ZYUtZ2b+TUdg9m+e3yula3S/3KNMR8eZxnvgS2R6ut2vpqA1ZZEbZvFIhwcQKnD7KzO+ 31MVOKDo8T1fWZhUWlGWtNbFTOx7L4XCQq2O8=
Received: by 10.42.136.129 with SMTP id u1mr11095705ict.459.1306864858090; Tue, 31 May 2011 11:00:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Tue, 31 May 2011 11:00:38 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> 
From: Doug Tangren 
Date: Tue, 31 May 2011 14:00:38 -0400
Message-ID: 
To: Chuck Mortimore 
Content-Type: multipart/alternative; boundary=90e6ba613594a2cbbc04a4962ff0
Cc: "oauth-bounces@ietf.org" , "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: Tue, 31 May 2011 18:00:59 -0000

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

-Doug Tangren
http://lessis.me


On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore
wrote:

>  Updated in language I just sent out =E2=80=93 thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances.   Facebook in turn uses the
> implicit grant type, and simply issues long term access_tokens.
>
> Are there any strong objections to adding optional support for
> referesh_token on the implicit grant along with security considerations?
>

I was under the impression that one should not issue a refresh_token in an
implicit grant flow because in order to make a refresh_token request call,
you'd need send client credentials including the clients secret which an
implicit client can not store securely.

I think there is still a usability issue with the implicit flow in general
where there is no way in the spec to obtain an access token without
re-asking the user for authorization a second time even if the user has
already authorized your client.

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


    -Doug Tangren
    http://lessis.me
    


    On Tue, May 31, 2011 at 1:41 PM, Chuck M=
ortimore <cmortimore@salesforce.com> wrote:
    






    
Updated in la=
nguage I just sent out =E2=80=93 thanks.
    

    
On that note, we currently return refresh_token using the implicit grant ty=
pe under certain controlled circumstances. =C2=A0=C2=A0Facebook in turn use=
s the implicit grant type, and simply issues long term access_tokens. =C2=
=A0=C2=A0=C2=A0
    

    
Are there any strong objections to adding optional support for referesh_tok=
en on the implicit grant along with security considerations?    <=
/div>

    I was under the impression that one should not i=
ssue a refresh_token in an implicit grant flow because in order to make a r=
efresh_token request call, you'd need send client credentials including=
 the clients secret which an implicit client can not store securely. 
    


    I think there is still a usability issue with the implicit flow in gene=
ral where there is no way in the spec to obtain an access token without re-=
asking the user for authorization a second time even if the user has alread=
y authorized your client.
    

=C2=A0
    

--90e6ba613594a2cbbc04a4962ff0--

From eran@hueniverse.com  Tue May 31 11:13: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 4115FE071B for ; Tue, 31 May 2011 11:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level: 
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 Am+zG6impBPh for ; Tue, 31 May 2011 11:13: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 7C7D0E06D9 for ; Tue, 31 May 2011 11:13:25 -0700 (PDT)
Received: (qmail 6737 invoked from network); 31 May 2011 18:13:24 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 31 May 2011 18:13:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 31 May 2011 11:13:15 -0700
From: Eran Hammer-Lahav 
To: Skylar Woodward , Adam Barth 
Date: Tue, 31 May 2011 11:12:48 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwfaVEzkIRMIFXjTtyHBISO3FcGjgAVO/EQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@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>
In-Reply-To: <06247DD1-D251-4A0F-AD61-B9E8CADDE0EA@kiva.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 
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: Tue, 31 May 2011 18:13:27 -0000

The client should calculate the time of issue based on when it gets the cre=
dentials. Network delays should be accounted for by the server when allowin=
g shifts in the nonce itself.

EHL

> -----Original Message-----
> From: Skylar Woodward [mailto:skylar@kiva.org]
> Sent: Tuesday, May 31, 2011 1:04 AM
> To: Adam Barth
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> It seems we're failing to communicate. Or you're not understanding my use
> cases. Age doesn't "just" work. It only works for a limited number of use=
s
> cases that must include all of yours - and it is brittle at that. It does=
n't work
> for any of our uses cases (where the client can't know issue_date w/o the
> server telling it - in which case we have the equivalent problem as
> timestamp).
>
> If you'd like to talk this out over Skype I'm happy to do that, so I can =
help you
> understand why age doesn't work.
>
>
>
> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>
> > Timestamps don't work when the client doesn't have a synchronized
> > clock.  It's true that a client could synchronize its clock with the
> > network, but our implementation experience is that many clients don't
> > for a variety of reasons.  That means that age better because, you
> > know, it works.
> >
> > Adam
> >
> >
> > On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward 
> wrote:
> >> I don't think you read my first message on the topic (or I wrote too m=
uch).
> >>
> >> Age is fragile because if the clock changes between issue_date and the
> time of submission, it will fail. We know many people don't have
> synchronized clocks, but using age only solves this problem if two
> assumptions hold true:
> >>
> >> 1) the client is able to guess the issue_date the server is using
> >> based on the time the credential was issued
> >> 2) the client system clock doesn't change between issue date and
> submission time.
> >>
> >> Timestamp has neither of these issues because the client can always
> inquire about network time and can effectively correct for inaccuracies i=
n the
> device timekeeping system.
> >>
> >> Regarding the first assumption, this fails when a token might be re-is=
sued
> between devices. An example is that we use MAC token for the client
> credentials, which are issued when a developer registers an application. =
The
> client has no way of determining on its own when the value was actually
> issued (unless we communicate that on the developer website and force
> users to embed that with client_id, which adds usability issues of users
> copying and entering string date values correctly). The same is actually =
true
> for all of our OAuth access tokens because we reissue tokens to the same
> client_id if they were previously issued and are still valid. (The client=
 would
> thus think the issue_date was now() when if fact it was the time of the f=
irst
> issue for client_id+scope+grantor_id). Thus, age is really just a convolu=
ted
> way of trying to communicate the device system offset:
> >>
> >>        local_offset =3D current_server_time - current_device_time
> >>        age =3D current_device_time - (server_issue_date-local_offset)
> >>
> >> Since the protocol doesn't currently allow for server_issue_date to be
> given with tokens, thus age currently can't have the resilience that
> timestamp does. It also forces servers to issue new tokens on demand just
> to make the convoluted age system work (rather than reuse existing valid
> tokens). Or, you have to modify the protocol to add server_issue_date and
> current_server_time into the token-issue exchange - eg, more complexity.
> >>
> >> Timestamp is simpler, proven, it and it has a solution for your use ca=
se of
> unsyncronized clocks.
> >>
> >> skylar
> >>
> >>
> >> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>
> >>> I can't speak for Mozilla, but I can tell you that many folks don't
> >>> have synchronized clocks, for a wide variety of reasons.  I guess I
> >>> don't really understand why you view age as problematic.  You
> >>> reference "fragility of using time-since-credentials-issued" but you
> >>> don't say what exactly is fragile about it.  There's nothing
> >>> particularly complex about age, especially when using the monotonic
> >>> clock provided by all modern operating systems.
> >>>
> >>> Adam
> >>>
> >>>
> >>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward 
> wrote:
> >>>> But see, now you are specializing the use of MAC token even more -
> now it's becoming a service mainly for user-agents on home desktops? This=
 is
> further for the original goal of making MAC as flexible is possible. In t=
his case
> you should change the spec name to
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> REFOX - or MTBCRLF for short.
> >>>>
> >>>> Sarcasm aside, my point is that timestamp is just as good as your of=
fset
> technique and is more: reliable, straightforward, flexible.
> >>>>
> >>>> User agents that care about creating robust behavior for home
> desktops or mobiles (presumably of users and OS not yet sophisticated
> enough to check network time on their own) should be advised to do clock
> correction on their own (by pinging a time service) and trusting the devi=
ce
> clock alone.
> >>>>
> >>>> Please change the spec back to using timestamp rather than age.
> >>>>
> >>>> I'd also like to hear a convincing argument from the Mozilla co-auth=
ors
> about why they think that age is more resilient than the above (I believe=
 it is
> not) and further more why they would find the above unattractive or diffi=
cult
> to implement in a modern user-agent.
> >>>>
> >>>> Thanks,
> >>>> skylar
> >>>>
> >>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - ... -.- =
-.-- .-.. .- .-. - .-- --- ---
> -.. .-- .- .-. -..
> >>>> skylar woodward
> >>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>
> >>>>
> >>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>
> >>>>> Any kind of clock sync requirement for user-agents (basically, home
> desktops) it completely impractical. The added complexity pales in
> comparison to the difficulty of trying to use timestamps and any kind of =
clock
> sync. No window will be big enough as experience shows some users have
> closes that are off by more than an hour and a half.
> >>>>>
> >>>>> The issue here is who is this being optimized for. Server-to-server
> communication should simply use TLS for privacy and MITM protection on
> top of MAC instead of using nonces to prevent replay. The whole point of
> this kind of replay protection is when TLS is not available.
> >>>>>
> >>>>> I think a better approach is to simply make checking the nonce
> optional when TLS is used.
> >>>>>
> >>>>> EHL
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>>>> Behalf Of Peter Wolanin
> >>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>> To: Skylar Woodward
> >>>>>> Cc: OAuth WG
> >>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element -
> MAC
> >>>>>> token
> >>>>>>
> >>>>>> I am also concerned by the fragility of using
> >>>>>> time-since-credentials-issued, and also the added complexity of
> specifying this construction.
> >>>>>>
> >>>>>> I think it would be preferable to always require a timestamp as
> >>>>>> part of the authorization header, and maybe even include in the
> >>>>>> spec a maximum time difference between client and server (e.g.
> >>>>>> 900 seconds) that can be tolerated.  This makes generating the
> >>>>>> nonce easier also, since the value need to longer be unique over a=
ll
> time.
> >>>>>>
> >>>>>> We have such rules in place for an HMAC-based authentication
> >>>>>> system we use.  Once in a while a client has a local clock so far
> >>>>>> out of sync that there is an issue, but it's rare.
> >>>>>>
> >>>>>> -Peter
> >>>>>>
> >>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>> 
> >>>>>> wrote:
> >>>>>>> Resending to the list from my subscribed account...
> >>>>>>>
> >>>>>>> Begin forwarded message:
> >>>>>>>
> >>>>>>>> From: Skylar Woodward 
> >>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>> To: Skylar Woodward 
> >>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
> >>>>>>>> 
> >>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC
> >>>>>>>> token
> >>>>>>>>
> >>>>>>>> So after discussing this today and reflecting on it a bit, I
> >>>>>>>> would suggest that
> >>>>>> nonce simply be the "unique value" (as it is so named) without
> >>>>>> further requirements. It might be suggested that this be composed
> >>>>>> of an
> >>>>>> random+timestamp (not age) value, but that seems more of a MAY
> or
> >>>>>> "recommended" practice. If the expectation is that very few if
> >>>>>> any providers would actually check the timestamp (or moreover,
> >>>>>> the nonce itself), why add terminology in the draft that requires
> >>>>>> it? Developers are doing extra housekeeping (and perhaps for a
> >>>>>> perceived benefit) but with no payoff or added security.
> >>>>>>>>
> >>>>>>>> I'm sending this feedback based on having implemented the v3-5
> >>>>>>>> changes
> >>>>>> last night (for both client credentials and requests w/ access
> >>>>>> tokens). After the changes, the nonce creation is now the most
> >>>>>> complicated part of the normalized request string and yet these
> changes offer the least benefit.
> >>>>>> What's most important is that nonces are unique on each request fo=
r
> an ID.
> >>>>>>>>
> >>>>>>>> There are issues with age as well:
> >>>>>>>>
> >>>>>>>> - As Bill mentioned, if the client stores the issue time based
> >>>>>>>> on receipt, then the internal clock changes (presumably w/o
> >>>>>>>> knowledge of the software storing the dates) then time will
> >>>>>>>> also fail. Assuming that a user with a bad clock (of by hours
> >>>>>>>> or more) will never fix it and actually encourages bad user
> >>>>>>>> behavior (don't fix your clock or Twitterbot will stop
> >>>>>>>> working!). Though we say that timezones won't bring about the
> >>>>>>>> situation of changed clock, I'd be to differ. Many users aren't
> >>>>>>>> savvy enough to change time zone, but just adjust the time to
> >>>>>>>> local time anyway. Users who are more likely to get it right
> >>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
> >>>>>>>>
> >>>>>>>> - What if the token wasn't originally issued programmatically?
> >>>>>>>> In this case,
> >>>>>> the issue time has to be obtained from the server and stored on
> >>>>>> the client then you have the same problem as with a timestamp -
> >>>>>> the client clock is not sync'd to the server clock and there is
> >>>>>> no adjustment. You want this to apply to uses outside of just
> >>>>>> OAuth, but now requiring the client to be able to determine an
> >>>>>> issue time based on when it receives an HTTP request necessarily
> limits the types of token flows for which this can be used.
> >>>>>>>>
> >>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>> developer, but it is
> >>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it
> >>>>>> is actually more of a recording of "my personal clock offset
> >>>>>> value" but obfuscated several times over (one for each token) as
> issue_date.
> >>>>>>>>
> >>>>>>>> - This implementation assumes software programs use the
> >>>>>>>> computer
> >>>>>> internal clock exclusively for timestamp. A robust program that
> >>>>>> is dependent on accurate timestamps would ping the origin server
> >>>>>> (or similar trusted time
> >>>>>> authority) to ask it the current time. Then it could store a "my
> >>>>>> device clock offset" value for the lifetime of the program
> >>>>>> execution. All requests needing timestamp would be adjusted
> >>>>>> accordingly. For age, if the clock is changed since the stored
> issue_date, the problem can't be corrected in this manner.
> >>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>
> >>>>>>>> All in all, this seems like a misguided but well-intentioned
> >>>>>>>> attempt to get
> >>>>>> around end-user issues of mis-set clocks. It feels like a hack
> >>>>>> and it certainly isn't a foolproof solution. The more I think
> >>>>>> about the implications of the age parameter, the less I like it.
> >>>>>> Timestamp has been used for many years in the industry and with
> >>>>>> reasonable success in relevant applications. If we change to a
> >>>>>> new way of trying to sync on time I think we run a greater risk of
> stumbling upon unforeseen issues, such as those outlined above.
> >>>>>>>>
> >>>>>>>> I recommend the requirement of an age (or timestamp for that
> >>>>>>>> matter)
> >>>>>> be dropped from the nonce construction. For providers that deem
> >>>>>> it valuable, timestamp can be an optional value (either as part
> >>>>>> of the nonce or the overall header, as before).
> >>>>>>>>
> >>>>>>>> skylar
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>
> >>>>>>>>> You may have noticed, on page 8 the host is listed as
> "example.net"
> >>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>
> >>>>>>>>> All in all, I'm in support of the changes in v2. Certainly
> >>>>>>>>> addresses my
> >>>>>> hesitations from v2.
> >>>>>>>>>
> >>>>>>>>> skylar
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On May 9, 2011, at 12:36 PM, 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
> >>>>>>>>>>
> >>>>>>>>>> While this document has moved to the Apps-Discuss mailing
> >>>>>>>>>> list for the
> >>>>>> time being, I wanted to give a quick update to those who have
> >>>>>> been following this draft which originated on this list.
> >>>>>>>>>>
> >>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>
> >>>>>>>>>> * Removed OAuth terminology and association. The draft is
> now
> >>>>>>>>>> a
> >>>>>> general purpose HTTP authentication scheme. It does include an
> >>>>>> OAuth 2.0 binding which is described in less than a page. One
> >>>>>> suggestion would be to move section 5.1 into the OAuth
> >>>>>> specification and drop all the OAuth 2.0 text from the MAC draft.
> >>>>>>>>>>
> >>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session
> cookies.
> >>>>>>>>>>
> >>>>>>>>>> * Removed request URI query normalization. The new draft
> uses
> >>>>>>>>>> the
> >>>>>> raw request URI unchanged.
> >>>>>>>>>>
> >>>>>>>>>> * Replaced timestamps with credentials age to remove the
> need
> >>>>>>>>>> for
> >>>>>> clock sync.
> >>>>>>>>>>
> >>>>>>>>>> * Added a placeholder for extension, allowing random text to
> >>>>>>>>>> be
> >>>>>> included in the request and MAC.
> >>>>>>>>>>
> >>>>>>>>>> * Added issuer attribute for identifying the source of the
> >>>>>>>>>> credentials as
> >>>>>> an additional protection.
> >>>>>>>>>>
> >>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
> >>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>
> >>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
> >>>>>> _______________________________________________
> >>>>>> 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 tim.freeman@hp.com  Tue May 31 11: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 00C11E08C7 for ; Tue, 31 May 2011 11:22:05 -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 0IeO85dwKjQV for ; Tue, 31 May 2011 11:22:02 -0700 (PDT)
Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0742BE08DA for ; Tue, 31 May 2011 11:21:56 -0700 (PDT)
Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id EAF61CD90; Tue, 31 May 2011 18:21:31 +0000 (UTC)
Received: from G3W0632.americas.hpqcorp.net (16.233.58.62) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 31 May 2011 18:19:41 +0000
Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G3W0632.americas.hpqcorp.net ([16.233.58.62]) with mapi; Tue, 31 May 2011 18:19:40 +0000
From: "Freeman, Tim" 
To: Eran Hammer-Lahav , Peter Wolanin , Skylar Woodward 
Date: Tue, 31 May 2011 18:19:39 +0000
Thread-Topic: Clock synchronization (was RE: [OAUTH-WG] Fwd: issues with token age element - MAC token)
Thread-Index: AcwebFsMUi2IYSIETiit9m2WaVm7nwAIS04wAEvy30A=
Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A6B854DE223@GVW0432EXB.americas.hpqcorp.net>
References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com> <3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org>  <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: OAuth WG 
Subject: [OAUTH-WG] Clock synchronization (was RE: 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: Tue, 31 May 2011 18:22:05 -0000

Pk5vIHdpbmRvdyB3aWxsIGJlIGJpZyBlbm91Z2ggYXMgZXhwZXJpZW5jZSBzaG93cyBzb21lIHVz
ZXJzIGhhdmUgW2Nsb2Nrc10gdGhhdCBhcmUgb2ZmIGJ5IG1vcmUgdGhhbiBhbiBob3VyIGFuZCBh
IGhhbGYuDQoNCkZXSVcsIEkgaGF2ZSBzZWVuIHVzZXJzIHdpdGggY2xvY2tzIGEgeWVhciBvZmYg
KG5vdCBhdCBIUCkuICBUaGV5IHNldCB0aGVpciBjbG9ja3Mgd3Jvbmcgc28gdGhleSBjb3VsZCBy
dW4gZXhwaXJlZCBiZXRhIHNvZnR3YXJlLiAgDQoNCkFueSByZXF1aXJlbWVudCBmb3Igc3luY2hy
b25pemluZyBjbG9ja3Mgd2lsbCBiZSBhY3RpdmVseSBjaXJjdW12ZW50ZWQsIG9jY2FzaW9uYWxs
eS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJhbiBI
YW1tZXItTGFoYXYNClNlbnQ6IFN1bmRheSwgTWF5IDI5LCAyMDExIDEwOjU1IFBNDQpUbzogUGV0
ZXIgV29sYW5pbjsgU2t5bGFyIFdvb2R3YXJkDQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIEZ3ZDogaXNzdWVzIHdpdGggdG9rZW4gYWdlIGVsZW1lbnQgLSBNQUMgdG9rZW4N
Cg0KQW55IGtpbmQgb2YgY2xvY2sgc3luYyByZXF1aXJlbWVudCBmb3IgdXNlci1hZ2VudHMgKGJh
c2ljYWxseSwgaG9tZSBkZXNrdG9wcykgaXQgY29tcGxldGVseSBpbXByYWN0aWNhbC4gVGhlIGFk
ZGVkIGNvbXBsZXhpdHkgcGFsZXMgaW4gY29tcGFyaXNvbiB0byB0aGUgZGlmZmljdWx0eSBvZiB0
cnlpbmcgdG8gdXNlIHRpbWVzdGFtcHMgYW5kIGFueSBraW5kIG9mIGNsb2NrIHN5bmMuIE5vIHdp
bmRvdyB3aWxsIGJlIGJpZyBlbm91Z2ggYXMgZXhwZXJpZW5jZSBzaG93cyBzb21lIHVzZXJzIGhh
dmUgY2xvc2VzIHRoYXQgYXJlIG9mZiBieSBtb3JlIHRoYW4gYW4gaG91ciBhbmQgYSBoYWxmLg0K
DQpUaGUgaXNzdWUgaGVyZSBpcyB3aG8gaXMgdGhpcyBiZWluZyBvcHRpbWl6ZWQgZm9yLiBTZXJ2
ZXItdG8tc2VydmVyIGNvbW11bmljYXRpb24gc2hvdWxkIHNpbXBseSB1c2UgVExTIGZvciBwcml2
YWN5IGFuZCBNSVRNIHByb3RlY3Rpb24gb24gdG9wIG9mIE1BQyBpbnN0ZWFkIG9mIHVzaW5nIG5v
bmNlcyB0byBwcmV2ZW50IHJlcGxheS4gVGhlIHdob2xlIHBvaW50IG9mIHRoaXMga2luZCBvZiBy
ZXBsYXkgcHJvdGVjdGlvbiBpcyB3aGVuIFRMUyBpcyBub3QgYXZhaWxhYmxlLg0KDQpJIHRoaW5r
IGEgYmV0dGVyIGFwcHJvYWNoIGlzIHRvIHNpbXBseSBtYWtlIGNoZWNraW5nIHRoZSBub25jZSBv
cHRpb25hbCB3aGVuIFRMUyBpcyB1c2VkLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFBldGVyIFdvbGFuaW4NCj4gU2VudDogU3Vu
ZGF5LCBNYXkgMjksIDIwMTEgNjo1MyBQTQ0KPiBUbzogU2t5bGFyIFdvb2R3YXJkDQo+IENjOiBP
QXV0aCBXRw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGd2Q6IGlzc3VlcyB3aXRoIHRva2Vu
IGFnZSBlbGVtZW50IC0gTUFDIHRva2VuDQo+IA0KPiBJIGFtIGFsc28gY29uY2VybmVkIGJ5IHRo
ZSBmcmFnaWxpdHkgb2YgdXNpbmcgdGltZS1zaW5jZS1jcmVkZW50aWFscy1pc3N1ZWQsDQo+IGFu
ZCBhbHNvIHRoZSBhZGRlZCBjb21wbGV4aXR5IG9mIHNwZWNpZnlpbmcgdGhpcyBjb25zdHJ1Y3Rp
b24uDQo+IA0KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIHByZWZlcmFibGUgdG8gYWx3YXlzIHJlcXVp
cmUgYSB0aW1lc3RhbXAgYXMgcGFydCBvZiB0aGUNCj4gYXV0aG9yaXphdGlvbiBoZWFkZXIsIGFu
ZCBtYXliZSBldmVuIGluY2x1ZGUgaW4gdGhlIHNwZWMgYSBtYXhpbXVtIHRpbWUNCj4gZGlmZmVy
ZW5jZSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIChlLmcuIDkwMCBzZWNvbmRzKSB0aGF0IGNh
biBiZQ0KPiB0b2xlcmF0ZWQuICBUaGlzIG1ha2VzIGdlbmVyYXRpbmcgdGhlIG5vbmNlIGVhc2ll
ciBhbHNvLCBzaW5jZSB0aGUgdmFsdWUgbmVlZA0KPiB0byBsb25nZXIgYmUgdW5pcXVlIG92ZXIg
YWxsIHRpbWUuDQo+IA0KPiBXZSBoYXZlIHN1Y2ggcnVsZXMgaW4gcGxhY2UgZm9yIGFuIEhNQUMt
YmFzZWQgYXV0aGVudGljYXRpb24gc3lzdGVtIHdlDQo+IHVzZS4gIE9uY2UgaW4gYSB3aGlsZSBh
IGNsaWVudCBoYXMgYSBsb2NhbCBjbG9jayBzbyBmYXIgb3V0IG9mIHN5bmMgdGhhdCB0aGVyZSBp
cyBhbg0KPiBpc3N1ZSwgYnV0IGl0J3MgcmFyZS4NCj4gDQo+IC1QZXRlcg0KPiANCj4gT24gTW9u
LCBNYXkgMjMsIDIwMTEgYXQgOToxNiBQTSwgU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJAa2l2YS5v
cmc+DQo+IHdyb3RlOg0KPiA+IFJlc2VuZGluZyB0byB0aGUgbGlzdCBmcm9tIG15IHN1YnNjcmli
ZWQgYWNjb3VudC4uLg0KPiA+DQo+ID4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+ID4NCj4g
Pj4gRnJvbTogU2t5bGFyIFdvb2R3YXJkIDxza3lsYXJAbGFydy5jb20+DQo+ID4+IERhdGU6IE1h
eSAyMywgMjAxMSA2OjE0OjAwIFBNIFBEVA0KPiA+PiBUbzogU2t5bGFyIFdvb2R3YXJkIDxza3ls
YXJAa2l2YS5vcmc+DQo+ID4+IENjOiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNl
LmNvbT4sIE9BdXRoIFdHDQo+ID4+IDxvYXV0aEBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gaXNzdWVzIHdpdGggdG9rZW4gYWdlIGVsZW1lbnQgLSBNQUMgdG9rZW4NCj4g
Pj4NCj4gPj4gU28gYWZ0ZXIgZGlzY3Vzc2luZyB0aGlzIHRvZGF5IGFuZCByZWZsZWN0aW5nIG9u
IGl0IGEgYml0LCBJIHdvdWxkIHN1Z2dlc3QgdGhhdA0KPiBub25jZSBzaW1wbHkgYmUgdGhlICJ1
bmlxdWUgdmFsdWUiIChhcyBpdCBpcyBzbyBuYW1lZCkgd2l0aG91dCBmdXJ0aGVyDQo+IHJlcXVp
cmVtZW50cy4gSXQgbWlnaHQgYmUgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZSBjb21wb3NlZCBvZiBh
bg0KPiByYW5kb20rdGltZXN0YW1wIChub3QgYWdlKSB2YWx1ZSwgYnV0IHRoYXQgc2VlbXMgbW9y
ZSBvZiBhIE1BWSBvcg0KPiAicmVjb21tZW5kZWQiIHByYWN0aWNlLiBJZiB0aGUgZXhwZWN0YXRp
b24gaXMgdGhhdCB2ZXJ5IGZldyBpZiBhbnkgcHJvdmlkZXJzDQo+IHdvdWxkIGFjdHVhbGx5IGNo
ZWNrIHRoZSB0aW1lc3RhbXAgKG9yIG1vcmVvdmVyLCB0aGUgbm9uY2UgaXRzZWxmKSwgd2h5IGFk
ZA0KPiB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQgdGhhdCByZXF1aXJlcyBpdD8gRGV2ZWxvcGVy
cyBhcmUgZG9pbmcgZXh0cmENCj4gaG91c2VrZWVwaW5nIChhbmQgcGVyaGFwcyBmb3IgYSBwZXJj
ZWl2ZWQgYmVuZWZpdCkgYnV0IHdpdGggbm8gcGF5b2ZmIG9yDQo+IGFkZGVkIHNlY3VyaXR5Lg0K
PiA+Pg0KPiA+PiBJJ20gc2VuZGluZyB0aGlzIGZlZWRiYWNrIGJhc2VkIG9uIGhhdmluZyBpbXBs
ZW1lbnRlZCB0aGUgdjMtNSBjaGFuZ2VzDQo+IGxhc3QgbmlnaHQgKGZvciBib3RoIGNsaWVudCBj
cmVkZW50aWFscyBhbmQgcmVxdWVzdHMgdy8gYWNjZXNzIHRva2VucykuIEFmdGVyDQo+IHRoZSBj
aGFuZ2VzLCB0aGUgbm9uY2UgY3JlYXRpb24gaXMgbm93IHRoZSBtb3N0IGNvbXBsaWNhdGVkIHBh
cnQgb2YgdGhlDQo+IG5vcm1hbGl6ZWQgcmVxdWVzdCBzdHJpbmcgYW5kIHlldCB0aGVzZSBjaGFu
Z2VzIG9mZmVyIHRoZSBsZWFzdCBiZW5lZml0Lg0KPiBXaGF0J3MgbW9zdCBpbXBvcnRhbnQgaXMg
dGhhdCBub25jZXMgYXJlIHVuaXF1ZSBvbiBlYWNoIHJlcXVlc3QgZm9yIGFuIElELg0KPiA+Pg0K
PiA+PiBUaGVyZSBhcmUgaXNzdWVzIHdpdGggYWdlIGFzIHdlbGw6DQo+ID4+DQo+ID4+IC0gQXMg
QmlsbCBtZW50aW9uZWQsIGlmIHRoZSBjbGllbnQgc3RvcmVzIHRoZSBpc3N1ZSB0aW1lIGJhc2Vk
IG9uDQo+ID4+IHJlY2VpcHQsIHRoZW4gdGhlIGludGVybmFsIGNsb2NrIGNoYW5nZXMgKHByZXN1
bWFibHkgdy9vIGtub3dsZWRnZSBvZg0KPiA+PiB0aGUgc29mdHdhcmUgc3RvcmluZyB0aGUgZGF0
ZXMpIHRoZW4gdGltZSB3aWxsIGFsc28gZmFpbC4gQXNzdW1pbmcNCj4gPj4gdGhhdCBhIHVzZXIg
d2l0aCBhIGJhZCBjbG9jayAob2YgYnkgaG91cnMgb3IgbW9yZSkgd2lsbCBuZXZlciBmaXggaXQN
Cj4gPj4gYW5kIGFjdHVhbGx5IGVuY291cmFnZXMgYmFkIHVzZXIgYmVoYXZpb3IgKGRvbid0IGZp
eCB5b3VyIGNsb2NrIG9yDQo+ID4+IFR3aXR0ZXJib3Qgd2lsbCBzdG9wIHdvcmtpbmchKS4gVGhv
dWdoIHdlIHNheSB0aGF0IHRpbWV6b25lcyB3b24ndA0KPiA+PiBicmluZyBhYm91dCB0aGUgc2l0
dWF0aW9uIG9mIGNoYW5nZWQgY2xvY2ssIEknZCBiZSB0byBkaWZmZXIuIE1hbnkNCj4gPj4gdXNl
cnMgYXJlbid0IHNhdnZ5IGVub3VnaCB0byBjaGFuZ2UgdGltZSB6b25lLCBidXQganVzdCBhZGp1
c3QgdGhlDQo+ID4+IHRpbWUgdG8gbG9jYWwgdGltZSBhbnl3YXkuIFVzZXJzIHdobyBhcmUgbW9y
ZSBsaWtlbHkgdG8gZ2V0IGl0IHJpZ2h0DQo+ID4+IGFscmVhZHkgaGF2ZSBhdXRvIGNsb2NrIHN5
bmMgZW5hYmxlZCAodmlhIHdlYiwgbW9iaWxlLCBldGMuKQ0KPiA+Pg0KPiA+PiAtIFdoYXQgaWYg
dGhlIHRva2VuIHdhc24ndCBvcmlnaW5hbGx5IGlzc3VlZCBwcm9ncmFtbWF0aWNhbGx5PyBJbiB0
aGlzIGNhc2UsDQo+IHRoZSBpc3N1ZSB0aW1lIGhhcyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoZSBz
ZXJ2ZXIgYW5kIHN0b3JlZCBvbiB0aGUgY2xpZW50DQo+IHRoZW4geW91IGhhdmUgdGhlIHNhbWUg
cHJvYmxlbSBhcyB3aXRoIGEgdGltZXN0YW1wIC0gdGhlIGNsaWVudCBjbG9jayBpcyBub3QNCj4g
c3luYydkIHRvIHRoZSBzZXJ2ZXIgY2xvY2sgYW5kIHRoZXJlIGlzIG5vIGFkanVzdG1lbnQuIFlv
dSB3YW50IHRoaXMgdG8gYXBwbHkNCj4gdG8gdXNlcyBvdXRzaWRlIG9mIGp1c3QgT0F1dGgsIGJ1
dCBub3cgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gYmUgYWJsZSB0bw0KPiBkZXRlcm1pbmUgYW4g
aXNzdWUgdGltZSBiYXNlZCBvbiB3aGVuIGl0IHJlY2VpdmVzIGFuIEhUVFAgcmVxdWVzdA0KPiBu
ZWNlc3NhcmlseSBsaW1pdHMgdGhlIHR5cGVzIG9mIHRva2VuIGZsb3dzIGZvciB3aGljaCB0aGlz
IGNhbiBiZSB1c2VkLg0KPiA+Pg0KPiA+PiAtIEl0J3Mgb25lIG1vcmUgZGV0YWlsIHRvIHN0b3Jl
LiBIYXJkbHkgYW4gaXNzdWUgZm9yIGEgZGV2ZWxvcGVyLCBidXQgaXQgaXMNCj4gaW5lbGVnYW50
LiBJdCdzIGxpa2UgaGF2aW5nIGEgZG91YmxlIElELiBZZXQgaXQncyBub3QgYW4gSUQsIGl0IGlz
IGFjdHVhbGx5IG1vcmUgb2YgYQ0KPiByZWNvcmRpbmcgb2YgIm15IHBlcnNvbmFsIGNsb2NrIG9m
ZnNldCB2YWx1ZSIgYnV0IG9iZnVzY2F0ZWQgc2V2ZXJhbCB0aW1lcw0KPiBvdmVyIChvbmUgZm9y
IGVhY2ggdG9rZW4pIGFzIGlzc3VlX2RhdGUuDQo+ID4+DQo+ID4+IC0gVGhpcyBpbXBsZW1lbnRh
dGlvbiBhc3N1bWVzIHNvZnR3YXJlIHByb2dyYW1zIHVzZSB0aGUgY29tcHV0ZXINCj4gaW50ZXJu
YWwgY2xvY2sgZXhjbHVzaXZlbHkgZm9yIHRpbWVzdGFtcC4gQSByb2J1c3QgcHJvZ3JhbSB0aGF0
IGlzIGRlcGVuZGVudA0KPiBvbiBhY2N1cmF0ZSB0aW1lc3RhbXBzIHdvdWxkIHBpbmcgdGhlIG9y
aWdpbiBzZXJ2ZXIgKG9yIHNpbWlsYXIgdHJ1c3RlZCB0aW1lDQo+IGF1dGhvcml0eSkgdG8gYXNr
IGl0IHRoZSBjdXJyZW50IHRpbWUuIFRoZW4gaXQgY291bGQgc3RvcmUgYSAibXkgZGV2aWNlIGNs
b2NrDQo+IG9mZnNldCIgdmFsdWUgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgcHJvZ3JhbSBleGVj
dXRpb24uIEFsbCByZXF1ZXN0cyBuZWVkaW5nDQo+IHRpbWVzdGFtcCB3b3VsZCBiZSBhZGp1c3Rl
ZCBhY2NvcmRpbmdseS4gRm9yIGFnZSwgaWYgdGhlIGNsb2NrIGlzIGNoYW5nZWQNCj4gc2luY2Ug
dGhlIHN0b3JlZCBpc3N1ZV9kYXRlLCB0aGUgcHJvYmxlbSBjYW4ndCBiZSBjb3JyZWN0ZWQgaW4g
dGhpcyBtYW5uZXIuDQo+IFRodXMsIGEgc2lnbmlmaWNhbnQgYWR2YW50YWdlIGZvciB0aW1lc3Rh
bXAuDQo+ID4+DQo+ID4+IEFsbCBpbiBhbGwsIHRoaXMgc2VlbXMgbGlrZSBhIG1pc2d1aWRlZCBi
dXQgd2VsbC1pbnRlbnRpb25lZCBhdHRlbXB0IHRvIGdldA0KPiBhcm91bmQgZW5kLXVzZXIgaXNz
dWVzIG9mIG1pcy1zZXQgY2xvY2tzLiBJdCBmZWVscyBsaWtlIGEgaGFjayBhbmQgaXQgY2VydGFp
bmx5DQo+IGlzbid0IGEgZm9vbHByb29mIHNvbHV0aW9uLiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0
IHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhlIGFnZQ0KPiBwYXJhbWV0ZXIsIHRoZSBsZXNzIEkgbGlr
ZSBpdC4gVGltZXN0YW1wIGhhcyBiZWVuIHVzZWQgZm9yIG1hbnkgeWVhcnMgaW4gdGhlDQo+IGlu
ZHVzdHJ5IGFuZCB3aXRoIHJlYXNvbmFibGUgc3VjY2VzcyBpbiByZWxldmFudCBhcHBsaWNhdGlv
bnMuIElmIHdlIGNoYW5nZSB0bw0KPiBhIG5ldyB3YXkgb2YgdHJ5aW5nIHRvIHN5bmMgb24gdGlt
ZSBJIHRoaW5rIHdlIHJ1biBhIGdyZWF0ZXIgcmlzayBvZiBzdHVtYmxpbmcNCj4gdXBvbiB1bmZv
cmVzZWVuIGlzc3Vlcywgc3VjaCBhcyB0aG9zZSBvdXRsaW5lZCBhYm92ZS4NCj4gPj4NCj4gPj4g
SSByZWNvbW1lbmQgdGhlIHJlcXVpcmVtZW50IG9mIGFuIGFnZSAob3IgdGltZXN0YW1wIGZvciB0
aGF0IG1hdHRlcikNCj4gYmUgZHJvcHBlZCBmcm9tIHRoZSBub25jZSBjb25zdHJ1Y3Rpb24uIEZv
ciBwcm92aWRlcnMgdGhhdCBkZWVtIGl0DQo+IHZhbHVhYmxlLCB0aW1lc3RhbXAgY2FuIGJlIGFu
IG9wdGlvbmFsIHZhbHVlIChlaXRoZXIgYXMgcGFydCBvZiB0aGUgbm9uY2Ugb3INCj4gdGhlIG92
ZXJhbGwgaGVhZGVyLCBhcyBiZWZvcmUpLg0KPiA+Pg0KPiA+PiBza3lsYXINCj4gPj4NCj4gPj4N
Cj4gPj4NCj4gPj4gT24gTWF5IDIzLCAyMDExLCBhdCAyOjExIEFNLCBTa3lsYXIgV29vZHdhcmQg
d3JvdGU6DQo+ID4+DQo+ID4+PiBZb3UgbWF5IGhhdmUgbm90aWNlZCwgb24gcGFnZSA4IHRoZSBo
b3N0IGlzIGxpc3RlZCBhcyAiZXhhbXBsZS5uZXQiDQo+ID4+PiAtIHNob3VsZCBiZSBleGFtcGxl
LmNvbSwgSSBiZWxpZXZlLiDCoChkcmFmdCB2NSkNCj4gPj4+DQo+ID4+PiBBbGwgaW4gYWxsLCBJ
J20gaW4gc3VwcG9ydCBvZiB0aGUgY2hhbmdlcyBpbiB2Mi4gQ2VydGFpbmx5IGFkZHJlc3NlcyBt
eQ0KPiBoZXNpdGF0aW9ucyBmcm9tIHYyLg0KPiA+Pj4NCj4gPj4+IHNreWxhcg0KPiA+Pj4NCj4g
Pj4+DQo+ID4+PiBPbiBNYXkgOSwgMjAxMSwgYXQgMTI6MzYgUE0sIEVyYW4gSGFtbWVyLUxhaGF2
IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiAoUGxlYXNlIGRpc2N1c3MgdGhpcyBkcmFmdCBvbiB0aGUg
QXBwcy1EaXNjdXNzDQo+ID4+Pj4gPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gbWFpbGluZyBsaXN0
KQ0KPiA+Pj4+DQo+ID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFtbWVy
LW9hdXRoLXYyLW1hYy10b2tlbg0KPiA+Pj4+DQo+ID4+Pj4gV2hpbGUgdGhpcyBkb2N1bWVudCBo
YXMgbW92ZWQgdG8gdGhlIEFwcHMtRGlzY3VzcyBtYWlsaW5nIGxpc3QgZm9yIHRoZQ0KPiB0aW1l
IGJlaW5nLCBJIHdhbnRlZCB0byBnaXZlIGEgcXVpY2sgdXBkYXRlIHRvIHRob3NlIHdobyBoYXZl
IGJlZW4NCj4gZm9sbG93aW5nIHRoaXMgZHJhZnQgd2hpY2ggb3JpZ2luYXRlZCBvbiB0aGlzIGxp
c3QuDQo+ID4+Pj4NCj4gPj4+PiBUaGUgbWFqb3IgY2hhbmdlcyBzaW5jZSAtMDIgYXJlOg0KPiA+
Pj4+DQo+ID4+Pj4gKiBSZW1vdmVkIE9BdXRoIHRlcm1pbm9sb2d5IGFuZCBhc3NvY2lhdGlvbi4g
VGhlIGRyYWZ0IGlzIG5vdyBhDQo+IGdlbmVyYWwgcHVycG9zZSBIVFRQIGF1dGhlbnRpY2F0aW9u
IHNjaGVtZS4gSXQgZG9lcyBpbmNsdWRlIGFuIE9BdXRoIDIuMA0KPiBiaW5kaW5nIHdoaWNoIGlz
IGRlc2NyaWJlZCBpbiBsZXNzIHRoYW4gYSBwYWdlLiBPbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0
bw0KPiBtb3ZlIHNlY3Rpb24gNS4xIGludG8gdGhlIE9BdXRoIHNwZWNpZmljYXRpb24gYW5kIGRy
b3AgYWxsIHRoZSBPQXV0aCAyLjAgdGV4dA0KPiBmcm9tIHRoZSBNQUMgZHJhZnQuDQo+ID4+Pj4N
Cj4gPj4+PiAqIEFkZGVkICdTZXQtQ29va2llJyBleHRlbnNpb24gZm9yIHVzaW5nIE1BQyB3aXRo
IHNlc3Npb24gY29va2llcy4NCj4gPj4+Pg0KPiA+Pj4+ICogUmVtb3ZlZCByZXF1ZXN0IFVSSSBx
dWVyeSBub3JtYWxpemF0aW9uLiBUaGUgbmV3IGRyYWZ0IHVzZXMgdGhlDQo+IHJhdyByZXF1ZXN0
IFVSSSB1bmNoYW5nZWQuDQo+ID4+Pj4NCj4gPj4+PiAqIFJlcGxhY2VkIHRpbWVzdGFtcHMgd2l0
aCBjcmVkZW50aWFscyBhZ2UgdG8gcmVtb3ZlIHRoZSBuZWVkIGZvcg0KPiBjbG9jayBzeW5jLg0K
PiA+Pj4+DQo+ID4+Pj4gKiBBZGRlZCBhIHBsYWNlaG9sZGVyIGZvciBleHRlbnNpb24sIGFsbG93
aW5nIHJhbmRvbSB0ZXh0IHRvIGJlDQo+IGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IGFuZCBNQUMu
DQo+ID4+Pj4NCj4gPj4+PiAqIEFkZGVkIGlzc3VlciBhdHRyaWJ1dGUgZm9yIGlkZW50aWZ5aW5n
IHRoZSBzb3VyY2Ugb2YgdGhlIGNyZWRlbnRpYWxzIGFzDQo+IGFuIGFkZGl0aW9uYWwgcHJvdGVj
dGlvbi4NCj4gPj4+Pg0KPiA+Pj4+IERyYWZ0IC0wNCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHBy
ZXZpb3VzIGRyYWZ0cy4NCj4gPj4+Pg0KPiA+Pj4+IEVITA0KPiA+Pj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gT0F1dGggbWFpbGluZyBs
aXN0DQo+ID4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4+Pg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxp
c3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCj4gPg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBQZXRlciBNLiBXb2xhbmlu
LCBQaC5ELiDCoCDCoCDCoDogTW9tZW50dW0gU3BlY2lhbGlzdCzCoCBBY3F1aWEuIEluYy4NCj4g
cGV0ZXIud29sYW5pbkBhY3F1aWEuY29tIDogOTc4LTI5Ni01MjQ3DQo+IA0KPiAiR2V0IGEgZnJl
ZSwgaG9zdGVkIERydXBhbCA3IHNpdGU6IGh0dHA6Ly93d3cuZHJ1cGFsZ2FyZGVucy5jb20iDQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRo
IG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

From wmills@yahoo-inc.com  Tue May 31 12:03: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 F0F13E086E for ; Tue, 31 May 2011 12:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.618
X-Spam-Level: 
X-Spam-Status: No, score=-16.618 tagged_above=-999 required=5 tests=[AWL=-0.980, 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 5O8JKdCEOc7Z for ; Tue, 31 May 2011 12:03:43 -0700 (PDT)
Received: from nm19-vm2.bullet.mail.ne1.yahoo.com (nm19-vm2.bullet.mail.ne1.yahoo.com [98.138.91.95]) by ietfa.amsl.com (Postfix) with SMTP id D357EE08B3 for ; Tue, 31 May 2011 12:03:20 -0700 (PDT)
Received: from [98.138.90.57] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 31 May 2011 19:03:17 -0000
Received: from [98.138.89.168] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 31 May 2011 19:03:17 -0000
Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 31 May 2011 19:03:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 83531.83713.bm@omp1024.mail.ne1.yahoo.com
Received: (qmail 76570 invoked by uid 60001); 31 May 2011 19:03:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306868596; bh=Y+mjuMelplva0gCDMbYMle4Egv0udUSTw17tfibrC1A=; 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=ewwlfXSjjRD7ZlyM+pvnzWNMF9G0au74zosq0PHx8+F0huCNQgYXGK+KIvnN7K96Vyg5Qal+JDqEAiHnPbM9VFJjt4/DJ7Ml7jSAIFIW5/AusMjkK4S+phSEJFeLQKibyqTiudsv1Vl7N6VEFk2DhCAuW1/t6HIhiv90iPMzQdk=
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=NIzA1UyfH3TsdB0syudLIgcV7y6q8Q9X+AyEyQd4dAXXcq7OaHD+YBPhupsyBRwyh4PBGVPIBI7I3chzF9Y0ca2KQ8ZIj5jstUYfcnoQn8jav9B0Mtkf2HefMBo3AP+eYfS2xwCA7drh2c8EnGY41fPn/mEepVHFp5mgdfp5Pcs=;
X-YMail-OSG: T.PDAQkVM1nvMBwR9NNHq.BA0UZG_qZKC3AWUURh15wNdub M4SzTFBltN1RsZTQjnSAbJMAVwVTzxSZC.2bOKpMKtAW0x55LtHjys7PiEuT g0P2yjIO71Cwz9vfhExAm5R7DEqQyMJYaYJV53lJjZgRxCd72C01Uqqv8Xky EbJzHmpnm0fMGZ5LfPA5I5vqBicMV.XNbNMAjzpW1UGVGyfDWKVFJSnVqIVx lE_53S.2QArFGjeMAvpd7f2xR79nbyiH.K9PIoNeD3Ppzuf_q8Z3DDeDtaR0 5skOKlwMyDnhKuLpBzDApB5Zn6_4MfZ3mGY2089N_x.v3beHiOMBLdDgXL1V DrzXMbGsuBZZJsR8fXbmjdv_4MA4H_G7V4.EgPLgBfFtbGmd9mVmCOwmJQQW iEaUIbJunaj7MjEEncAVR8S5Of1wb7tc-
Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 31 May 2011 12:03:16 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
References:  <4E1F6AAD24975D4BA5B1680429673943380F6A46@TK5EX14MBXC203.redmond.corp.microsoft.com> 
Message-ID: <1306868596.53855.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Tue, 31 May 2011 12:03:16 -0700 (PDT)
From: "William J. Mills" 
To: David Recordon , Mike Jones , Doug Tangren , "oauth@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1429822711-1306868596=:53855"
Cc: paul Tarjan 
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: Tue, 31 May 2011 19:03:44 -0000

--0-1429822711-1306868596=:53855
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Except int he "bearer" authentication scheme, in which it is not named.=0A=
=0A=0A=0A________________________________=0AFrom: David Recordon =0ATo: Mike Jones ; Doug Tangren ; "oauth@ietf.org" =0ACc: paul Tarjan =0ASent: Saturday, May 28, 2011 9:30 AM=0ASubject: Re: [O=
AUTH-WG] consistency of token param name in bearer token type=0A=0ADid a fu=
ll read through of draft 16 and the bear token spec with Paul=0Ayesterday a=
fternoon in order to do a manual diff from draft 10. The=0Apoint Doug raise=
d was actually confusing. Throughout the core spec=0Ait's referred to as ac=
cess_token but then becomes bearer_token upon=0Ause.=0A=0AJust thinking thr=
ough this from a developer documentation perspective,=0Ait's going to becom=
e confusing. Developer documentation focuses on=0Agetting an access token a=
nd then using that access token to interact=0Awith an API. Thus the code yo=
u're writing as a client developer will=0Ause variables, cache keys, and da=
tabase columns named `access_token`.=0ABut then when you're going to use it=
, you'll need to put this access=0Atoken into a field named bearer_token.=
=0A=0AFeels quite a bit simpler to just name it access_token. Realize the=
=0Acore spec never did this since we didn't want to trample on protected=0A=
resources which might already have a different type of access_token=0Aparam=
eter. oauth_token was a good compromise since developers would=0Aalready kn=
ow that they were using OAuth and thus a new term wasn't=0Abeing introduced=
. That's no longer true with bearer_token since 99% of=0Adevelopers will ha=
ve never heard of a bearer token.=0A=0AGoogling for "bearer token" turns up=
 Eran's blog post titled "OAuth=0ABearer Tokens are a Terrible Idea" and th=
ere isn't a single result on=0Athe first page which explains what they are.=
 Binging for "bearer=0Atoken" is equally scary.=0A=0A--David=0A=0A=0AOn Mon=
, May 23, 2011 at 11:38 AM, Mike Jones=0A wrot=
e:=0A> The working group explicitly decided that a different name should be=
 used,=0A> to make it clear that other token types other than bearer tokens=
 could also=0A> 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=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-b=
ounces@ietf.org] On Behalf Of=0A> Doug Tangren=0A> Sent: Wednesday, May 11,=
 2011 10:09 PM=0A> To: oauth@ietf.org=0A> Subject: [OAUTH-WG] consistency o=
f token param name in bearer token type=0A>=0A>=0A>=0A> This may have come =
up before so I'm sorry if I'm repeating. Why does bearer=0A> token spec int=
roduce a new name for oauth2 access tokens [1],=0A> "bearer_token", and bef=
ore that [2], "oauth_token"?=0A>=0A>=0A>=0A> I=A0apologize=A0if this may so=
und shallow but, why introduce a new parameter=0A> name verses sticking wit=
h what the general oauth2 spec already defines,=0A> "access_token". It seem=
s arbitrary for an auth server to hand a client an=0A> apple then have the =
client hand it off to the resource server and call it an=0A> orange.=0A>=0A=
>=0A>=0A> Was this just for the sake of differentiating the parameter name =
enough so=0A> that the bearer tokens may be used in other protocols without=
 being confused=0A> with oauth2 access_tokens?=0A>=0A>=0A>=0A> [1]:=A0http:=
//tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2=0A>=0A> [2]=
:=A0http://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____________________=
___________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps:/=
/www.ietf.org/mailman/listinfo/oauth
--0-1429822711-1306868596=:53855
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


    Except int he "bearer" authentication scheme, in which it is not named.

    From:=
 David Recordon <recordond@gmail.com>
    To: Mike Jones <Michael.Jones@microsoft.com>=
; Doug Tangren <d.tangren@gmail.com>; "oauth@ietf.org" <oauth@ietf=
.org>
    Cc: paul Tarja=
n <paul.tarjan@fb.com>
    Sent:=
 Saturday, May 28, 2011 9:30 AM
    Subject: Re: [OAUTH-WG] consistency of token param name =
in bearer token type

    =0ADid a full read through of draft 16 a=
nd the bear token spec with Paul
    yesterday afternoon in order to do a ma=
nual diff from draft 10. The
    point Doug raised was actually confusing. T=
hroughout the core spec
    it's referred to as access_token but then become=
s bearer_token upon
    use.

    Just thinking through this from a develo=
per documentation perspective,
    it's going to become confusing. Developer=
 documentation focuses on
    getting an access token and then using that ac=
cess token to interact
    with an API. Thus the code you're writing as a cl=
ient developer will
    use variables, cache keys, and database columns name=
d `access_token`.
    But then when you're going to use it, you'll need to p=
ut 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 m=
ight 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 s=
ince 99% of
    developers will have never heard of a bearer token.

    G=
oogling for "bearer token" turns up Eran's blog post titled "OAuth
    Beare=
r Tokens are a Terrible Idea" and there isn't a single result on
    the fir=
st page which explains what they are. Binging for "bearer
    token" is equa=
lly scary.

    --David


    On Mon, May 23, 2011 at 11:38 AM, Mike=
 Jones
    <Michael.Jones@microsoft.com> 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.
    >
    >
    >
    >       &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike
    >
    >
    >
    > From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha=
lf Of
    > Doug Tangren
    > Sent: Wednesday, May 11, 2011 10:09 PM> To: oauth@ietf.org
    > Subject: [OAUTH-WG] consistency of token par=
am name in bearer token type
    >
    >
    >
    > This may have =
come
 up before so I'm sorry if I'm repeating. Why does bearer
    > token spe=
c introduce a new name for oauth2 access tokens [1],
    > "bearer_token"=
, and before that [2], "oauth_token"?
    >
    >
    >
    > I&nbs=
p;apologize if this may sound shallow but, why introduce a new paramet=
er
    > name verses sticking with what the general oauth2 spec already d=
efines,
    > "access_token". It seems arbitrary for an auth server to ha=
nd a client an
    > apple then have the client hand it off to the resour=
ce server and call it an
    > orange.
    >
    >
    >
    > Wa=
s this just for the sake of differentiating the parameter name enough so> that the bearer tokens may be used in other protocols without being c=
onfused
    > 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=

    >
    > _______________________________________________
    > OA=
uth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/li=
stinfo/oauth
    >
    >
    _______________________________________=
________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailma=
n/listinfo/oauth


    
--0-1429822711-1306868596=:53855--

From bcampbell@pingidentity.com  Tue May 31 12:06: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 AC5F6E087B; Tue, 31 May 2011 12:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.951
X-Spam-Level: 
X-Spam-Status: No, score=-5.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]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3OTTtXGZxqM; Tue, 31 May 2011 12:06:44 -0700 (PDT)
Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFDAE086E; Tue, 31 May 2011 12:06:43 -0700 (PDT)
Received: from mail-qy0-f175.google.com ([209.85.216.175]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTeU8P5Pd9pFmGESx+ydNEnkN0gOObYK5@postini.com; Tue, 31 May 2011 12:06:43 PDT
Received: by mail-qy0-f175.google.com with SMTP id 35so1666574qyk.13 for ; Tue, 31 May 2011 12:06:39 -0700 (PDT)
Received: by 10.224.214.5 with SMTP id gy5mr4280844qab.386.1306868799109; Tue, 31 May 2011 12:06:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.37.142 with HTTP; Tue, 31 May 2011 12:06:09 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>  
From: Brian Campbell 
Date: Tue, 31 May 2011 13:06:09 -0600
Message-ID: 
To: Doug Tangren 
Content-Type: multipart/alternative; boundary=20cf3005df4c89f9c704a4971ad5
Cc: "oauth-bounces@ietf.org" , "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: Tue, 31 May 2011 19:06:44 -0000

--20cf3005df4c89f9c704a4971ad5
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 31, 2011 at 12:00 PM, Doug Tangren  wrote:

>
> I think there is still a usability issue with the implicit flow in general
> where there is no way in the spec to obtain an access token without
> re-asking the user for authorization a second time even if the user has
> already authorized your client.
>
>

I don't think there is anything in the spec (correct me if I'm wrong) saying
that an AS couldn't "remember" a user's authorization for a given client
using implicit so as to avoid subsequent prompts for authorization?

--20cf3005df4c89f9c704a4971ad5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



    On Tue, May 31, 2011 at 12:00 PM, Doug T=
angren <d.tangr=
en@gmail.com> wrote:
    


    


    I think there is still a usability issue with the implicit flow in gene=
ral where there is no way in the spec to obtain an access token without re-=
asking the user for authorization a second time even if the user has alread=
y authorized your client.
    

=A0



    I don't think there is anything i=
n the spec (correct me if I'm wrong) saying that an AS couldn't &qu=
ot;remember" a user's authorization for a given client using impli=
cit so as to avoid subsequent prompts for authorization? 
    


    

--20cf3005df4c89f9c704a4971ad5--

From gffletch@aol.com  Tue May 31 12:30: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 33D54E06D4 for ; Tue, 31 May 2011 12:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372,  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 ehMJQ20mUPHu for ; Tue, 31 May 2011 12:30:09 -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 BD7FEE06A8 for ; Tue, 31 May 2011 12:30:08 -0700 (PDT)
Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4VJTw08031577; Tue, 31 May 2011 15:29:58 -0400
Received: from palantir.local (unknown [10.181.183.33]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AEE57E0000AC; Tue, 31 May 2011 15:29:57 -0400 (EDT)
Message-ID: <4DE541B5.6080605@aol.com>
Date: Tue, 31 May 2011 15:29:57 -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> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090906000405020708030902"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:514536416:93952408  
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d33c64de541b56baa
X-AOL-IP: 10.181.183.33
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: Tue, 31 May 2011 19:30:10 -0000

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

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


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



  
    
    
  
  
    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
<Michael.Jones@microsoft.com> 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

    
  


--------------090906000405020708030902--

From igor.faynberg@alcatel-lucent.com  Tue May 31 13: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 826B0E08D8 for ; Tue, 31 May 2011 13:50:19 -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 svC5AK0vhjwj for ; Tue, 31 May 2011 13:50:18 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F4E0830 for ; Tue, 31 May 2011 13:50:18 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4VKoBsX006752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 15:50:11 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4VKoAPF030565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 15:50:11 -0500
Received: from [135.244.18.4] (faynberg.lra.lucent.com [135.244.18.4]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4VKnxwX026778; Tue, 31 May 2011 15:50:01 -0500 (CDT)
Message-ID: <4DE55474.5050308@alcatel-lucent.com>
Date: Tue, 31 May 2011 16:49:56 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "Freeman, Tim" 
References: <5D4A58AD-2246-4433-AE73-2149812F4CA2@larw.com>	<3164324B-8926-431D-ADD7-26882E91CDEC@kiva.org>		<90C41DD21FB7C64BB94121FBBC2E723447583CA1A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <59DD1BA8FD3C0F4C90771C18F2B5B53A6B854DE223@GVW0432EXB.americas.hpqcorp.net>
In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A6B854DE223@GVW0432EXB.americas.hpqcorp.net>
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.12
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Clock synchronization (was RE: Fwd: issues with token age element - MAC token)
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, 31 May 2011 20:50:19 -0000

We have had a long discussion in the beginning on the OAuth analogies 
with Kerberos. I always thought that the topic of this thread is EXACTLY 
a case for import from Kerberos (which does rely on timestamps).  
Kerberos has been successfully deployed for a long time. But Kerberos 
has solved the problem of circumvention that Tim mentioned very simply: 
Those who circumvent clock synchronization won't be authenticated.

I actually thought that Skylar's proposal was in line with Kerberos.  I 
think it will be safe to import the appropriate procedures from (or 
refer to) Kerberos here.

To Eran's suggestion: Ensuring freshness of nonces is a non-trivial 
task, and I think it is much harder than clock synchronization.

Igor



Freeman, Tim wrote:
>> No window will be big enough as experience shows some users have [clocks] that are off by more than an hour and a half.
>>     
>
> FWIW, I have seen users with clocks a year off (not at HP).  They set their clocks wrong so they could run expired beta software.  
>
> Any requirement for synchronizing clocks will be actively circumvented, occasionally.
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
> Sent: Sunday, May 29, 2011 10:55 PM
> To: Peter Wolanin; Skylar Woodward
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Any kind of clock sync requirement for user-agents (basically, home desktops) it completely impractical. The added complexity pales in comparison to the difficulty of trying to use timestamps and any kind of clock sync. No window will be big enough as experience shows some users have closes that are off by more than an hour and a half.
>
> The issue here is who is this being optimized for. Server-to-server communication should simply use TLS for privacy and MITM protection on top of MAC instead of using nonces to prevent replay. The whole point of this kind of replay protection is when TLS is not available.
>
> I think a better approach is to simply make checking the nonce optional when TLS is used.
>
> EHL
>
>   
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Peter Wolanin
>> Sent: Sunday, May 29, 2011 6:53 PM
>> To: Skylar Woodward
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> I am also concerned by the fragility of using time-since-credentials-issued,
>> and also the added complexity of specifying this construction.
>>
>> I think it would be preferable to always require a timestamp as part of the
>> authorization header, and maybe even include in the spec a maximum time
>> difference between client and server (e.g. 900 seconds) that can be
>> tolerated.  This makes generating the nonce easier also, since the value need
>> to longer be unique over all time.
>>
>> We have such rules in place for an HMAC-based authentication system we
>> use.  Once in a while a client has a local clock so far out of sync that there is an
>> issue, but it's rare.
>>
>> -Peter
>>
>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>> wrote:
>>     
>>> Resending to the list from my subscribed account...
>>>
>>> Begin forwarded message:
>>>
>>>       
>>>> From: Skylar Woodward 
>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>> To: Skylar Woodward 
>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>> 
>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>
>>>> So after discussing this today and reflecting on it a bit, I would suggest that
>>>>         
>> nonce simply be the "unique value" (as it is so named) without further
>> requirements. It might be suggested that this be composed of an
>> random+timestamp (not age) value, but that seems more of a MAY or
>> "recommended" practice. If the expectation is that very few if any providers
>> would actually check the timestamp (or moreover, the nonce itself), why add
>> terminology in the draft that requires it? Developers are doing extra
>> housekeeping (and perhaps for a perceived benefit) but with no payoff or
>> added security.
>>     
>>>> I'm sending this feedback based on having implemented the v3-5 changes
>>>>         
>> last night (for both client credentials and requests w/ access tokens). After
>> the changes, the nonce creation is now the most complicated part of the
>> normalized request string and yet these changes offer the least benefit.
>> What's most important is that nonces are unique on each request for an ID.
>>     
>>>> There are issues with age as well:
>>>>
>>>> - As Bill mentioned, if the client stores the issue time based on
>>>> receipt, then the internal clock changes (presumably w/o knowledge of
>>>> the software storing the dates) then time will also fail. Assuming
>>>> that a user with a bad clock (of by hours or more) will never fix it
>>>> and actually encourages bad user behavior (don't fix your clock or
>>>> Twitterbot will stop working!). Though we say that timezones won't
>>>> bring about the situation of changed clock, I'd be to differ. Many
>>>> users aren't savvy enough to change time zone, but just adjust the
>>>> time to local time anyway. Users who are more likely to get it right
>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>
>>>> - What if the token wasn't originally issued programmatically? In this case,
>>>>         
>> the issue time has to be obtained from the server and stored on the client
>> then you have the same problem as with a timestamp - the client clock is not
>> sync'd to the server clock and there is no adjustment. You want this to apply
>> to uses outside of just OAuth, but now requiring the client to be able to
>> determine an issue time based on when it receives an HTTP request
>> necessarily limits the types of token flows for which this can be used.
>>     
>>>> - It's one more detail to store. Hardly an issue for a developer, but it is
>>>>         
>> inelegant. It's like having a double ID. Yet it's not an ID, it is actually more of a
>> recording of "my personal clock offset value" but obfuscated several times
>> over (one for each token) as issue_date.
>>     
>>>> - This implementation assumes software programs use the computer
>>>>         
>> internal clock exclusively for timestamp. A robust program that is dependent
>> on accurate timestamps would ping the origin server (or similar trusted time
>> authority) to ask it the current time. Then it could store a "my device clock
>> offset" value for the lifetime of the program execution. All requests needing
>> timestamp would be adjusted accordingly. For age, if the clock is changed
>> since the stored issue_date, the problem can't be corrected in this manner.
>> Thus, a significant advantage for timestamp.
>>     
>>>> All in all, this seems like a misguided but well-intentioned attempt to get
>>>>         
>> around end-user issues of mis-set clocks. It feels like a hack and it certainly
>> isn't a foolproof solution. The more I think about the implications of the age
>> parameter, the less I like it. Timestamp has been used for many years in the
>> industry and with reasonable success in relevant applications. If we change to
>> a new way of trying to sync on time I think we run a greater risk of stumbling
>> upon unforeseen issues, such as those outlined above.
>>     
>>>> I recommend the requirement of an age (or timestamp for that matter)
>>>>         
>> be dropped from the nonce construction. For providers that deem it
>> valuable, timestamp can be an optional value (either as part of the nonce or
>> the overall header, as before).
>>     
>>>> skylar
>>>>
>>>>
>>>>
>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>
>>>>         
>>>>> You may have noticed, on page 8 the host is listed as "example.net"
>>>>> - should be example.com, I believe.  (draft v5)
>>>>>
>>>>> All in all, I'm in support of the changes in v2. Certainly addresses my
>>>>>           
>> hesitations from v2.
>>     
>>>>> skylar
>>>>>
>>>>>
>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>
>>>>>> While this document has moved to the Apps-Discuss mailing list for the
>>>>>>             
>> time being, I wanted to give a quick update to those who have been
>> following this draft which originated on this list.
>>     
>>>>>> The major changes since -02 are:
>>>>>>
>>>>>> * Removed OAuth terminology and association. The draft is now a
>>>>>>             
>> general purpose HTTP authentication scheme. It does include an OAuth 2.0
>> binding which is described in less than a page. One suggestion would be to
>> move section 5.1 into the OAuth specification and drop all the OAuth 2.0 text
>> from the MAC draft.
>>     
>>>>>> * Added 'Set-Cookie' extension for using MAC with session cookies.
>>>>>>
>>>>>> * Removed request URI query normalization. The new draft uses the
>>>>>>             
>> raw request URI unchanged.
>>     
>>>>>> * Replaced timestamps with credentials age to remove the need for
>>>>>>             
>> clock sync.
>>     
>>>>>> * Added a placeholder for extension, allowing random text to be
>>>>>>             
>> included in the request and MAC.
>>     
>>>>>> * Added issuer attribute for identifying the source of the credentials as
>>>>>>             
>> an additional protection.
>>     
>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>
>>>>>> 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
>>>
>>>       
>>
>> --
>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
>> peter.wolanin@acquia.com : 978-296-5247
>>
>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>> _______________________________________________
>> 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 mark.mcgloin@ie.ibm.com  Tue May 31 13:59: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 4DCE9E08E8 for ; Tue, 31 May 2011 13:59:01 -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 1BWWDk-GS398 for ; Tue, 31 May 2011 13:59:00 -0700 (PDT)
Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE92E08AE for ; Tue, 31 May 2011 13:59:00 -0700 (PDT)
Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p4VKwwaJ032466 for ; Tue, 31 May 2011 20:58:58 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 p4VKwwjY2629668 for ; Tue, 31 May 2011 21:58:58 +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 p4VKwvbD004738 for ; Tue, 31 May 2011 14:58:58 -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 p4VKwvqi004735 for ; Tue, 31 May 2011 14:58:57 -0600
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@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> <90C41DD21FB7C64BB94121FBBC2E723447583CA2E4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-KeepSent: CAEA0D20:47D642DB-802578A1:0072D39C; type=4; name=$KeepSent
To: oauth@ietf.org
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Mark Mcgloin 
Date: Tue, 31 May 2011 21:58:21 +0100
X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 31/05/2011 21:58:22
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [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: Tue, 31 May 2011 20:59:01 -0000

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


From torsten@lodderstedt.net  Tue May 31 14:01: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 ED930E08F0; Tue, 31 May 2011 14:01:52 -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 WLopCNV0hhco; Tue, 31 May 2011 14:01:51 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id E7740E08AE; Tue, 31 May 2011 14:01:50 -0700 (PDT)
Received: from [79.253.20.182] (helo=[192.168.71.27]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRW4S-0004mq-Sm; Tue, 31 May 2011 23:01:48 +0200
Message-ID: <4DE5573D.2080005@lodderstedt.net>
Date: Tue, 31 May 2011 23:01:49 +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: Chuck Mortimore 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050303020509010608060703"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth-bounces@ietf.org" , "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: Tue, 31 May 2011 21:01:53 -0000

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

I think refresh token support in implicit grant is worth a discussion. 
The main difference to authz code from a security perspective is that 
the refresh token as long term credential could be disclosed via the 
user agent's URL history. In my perception, this fact and the assumption 
that user agent clients (the primary audience of this grant type) are 
not able to securely store referesh tokens are the reasons why the spec 
currently does not support it.

wrt Facebook's implementation: is this really inline with the spec's 
idea of access token duration?

regards,
Torsten.

Am 31.05.2011 19:41, schrieb Chuck Mortimore:
> Updated in language I just sent out -- thanks.
>
> On that note, we currently return refresh_token using the implicit 
> grant type under certain controlled circumstances.   Facebook in turn 
> uses the implicit grant type, and simply issues long term access_tokens.
>
> Are there any strong objections to adding optional support for 
> referesh_token on the implicit grant along with security considerations?
>
> -cmort
>
>
> On 5/24/11 10:30 PM, "torsten@lodderstedt.net" 
>  wrote:
>
>     Hi Chuck,
>
>     one of the advantages of the authz code grant type is refresh
>     token support. I would suggest to mention this in the comparision
>     with the implicit grant type.
>
>     regards,
>     Torsten.
>     Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>
>     -----Original Message-----
>     From: Chuck Mortimore 
>     Sender: oauth-bounces@ietf.org
>     Date: Tue, 24 May 2011 17:30:05
>     To: oauth@ietf.org@ietf.org>
>     Subject: [OAUTH-WG] Text for Native Applications
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org
>     https://www.ietf.org/mailman/listinfo/oauth
>
>

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



  
    
  
  
    I think refresh token support in implicit grant is worth a
    discussion. The main difference to authz code from a security
    perspective is that the refresh token as long term credential could
    be disclosed via the user agent's URL history. In my perception,
    this fact and the assumption that user agent clients (the primary
    audience of this grant type) are not able to securely store referesh
    tokens are the reasons why the spec currently does not support it. 
    
    
    
    wrt Facebook's implementation: is this really inline with the spec's
    idea of access token duration? 
    
    
    
    regards,
    
    Torsten.
    
    
    
    Am 31.05.2011 19:41, schrieb Chuck Mortimore:
    
    
      Re: AW: [OAUTH-WG] Text for Native Applications
      Updated
          in language I just sent out – thanks.
    
          
    
          On that note, we currently return refresh_token using the
          implicit grant type under certain controlled circumstances.
            Facebook in turn uses the implicit grant type, and simply
          issues long term access_tokens.    
    
          
    
          Are there any strong objections to adding optional support for
          referesh_token on the implicit grant along with security
          considerations?
    
          
    
          -cmort 
    
          
    
          
    
          On 5/24/11 10:30 PM, "torsten@lodderstedt.net"
          <torsten@lodderstedt.net>
          wrote:
    
          
    
            
      
    Hi Chuck,
    
            
    
            one of the advantages of the authz code grant type is
            refresh token support. I would suggest to mention this in
            the comparision with the implicit grant type.
    
            
    
            regards,
    
            Torsten.
    
            Gesendet mit BlackBerry® Webmail von Telekom Deutschland 
    
            
    
            -----Original Message-----
    
            From: Chuck Mortimore <cmortimore@salesforce.com>
    
            Sender: oauth-bounces@ietf.org
    
            Date: Tue, 24 May 2011 17:30:05
    
            To: oauth@ietf.org<oauth@ietf.org>
    
            Subject: [OAUTH-WG] Text for Native Applications
    
            
    
            _______________________________________________
    
            OAuth mailing list
    
            OAuth@ietf.org
    
            https://www.ietf.org/mailman/listinfo/oauth
    
            
    
            
    
          
    
    
    
  


--------------050303020509010608060703--

From torsten@lodderstedt.net  Tue May 31 14:08: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 81061E0901; Tue, 31 May 2011 14:08:38 -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 YU2-+IV8BoVK; Tue, 31 May 2011 14:08:38 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id B4837E08FB; Tue, 31 May 2011 14:08:37 -0700 (PDT)
Received: from [79.253.20.182] (helo=[192.168.71.27]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRWB2-00087F-8Z; Tue, 31 May 2011 23:08:36 +0200
Message-ID: <4DE558D4.8050501@lodderstedt.net>
Date: Tue, 31 May 2011 23:08:36 +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 Campbell 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>		 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050700010805050406060105"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth-bounces@ietf.org" , "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: Tue, 31 May 2011 21:08:38 -0000

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

the security considerations section does recommend to not automatically 
process repeated authorizations without validating the client's identity

The authorization server SHOULD NOT automatically, without active
    end-user interaction, process repeated authorization requests without
    authenticating the client or relying on other measures to ensure the
    repeated request comes from a valid client and not an impersonator.

BTW: I would suggest to rephrase the last part to "... comes from the 
same client as authorized by the original authorization request"

regards,
Torsten.

Am 31.05.2011 21:06, schrieb Brian Campbell:
>
>
> On Tue, May 31, 2011 at 12:00 PM, Doug Tangren  > wrote:
>
>
>     I think there is still a usability issue with the implicit flow in
>     general where there is no way in the spec to obtain an access
>     token without re-asking the user for authorization a second time
>     even if the user has already authorized your client.
>
>
> I don't think there is anything in the spec (correct me if I'm wrong) 
> saying that an AS couldn't "remember" a user's authorization for a 
> given client using implicit so as to avoid subsequent prompts for 
> authorization?
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



  
    
  
  
    the security considerations section does recommend to not
    automatically process repeated authorizations without validating the
    client's identity
    
    
    The authorization server SHOULD NOT automatically, without active
   end-user interaction, process repeated authorization requests without
   authenticating the client or relying on other measures to ensure the
   repeated request comes from a valid client and not an impersonator.
    
    BTW: I would suggest to rephrase the last part to "... comes from
    the same client as authorized by the original authorization request"
    
    
    
    regards,
    
    Torsten.
    
    
    
    Am 31.05.2011 21:06, schrieb Brian Campbell:
    

    
      
    
      
    On Tue, May 31, 2011 at 12:00 PM, Doug
        Tangren <d.tangren@gmail.com>
        wrote:
    
        
    
          
    
            
    
              
    
              I think there is still a usability issue with the implicit
              flow in general where there is no way in the spec to
              obtain an access token without re-asking the user for
              authorization a second time even if the user has already
              authorized your client.
    
               
              
    
            
    
          
    
        
    
        

    
          I don't think there is anything in the spec (correct me if I'm
          wrong) saying that an AS couldn't "remember" a user's
          authorization for a given client using implicit so as to avoid
          subsequent prompts for authorization? 
    
        
    
      
    
      
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
  


--------------050700010805050406060105--

From torsten@lodderstedt.net  Tue May 31 14:17: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 207B6E0912; Tue, 31 May 2011 14:17:01 -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 EH1Q9LFSM6Zo; Tue, 31 May 2011 14:17:00 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3B463E083E; Tue, 31 May 2011 14:17:00 -0700 (PDT)
Received: from [79.253.20.182] (helo=[192.168.71.27]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QRWJ9-0006dP-9G; Tue, 31 May 2011 23:16:59 +0200
Message-ID: <4DE55ACB.1040808@lodderstedt.net>
Date: Tue, 31 May 2011 23:16:59 +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: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000903080507040700000300"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: "oauth-bounces@ietf.org" , "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: Tue, 31 May 2011 21:17:01 -0000

This is a multi-part message in MIME format.
--------------000903080507040700000300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Am 31.05.2011 20:00, schrieb Doug Tangren:
>
> -Doug Tangren
> http://lessis.me
>
>
> On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore 
> > wrote:
>
>     Updated in language I just sent out – thanks.
>
>     On that note, we currently return refresh_token using the implicit
>     grant type under certain controlled circumstances.   Facebook in
>     turn uses the implicit grant type, and simply issues long term
>     access_tokens.
>
>     Are there any strong objections to adding optional support for
>     referesh_token on the implicit grant along with security
>     considerations?
>
>
> I was under the impression that one should not issue a refresh_token 
> in an implicit grant flow because in order to make a refresh_token 
> request call, you'd need send client credentials including the clients 
> secret which an implicit client can not store securely.

It is possible to obtain refresh tokens using the authz code grant type 
without client authentication. So why not do the same with implicit 
grant? As long as the user authorizes the issuance of such tokens I 
don't see any problem. The refresh token is a client instance secret 
associated with the grant authorized by the end user and is issued to 
the originator of the authz request only. The problem with native 
clients is the distribution of client secrets not their aibility to 
securely store a dynamically created instance-related secret.

regards,
Torsten.


>
> I think there is still a usability issue with the implicit flow in 
> general where there is no way in the spec to obtain an access token 
> without re-asking the user for authorization a second time even if the 
> user has already authorized your client.

--------------000903080507040700000300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
    
    Am 31.05.2011 20:00, schrieb Doug Tangren:
    

    
      -Doug Tangren
    
      http://lessis.me
    
      
    
      
    
      
    On Tue, May 31, 2011 at 1:41 PM, Chuck
        Mortimore <cmortimore@salesforce.com>
        wrote:
    
        
    
          
    
            Updated
                in language I just sent out – thanks.
    
                
    
                On that note, we currently return refresh_token using
                the implicit grant type under certain controlled
                circumstances.   Facebook in turn uses the implicit
                grant type, and simply issues long term access_tokens.
                   
    
                
    
                Are there any strong objections to adding optional
                support for referesh_token on the implicit grant along
                with security considerations?
    
        
    
        

    
          I was under the impression that one should not issue a
          refresh_token in an implicit grant flow because in order to
          make a refresh_token request call, you'd need send client
          credentials including the clients secret which an implicit
          client can not store securely. 
    
        
    
      
    
    
    
    
    
    It is possible to obtain refresh tokens using the authz code grant
    type without client authentication. So why not do the same with
    implicit grant? As long as the user authorizes the issuance of such
    tokens I don't see any problem. The refresh token is a client
    instance secret associated with the grant authorized by the end user
    and is issued to the originator of the authz request only. The
    problem with native clients is the distribution of client secrets
    not their aibility to securely store a dynamically created
    instance-related secret. 
    
    
    
    regards,
    
    Torsten.
    
    
    
    
    
    
    
      
    
        
    
          
    
          I think there is still a usability issue with the implicit
          flow in general where there is no way in the spec to obtain an
          access token without re-asking the user for authorization a
          second time even if the user has already authorized your
          client.
    
           
    
      
    
    
    
  


--------------000903080507040700000300--

From dnelson@elbrys.com  Tue May 31 14:17: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 ADAB4E0688 for ; Tue, 31 May 2011 14:17:21 -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 HN0DaOhN1Yla for ; Tue, 31 May 2011 14:17:20 -0700 (PDT)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with SMTP id 7B542E083E for ; Tue, 31 May 2011 14:17:15 -0700 (PDT)
Received: from mail-yw0-f43.google.com ([209.85.213.43]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTeVa1KRGJzYoztuR3AxYeu/mD+wL/h7q@postini.com; Tue, 31 May 2011 14:17:15 PDT
Received: by ywa6 with SMTP id 6so2676667ywa.16 for ; Tue, 31 May 2011 14:17:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.18.225 with SMTP id l61mr7444859yhl.519.1306876627344; Tue, 31 May 2011 14:17:07 -0700 (PDT)
Received: by 10.236.161.40 with HTTP; Tue, 31 May 2011 14:17:07 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 31 May 2011 17:17:07 -0400
Message-ID: 
From: Dave Nelson 
To: "oauth@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Tue, 31 May 2011 21:17:21 -0000

This issue has likely been discussed "long ago", but I'd like to
potentially re-open the discussion.

> =A0=A0=A0o =A0Native applications that use the authorization code grant t=
ype flow
> SHOULD do so without client password credentials, due to their inability =
to
> keep those credentials confidential.

I understand that, in a strict sense, a software component running in
a non-embedded environment cannot be guaranteed to maintain the
confidentiality of credentials entrusted to it.  On the other hand, I
think this proscription may go too far.  All security is a matter of
providing sufficient counter-measures to identified attack vectors,
and I believe that native applications probably *can* keep secrets
well enough to resist the types of attacks they are likely to be
subject to in certain specified use cases.  Perhaps the "SHOULD"
wording leaves enough room for implementations with credential hiding
mechanisms that are deemed appropriate in a given use scenario to
include the use of a client password.  I think it would be more
accurate to say that native applications SHOULD NOT include the client
password in the authorization grant type flow, *unless* the design of
the application can provide a sufficient level of protection for said
password storage to meet the risks identified in association with the
deployment scenario.

Thoughts?

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

From ietf@adambarth.com  Tue May 31 14:41: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 7172DE06CF for ; Tue, 31 May 2011 14:41:42 -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 pbMh9mD9k2YC for ; Tue, 31 May 2011 14:41:40 -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 7D9B8E0854 for ; Tue, 31 May 2011 14:41:40 -0700 (PDT)
Received: by yic13 with SMTP id 13so2683272yic.31 for ; Tue, 31 May 2011 14:41:40 -0700 (PDT)
Received: by 10.236.186.38 with SMTP id v26mr7496960yhm.415.1306878099883; Tue, 31 May 2011 14:41:39 -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 c63sm480577yhe.32.2011.05.31.14.41.38 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 14:41:38 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2686927gyf.31 for ; Tue, 31 May 2011 14:41:38 -0700 (PDT)
Received: by 10.91.96.2 with SMTP id y2mr5374327agl.179.1306878098118; Tue, 31 May 2011 14:41:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 14:41:08 -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>  
From: Adam Barth 
Date: Tue, 31 May 2011 14:41:08 -0700
Message-ID: 
To: Skylar Woodward 
Content-Type: text/plain; charset=windows-1252
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: Tue, 31 May 2011 21:41:42 -0000

You haven't described a problem.

On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  wrote:
> First we should agree on a common understanding of the spec. The reason w=
hy age works with unsynchronized clocks is that the client determines issue=
_date based on the time when it receives the token over the wire. This depe=
nds on the server and client both recording time this way and for the trans=
mission of the token to be be not longer than the margin of error for valid=
ating age. Are we agreed on this understanding?

That's not correct.

The age allows the server to protect against replay attacks in bounded
memory.  With unbounded memory, the server can just remember every
nonce it has ever seen associated with a given key and reject replays.
 With bounded memory, the server eventually needs to evict some of
these nonces due to memory pressure.  The age value lets the server
reject the nonces with the smallest age values first.  The server then
rejects any messages with age values smaller than (or equal to) the
largest age value it has ever evicted for the given key.

Notice that neither clock synchronization nor transmission time plays
a role in that implementation.

> The easiest case for me to explain here is client credentials because I h=
ave to assume you've built and registered a Twitter app at some point (or s=
imilar OAuth 1.0a app). You registered your app on the site and were issued=
 a client_id and client_secret (called consumer_key and consumer_secret in =
1.0). You then embedded these values in your client (they were not issued p=
rogrammatically to your app). Assuming the MAC token algorithm is used then=
 for establishing client identity (originally one of the uses we, the worki=
ng group, hoped MAC would cover) how then will your client determine issue =
date?

I recommend the date at which the developer obtained the credential
from Twitter because that is the date when the credential was issued.

> After we can establish where you're at on the two above points I'll conti=
nue with the explanation. But as a preview, the next points would be:
>
> - If issue_date comes form the server, how is it translated to the client=
?

The issue_date does not come from the server.

> - If you use a server provided issue_date, how do you then translate that=
 a value relative to the local unsyncronized clock?

The server does not provide the issue_date.

> - If your answer to that is to also provide the current server time to th=
e client so the offset on the server provided issue_date can be calculated =
what is the difference between all of these values and just using timestamp=
?

My answer is not to provide the current server time to the client.

Kind regards,
Adam


> So don't get wrapped up in those 3 questions until we establish your cont=
extual understanding of the first two paragraphs. Feel free to also respond=
 to me off the list so we don't trouble everyone else with us getting on th=
e same page (the reason, I thought, why a Skype call would be more efficien=
t and painless). I do think my explanations all have been very clear thus f=
ar. There must be a contextual confusion that is keeping us from a common u=
nderstanding of the terminology or the use cases.
>
> skylar
>
>
> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>
>> I'm not sure we need a Skype call. =A0Can you explain the trouble caused
>> by age clearly? =A0I didn't understand your previous explanation. =A0The
>> more concrete you can be, the better.
>>
>> Thanks,
>> Adam
>>
>>
>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  wrote=
:
>>> It seems we're failing to communicate. Or you're not understanding my u=
se cases. Age doesn't "just" work. It only works for a limited number of us=
es cases that must include all of yours - and it is brittle at that. It doe=
sn't work for any of our uses cases (where the client can't know issue_date=
 w/o the server telling it - in which case we have the equivalent problem a=
s timestamp).
>>>
>>> If you'd like to talk this out over Skype I'm happy to do that, so I ca=
n help you understand why age doesn't work.
>>>
>>>
>>>
>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>
>>>> Timestamps don't work when the client doesn't have a synchronized
>>>> clock. =A0It's true that a client could synchronize its clock with the
>>>> network, but our implementation experience is that many clients don't
>>>> for a variety of reasons. =A0That means that age better because, you
>>>> know, it works.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  wr=
ote:
>>>>> I don't think you read my first message on the topic (or I wrote too =
much).
>>>>>
>>>>> Age is fragile because if the clock changes between issue_date and th=
e time of submission, it will fail. We know many people don't have synchron=
ized clocks, but using age only solves this problem if two assumptions hold=
 true:
>>>>>
>>>>> 1) the client is able to guess the issue_date the server is using bas=
ed on the time the credential was issued
>>>>> 2) the client system clock doesn't change between issue date and subm=
ission time.
>>>>>
>>>>> Timestamp has neither of these issues because the client can always i=
nquire about network time and can effectively correct for inaccuracies in t=
he device timekeeping system.
>>>>>
>>>>> Regarding the first assumption, this fails when a token might be re-i=
ssued between devices. An example is that we use MAC token for the client c=
redentials, which are issued when a developer registers an application. The=
 client has no way of determining on its own when the value was actually is=
sued (unless we communicate that on the developer website and force users t=
o embed that with client_id, which adds usability issues of users copying a=
nd entering string date values correctly). The same is actually true for al=
l of our OAuth access tokens because we reissue tokens to the same client_i=
d if they were previously issued and are still valid. (The client would thu=
s think the issue_date was now() when if fact it was the time of the first =
issue for client_id+scope+grantor_id). Thus, age is really just a convolute=
d way of trying to communicate the device system offset:
>>>>>
>>>>> =A0 =A0 =A0 =A0local_offset =3D current_server_time - current_device_=
time
>>>>> =A0 =A0 =A0 =A0age =3D current_device_time - (server_issue_date-local=
_offset)
>>>>>
>>>>> Since the protocol doesn't currently allow for server_issue_date to b=
e given with tokens, thus age currently can't have the resilience that time=
stamp does. It also forces servers to issue new tokens on demand just to ma=
ke the convoluted age system work (rather than reuse existing valid tokens)=
. Or, you have to modify the protocol to add server_issue_date and current_=
server_time into the token-issue exchange - eg, more complexity.
>>>>>
>>>>> Timestamp is simpler, proven, it and it has a solution for your use c=
ase of unsyncronized clocks.
>>>>>
>>>>> skylar
>>>>>
>>>>>
>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>
>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't
>>>>>> have synchronized clocks, for a wide variety of reasons. =A0I guess =
I
>>>>>> don't really understand why you view age as problematic. =A0You
>>>>>> reference "fragility of using time-since-credentials-issued" but you
>>>>>> don't say what exactly is fragile about it. =A0There's nothing
>>>>>> particularly complex about age, especially when using the monotonic
>>>>>> clock provided by all modern operating systems.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  =
wrote:
>>>>>>> But see, now you are specializing the use of MAC token even more - =
now it's becoming a service mainly for user-agents on home desktops? This i=
s further for the original goal of making MAC as flexible is possible. In t=
his case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_RE=
PLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>>>>>
>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your o=
ffset technique and is more: reliable, straightforward, flexible.
>>>>>>>
>>>>>>> User agents that care about creating robust behavior for home deskt=
ops or mobiles (presumably of users and OS not yet sophisticated enough to =
check network time on their own) should be advised to do clock correction o=
n their own (by pinging a time service) and trusting the device clock alone=
.
>>>>>>>
>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>
>>>>>>> I'd also like to hear a convincing argument from the Mozilla co-aut=
hors about why they think that age is more resilient than the above (I beli=
eve it is not) and further more why they would find the above unattractive =
or difficult to implement in a modern user-agent.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> skylar
>>>>>>>
>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 ...=
 -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>> skylar woodward
>>>>>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiva
>>>>>>>
>>>>>>>
>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>
>>>>>>>> Any kind of clock sync requirement for user-agents (basically, hom=
e desktops) it completely impractical. The added complexity pales in compar=
ison to the difficulty of trying to use timestamps and any kind of clock sy=
nc. No window will be big enough as experience shows some users have closes=
 that are off by more than an hour and a half.
>>>>>>>>
>>>>>>>> The issue here is who is this being optimized for. Server-to-serve=
r communication should simply use TLS for privacy and MITM protection on to=
p of MAC instead of using nonces to prevent replay. The whole point of this=
 kind of replay protection is when TLS is not available.
>>>>>>>>
>>>>>>>> I think a better approach is to simply make checking the nonce opt=
ional when TLS is used.
>>>>>>>>
>>>>>>>> EHL
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B=
ehalf
>>>>>>>>> Of Peter Wolanin
>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>> To: Skylar Woodward
>>>>>>>>> Cc: OAuth WG
>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>>>>>>>>
>>>>>>>>> I am also concerned by the fragility of using time-since-credenti=
als-issued,
>>>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>>>
>>>>>>>>> I think it would be preferable to always require a timestamp as p=
art of the
>>>>>>>>> authorization header, and maybe even include in the spec a maximu=
m time
>>>>>>>>> difference between client and server (e.g. 900 seconds) that can =
be
>>>>>>>>> tolerated. =A0This makes generating the nonce easier also, since =
the value need
>>>>>>>>> to longer be unique over all time.
>>>>>>>>>
>>>>>>>>> We have such rules in place for an HMAC-based authentication syst=
em we
>>>>>>>>> use. =A0Once in a while a client has a local clock so far out of =
sync that there is an
>>>>>>>>> issue, but it's rare.
>>>>>>>>>
>>>>>>>>> -Peter
>>>>>>>>>
>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>>>>>> wrote:
>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>
>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>
>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>> 
>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC tok=
en
>>>>>>>>>>>
>>>>>>>>>>> So after discussing this today and reflecting on it a bit, I wo=
uld suggest that
>>>>>>>>> nonce simply be the "unique value" (as it is so named) without fu=
rther
>>>>>>>>> requirements. It might be suggested that this be composed of an
>>>>>>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>>>>>>> "recommended" practice. If the expectation is that very few if an=
y providers
>>>>>>>>> would actually check the timestamp (or moreover, the nonce itself=
), why add
>>>>>>>>> terminology in the draft that requires it? Developers are doing e=
xtra
>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no pa=
yoff or
>>>>>>>>> added security.
>>>>>>>>>>>
>>>>>>>>>>> I'm sending this feedback based on having implemented the v3-5 =
changes
>>>>>>>>> last night (for both client credentials and requests w/ access to=
kens). After
>>>>>>>>> the changes, the nonce creation is now the most complicated part =
of the
>>>>>>>>> normalized request string and yet these changes offer the least b=
enefit.
>>>>>>>>> What's most important is that nonces are unique on each request f=
or an ID.
>>>>>>>>>>>
>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>
>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time based =
on
>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o knowle=
dge of
>>>>>>>>>>> the software storing the dates) then time will also fail. Assum=
ing
>>>>>>>>>>> that a user with a bad clock (of by hours or more) will never f=
ix it
>>>>>>>>>>> and actually encourages bad user behavior (don't fix your clock=
 or
>>>>>>>>>>> Twitterbot will stop working!). Though we say that timezones wo=
n't
>>>>>>>>>>> bring about the situation of changed clock, I'd be to differ. M=
any
>>>>>>>>>>> users aren't savvy enough to change time zone, but just adjust =
the
>>>>>>>>>>> time to local time anyway. Users who are more likely to get it =
right
>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>
>>>>>>>>>>> - What if the token wasn't originally issued programmatically? =
In this case,
>>>>>>>>> the issue time has to be obtained from the server and stored on t=
he client
>>>>>>>>> then you have the same problem as with a timestamp - the client c=
lock is not
>>>>>>>>> sync'd to the server clock and there is no adjustment. You want t=
his to apply
>>>>>>>>> to uses outside of just OAuth, but now requiring the client to be=
 able to
>>>>>>>>> determine an issue time based on when it receives an HTTP request
>>>>>>>>> necessarily limits the types of token flows for which this can be=
 used.
>>>>>>>>>>>
>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a develope=
r, but it is
>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it i=
s actually more of a
>>>>>>>>> recording of "my personal clock offset value" but obfuscated seve=
ral times
>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>
>>>>>>>>>>> - This implementation assumes software programs use the compute=
r
>>>>>>>>> internal clock exclusively for timestamp. A robust program that i=
s dependent
>>>>>>>>> on accurate timestamps would ping the origin server (or similar t=
rusted time
>>>>>>>>> authority) to ask it the current time. Then it could store a "my =
device clock
>>>>>>>>> offset" value for the lifetime of the program execution. All requ=
ests needing
>>>>>>>>> timestamp would be adjusted accordingly. For age, if the clock is=
 changed
>>>>>>>>> since the stored issue_date, the problem can't be corrected in th=
is manner.
>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>
>>>>>>>>>>> All in all, this seems like a misguided but well-intentioned at=
tempt to get
>>>>>>>>> around end-user issues of mis-set clocks. It feels like a hack an=
d it certainly
>>>>>>>>> isn't a foolproof solution. The more I think about the implicatio=
ns of the age
>>>>>>>>> parameter, the less I like it. Timestamp has been used for many y=
ears in the
>>>>>>>>> industry and with reasonable success in relevant applications. If=
 we change to
>>>>>>>>> a new way of trying to sync on time I think we run a greater risk=
 of stumbling
>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>
>>>>>>>>>>> I recommend the requirement of an age (or timestamp for that ma=
tter)
>>>>>>>>> be dropped from the nonce construction. For providers that deem i=
t
>>>>>>>>> valuable, timestamp can be an optional value (either as part of t=
he nonce or
>>>>>>>>> the overall header, as before).
>>>>>>>>>>>
>>>>>>>>>>> skylar
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>
>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as "example=
.net"
>>>>>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>>>>>>>
>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly add=
resses my
>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>
>>>>>>>>>>>> skylar
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing lis=
t for the
>>>>>>>>> time being, I wanted to give a quick update to those who have bee=
n
>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is now=
 a
>>>>>>>>> general purpose HTTP authentication scheme. It does include an OA=
uth 2.0
>>>>>>>>> binding which is described in less than a page. One suggestion wo=
uld be to
>>>>>>>>> move section 5.1 into the OAuth specification and drop all the OA=
uth 2.0 text
>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session coo=
kies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Removed request URI query normalization. The new draft uses=
 the
>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the need=
 for
>>>>>>>>> clock sync.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text to =
be
>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Added issuer attribute for identifying the source of the cr=
edentials as
>>>>>>>>> an additional protection.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0Acqu=
ia. Inc.
>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>
>>>>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>>>>>>> _______________________________________________
>>>>>>>>> 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 phil.hunt@oracle.com  Tue May 31 15:35: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 36805E06FA for ; Tue, 31 May 2011 15:35:24 -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 G5OKfptfADqc for ; Tue, 31 May 2011 15:35:22 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id D8349E066A for ; Tue, 31 May 2011 15:35:21 -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 p4VMZIk2026785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 22:35:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4VMZHGm020411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 22:35:18 GMT
Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4VMZCG3012331; Tue, 31 May 2011 17:35:12 -0500
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 May 2011 15:35:11 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Phil Hunt 
In-Reply-To: 
Date: Tue, 31 May 2011 15:35:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.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>   
To: Adam Barth 
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.0A090209.4DE56D28.0100:SCFMA922111,ss=1,fgs=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: Tue, 31 May 2011 22:35:24 -0000

There seems to be a demonstrated need for both age and timestamp tokens.

The list has 2 separate cases with 2 separate proposals that do not =
solve all cases.

Can we at least agree that neither proposal works in all cases?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-05-31, at 2:41 PM, Adam Barth wrote:

> You haven't described a problem.
>=20
> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  =
wrote:
>> First we should agree on a common understanding of the spec. The =
reason why age works with unsynchronized clocks is that the client =
determines issue_date based on the time when it receives the token over =
the wire. This depends on the server and client both recording time this =
way and for the transmission of the token to be be not longer than the =
margin of error for validating age. Are we agreed on this understanding?
>=20
> That's not correct.
>=20
> The age allows the server to protect against replay attacks in bounded
> memory.  With unbounded memory, the server can just remember every
> nonce it has ever seen associated with a given key and reject replays.
> With bounded memory, the server eventually needs to evict some of
> these nonces due to memory pressure.  The age value lets the server
> reject the nonces with the smallest age values first.  The server then
> rejects any messages with age values smaller than (or equal to) the
> largest age value it has ever evicted for the given key.
>=20
> Notice that neither clock synchronization nor transmission time plays
> a role in that implementation.
>=20
>> The easiest case for me to explain here is client credentials because =
I have to assume you've built and registered a Twitter app at some point =
(or similar OAuth 1.0a app). You registered your app on the site and =
were issued a client_id and client_secret (called consumer_key and =
consumer_secret in 1.0). You then embedded these values in your client =
(they were not issued programmatically to your app). Assuming the MAC =
token algorithm is used then for establishing client identity =
(originally one of the uses we, the working group, hoped MAC would =
cover) how then will your client determine issue date?
>=20
> I recommend the date at which the developer obtained the credential
> from Twitter because that is the date when the credential was issued.
>=20
>> After we can establish where you're at on the two above points I'll =
continue with the explanation. But as a preview, the next points would =
be:
>>=20
>> - If issue_date comes form the server, how is it translated to the =
client?
>=20
> The issue_date does not come from the server.
>=20
>> - If you use a server provided issue_date, how do you then translate =
that a value relative to the local unsyncronized clock?
>=20
> The server does not provide the issue_date.
>=20
>> - If your answer to that is to also provide the current server time =
to the client so the offset on the server provided issue_date can be =
calculated what is the difference between all of these values and just =
using timestamp?
>=20
> My answer is not to provide the current server time to the client.
>=20
> Kind regards,
> Adam
>=20
>=20
>> So don't get wrapped up in those 3 questions until we establish your =
contextual understanding of the first two paragraphs. Feel free to also =
respond to me off the list so we don't trouble everyone else with us =
getting on the same page (the reason, I thought, why a Skype call would =
be more efficient and painless). I do think my explanations all have =
been very clear thus far. There must be a contextual confusion that is =
keeping us from a common understanding of the terminology or the use =
cases.
>>=20
>> skylar
>>=20
>>=20
>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>=20
>>> I'm not sure we need a Skype call.  Can you explain the trouble =
caused
>>> by age clearly?  I didn't understand your previous explanation.  The
>>> more concrete you can be, the better.
>>>=20
>>> Thanks,
>>> Adam
>>>=20
>>>=20
>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  =
wrote:
>>>> It seems we're failing to communicate. Or you're not understanding =
my use cases. Age doesn't "just" work. It only works for a limited =
number of uses cases that must include all of yours - and it is brittle =
at that. It doesn't work for any of our uses cases (where the client =
can't know issue_date w/o the server telling it - in which case we have =
the equivalent problem as timestamp).
>>>>=20
>>>> If you'd like to talk this out over Skype I'm happy to do that, so =
I can help you understand why age doesn't work.
>>>>=20
>>>>=20
>>>>=20
>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>=20
>>>>> Timestamps don't work when the client doesn't have a synchronized
>>>>> clock.  It's true that a client could synchronize its clock with =
the
>>>>> network, but our implementation experience is that many clients =
don't
>>>>> for a variety of reasons.  That means that age better because, you
>>>>> know, it works.
>>>>>=20
>>>>> Adam
>>>>>=20
>>>>>=20
>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward =
 wrote:
>>>>>> I don't think you read my first message on the topic (or I wrote =
too much).
>>>>>>=20
>>>>>> Age is fragile because if the clock changes between issue_date =
and the time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:
>>>>>>=20
>>>>>> 1) the client is able to guess the issue_date the server is using =
based on the time the credential was issued
>>>>>> 2) the client system clock doesn't change between issue date and =
submission time.
>>>>>>=20
>>>>>> Timestamp has neither of these issues because the client can =
always inquire about network time and can effectively correct for =
inaccuracies in the device timekeeping system.
>>>>>>=20
>>>>>> Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the =
client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:
>>>>>>=20
>>>>>>        local_offset =3D current_server_time - current_device_time
>>>>>>        age =3D current_device_time - =
(server_issue_date-local_offset)
>>>>>>=20
>>>>>> Since the protocol doesn't currently allow for server_issue_date =
to be given with tokens, thus age currently can't have the resilience =
that timestamp does. It also forces servers to issue new tokens on =
demand just to make the convoluted age system work (rather than reuse =
existing valid tokens). Or, you have to modify the protocol to add =
server_issue_date and current_server_time into the token-issue exchange =
- eg, more complexity.
>>>>>>=20
>>>>>> Timestamp is simpler, proven, it and it has a solution for your =
use case of unsyncronized clocks.
>>>>>>=20
>>>>>> skylar
>>>>>>=20
>>>>>>=20
>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>=20
>>>>>>> I can't speak for Mozilla, but I can tell you that many folks =
don't
>>>>>>> have synchronized clocks, for a wide variety of reasons.  I =
guess I
>>>>>>> don't really understand why you view age as problematic.  You
>>>>>>> reference "fragility of using time-since-credentials-issued" but =
you
>>>>>>> don't say what exactly is fragile about it.  There's nothing
>>>>>>> particularly complex about age, especially when using the =
monotonic
>>>>>>> clock provided by all modern operating systems.
>>>>>>>=20
>>>>>>> Adam
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward =
 wrote:
>>>>>>>> But see, now you are specializing the use of MAC token even =
more - now it's becoming a service mainly for user-agents on home =
desktops? This is further for the original goal of making MAC as =
flexible is possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>>>>>>>=20
>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as =
your offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>=20
>>>>>>>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>>>>>>>=20
>>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>>=20
>>>>>>>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> skylar
>>>>>>>>=20
>>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 =
... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>>> skylar woodward
>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>=20
>>>>>>>>> Any kind of clock sync requirement for user-agents (basically, =
home desktops) it completely impractical. The added complexity pales in =
comparison to the difficulty of trying to use timestamps and any kind of =
clock sync. No window will be big enough as experience shows some users =
have closes that are off by more than an hour and a half.
>>>>>>>>>=20
>>>>>>>>> The issue here is who is this being optimized for. =
Server-to-server communication should simply use TLS for privacy and =
MITM protection on top of MAC instead of using nonces to prevent replay. =
The whole point of this kind of replay protection is when TLS is not =
available.
>>>>>>>>>=20
>>>>>>>>> I think a better approach is to simply make checking the nonce =
optional when TLS is used.
>>>>>>>>>=20
>>>>>>>>> EHL
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf
>>>>>>>>>> Of Peter Wolanin
>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - =
MAC token
>>>>>>>>>>=20
>>>>>>>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>>>>>>>> and also the added complexity of specifying this =
construction.
>>>>>>>>>>=20
>>>>>>>>>> I think it would be preferable to always require a timestamp =
as part of the
>>>>>>>>>> authorization header, and maybe even include in the spec a =
maximum time
>>>>>>>>>> difference between client and server (e.g. 900 seconds) that =
can be
>>>>>>>>>> tolerated.  This makes generating the nonce easier also, =
since the value need
>>>>>>>>>> to longer be unique over all time.
>>>>>>>>>>=20
>>>>>>>>>> We have such rules in place for an HMAC-based authentication =
system we
>>>>>>>>>> use.  Once in a while a client has a local clock so far out =
of sync that there is an
>>>>>>>>>> issue, but it's rare.
>>>>>>>>>>=20
>>>>>>>>>> -Peter
>>>>>>>>>>=20
>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward =

>>>>>>>>>> wrote:
>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>=20
>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>=20
>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>>> 
>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC =
token
>>>>>>>>>>>>=20
>>>>>>>>>>>> So after discussing this today and reflecting on it a bit, =
I would suggest that
>>>>>>>>>> nonce simply be the "unique value" (as it is so named) =
without further
>>>>>>>>>> requirements. It might be suggested that this be composed of =
an
>>>>>>>>>> random+timestamp (not age) value, but that seems more of a =
MAY or
>>>>>>>>>> "recommended" practice. If the expectation is that very few =
if any providers
>>>>>>>>>> would actually check the timestamp (or moreover, the nonce =
itself), why add
>>>>>>>>>> terminology in the draft that requires it? Developers are =
doing extra
>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with =
no payoff or
>>>>>>>>>> added security.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I'm sending this feedback based on having implemented the =
v3-5 changes
>>>>>>>>>> last night (for both client credentials and requests w/ =
access tokens). After
>>>>>>>>>> the changes, the nonce creation is now the most complicated =
part of the
>>>>>>>>>> normalized request string and yet these changes offer the =
least benefit.
>>>>>>>>>> What's most important is that nonces are unique on each =
request for an ID.
>>>>>>>>>>>>=20
>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>=20
>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time =
based on
>>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>>>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>>>>>>>> that a user with a bad clock (of by hours or more) will =
never fix it
>>>>>>>>>>>> and actually encourages bad user behavior (don't fix your =
clock or
>>>>>>>>>>>> Twitterbot will stop working!). Though we say that =
timezones won't
>>>>>>>>>>>> bring about the situation of changed clock, I'd be to =
differ. Many
>>>>>>>>>>>> users aren't savvy enough to change time zone, but just =
adjust the
>>>>>>>>>>>> time to local time anyway. Users who are more likely to get =
it right
>>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, =
etc.)
>>>>>>>>>>>>=20
>>>>>>>>>>>> - What if the token wasn't originally issued =
programmatically? In this case,
>>>>>>>>>> the issue time has to be obtained from the server and stored =
on the client
>>>>>>>>>> then you have the same problem as with a timestamp - the =
client clock is not
>>>>>>>>>> sync'd to the server clock and there is no adjustment. You =
want this to apply
>>>>>>>>>> to uses outside of just OAuth, but now requiring the client =
to be able to
>>>>>>>>>> determine an issue time based on when it receives an HTTP =
request
>>>>>>>>>> necessarily limits the types of token flows for which this =
can be used.
>>>>>>>>>>>>=20
>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a =
developer, but it is
>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, =
it is actually more of a
>>>>>>>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>>=20
>>>>>>>>>>>> - This implementation assumes software programs use the =
computer
>>>>>>>>>> internal clock exclusively for timestamp. A robust program =
that is dependent
>>>>>>>>>> on accurate timestamps would ping the origin server (or =
similar trusted time
>>>>>>>>>> authority) to ask it the current time. Then it could store a =
"my device clock
>>>>>>>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>>>>>>>> timestamp would be adjusted accordingly. For age, if the =
clock is changed
>>>>>>>>>> since the stored issue_date, the problem can't be corrected =
in this manner.
>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>=20
>>>>>>>>>>>> All in all, this seems like a misguided but =
well-intentioned attempt to get
>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a =
hack and it certainly
>>>>>>>>>> isn't a foolproof solution. The more I think about the =
implications of the age
>>>>>>>>>> parameter, the less I like it. Timestamp has been used for =
many years in the
>>>>>>>>>> industry and with reasonable success in relevant =
applications. If we change to
>>>>>>>>>> a new way of trying to sync on time I think we run a greater =
risk of stumbling
>>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for =
that matter)
>>>>>>>>>> be dropped from the nonce construction. For providers that =
deem it
>>>>>>>>>> valuable, timestamp can be an optional value (either as part =
of the nonce or
>>>>>>>>>> the overall header, as before).
>>>>>>>>>>>>=20
>>>>>>>>>>>> skylar
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly =
addresses my
>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> =
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing =
list for the
>>>>>>>>>> time being, I wanted to give a quick update to those who have =
been
>>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is =
now a
>>>>>>>>>> general purpose HTTP authentication scheme. It does include =
an OAuth 2.0
>>>>>>>>>> binding which is described in less than a page. One =
suggestion would be to
>>>>>>>>>> move section 5.1 into the OAuth specification and drop all =
the OAuth 2.0 text
>>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session =
cookies.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Removed request URI query normalization. The new draft =
uses the
>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the =
need for
>>>>>>>>>> clock sync.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text =
to be
>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of =
the credentials as
>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. =
Inc.
>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>=20
>>>>>>>>>> "Get a free, hosted Drupal 7 site: =
http://www.drupalgardens.com"
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>=20
>>=20
>>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From ietf@adambarth.com  Tue May 31 15:49: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 B33BFE0731 for ; Tue, 31 May 2011 15:49:41 -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 sGpWK1mntWXm for ; Tue, 31 May 2011 15:49:39 -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 9765BE078B for ; Tue, 31 May 2011 15:49:39 -0700 (PDT)
Received: by yxk30 with SMTP id 30so2707465yxk.31 for ; Tue, 31 May 2011 15:49:39 -0700 (PDT)
Received: by 10.151.86.4 with SMTP id o4mr5455585ybl.339.1306882178854; Tue, 31 May 2011 15:49:38 -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 o13sm215795ybk.4.2011.05.31.15.49.37 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 15:49:37 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2713164gyf.31 for ; Tue, 31 May 2011 15:49:37 -0700 (PDT)
Received: by 10.91.207.26 with SMTP id j26mr5390996agq.206.1306882177126; Tue, 31 May 2011 15:49:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 15:49:07 -0700 (PDT)
In-Reply-To: <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com>
From: Adam Barth 
Date: Tue, 31 May 2011 15:49:07 -0700
Message-ID: 
To: Phil Hunt 
Content-Type: text/plain; charset=windows-1252
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: Tue, 31 May 2011 22:49:41 -0000

What use case isn't addressed by age?  No one has actually articulated it.

Adam


On Tue, May 31, 2011 at 3:35 PM, Phil Hunt  wrote:
> There seems to be a demonstrated need for both age and timestamp tokens.
>
> The list has 2 separate cases with 2 separate proposals that do not solve=
 all cases.
>
> Can we at least agree that neither proposal works in all cases?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>
>> You haven't described a problem.
>>
>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  wrote=
:
>>> First we should agree on a common understanding of the spec. The reason=
 why age works with unsynchronized clocks is that the client determines iss=
ue_date based on the time when it receives the token over the wire. This de=
pends on the server and client both recording time this way and for the tra=
nsmission of the token to be be not longer than the margin of error for val=
idating age. Are we agreed on this understanding?
>>
>> That's not correct.
>>
>> The age allows the server to protect against replay attacks in bounded
>> memory. =A0With unbounded memory, the server can just remember every
>> nonce it has ever seen associated with a given key and reject replays.
>> With bounded memory, the server eventually needs to evict some of
>> these nonces due to memory pressure. =A0The age value lets the server
>> reject the nonces with the smallest age values first. =A0The server then
>> rejects any messages with age values smaller than (or equal to) the
>> largest age value it has ever evicted for the given key.
>>
>> Notice that neither clock synchronization nor transmission time plays
>> a role in that implementation.
>>
>>> The easiest case for me to explain here is client credentials because I=
 have to assume you've built and registered a Twitter app at some point (or=
 similar OAuth 1.0a app). You registered your app on the site and were issu=
ed a client_id and client_secret (called consumer_key and consumer_secret i=
n 1.0). You then embedded these values in your client (they were not issued=
 programmatically to your app). Assuming the MAC token algorithm is used th=
en for establishing client identity (originally one of the uses we, the wor=
king group, hoped MAC would cover) how then will your client determine issu=
e date?
>>
>> I recommend the date at which the developer obtained the credential
>> from Twitter because that is the date when the credential was issued.
>>
>>> After we can establish where you're at on the two above points I'll con=
tinue with the explanation. But as a preview, the next points would be:
>>>
>>> - If issue_date comes form the server, how is it translated to the clie=
nt?
>>
>> The issue_date does not come from the server.
>>
>>> - If you use a server provided issue_date, how do you then translate th=
at a value relative to the local unsyncronized clock?
>>
>> The server does not provide the issue_date.
>>
>>> - If your answer to that is to also provide the current server time to =
the client so the offset on the server provided issue_date can be calculate=
d what is the difference between all of these values and just using timesta=
mp?
>>
>> My answer is not to provide the current server time to the client.
>>
>> Kind regards,
>> Adam
>>
>>
>>> So don't get wrapped up in those 3 questions until we establish your co=
ntextual understanding of the first two paragraphs. Feel free to also respo=
nd to me off the list so we don't trouble everyone else with us getting on =
the same page (the reason, I thought, why a Skype call would be more effici=
ent and painless). I do think my explanations all have been very clear thus=
 far. There must be a contextual confusion that is keeping us from a common=
 understanding of the terminology or the use cases.
>>>
>>> skylar
>>>
>>>
>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>
>>>> I'm not sure we need a Skype call. =A0Can you explain the trouble caus=
ed
>>>> by age clearly? =A0I didn't understand your previous explanation. =A0T=
he
>>>> more concrete you can be, the better.
>>>>
>>>> Thanks,
>>>> Adam
>>>>
>>>>
>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  wro=
te:
>>>>> It seems we're failing to communicate. Or you're not understanding my=
 use cases. Age doesn't "just" work. It only works for a limited number of =
uses cases that must include all of yours - and it is brittle at that. It d=
oesn't work for any of our uses cases (where the client can't know issue_da=
te w/o the server telling it - in which case we have the equivalent problem=
 as timestamp).
>>>>>
>>>>> If you'd like to talk this out over Skype I'm happy to do that, so I =
can help you understand why age doesn't work.
>>>>>
>>>>>
>>>>>
>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>
>>>>>> Timestamps don't work when the client doesn't have a synchronized
>>>>>> clock. =A0It's true that a client could synchronize its clock with t=
he
>>>>>> network, but our implementation experience is that many clients don'=
t
>>>>>> for a variety of reasons. =A0That means that age better because, you
>>>>>> know, it works.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  =
wrote:
>>>>>>> I don't think you read my first message on the topic (or I wrote to=
o much).
>>>>>>>
>>>>>>> Age is fragile because if the clock changes between issue_date and =
the time of submission, it will fail. We know many people don't have synchr=
onized clocks, but using age only solves this problem if two assumptions ho=
ld true:
>>>>>>>
>>>>>>> 1) the client is able to guess the issue_date the server is using b=
ased on the time the credential was issued
>>>>>>> 2) the client system clock doesn't change between issue date and su=
bmission time.
>>>>>>>
>>>>>>> Timestamp has neither of these issues because the client can always=
 inquire about network time and can effectively correct for inaccuracies in=
 the device timekeeping system.
>>>>>>>
>>>>>>> Regarding the first assumption, this fails when a token might be re=
-issued between devices. An example is that we use MAC token for the client=
 credentials, which are issued when a developer registers an application. T=
he client has no way of determining on its own when the value was actually =
issued (unless we communicate that on the developer website and force users=
 to embed that with client_id, which adds usability issues of users copying=
 and entering string date values correctly). The same is actually true for =
all of our OAuth access tokens because we reissue tokens to the same client=
_id if they were previously issued and are still valid. (The client would t=
hus think the issue_date was now() when if fact it was the time of the firs=
t issue for client_id+scope+grantor_id). Thus, age is really just a convolu=
ted way of trying to communicate the device system offset:
>>>>>>>
>>>>>>> =A0 =A0 =A0 =A0local_offset =3D current_server_time - current_devic=
e_time
>>>>>>> =A0 =A0 =A0 =A0age =3D current_device_time - (server_issue_date-loc=
al_offset)
>>>>>>>
>>>>>>> Since the protocol doesn't currently allow for server_issue_date to=
 be given with tokens, thus age currently can't have the resilience that ti=
mestamp does. It also forces servers to issue new tokens on demand just to =
make the convoluted age system work (rather than reuse existing valid token=
s). Or, you have to modify the protocol to add server_issue_date and curren=
t_server_time into the token-issue exchange - eg, more complexity.
>>>>>>>
>>>>>>> Timestamp is simpler, proven, it and it has a solution for your use=
 case of unsyncronized clocks.
>>>>>>>
>>>>>>> skylar
>>>>>>>
>>>>>>>
>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>
>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don'=
t
>>>>>>>> have synchronized clocks, for a wide variety of reasons. =A0I gues=
s I
>>>>>>>> don't really understand why you view age as problematic. =A0You
>>>>>>>> reference "fragility of using time-since-credentials-issued" but y=
ou
>>>>>>>> don't say what exactly is fragile about it. =A0There's nothing
>>>>>>>> particularly complex about age, especially when using the monotoni=
c
>>>>>>>> clock provided by all modern operating systems.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wrote:
>>>>>>>>> But see, now you are specializing the use of MAC token even more =
- now it's becoming a service mainly for user-agents on home desktops? This=
 is further for the original goal of making MAC as flexible is possible. In=
 this case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_=
REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>>>>>>>
>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your=
 offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>>
>>>>>>>>> User agents that care about creating robust behavior for home des=
ktops or mobiles (presumably of users and OS not yet sophisticated enough t=
o check network time on their own) should be advised to do clock correction=
 on their own (by pinging a time service) and trusting the device clock alo=
ne.
>>>>>>>>>
>>>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>>>
>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla co-a=
uthors about why they think that age is more resilient than the above (I be=
lieve it is not) and further more why they would find the above unattractiv=
e or difficult to implement in a modern user-agent.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> skylar
>>>>>>>>>
>>>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97 .=
.. -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>>>> skylar woodward
>>>>>>>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiva
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>
>>>>>>>>>> Any kind of clock sync requirement for user-agents (basically, h=
ome desktops) it completely impractical. The added complexity pales in comp=
arison to the difficulty of trying to use timestamps and any kind of clock =
sync. No window will be big enough as experience shows some users have clos=
es that are off by more than an hour and a half.
>>>>>>>>>>
>>>>>>>>>> The issue here is who is this being optimized for. Server-to-ser=
ver communication should simply use TLS for privacy and MITM protection on =
top of MAC instead of using nonces to prevent replay. The whole point of th=
is kind of replay protection is when TLS is not available.
>>>>>>>>>>
>>>>>>>>>> I think a better approach is to simply make checking the nonce o=
ptional when TLS is used.
>>>>>>>>>>
>>>>>>>>>> EHL
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=
 Behalf
>>>>>>>>>>> Of Peter Wolanin
>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MA=
C token
>>>>>>>>>>>
>>>>>>>>>>> I am also concerned by the fragility of using time-since-creden=
tials-issued,
>>>>>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>>>>>
>>>>>>>>>>> I think it would be preferable to always require a timestamp as=
 part of the
>>>>>>>>>>> authorization header, and maybe even include in the spec a maxi=
mum time
>>>>>>>>>>> difference between client and server (e.g. 900 seconds) that ca=
n be
>>>>>>>>>>> tolerated. =A0This makes generating the nonce easier also, sinc=
e the value need
>>>>>>>>>>> to longer be unique over all time.
>>>>>>>>>>>
>>>>>>>>>>> We have such rules in place for an HMAC-based authentication sy=
stem we
>>>>>>>>>>> use. =A0Once in a while a client has a local clock so far out o=
f sync that there is an
>>>>>>>>>>> issue, but it's rare.
>>>>>>>>>>>
>>>>>>>>>>> -Peter
>>>>>>>>>>>
>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>
>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC t=
oken
>>>>>>>>>>>>>
>>>>>>>>>>>>> So after discussing this today and reflecting on it a bit, I =
would suggest that
>>>>>>>>>>> nonce simply be the "unique value" (as it is so named) without =
further
>>>>>>>>>>> requirements. It might be suggested that this be composed of an
>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a MAY =
or
>>>>>>>>>>> "recommended" practice. If the expectation is that very few if =
any providers
>>>>>>>>>>> would actually check the timestamp (or moreover, the nonce itse=
lf), why add
>>>>>>>>>>> terminology in the draft that requires it? Developers are doing=
 extra
>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no =
payoff or
>>>>>>>>>>> added security.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm sending this feedback based on having implemented the v3-=
5 changes
>>>>>>>>>>> last night (for both client credentials and requests w/ access =
tokens). After
>>>>>>>>>>> the changes, the nonce creation is now the most complicated par=
t of the
>>>>>>>>>>> normalized request string and yet these changes offer the least=
 benefit.
>>>>>>>>>>> What's most important is that nonces are unique on each request=
 for an ID.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time base=
d on
>>>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o know=
ledge of
>>>>>>>>>>>>> the software storing the dates) then time will also fail. Ass=
uming
>>>>>>>>>>>>> that a user with a bad clock (of by hours or more) will never=
 fix it
>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix your clo=
ck or
>>>>>>>>>>>>> Twitterbot will stop working!). Though we say that timezones =
won't
>>>>>>>>>>>>> bring about the situation of changed clock, I'd be to differ.=
 Many
>>>>>>>>>>>>> users aren't savvy enough to change time zone, but just adjus=
t the
>>>>>>>>>>>>> time to local time anyway. Users who are more likely to get i=
t right
>>>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> - What if the token wasn't originally issued programmatically=
? In this case,
>>>>>>>>>>> the issue time has to be obtained from the server and stored on=
 the client
>>>>>>>>>>> then you have the same problem as with a timestamp - the client=
 clock is not
>>>>>>>>>>> sync'd to the server clock and there is no adjustment. You want=
 this to apply
>>>>>>>>>>> to uses outside of just OAuth, but now requiring the client to =
be able to
>>>>>>>>>>> determine an issue time based on when it receives an HTTP reque=
st
>>>>>>>>>>> necessarily limits the types of token flows for which this can =
be used.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a develo=
per, but it is
>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it=
 is actually more of a
>>>>>>>>>>> recording of "my personal clock offset value" but obfuscated se=
veral times
>>>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - This implementation assumes software programs use the compu=
ter
>>>>>>>>>>> internal clock exclusively for timestamp. A robust program that=
 is dependent
>>>>>>>>>>> on accurate timestamps would ping the origin server (or similar=
 trusted time
>>>>>>>>>>> authority) to ask it the current time. Then it could store a "m=
y device clock
>>>>>>>>>>> offset" value for the lifetime of the program execution. All re=
quests needing
>>>>>>>>>>> timestamp would be adjusted accordingly. For age, if the clock =
is changed
>>>>>>>>>>> since the stored issue_date, the problem can't be corrected in =
this manner.
>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All in all, this seems like a misguided but well-intentioned =
attempt to get
>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a hack =
and it certainly
>>>>>>>>>>> isn't a foolproof solution. The more I think about the implicat=
ions of the age
>>>>>>>>>>> parameter, the less I like it. Timestamp has been used for many=
 years in the
>>>>>>>>>>> industry and with reasonable success in relevant applications. =
If we change to
>>>>>>>>>>> a new way of trying to sync on time I think we run a greater ri=
sk of stumbling
>>>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for that =
matter)
>>>>>>>>>>> be dropped from the nonce construction. For providers that deem=
 it
>>>>>>>>>>> valuable, timestamp can be an optional value (either as part of=
 the nonce or
>>>>>>>>>>> the overall header, as before).
>>>>>>>>>>>>>
>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as "examp=
le.net"
>>>>>>>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly a=
ddresses my
>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing l=
ist for the
>>>>>>>>>>> time being, I wanted to give a quick update to those who have b=
een
>>>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is n=
ow a
>>>>>>>>>>> general purpose HTTP authentication scheme. It does include an =
OAuth 2.0
>>>>>>>>>>> binding which is described in less than a page. One suggestion =
would be to
>>>>>>>>>>> move section 5.1 into the OAuth specification and drop all the =
OAuth 2.0 text
>>>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session c=
ookies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Removed request URI query normalization. The new draft us=
es the
>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the ne=
ed for
>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text t=
o be
>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of the =
credentials as
>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0Ac=
quia. Inc.
>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>
>>>>>>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com=
"
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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 igor.faynberg@alcatel-lucent.com  Tue May 31 15:49: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 B67FBE0927 for ; Tue, 31 May 2011 15:49:52 -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 2hb8A2Nz1dBB for ; Tue, 31 May 2011 15:49:51 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D9515E0926 for ; Tue, 31 May 2011 15:49:50 -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 p4VMnnIY007457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 17:49:49 -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 p4VMnn4V002121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 17:49:49 -0500
Received: from [135.244.18.4] (faynberg.lra.lucent.com [135.244.18.4]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p4VMnmNQ020022; Tue, 31 May 2011 17:49:48 -0500 (CDT)
Message-ID: <4DE5708B.9090505@alcatel-lucent.com>
Date: Tue, 31 May 2011 18:49:47 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Phil Hunt 
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>			 <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com>
In-Reply-To: <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
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
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, 31 May 2011 22:49:52 -0000

...Sorry to turn the question around so as to underline my pet peeve:  
Have we *documented* all cases?  (This is what the Use Cases document is 
supposed to be all about.)

Just to clarify: I am not arguing with Phil's point now. I just stress 
that as of this moment we don't have anything to check against.

Igor

Phil Hunt wrote:
> There seems to be a demonstrated need for both age and timestamp tokens.
>
> The list has 2 separate cases with 2 separate proposals that do not solve all cases.
>
> Can we at least agree that neither proposal works in all cases?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>
>   
>> You haven't described a problem.
>>
>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  wrote:
>>     
>>> First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding?
>>>       
>> That's not correct.
>>
>> The age allows the server to protect against replay attacks in bounded
>> memory.  With unbounded memory, the server can just remember every
>> nonce it has ever seen associated with a given key and reject replays.
>> With bounded memory, the server eventually needs to evict some of
>> these nonces due to memory pressure.  The age value lets the server
>> reject the nonces with the smallest age values first.  The server then
>> rejects any messages with age values smaller than (or equal to) the
>> largest age value it has ever evicted for the given key.
>>
>> Notice that neither clock synchronization nor transmission time plays
>> a role in that implementation.
>>
>>     
>>> The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would cover) how then will your client determine issue date?
>>>       
>> I recommend the date at which the developer obtained the credential
>> from Twitter because that is the date when the credential was issued.
>>
>>     
>>> After we can establish where you're at on the two above points I'll continue with the explanation. But as a preview, the next points would be:
>>>
>>> - If issue_date comes form the server, how is it translated to the client?
>>>       
>> The issue_date does not come from the server.
>>
>>     
>>> - If you use a server provided issue_date, how do you then translate that a value relative to the local unsyncronized clock?
>>>       
>> The server does not provide the issue_date.
>>
>>     
>>> - If your answer to that is to also provide the current server time to the client so the offset on the server provided issue_date can be calculated what is the difference between all of these values and just using timestamp?
>>>       
>> My answer is not to provide the current server time to the client.
>>
>> Kind regards,
>> Adam
>>
>>
>>     
>>> So don't get wrapped up in those 3 questions until we establish your contextual understanding of the first two paragraphs. Feel free to also respond to me off the list so we don't trouble everyone else with us getting on the same page (the reason, I thought, why a Skype call would be more efficient and painless). I do think my explanations all have been very clear thus far. There must be a contextual confusion that is keeping us from a common understanding of the terminology or the use cases.
>>>
>>> skylar
>>>
>>>
>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>
>>>       
>>>> I'm not sure we need a Skype call.  Can you explain the trouble caused
>>>> by age clearly?  I didn't understand your previous explanation.  The
>>>> more concrete you can be, the better.
>>>>
>>>> Thanks,
>>>> Adam
>>>>
>>>>
>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  wrote:
>>>>         
>>>>> It seems we're failing to communicate. Or you're not understanding my use cases. Age doesn't "just" work. It only works for a limited number of uses cases that must include all of yours - and it is brittle at that. It doesn't work for any of our uses cases (where the client can't know issue_date w/o the server telling it - in which case we have the equivalent problem as timestamp).
>>>>>
>>>>> If you'd like to talk this out over Skype I'm happy to do that, so I can help you understand why age doesn't work.
>>>>>
>>>>>
>>>>>
>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>
>>>>>           
>>>>>> Timestamps don't work when the client doesn't have a synchronized
>>>>>> clock.  It's true that a client could synchronize its clock with the
>>>>>> network, but our implementation experience is that many clients don't
>>>>>> for a variety of reasons.  That means that age better because, you
>>>>>> know, it works.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  wrote:
>>>>>>             
>>>>>>> I don't think you read my first message on the topic (or I wrote too much).
>>>>>>>
>>>>>>> Age is fragile because if the clock changes between issue_date and the time of submission, it will fail. We know many people don't have synchronized clocks, but using age only solves this problem if two assumptions hold true:
>>>>>>>
>>>>>>> 1) the client is able to guess the issue_date the server is using based on the time the credential was issued
>>>>>>> 2) the client system clock doesn't change between issue date and submission time.
>>>>>>>
>>>>>>> Timestamp has neither of these issues because the client can always inquire about network time and can effectively correct for inaccuracies in the device timekeeping system.
>>>>>>>
>>>>>>> Regarding the first assumption, this fails when a token might be re-issued between devices. An example is that we use MAC token for the client credentials, which are issued when a developer registers an application. The client has no way of determining on its own when the value was actually issued (unless we communicate that on the developer website and force users to embed that with client_id, which adds usability issues of users copying and entering string date values correctly). The same is actually true for all of our OAuth access tokens because we reissue tokens to the same client_id if they were previously issued and are still valid. (The client would thus think the issue_date was now() when if fact it was the time of the first issue for client_id+scope+grantor_id). Thus, age is really just a convoluted way of trying to communicate the device system offset:
>>>>>>>
>>>>>>>        local_offset = current_server_time - current_device_time
>>>>>>>        age = current_device_time - (server_issue_date-local_offset)
>>>>>>>
>>>>>>> Since the protocol doesn't currently allow for server_issue_date to be given with tokens, thus age currently can't have the resilience that timestamp does. It also forces servers to issue new tokens on demand just to make the convoluted age system work (rather than reuse existing valid tokens). Or, you have to modify the protocol to add server_issue_date and current_server_time into the token-issue exchange - eg, more complexity.
>>>>>>>
>>>>>>> Timestamp is simpler, proven, it and it has a solution for your use case of unsyncronized clocks.
>>>>>>>
>>>>>>> skylar
>>>>>>>
>>>>>>>
>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks don't
>>>>>>>> have synchronized clocks, for a wide variety of reasons.  I guess I
>>>>>>>> don't really understand why you view age as problematic.  You
>>>>>>>> reference "fragility of using time-since-credentials-issued" but you
>>>>>>>> don't say what exactly is fragile about it.  There's nothing
>>>>>>>> particularly complex about age, especially when using the monotonic
>>>>>>>> clock provided by all modern operating systems.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wrote:
>>>>>>>>                 
>>>>>>>>> But see, now you are specializing the use of MAC token even more - now it's becoming a service mainly for user-agents on home desktops? This is further for the original goal of making MAC as flexible is possible. In this case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>>>>>>>
>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>>
>>>>>>>>> User agents that care about creating robust behavior for home desktops or mobiles (presumably of users and OS not yet sophisticated enough to check network time on their own) should be advised to do clock correction on their own (by pinging a time service) and trusting the device clock alone.
>>>>>>>>>
>>>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>>>
>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla co-authors about why they think that age is more resilient than the above (I believe it is not) and further more why they would find the above unattractive or difficult to implement in a modern user-agent.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> skylar
>>>>>>>>>
>>>>>>>>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -..
>>>>>>>>> skylar woodward
>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Any kind of clock sync requirement for user-agents (basically, home desktops) it completely impractical. The added complexity pales in comparison to the difficulty of trying to use timestamps and any kind of clock sync. No window will be big enough as experience shows some users have closes that are off by more than an hour and a half.
>>>>>>>>>>
>>>>>>>>>> The issue here is who is this being optimized for. Server-to-server communication should simply use TLS for privacy and MITM protection on top of MAC instead of using nonces to prevent replay. The whole point of this kind of replay protection is when TLS is not available.
>>>>>>>>>>
>>>>>>>>>> I think a better approach is to simply make checking the nonce optional when TLS is used.
>>>>>>>>>>
>>>>>>>>>> EHL
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>>>>>>>>> Of Peter Wolanin
>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>>>>>>>>>>
>>>>>>>>>>> I am also concerned by the fragility of using time-since-credentials-issued,
>>>>>>>>>>> and also the added complexity of specifying this construction.
>>>>>>>>>>>
>>>>>>>>>>> I think it would be preferable to always require a timestamp as part of the
>>>>>>>>>>> authorization header, and maybe even include in the spec a maximum time
>>>>>>>>>>> difference between client and server (e.g. 900 seconds) that can be
>>>>>>>>>>> tolerated.  This makes generating the nonce easier also, since the value need
>>>>>>>>>>> to longer be unique over all time.
>>>>>>>>>>>
>>>>>>>>>>> We have such rules in place for an HMAC-based authentication system we
>>>>>>>>>>> use.  Once in a while a client has a local clock so far out of sync that there is an
>>>>>>>>>>> issue, but it's rare.
>>>>>>>>>>>
>>>>>>>>>>> -Peter
>>>>>>>>>>>
>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>>>>>>>> wrote:
>>>>>>>>>>>                       
>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token
>>>>>>>>>>>>>
>>>>>>>>>>>>> So after discussing this today and reflecting on it a bit, I would suggest that
>>>>>>>>>>>>>                           
>>>>>>>>>>> nonce simply be the "unique value" (as it is so named) without further
>>>>>>>>>>> requirements. It might be suggested that this be composed of an
>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a MAY or
>>>>>>>>>>> "recommended" practice. If the expectation is that very few if any providers
>>>>>>>>>>> would actually check the timestamp (or moreover, the nonce itself), why add
>>>>>>>>>>> terminology in the draft that requires it? Developers are doing extra
>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with no payoff or
>>>>>>>>>>> added security.
>>>>>>>>>>>                       
>>>>>>>>>>>>> I'm sending this feedback based on having implemented the v3-5 changes
>>>>>>>>>>>>>                           
>>>>>>>>>>> last night (for both client credentials and requests w/ access tokens). After
>>>>>>>>>>> the changes, the nonce creation is now the most complicated part of the
>>>>>>>>>>> normalized request string and yet these changes offer the least benefit.
>>>>>>>>>>> What's most important is that nonces are unique on each request for an ID.
>>>>>>>>>>>                       
>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time based on
>>>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o knowledge of
>>>>>>>>>>>>> the software storing the dates) then time will also fail. Assuming
>>>>>>>>>>>>> that a user with a bad clock (of by hours or more) will never fix it
>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix your clock or
>>>>>>>>>>>>> Twitterbot will stop working!). Though we say that timezones won't
>>>>>>>>>>>>> bring about the situation of changed clock, I'd be to differ. Many
>>>>>>>>>>>>> users aren't savvy enough to change time zone, but just adjust the
>>>>>>>>>>>>> time to local time anyway. Users who are more likely to get it right
>>>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> - What if the token wasn't originally issued programmatically? In this case,
>>>>>>>>>>>>>                           
>>>>>>>>>>> the issue time has to be obtained from the server and stored on the client
>>>>>>>>>>> then you have the same problem as with a timestamp - the client clock is not
>>>>>>>>>>> sync'd to the server clock and there is no adjustment. You want this to apply
>>>>>>>>>>> to uses outside of just OAuth, but now requiring the client to be able to
>>>>>>>>>>> determine an issue time based on when it receives an HTTP request
>>>>>>>>>>> necessarily limits the types of token flows for which this can be used.
>>>>>>>>>>>                       
>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a developer, but it is
>>>>>>>>>>>>>                           
>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, it is actually more of a
>>>>>>>>>>> recording of "my personal clock offset value" but obfuscated several times
>>>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>                       
>>>>>>>>>>>>> - This implementation assumes software programs use the computer
>>>>>>>>>>>>>                           
>>>>>>>>>>> internal clock exclusively for timestamp. A robust program that is dependent
>>>>>>>>>>> on accurate timestamps would ping the origin server (or similar trusted time
>>>>>>>>>>> authority) to ask it the current time. Then it could store a "my device clock
>>>>>>>>>>> offset" value for the lifetime of the program execution. All requests needing
>>>>>>>>>>> timestamp would be adjusted accordingly. For age, if the clock is changed
>>>>>>>>>>> since the stored issue_date, the problem can't be corrected in this manner.
>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>                       
>>>>>>>>>>>>> All in all, this seems like a misguided but well-intentioned attempt to get
>>>>>>>>>>>>>                           
>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a hack and it certainly
>>>>>>>>>>> isn't a foolproof solution. The more I think about the implications of the age
>>>>>>>>>>> parameter, the less I like it. Timestamp has been used for many years in the
>>>>>>>>>>> industry and with reasonable success in relevant applications. If we change to
>>>>>>>>>>> a new way of trying to sync on time I think we run a greater risk of stumbling
>>>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>                       
>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for that matter)
>>>>>>>>>>>>>                           
>>>>>>>>>>> be dropped from the nonce construction. For providers that deem it
>>>>>>>>>>> valuable, timestamp can be an optional value (either as part of the nonce or
>>>>>>>>>>> the overall header, as before).
>>>>>>>>>>>                       
>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as "example.net"
>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly addresses my
>>>>>>>>>>>>>>                             
>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>                       
>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing list for the
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> time being, I wanted to give a quick update to those who have been
>>>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is now a
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> general purpose HTTP authentication scheme. It does include an OAuth 2.0
>>>>>>>>>>> binding which is described in less than a page. One suggestion would be to
>>>>>>>>>>> move section 5.1 into the OAuth specification and drop all the OAuth 2.0 text
>>>>>>>>>>> from the MAC draft.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session cookies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Removed request URI query normalization. The new draft uses the
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the need for
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> clock sync.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text to be
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of the credentials as
>>>>>>>>>>>>>>>                               
>>>>>>>>>>> an additional protection.
>>>>>>>>>>>                       
>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>
>>>>>>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>                       
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>               
>>>>>           
>>>       
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>     
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>   

From wmills@yahoo-inc.com  Tue May 31 16:17: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 4E540E0745 for ; Tue, 31 May 2011 16:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.128
X-Spam-Level: 
X-Spam-Status: No, score=-16.128 tagged_above=-999 required=5 tests=[AWL=-0.490, 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 fWN15lUXjTiG for ; Tue, 31 May 2011 16:17:48 -0700 (PDT)
Received: from nm6-vm0.bullet.mail.bf1.yahoo.com (nm6-vm0.bullet.mail.bf1.yahoo.com [98.139.213.146]) by ietfa.amsl.com (Postfix) with SMTP id 8CC43E06DD for ; Tue, 31 May 2011 16:17:48 -0700 (PDT)
Received: from [98.139.212.144] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2011 23:17:45 -0000
Received: from [98.139.212.199] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2011 23:17:45 -0000
Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 31 May 2011 23:17:45 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 293569.25764.bm@omp1008.mail.bf1.yahoo.com
Received: (qmail 92597 invoked by uid 60001); 31 May 2011 23:17:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1306883864; bh=xxWil7K4J1m7Iv6xeAtPNfFspPOvsBJWgTM2C2a+r3s=; 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=Uv1n6Alp9/Ftyb1juzpoq48Xubt+N3NQkE7s+2F1icCwYMrlyWEQtgToUsHUGFSHo8lNQ238uA5geEKZJSJ5BQvwj/bOyK4EQ4FRB5DpVqFjElg5TO2BYP9cwBVteD0sbI48i/o1AAHXJ+JhwHHdOJrLKRLAH4JkCm/XZ/0qfoc=
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=claR7bbPEczeg+eJx0jMInmPuywr/nJ4g+6FGhxLJ0hdpbwlrW0xOjhWhasm3phaRup+bSNtB2A02rd7Piwu071P9BhBA+WuybLp+VcpFPC3IvbgjRet9YedfMlEffLNyHI8FhGGMk6HNN8RNAqsx872IpnPZqUWpErRvDrLR3k=;
X-YMail-OSG: Dn_EJe4VM1lQnl1L03mrgEo9MQbH_hVHUdSUueUMbQh_SR9 etxidjKqL6pkTK.LqXpY.F6G5Di6R023UY5Zb6c9TO_Z0sa_LfMcEcdwfIkJ yin7MPRUuUwX08KAmWF_X536iKvfNTtMd8lrUdQxDk81XFgEAjnv7B8HVsAH lDNiVAZ_1o4Loi.IsrQGjzqj4Rz6JdNf3XjOVReIq_gDLzn8qrtrTh3Hl94E Dp.GHHv3UTgxEh6a3TUFQ8PrBm.kjp3p9jbvuKzdprnDWyhNbTHRowxAMJ6T SFXMimPZFugGLsnpN7FZGseunc5MO3HwrQkfDX4RApMx6.N53aaP6g_Xo_Gm obsAE25RxjnP645TdOWD7okTXXazn3NzteBL0KUI-
Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 31 May 2011 16:17:44 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.112.307740
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> 
Message-ID: <1306883864.84178.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Tue, 31 May 2011 16:17:44 -0700 (PDT)
From: "William J. Mills" 
To: Mark Mcgloin , "oauth@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1264693243-1306883864=:84178"
Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions
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, 31 May 2011 23:17:50 -0000

--0-1264693243-1306883864=:84178
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF defini=
tion, which I think is clearer.=A0 Perhaps that can be used to touch up you=
r first paragraph?=0A=0A=0A=0A________________________________=0AFrom: Mark=
 Mcgloin =0ATo: oauth@ietf.org=0ASent: Tuesday, Ma=
y 31, 2011 1:58 PM=0ASubject: [OAUTH-WG] Draft 16 Security Considerations a=
dditions=0A=0AEran=0A=0AHere are some additional sections to add to the nex=
t draft under security=0Aconsiderations=0A=0ACSRF=0ACross-Site Request Forg=
ery (CSRF) is a web-based attack whereby HTTP=0Arequests are transmitted fr=
om a user that the website trusts or has=0Aauthenticated. CSRF attacks on O=
Auth approvals can allow an attacker to=0Aobtain authorization to OAuth Pro=
tected Resources without the consent of=0Athe User.=0AThe state parameter s=
hould be used to mitigate against CSRF attacks,=0Aparticularly for login CS=
RF attacks. It is strongly RECOMMENDED that the=0Aclient sends the state pa=
rameter with authorization requests to the=0Aauthorization server. The auth=
orization server will send it in the response=0Awhen redirecting the user t=
o back to the client which SHOULD then validate=0Athe state parameter match=
es on the response.=0A=0AClickjacking=0AClickjacking is the process of tric=
king users into revealing confidential=0Ainformation or taking control of t=
heir computer while clicking on seemingly=0Ainnocuous web pages. In more de=
tail, a malicious site loads the target site=0Ain a transparent iframe over=
laid on top of a set of dummy buttons which are=0Acarefully constructed to =
be placed directly under important buttons on the=0Atarget site. When a use=
r clicks a visible button, they are actually=0Aclicking a button (such as a=
n "Authorize" button) on the hidden page.=0ATo prevent clickjacking (and ph=
ishing attacks), native applications SHOULD=0Ause external browsers instead=
 of embedding browsers in an iFrame when=0Arequesting end-user authorizatio=
n. For newer browsers, avoidance of iFrames=0Acan be enforced server side b=
y using the X-FRAME-OPTION header. This header=0Acan have two values, deny =
and sameorigin, which will block any framing or=0Aframing by sites with a d=
ifferent origin, respectively. For older browsers,=0Ajavascript framebustin=
g techniques can be used but may not be effective in=0Aall browsers.=0A=0A=
=0ARegards=0AMark=0A=0A_______________________________________________=0AOA=
uth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/o=
auth
--0-1264693243-1306883864=:84178
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


    http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF defi=
nition, which I think is clearer.  Perhaps that can be used to touch u=
p your first paragraph?

    <=
div style=3D"font-family: times new roman,new york,times,serif; font-size: =
12pt;">
    From: Mark Mcgloin <mark.mcgloin@ie.ibm.com&=
gt;
    To: oauth@ietf.org<=
br>Sent: Tuesday, May 31, =
2011 1:58 PM
    Subject: [=
OAUTH-WG] Draft 16 Security Considerations additions

    =0AEran<=
br>
    Here are some additional sections to add to the next draft under sec=
urity
    considerations

    CSRF
    Cross-Site Request Forgery (CSRF) is=
 a web-based attack whereby HTTP
    requests are transmitted from a user th=
at the website trusts or has
    authenticated. CSRF attacks on OAuth approv=
als can allow an attacker to
    obtain authorization to OAuth Protected Res=
ources without the consent of
    the User.
    The state parameter should be=
 used to mitigate against CSRF attacks,
    particularly for login CSRF atta=
cks. It is strongly RECOMMENDED that the
    client sends the state paramete=
r with authorization requests to the
    authorization server. The authoriza=
tion server will send it in the response
    when redirecting the user to ba=
ck to the client which SHOULD then validate
    the state parameter matches =
on the response.

    Clickjacking
    Clickjacking is the process of tric=
king users into revealing confidential
    information or taking
 control of their computer while clicking on seemingly
    innocuous web pag=
es. In more detail, a malicious site loads the target site
    in a transpar=
ent 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 c=
lickjacking (and phishing attacks), native applications SHOULD
    use exter=
nal 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
    f=
raming by sites with a different origin, respectively. For older browsers,<=
br>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


    =

    
--0-1264693243-1306883864=:84178--

From phil.hunt@oracle.com  Tue May 31 16:23: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 D9141E0745 for ; Tue, 31 May 2011 16:23: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 wZrLeU3EceRN for ; Tue, 31 May 2011 16:23:14 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id AC533E06DD for ; Tue, 31 May 2011 16:23:14 -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 p4VNNAv3025229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 23:23:11 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 p4VNN8jO019246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 23:23:09 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 p4VNN3vf010751; Tue, 31 May 2011 18:23:03 -0500
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 May 2011 16:23:01 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Phil Hunt 
In-Reply-To: <4DE5708B.9090505@alcatel-lucent.com>
Date: Tue, 31 May 2011 16:23:00 -0700
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>			 <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com>
To: igor.faynberg@alcatel-lucent.com
X-Mailer: Apple Mail (2.1084)
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090202.4DE57860.007B:SCFSTAT5015188,ss=1,fgs=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: Tue, 31 May 2011 23:23:17 -0000

I think Skylar has made his case that age isn't sufficient for his =
needs.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-05-31, at 3:49 PM, Igor Faynberg wrote:

> ...Sorry to turn the question around so as to underline my pet peeve:  =
Have we *documented* all cases?  (This is what the Use Cases document is =
supposed to be all about.)
>=20
> Just to clarify: I am not arguing with Phil's point now. I just stress =
that as of this moment we don't have anything to check against.
>=20
> Igor
>=20
> Phil Hunt wrote:
>> There seems to be a demonstrated need for both age and timestamp =
tokens.
>>=20
>> The list has 2 separate cases with 2 separate proposals that do not =
solve all cases.
>>=20
>> Can we at least agree that neither proposal works in all cases?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>=20
>> =20
>>> You haven't described a problem.
>>>=20
>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  =
wrote:
>>>   =20
>>>> First we should agree on a common understanding of the spec. The =
reason why age works with unsynchronized clocks is that the client =
determines issue_date based on the time when it receives the token over =
the wire. This depends on the server and client both recording time this =
way and for the transmission of the token to be be not longer than the =
margin of error for validating age. Are we agreed on this understanding?
>>>>     =20
>>> That's not correct.
>>>=20
>>> The age allows the server to protect against replay attacks in =
bounded
>>> memory.  With unbounded memory, the server can just remember every
>>> nonce it has ever seen associated with a given key and reject =
replays.
>>> With bounded memory, the server eventually needs to evict some of
>>> these nonces due to memory pressure.  The age value lets the server
>>> reject the nonces with the smallest age values first.  The server =
then
>>> rejects any messages with age values smaller than (or equal to) the
>>> largest age value it has ever evicted for the given key.
>>>=20
>>> Notice that neither clock synchronization nor transmission time =
plays
>>> a role in that implementation.
>>>=20
>>>   =20
>>>> The easiest case for me to explain here is client credentials =
because I have to assume you've built and registered a Twitter app at =
some point (or similar OAuth 1.0a app). You registered your app on the =
site and were issued a client_id and client_secret (called consumer_key =
and consumer_secret in 1.0). You then embedded these values in your =
client (they were not issued programmatically to your app). Assuming the =
MAC token algorithm is used then for establishing client identity =
(originally one of the uses we, the working group, hoped MAC would =
cover) how then will your client determine issue date?
>>>>     =20
>>> I recommend the date at which the developer obtained the credential
>>> from Twitter because that is the date when the credential was =
issued.
>>>=20
>>>   =20
>>>> After we can establish where you're at on the two above points I'll =
continue with the explanation. But as a preview, the next points would =
be:
>>>>=20
>>>> - If issue_date comes form the server, how is it translated to the =
client?
>>>>     =20
>>> The issue_date does not come from the server.
>>>=20
>>>   =20
>>>> - If you use a server provided issue_date, how do you then =
translate that a value relative to the local unsyncronized clock?
>>>>     =20
>>> The server does not provide the issue_date.
>>>=20
>>>   =20
>>>> - If your answer to that is to also provide the current server time =
to the client so the offset on the server provided issue_date can be =
calculated what is the difference between all of these values and just =
using timestamp?
>>>>     =20
>>> My answer is not to provide the current server time to the client.
>>>=20
>>> Kind regards,
>>> Adam
>>>=20
>>>=20
>>>   =20
>>>> So don't get wrapped up in those 3 questions until we establish =
your contextual understanding of the first two paragraphs. Feel free to =
also respond to me off the list so we don't trouble everyone else with =
us getting on the same page (the reason, I thought, why a Skype call =
would be more efficient and painless). I do think my explanations all =
have been very clear thus far. There must be a contextual confusion that =
is keeping us from a common understanding of the terminology or the use =
cases.
>>>>=20
>>>> skylar
>>>>=20
>>>>=20
>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>=20
>>>>     =20
>>>>> I'm not sure we need a Skype call.  Can you explain the trouble =
caused
>>>>> by age clearly?  I didn't understand your previous explanation.  =
The
>>>>> more concrete you can be, the better.
>>>>>=20
>>>>> Thanks,
>>>>> Adam
>>>>>=20
>>>>>=20
>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  =
wrote:
>>>>>       =20
>>>>>> It seems we're failing to communicate. Or you're not =
understanding my use cases. Age doesn't "just" work. It only works for a =
limited number of uses cases that must include all of yours - and it is =
brittle at that. It doesn't work for any of our uses cases (where the =
client can't know issue_date w/o the server telling it - in which case =
we have the equivalent problem as timestamp).
>>>>>>=20
>>>>>> If you'd like to talk this out over Skype I'm happy to do that, =
so I can help you understand why age doesn't work.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>=20
>>>>>>         =20
>>>>>>> Timestamps don't work when the client doesn't have a =
synchronized
>>>>>>> clock.  It's true that a client could synchronize its clock with =
the
>>>>>>> network, but our implementation experience is that many clients =
don't
>>>>>>> for a variety of reasons.  That means that age better because, =
you
>>>>>>> know, it works.
>>>>>>>=20
>>>>>>> Adam
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward =
 wrote:
>>>>>>>           =20
>>>>>>>> I don't think you read my first message on the topic (or I =
wrote too much).
>>>>>>>>=20
>>>>>>>> Age is fragile because if the clock changes between issue_date =
and the time of submission, it will fail. We know many people don't have =
synchronized clocks, but using age only solves this problem if two =
assumptions hold true:
>>>>>>>>=20
>>>>>>>> 1) the client is able to guess the issue_date the server is =
using based on the time the credential was issued
>>>>>>>> 2) the client system clock doesn't change between issue date =
and submission time.
>>>>>>>>=20
>>>>>>>> Timestamp has neither of these issues because the client can =
always inquire about network time and can effectively correct for =
inaccuracies in the device timekeeping system.
>>>>>>>>=20
>>>>>>>> Regarding the first assumption, this fails when a token might =
be re-issued between devices. An example is that we use MAC token for =
the client credentials, which are issued when a developer registers an =
application. The client has no way of determining on its own when the =
value was actually issued (unless we communicate that on the developer =
website and force users to embed that with client_id, which adds =
usability issues of users copying and entering string date values =
correctly). The same is actually true for all of our OAuth access tokens =
because we reissue tokens to the same client_id if they were previously =
issued and are still valid. (The client would thus think the issue_date =
was now() when if fact it was the time of the first issue for =
client_id+scope+grantor_id). Thus, age is really just a convoluted way =
of trying to communicate the device system offset:
>>>>>>>>=20
>>>>>>>>       local_offset =3D current_server_time - =
current_device_time
>>>>>>>>       age =3D current_device_time - =
(server_issue_date-local_offset)
>>>>>>>>=20
>>>>>>>> Since the protocol doesn't currently allow for =
server_issue_date to be given with tokens, thus age currently can't have =
the resilience that timestamp does. It also forces servers to issue new =
tokens on demand just to make the convoluted age system work (rather =
than reuse existing valid tokens). Or, you have to modify the protocol =
to add server_issue_date and current_server_time into the token-issue =
exchange - eg, more complexity.
>>>>>>>>=20
>>>>>>>> Timestamp is simpler, proven, it and it has a solution for your =
use case of unsyncronized clocks.
>>>>>>>>=20
>>>>>>>> skylar
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>=20
>>>>>>>>             =20
>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks =
don't
>>>>>>>>> have synchronized clocks, for a wide variety of reasons.  I =
guess I
>>>>>>>>> don't really understand why you view age as problematic.  You
>>>>>>>>> reference "fragility of using time-since-credentials-issued" =
but you
>>>>>>>>> don't say what exactly is fragile about it.  There's nothing
>>>>>>>>> particularly complex about age, especially when using the =
monotonic
>>>>>>>>> clock provided by all modern operating systems.
>>>>>>>>>=20
>>>>>>>>> Adam
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward =
 wrote:
>>>>>>>>>               =20
>>>>>>>>>> But see, now you are specializing the use of MAC token even =
more - now it's becoming a service mainly for user-agents on home =
desktops? This is further for the original goal of making MAC as =
flexible is possible. In this case you should change the spec name to =
MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or =
MTBCRLF for short.
>>>>>>>>>>=20
>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as =
your offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>>>=20
>>>>>>>>>> User agents that care about creating robust behavior for home =
desktops or mobiles (presumably of users and OS not yet sophisticated =
enough to check network time on their own) should be advised to do clock =
correction on their own (by pinging a time service) and trusting the =
device clock alone.
>>>>>>>>>>=20
>>>>>>>>>> Please change the spec back to using timestamp rather than =
age.
>>>>>>>>>>=20
>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla =
co-authors about why they think that age is more resilient than the =
above (I believe it is not) and further more why they would find the =
above unattractive or difficult to implement in a modern user-agent.
>>>>>>>>>>=20
>>>>>>>>>> Thanks,
>>>>>>>>>> skylar
>>>>>>>>>>=20
>>>>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97=
 ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>>>>> skylar woodward
>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>=20
>>>>>>>>>>                 =20
>>>>>>>>>>> Any kind of clock sync requirement for user-agents =
(basically, home desktops) it completely impractical. The added =
complexity pales in comparison to the difficulty of trying to use =
timestamps and any kind of clock sync. No window will be big enough as =
experience shows some users have closes that are off by more than an =
hour and a half.
>>>>>>>>>>>=20
>>>>>>>>>>> The issue here is who is this being optimized for. =
Server-to-server communication should simply use TLS for privacy and =
MITM protection on top of MAC instead of using nonces to prevent replay. =
The whole point of this kind of replay protection is when TLS is not =
available.
>>>>>>>>>>>=20
>>>>>>>>>>> I think a better approach is to simply make checking the =
nonce optional when TLS is used.
>>>>>>>>>>>=20
>>>>>>>>>>> EHL
>>>>>>>>>>>=20
>>>>>>>>>>>                   =20
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On Behalf
>>>>>>>>>>>> Of Peter Wolanin
>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element =
- MAC token
>>>>>>>>>>>>=20
>>>>>>>>>>>> I am also concerned by the fragility of using =
time-since-credentials-issued,
>>>>>>>>>>>> and also the added complexity of specifying this =
construction.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I think it would be preferable to always require a =
timestamp as part of the
>>>>>>>>>>>> authorization header, and maybe even include in the spec a =
maximum time
>>>>>>>>>>>> difference between client and server (e.g. 900 seconds) =
that can be
>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also, =
since the value need
>>>>>>>>>>>> to longer be unique over all time.
>>>>>>>>>>>>=20
>>>>>>>>>>>> We have such rules in place for an HMAC-based =
authentication system we
>>>>>>>>>>>> use.  Once in a while a client has a local clock so far out =
of sync that there is an
>>>>>>>>>>>> issue, but it's rare.
>>>>>>>>>>>>=20
>>>>>>>>>>>> -Peter
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward =

>>>>>>>>>>>> wrote:
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>                       =20
>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - =
MAC token
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> So after discussing this today and reflecting on it a =
bit, I would suggest that
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named) =
without further
>>>>>>>>>>>> requirements. It might be suggested that this be composed =
of an
>>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a =
MAY or
>>>>>>>>>>>> "recommended" practice. If the expectation is that very few =
if any providers
>>>>>>>>>>>> would actually check the timestamp (or moreover, the nonce =
itself), why add
>>>>>>>>>>>> terminology in the draft that requires it? Developers are =
doing extra
>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with =
no payoff or
>>>>>>>>>>>> added security.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> I'm sending this feedback based on having implemented the =
v3-5 changes
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> last night (for both client credentials and requests w/ =
access tokens). After
>>>>>>>>>>>> the changes, the nonce creation is now the most complicated =
part of the
>>>>>>>>>>>> normalized request string and yet these changes offer the =
least benefit.
>>>>>>>>>>>> What's most important is that nonces are unique on each =
request for an ID.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time =
based on
>>>>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o =
knowledge of
>>>>>>>>>>>>>> the software storing the dates) then time will also fail. =
Assuming
>>>>>>>>>>>>>> that a user with a bad clock (of by hours or more) will =
never fix it
>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix your =
clock or
>>>>>>>>>>>>>> Twitterbot will stop working!). Though we say that =
timezones won't
>>>>>>>>>>>>>> bring about the situation of changed clock, I'd be to =
differ. Many
>>>>>>>>>>>>>> users aren't savvy enough to change time zone, but just =
adjust the
>>>>>>>>>>>>>> time to local time anyway. Users who are more likely to =
get it right
>>>>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, =
etc.)
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> - What if the token wasn't originally issued =
programmatically? In this case,
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> the issue time has to be obtained from the server and =
stored on the client
>>>>>>>>>>>> then you have the same problem as with a timestamp - the =
client clock is not
>>>>>>>>>>>> sync'd to the server clock and there is no adjustment. You =
want this to apply
>>>>>>>>>>>> to uses outside of just OAuth, but now requiring the client =
to be able to
>>>>>>>>>>>> determine an issue time based on when it receives an HTTP =
request
>>>>>>>>>>>> necessarily limits the types of token flows for which this =
can be used.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a =
developer, but it is
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an =
ID, it is actually more of a
>>>>>>>>>>>> recording of "my personal clock offset value" but =
obfuscated several times
>>>>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> - This implementation assumes software programs use the =
computer
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program =
that is dependent
>>>>>>>>>>>> on accurate timestamps would ping the origin server (or =
similar trusted time
>>>>>>>>>>>> authority) to ask it the current time. Then it could store =
a "my device clock
>>>>>>>>>>>> offset" value for the lifetime of the program execution. =
All requests needing
>>>>>>>>>>>> timestamp would be adjusted accordingly. For age, if the =
clock is changed
>>>>>>>>>>>> since the stored issue_date, the problem can't be corrected =
in this manner.
>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> All in all, this seems like a misguided but =
well-intentioned attempt to get
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a =
hack and it certainly
>>>>>>>>>>>> isn't a foolproof solution. The more I think about the =
implications of the age
>>>>>>>>>>>> parameter, the less I like it. Timestamp has been used for =
many years in the
>>>>>>>>>>>> industry and with reasonable success in relevant =
applications. If we change to
>>>>>>>>>>>> a new way of trying to sync on time I think we run a =
greater risk of stumbling
>>>>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for =
that matter)
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>> be dropped from the nonce construction. For providers that =
deem it
>>>>>>>>>>>> valuable, timestamp can be an optional value (either as =
part of the nonce or
>>>>>>>>>>>> the overall header, as before).
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>                         =20
>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as =
"example.net"
>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. =
Certainly addresses my
>>>>>>>>>>>>>>>                           =20
>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>                           =20
>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> =
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss =
mailing list for the
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> time being, I wanted to give a quick update to those who =
have been
>>>>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft =
is now a
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> general purpose HTTP authentication scheme. It does include =
an OAuth 2.0
>>>>>>>>>>>> binding which is described in less than a page. One =
suggestion would be to
>>>>>>>>>>>> move section 5.1 into the OAuth specification and drop all =
the OAuth 2.0 text
>>>>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with =
session cookies.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new =
draft uses the
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove =
the need for
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random =
text to be
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of =
the credentials as
>>>>>>>>>>>>>>>>                             =20
>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>                     =20
>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>                       =20
>>>>>>>>>>>>=20
>>>>>>>>>>>> --
>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  =
Acquia. Inc.
>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>=20
>>>>>>>>>>>> "Get a free, hosted Drupal 7 site: =
http://www.drupalgardens.com"
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>=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
>> =20


From ietf@adambarth.com  Tue May 31 16: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 3E575E0745 for ; Tue, 31 May 2011 16:26:59 -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 heIqMM53nDwY for ; Tue, 31 May 2011 16:26:57 -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 1AB5AE06DD for ; Tue, 31 May 2011 16:26:57 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2725602gyf.31 for ; Tue, 31 May 2011 16:26:56 -0700 (PDT)
Received: by 10.236.145.2 with SMTP id o2mr2930691yhj.141.1306884416498; Tue, 31 May 2011 16:26:56 -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 f65sm574299yhn.39.2011.05.31.16.26.55 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 16:26:55 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2725592gyf.31 for ; Tue, 31 May 2011 16:26:55 -0700 (PDT)
Received: by 10.91.207.11 with SMTP id j11mr5047775agq.17.1306884415164; Tue, 31 May 2011 16:26:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 16:26:25 -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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> 
From: Adam Barth 
Date: Tue, 31 May 2011 16:26:25 -0700
Message-ID: 
To: Phil Hunt 
Content-Type: text/plain; charset=windows-1252
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: Tue, 31 May 2011 23:26:59 -0000

Really?  Can you point me to the email where he explains what the
actual problem is?

Adam


On Tue, May 31, 2011 at 4:23 PM, Phil Hunt  wrote:
> I think Skylar has made his case that age isn't sufficient for his needs.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2011-05-31, at 3:49 PM, Igor Faynberg wrote:
>
>> ...Sorry to turn the question around so as to underline my pet peeve: =
=A0Have we *documented* all cases? =A0(This is what the Use Cases document =
is supposed to be all about.)
>>
>> Just to clarify: I am not arguing with Phil's point now. I just stress t=
hat as of this moment we don't have anything to check against.
>>
>> Igor
>>
>> Phil Hunt wrote:
>>> There seems to be a demonstrated need for both age and timestamp tokens=
.
>>>
>>> The list has 2 separate cases with 2 separate proposals that do not sol=
ve all cases.
>>>
>>> Can we at least agree that neither proposal works in all cases?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>>
>>>
>>>> You haven't described a problem.
>>>>
>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  wro=
te:
>>>>
>>>>> First we should agree on a common understanding of the spec. The reas=
on why age works with unsynchronized clocks is that the client determines i=
ssue_date based on the time when it receives the token over the wire. This =
depends on the server and client both recording time this way and for the t=
ransmission of the token to be be not longer than the margin of error for v=
alidating age. Are we agreed on this understanding?
>>>>>
>>>> That's not correct.
>>>>
>>>> The age allows the server to protect against replay attacks in bounded
>>>> memory. =A0With unbounded memory, the server can just remember every
>>>> nonce it has ever seen associated with a given key and reject replays.
>>>> With bounded memory, the server eventually needs to evict some of
>>>> these nonces due to memory pressure. =A0The age value lets the server
>>>> reject the nonces with the smallest age values first. =A0The server th=
en
>>>> rejects any messages with age values smaller than (or equal to) the
>>>> largest age value it has ever evicted for the given key.
>>>>
>>>> Notice that neither clock synchronization nor transmission time plays
>>>> a role in that implementation.
>>>>
>>>>
>>>>> The easiest case for me to explain here is client credentials because=
 I have to assume you've built and registered a Twitter app at some point (=
or similar OAuth 1.0a app). You registered your app on the site and were is=
sued a client_id and client_secret (called consumer_key and consumer_secret=
 in 1.0). You then embedded these values in your client (they were not issu=
ed programmatically to your app). Assuming the MAC token algorithm is used =
then for establishing client identity (originally one of the uses we, the w=
orking group, hoped MAC would cover) how then will your client determine is=
sue date?
>>>>>
>>>> I recommend the date at which the developer obtained the credential
>>>> from Twitter because that is the date when the credential was issued.
>>>>
>>>>
>>>>> After we can establish where you're at on the two above points I'll c=
ontinue with the explanation. But as a preview, the next points would be:
>>>>>
>>>>> - If issue_date comes form the server, how is it translated to the cl=
ient?
>>>>>
>>>> The issue_date does not come from the server.
>>>>
>>>>
>>>>> - If you use a server provided issue_date, how do you then translate =
that a value relative to the local unsyncronized clock?
>>>>>
>>>> The server does not provide the issue_date.
>>>>
>>>>
>>>>> - If your answer to that is to also provide the current server time t=
o the client so the offset on the server provided issue_date can be calcula=
ted what is the difference between all of these values and just using times=
tamp?
>>>>>
>>>> My answer is not to provide the current server time to the client.
>>>>
>>>> Kind regards,
>>>> Adam
>>>>
>>>>
>>>>
>>>>> So don't get wrapped up in those 3 questions until we establish your =
contextual understanding of the first two paragraphs. Feel free to also res=
pond to me off the list so we don't trouble everyone else with us getting o=
n the same page (the reason, I thought, why a Skype call would be more effi=
cient and painless). I do think my explanations all have been very clear th=
us far. There must be a contextual confusion that is keeping us from a comm=
on understanding of the terminology or the use cases.
>>>>>
>>>>> skylar
>>>>>
>>>>>
>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>>
>>>>>
>>>>>> I'm not sure we need a Skype call. =A0Can you explain the trouble ca=
used
>>>>>> by age clearly? =A0I didn't understand your previous explanation. =
=A0The
>>>>>> more concrete you can be, the better.
>>>>>>
>>>>>> Thanks,
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward  w=
rote:
>>>>>>
>>>>>>> It seems we're failing to communicate. Or you're not understanding =
my use cases. Age doesn't "just" work. It only works for a limited number o=
f uses cases that must include all of yours - and it is brittle at that. It=
 doesn't work for any of our uses cases (where the client can't know issue_=
date w/o the server telling it - in which case we have the equivalent probl=
em as timestamp).
>>>>>>>
>>>>>>> If you'd like to talk this out over Skype I'm happy to do that, so =
I can help you understand why age doesn't work.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Timestamps don't work when the client doesn't have a synchronized
>>>>>>>> clock. =A0It's true that a client could synchronize its clock with=
 the
>>>>>>>> network, but our implementation experience is that many clients do=
n't
>>>>>>>> for a variety of reasons. =A0That means that age better because, y=
ou
>>>>>>>> know, it works.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward  wrote:
>>>>>>>>
>>>>>>>>> I don't think you read my first message on the topic (or I wrote =
too much).
>>>>>>>>>
>>>>>>>>> Age is fragile because if the clock changes between issue_date an=
d the time of submission, it will fail. We know many people don't have sync=
hronized clocks, but using age only solves this problem if two assumptions =
hold true:
>>>>>>>>>
>>>>>>>>> 1) the client is able to guess the issue_date the server is using=
 based on the time the credential was issued
>>>>>>>>> 2) the client system clock doesn't change between issue date and =
submission time.
>>>>>>>>>
>>>>>>>>> Timestamp has neither of these issues because the client can alwa=
ys inquire about network time and can effectively correct for inaccuracies =
in the device timekeeping system.
>>>>>>>>>
>>>>>>>>> Regarding the first assumption, this fails when a token might be =
re-issued between devices. An example is that we use MAC token for the clie=
nt credentials, which are issued when a developer registers an application.=
 The client has no way of determining on its own when the value was actuall=
y issued (unless we communicate that on the developer website and force use=
rs to embed that with client_id, which adds usability issues of users copyi=
ng and entering string date values correctly). The same is actually true fo=
r all of our OAuth access tokens because we reissue tokens to the same clie=
nt_id if they were previously issued and are still valid. (The client would=
 thus think the issue_date was now() when if fact it was the time of the fi=
rst issue for client_id+scope+grantor_id). Thus, age is really just a convo=
luted way of trying to communicate the device system offset:
>>>>>>>>>
>>>>>>>>> =A0 =A0 =A0 local_offset =3D current_server_time - current_device=
_time
>>>>>>>>> =A0 =A0 =A0 age =3D current_device_time - (server_issue_date-loca=
l_offset)
>>>>>>>>>
>>>>>>>>> Since the protocol doesn't currently allow for server_issue_date =
to be given with tokens, thus age currently can't have the resilience that =
timestamp does. It also forces servers to issue new tokens on demand just t=
o make the convoluted age system work (rather than reuse existing valid tok=
ens). Or, you have to modify the protocol to add server_issue_date and curr=
ent_server_time into the token-issue exchange - eg, more complexity.
>>>>>>>>>
>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for your u=
se case of unsyncronized clocks.
>>>>>>>>>
>>>>>>>>> skylar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks do=
n't
>>>>>>>>>> have synchronized clocks, for a wide variety of reasons. =A0I gu=
ess I
>>>>>>>>>> don't really understand why you view age as problematic. =A0You
>>>>>>>>>> reference "fragility of using time-since-credentials-issued" but=
 you
>>>>>>>>>> don't say what exactly is fragile about it. =A0There's nothing
>>>>>>>>>> particularly complex about age, especially when using the monoto=
nic
>>>>>>>>>> clock provided by all modern operating systems.
>>>>>>>>>>
>>>>>>>>>> Adam
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward  wrote:
>>>>>>>>>>
>>>>>>>>>>> But see, now you are specializing the use of MAC token even mor=
e - now it's becoming a service mainly for user-agents on home desktops? Th=
is is further for the original goal of making MAC as flexible is possible. =
In this case you should change the spec name to MAC_TOKEN_FOR_BROWSER_COOKI=
E_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or MTBCRLF for short.
>>>>>>>>>>>
>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as yo=
ur offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>>>>
>>>>>>>>>>> User agents that care about creating robust behavior for home d=
esktops or mobiles (presumably of users and OS not yet sophisticated enough=
 to check network time on their own) should be advised to do clock correcti=
on on their own (by pinging a time service) and trusting the device clock a=
lone.
>>>>>>>>>>>
>>>>>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>>>>>
>>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla co=
-authors about why they think that age is more resilient than the above (I =
believe it is not) and further more why they would find the above unattract=
ive or difficult to implement in a modern user-agent.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> skylar
>>>>>>>>>>>
>>>>>>>>>>> ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -.. =97=
 ... -.- -.-- .-.. .- .-. =97 .-- --- --- -.. .-- .- .-. -..
>>>>>>>>>>> skylar woodward
>>>>>>>>>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@buildkiv=
a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Any kind of clock sync requirement for user-agents (basically,=
 home desktops) it completely impractical. The added complexity pales in co=
mparison to the difficulty of trying to use timestamps and any kind of cloc=
k sync. No window will be big enough as experience shows some users have cl=
oses that are off by more than an hour and a half.
>>>>>>>>>>>>
>>>>>>>>>>>> The issue here is who is this being optimized for. Server-to-s=
erver communication should simply use TLS for privacy and MITM protection o=
n top of MAC instead of using nonces to prevent replay. The whole point of =
this kind of replay protection is when TLS is not available.
>>>>>>>>>>>>
>>>>>>>>>>>> I think a better approach is to simply make checking the nonce=
 optional when TLS is used.
>>>>>>>>>>>>
>>>>>>>>>>>> EHL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf
>>>>>>>>>>>>> Of Peter Wolanin
>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - =
MAC token
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am also concerned by the fragility of using time-since-cred=
entials-issued,
>>>>>>>>>>>>> and also the added complexity of specifying this construction=
.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would be preferable to always require a timestamp =
as part of the
>>>>>>>>>>>>> authorization header, and maybe even include in the spec a ma=
ximum time
>>>>>>>>>>>>> difference between client and server (e.g. 900 seconds) that =
can be
>>>>>>>>>>>>> tolerated. =A0This makes generating the nonce easier also, si=
nce the value need
>>>>>>>>>>>>> to longer be unique over all time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have such rules in place for an HMAC-based authentication =
system we
>>>>>>>>>>>>> use. =A0Once in a while a client has a local clock so far out=
 of sync that there is an
>>>>>>>>>>>>> issue, but it's rare.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Peter
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth WG
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC=
 token
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a bit, =
I would suggest that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named) withou=
t further
>>>>>>>>>>>>> requirements. It might be suggested that this be composed of =
an
>>>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a MA=
Y or
>>>>>>>>>>>>> "recommended" practice. If the expectation is that very few i=
f any providers
>>>>>>>>>>>>> would actually check the timestamp (or moreover, the nonce it=
self), why add
>>>>>>>>>>>>> terminology in the draft that requires it? Developers are doi=
ng extra
>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with n=
o payoff or
>>>>>>>>>>>>> added security.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm sending this feedback based on having implemented the v=
3-5 changes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> last night (for both client credentials and requests w/ acces=
s tokens). After
>>>>>>>>>>>>> the changes, the nonce creation is now the most complicated p=
art of the
>>>>>>>>>>>>> normalized request string and yet these changes offer the lea=
st benefit.
>>>>>>>>>>>>> What's most important is that nonces are unique on each reque=
st for an ID.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time ba=
sed on
>>>>>>>>>>>>>>> receipt, then the internal clock changes (presumably w/o kn=
owledge of
>>>>>>>>>>>>>>> the software storing the dates) then time will also fail. A=
ssuming
>>>>>>>>>>>>>>> that a user with a bad clock (of by hours or more) will nev=
er fix it
>>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix your c=
lock or
>>>>>>>>>>>>>>> Twitterbot will stop working!). Though we say that timezone=
s won't
>>>>>>>>>>>>>>> bring about the situation of changed clock, I'd be to diffe=
r. Many
>>>>>>>>>>>>>>> users aren't savvy enough to change time zone, but just adj=
ust the
>>>>>>>>>>>>>>> time to local time anyway. Users who are more likely to get=
 it right
>>>>>>>>>>>>>>> already have auto clock sync enabled (via web, mobile, etc.=
)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - What if the token wasn't originally issued programmatical=
ly? In this case,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> the issue time has to be obtained from the server and stored =
on the client
>>>>>>>>>>>>> then you have the same problem as with a timestamp - the clie=
nt clock is not
>>>>>>>>>>>>> sync'd to the server clock and there is no adjustment. You wa=
nt this to apply
>>>>>>>>>>>>> to uses outside of just OAuth, but now requiring the client t=
o be able to
>>>>>>>>>>>>> determine an issue time based on when it receives an HTTP req=
uest
>>>>>>>>>>>>> necessarily limits the types of token flows for which this ca=
n be used.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a deve=
loper, but it is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID, =
it is actually more of a
>>>>>>>>>>>>> recording of "my personal clock offset value" but obfuscated =
several times
>>>>>>>>>>>>> over (one for each token) as issue_date.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - This implementation assumes software programs use the com=
puter
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program th=
at is dependent
>>>>>>>>>>>>> on accurate timestamps would ping the origin server (or simil=
ar trusted time
>>>>>>>>>>>>> authority) to ask it the current time. Then it could store a =
"my device clock
>>>>>>>>>>>>> offset" value for the lifetime of the program execution. All =
requests needing
>>>>>>>>>>>>> timestamp would be adjusted accordingly. For age, if the cloc=
k is changed
>>>>>>>>>>>>> since the stored issue_date, the problem can't be corrected i=
n this manner.
>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All in all, this seems like a misguided but well-intentione=
d attempt to get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a hac=
k and it certainly
>>>>>>>>>>>>> isn't a foolproof solution. The more I think about the implic=
ations of the age
>>>>>>>>>>>>> parameter, the less I like it. Timestamp has been used for ma=
ny years in the
>>>>>>>>>>>>> industry and with reasonable success in relevant applications=
. If we change to
>>>>>>>>>>>>> a new way of trying to sync on time I think we run a greater =
risk of stumbling
>>>>>>>>>>>>> upon unforeseen issues, such as those outlined above.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for tha=
t matter)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> be dropped from the nonce construction. For providers that de=
em it
>>>>>>>>>>>>> valuable, timestamp can be an optional value (either as part =
of the nonce or
>>>>>>>>>>>>> the overall header, as before).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as "exa=
mple.net"
>>>>>>>>>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly=
 addresses my
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-toke=
n
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss mailing=
 list for the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> time being, I wanted to give a quick update to those who have=
 been
>>>>>>>>>>>>> following this draft which originated on this list.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft is=
 now a
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does include a=
n OAuth 2.0
>>>>>>>>>>>>> binding which is described in less than a page. One suggestio=
n would be to
>>>>>>>>>>>>> move section 5.1 into the OAuth specification and drop all th=
e OAuth 2.0 text
>>>>>>>>>>>>> from the MAC draft.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session=
 cookies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new draft =
uses the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove the =
need for
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random text=
 to be
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of th=
e credentials as
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =A0=
Acquia. Inc.
>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.c=
om"
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>
>

From mnot@mnot.net  Tue May 31 16:57: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 BC96CE06E6; Tue, 31 May 2011 16:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.283
X-Spam-Level: 
X-Spam-Status: No, score=-105.283 tagged_above=-999 required=5 tests=[AWL=-2.684, 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 wZ7Ti+QZDZ6F; Tue, 31 May 2011 16:57:29 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B361CE06A0; Tue, 31 May 2011 16:57:29 -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 6CD2D509DB; Tue, 31 May 2011 19:57:22 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Mark Nottingham 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 09:57:19 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@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: Tue, 31 May 2011 23:57:30 -0000

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)
> =20
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
> =20
> The draft includes:
> =20
> * 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.
> =20
> 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 =93abused=94 for simple client-server authentication (the =
poorly named =91two-legged=92 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.
> =20
> Comments and feedback is greatly appreciated.
> =20
> EHL
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




From eran@hueniverse.com  Tue May 31 17:01: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 332A0E0836 for ; Tue, 31 May 2011 17:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.401,  BAYES_00=-2.599, 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 ScORqg+tZD1G for ; Tue, 31 May 2011 17:01:15 -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 765D1E078B for ; Tue, 31 May 2011 17:01:14 -0700 (PDT)
Received: (qmail 6281 invoked from network); 1 Jun 2011 00:01:13 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 00:01:12 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 31 May 2011 17:01:07 -0700
From: Eran Hammer-Lahav 
To: "igor.faynberg@alcatel-lucent.com" , Phil Hunt 
Date: Tue, 31 May 2011 17:00:39 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: Acwf5RhSxl8bSvggRday3XgeehrmNwACcO4w
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA402@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com>
In-Reply-To: <4DE5708B.9090505@alcatel-lucent.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
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 00:01:18 -0000

I think the use case document should focus on v2, not on MAC. At some point=
, it becomes impractical to keep every use case discussed on this list reco=
rded.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Igor Faynberg
> Sent: Tuesday, May 31, 2011 3:50 PM
> To: Phil Hunt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> ...Sorry to turn the question around so as to underline my pet peeve:
> Have we *documented* all cases?  (This is what the Use Cases document is
> supposed to be all about.)
>
> Just to clarify: I am not arguing with Phil's point now. I just stress th=
at as of
> this moment we don't have anything to check against.
>
> Igor
>
> Phil Hunt wrote:
> > There seems to be a demonstrated need for both age and timestamp
> tokens.
> >
> > The list has 2 separate cases with 2 separate proposals that do not sol=
ve all
> cases.
> >
> > Can we at least agree that neither proposal works in all cases?
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com
> >
> >
> >
> >
> >
> > On 2011-05-31, at 2:41 PM, Adam Barth wrote:
> >
> >
> >> You haven't described a problem.
> >>
> >> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
> wrote:
> >>
> >>> First we should agree on a common understanding of the spec. The
> reason why age works with unsynchronized clocks is that the client
> determines issue_date based on the time when it receives the token over
> the wire. This depends on the server and client both recording time this =
way
> and for the transmission of the token to be be not longer than the margin=
 of
> error for validating age. Are we agreed on this understanding?
> >>>
> >> That's not correct.
> >>
> >> The age allows the server to protect against replay attacks in
> >> bounded memory.  With unbounded memory, the server can just
> remember
> >> every nonce it has ever seen associated with a given key and reject
> replays.
> >> With bounded memory, the server eventually needs to evict some of
> >> these nonces due to memory pressure.  The age value lets the server
> >> reject the nonces with the smallest age values first.  The server
> >> then rejects any messages with age values smaller than (or equal to)
> >> the largest age value it has ever evicted for the given key.
> >>
> >> Notice that neither clock synchronization nor transmission time plays
> >> a role in that implementation.
> >>
> >>
> >>> The easiest case for me to explain here is client credentials because=
 I
> have to assume you've built and registered a Twitter app at some point (o=
r
> similar OAuth 1.0a app). You registered your app on the site and were iss=
ued
> a client_id and client_secret (called consumer_key and consumer_secret in
> 1.0). You then embedded these values in your client (they were not issued
> programmatically to your app). Assuming the MAC token algorithm is used
> then for establishing client identity (originally one of the uses we, the
> working group, hoped MAC would cover) how then will your client
> determine issue date?
> >>>
> >> I recommend the date at which the developer obtained the credential
> >> from Twitter because that is the date when the credential was issued.
> >>
> >>
> >>> After we can establish where you're at on the two above points I'll
> continue with the explanation. But as a preview, the next points would be=
:
> >>>
> >>> - If issue_date comes form the server, how is it translated to the cl=
ient?
> >>>
> >> The issue_date does not come from the server.
> >>
> >>
> >>> - If you use a server provided issue_date, how do you then translate
> that a value relative to the local unsyncronized clock?
> >>>
> >> The server does not provide the issue_date.
> >>
> >>
> >>> - If your answer to that is to also provide the current server time t=
o the
> client so the offset on the server provided issue_date can be calculated =
what
> is the difference between all of these values and just using timestamp?
> >>>
> >> My answer is not to provide the current server time to the client.
> >>
> >> Kind regards,
> >> Adam
> >>
> >>
> >>
> >>> So don't get wrapped up in those 3 questions until we establish your
> contextual understanding of the first two paragraphs. Feel free to also
> respond to me off the list so we don't trouble everyone else with us gett=
ing
> on the same page (the reason, I thought, why a Skype call would be more
> efficient and painless). I do think my explanations all have been very cl=
ear
> thus far. There must be a contextual confusion that is keeping us from a
> common understanding of the terminology or the use cases.
> >>>
> >>> skylar
> >>>
> >>>
> >>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>>
> >>>
> >>>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>>> caused by age clearly?  I didn't understand your previous
> >>>> explanation.  The more concrete you can be, the better.
> >>>>
> >>>> Thanks,
> >>>> Adam
> >>>>
> >>>>
> >>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward 
> wrote:
> >>>>
> >>>>> It seems we're failing to communicate. Or you're not understanding
> my use cases. Age doesn't "just" work. It only works for a limited number=
 of
> uses cases that must include all of yours - and it is brittle at that. It=
 doesn't
> work for any of our uses cases (where the client can't know issue_date w/=
o
> the server telling it - in which case we have the equivalent problem as
> timestamp).
> >>>>>
> >>>>> If you'd like to talk this out over Skype I'm happy to do that, so =
I can
> help you understand why age doesn't work.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>>
> >>>>>
> >>>>>> Timestamps don't work when the client doesn't have a synchronized
> >>>>>> clock.  It's true that a client could synchronize its clock with
> >>>>>> the network, but our implementation experience is that many
> >>>>>> clients don't for a variety of reasons.  That means that age
> >>>>>> better because, you know, it works.
> >>>>>>
> >>>>>> Adam
> >>>>>>
> >>>>>>
> >>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>  wrote:
> >>>>>>
> >>>>>>> I don't think you read my first message on the topic (or I wrote =
too
> much).
> >>>>>>>
> >>>>>>> Age is fragile because if the clock changes between issue_date an=
d
> the time of submission, it will fail. We know many people don't have
> synchronized clocks, but using age only solves this problem if two
> assumptions hold true:
> >>>>>>>
> >>>>>>> 1) the client is able to guess the issue_date the server is
> >>>>>>> using based on the time the credential was issued
> >>>>>>> 2) the client system clock doesn't change between issue date and
> submission time.
> >>>>>>>
> >>>>>>> Timestamp has neither of these issues because the client can
> always inquire about network time and can effectively correct for
> inaccuracies in the device timekeeping system.
> >>>>>>>
> >>>>>>> Regarding the first assumption, this fails when a token might be =
re-
> issued between devices. An example is that we use MAC token for the clien=
t
> credentials, which are issued when a developer registers an application. =
The
> client has no way of determining on its own when the value was actually
> issued (unless we communicate that on the developer website and force
> users to embed that with client_id, which adds usability issues of users
> copying and entering string date values correctly). The same is actually =
true
> for all of our OAuth access tokens because we reissue tokens to the same
> client_id if they were previously issued and are still valid. (The client=
 would
> thus think the issue_date was now() when if fact it was the time of the f=
irst
> issue for client_id+scope+grantor_id). Thus, age is really just a convolu=
ted
> way of trying to communicate the device system offset:
> >>>>>>>
> >>>>>>>        local_offset =3D current_server_time - current_device_time
> >>>>>>>        age =3D current_device_time -
> >>>>>>> (server_issue_date-local_offset)
> >>>>>>>
> >>>>>>> Since the protocol doesn't currently allow for server_issue_date =
to
> be given with tokens, thus age currently can't have the resilience that
> timestamp does. It also forces servers to issue new tokens on demand just
> to make the convoluted age system work (rather than reuse existing valid
> tokens). Or, you have to modify the protocol to add server_issue_date and
> current_server_time into the token-issue exchange - eg, more complexity.
> >>>>>>>
> >>>>>>> Timestamp is simpler, proven, it and it has a solution for your u=
se
> case of unsyncronized clocks.
> >>>>>>>
> >>>>>>> skylar
> >>>>>>>
> >>>>>>>
> >>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
> >>>>>>>> don't have synchronized clocks, for a wide variety of reasons.
> >>>>>>>> I guess I don't really understand why you view age as
> >>>>>>>> problematic.  You reference "fragility of using
> >>>>>>>> time-since-credentials-issued" but you don't say what exactly
> >>>>>>>> is fragile about it.  There's nothing particularly complex
> >>>>>>>> about age, especially when using the monotonic clock provided by
> all modern operating systems.
> >>>>>>>>
> >>>>>>>> Adam
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>  wrote:
> >>>>>>>>
> >>>>>>>>> But see, now you are specializing the use of MAC token even
> more - now it's becoming a service mainly for user-agents on home
> desktops? This is further for the original goal of making MAC as flexible=
 is
> possible. In this case you should change the spec name to
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> REFOX - or MTBCRLF for short.
> >>>>>>>>>
> >>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as yo=
ur
> offset technique and is more: reliable, straightforward, flexible.
> >>>>>>>>>
> >>>>>>>>> User agents that care about creating robust behavior for home
> desktops or mobiles (presumably of users and OS not yet sophisticated
> enough to check network time on their own) should be advised to do clock
> correction on their own (by pinging a time service) and trusting the devi=
ce
> clock alone.
> >>>>>>>>>
> >>>>>>>>> Please change the spec back to using timestamp rather than age.
> >>>>>>>>>
> >>>>>>>>> I'd also like to hear a convincing argument from the Mozilla co=
-
> authors about why they think that age is more resilient than the above (I
> believe it is not) and further more why they would find the above
> unattractive or difficult to implement in a modern user-agent.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> skylar
> >>>>>>>>>
> >>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - ...=
 -.- -.-- .-.. .- .-. - .-
> - --- --- -.. .-- .- .-. -..
> >>>>>>>>> skylar woodward
> >>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Any kind of clock sync requirement for user-agents (basically,
> home desktops) it completely impractical. The added complexity pales in
> comparison to the difficulty of trying to use timestamps and any kind of =
clock
> sync. No window will be big enough as experience shows some users have
> closes that are off by more than an hour and a half.
> >>>>>>>>>>
> >>>>>>>>>> The issue here is who is this being optimized for. Server-to-
> server communication should simply use TLS for privacy and MITM protectio=
n
> on top of MAC instead of using nonces to prevent replay. The whole point =
of
> this kind of replay protection is when TLS is not available.
> >>>>>>>>>>
> >>>>>>>>>> I think a better approach is to simply make checking the nonce
> optional when TLS is used.
> >>>>>>>>>>
> >>>>>>>>>> EHL
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> bounces@ietf.org]
> >>>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
> element -
> >>>>>>>>>>> MAC token
> >>>>>>>>>>>
> >>>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>>> time-since-credentials-issued, and also the added complexity
> of specifying this construction.
> >>>>>>>>>>>
> >>>>>>>>>>> I think it would be preferable to always require a timestamp
> >>>>>>>>>>> as part of the authorization header, and maybe even include
> >>>>>>>>>>> in the spec a maximum time difference between client and
> >>>>>>>>>>> server (e.g. 900 seconds) that can be tolerated.  This makes
> >>>>>>>>>>> generating the nonce easier also, since the value need to
> longer be unique over all time.
> >>>>>>>>>>>
> >>>>>>>>>>> We have such rules in place for an HMAC-based
> authentication
> >>>>>>>>>>> system we use.  Once in a while a client has a local clock
> >>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
> >>>>>>>>>>>
> >>>>>>>>>>> -Peter
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>>> 
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>>
> >>>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth
> WG
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element -
> >>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So after discussing this today and reflecting on it a bit,
> >>>>>>>>>>>>> I would suggest that
> >>>>>>>>>>>>>
> >>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>>> without further requirements. It might be suggested that
> >>>>>>>>>>> this be composed of an
> >>>>>>>>>>> random+timestamp (not age) value, but that seems more of a
> >>>>>>>>>>> random+MAY or
> >>>>>>>>>>> "recommended" practice. If the expectation is that very few
> >>>>>>>>>>> if any providers would actually check the timestamp (or
> >>>>>>>>>>> moreover, the nonce itself), why add terminology in the
> >>>>>>>>>>> draft that requires it? Developers are doing extra
> >>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with
> no payoff or added security.
> >>>>>>>>>>>
> >>>>>>>>>>>>> I'm sending this feedback based on having implemented
> the
> >>>>>>>>>>>>> v3-5 changes
> >>>>>>>>>>>>>
> >>>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>>> access tokens). After the changes, the nonce creation is now
> >>>>>>>>>>> the most complicated part of the normalized request string
> and yet these changes offer the least benefit.
> >>>>>>>>>>> What's most important is that nonces are unique on each
> request for an ID.
> >>>>>>>>>>>
> >>>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
> >>>>>>>>>>>>> based on receipt, then the internal clock changes
> >>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
> >>>>>>>>>>>>> dates) then time will also fail. Assuming that a user with
> >>>>>>>>>>>>> a bad clock (of by hours or more) will never fix it and
> >>>>>>>>>>>>> actually encourages bad user behavior (don't fix your
> >>>>>>>>>>>>> clock or Twitterbot will stop working!). Though we say
> >>>>>>>>>>>>> that timezones won't bring about the situation of changed
> >>>>>>>>>>>>> clock, I'd be to differ. Many users aren't savvy enough to
> >>>>>>>>>>>>> change time zone, but just adjust the time to local time
> >>>>>>>>>>>>> anyway. Users who are more likely to get it right already
> >>>>>>>>>>>>> have auto clock sync enabled (via web, mobile, etc.)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>>>>>
> >>>>>>>>>>> the issue time has to be obtained from the server and stored
> >>>>>>>>>>> on the client then you have the same problem as with a
> >>>>>>>>>>> timestamp - the client clock is not sync'd to the server
> >>>>>>>>>>> clock and there is no adjustment. You want this to apply to
> >>>>>>>>>>> uses outside of just OAuth, but now requiring the client to
> >>>>>>>>>>> be able to determine an issue time based on when it receives
> an HTTP request necessarily limits the types of token flows for which thi=
s can
> be used.
> >>>>>>>>>>>
> >>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>>> developer, but it is
> >>>>>>>>>>>>>
> >>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID,
> >>>>>>>>>>> it is actually more of a recording of "my personal clock
> >>>>>>>>>>> offset value" but obfuscated several times over (one for each
> token) as issue_date.
> >>>>>>>>>>>
> >>>>>>>>>>>>> - This implementation assumes software programs use the
> >>>>>>>>>>>>> computer
> >>>>>>>>>>>>>
> >>>>>>>>>>> internal clock exclusively for timestamp. A robust program
> >>>>>>>>>>> that is dependent on accurate timestamps would ping the
> >>>>>>>>>>> origin server (or similar trusted time
> >>>>>>>>>>> authority) to ask it the current time. Then it could store a
> >>>>>>>>>>> "my device clock offset" value for the lifetime of the
> >>>>>>>>>>> program execution. All requests needing timestamp would be
> >>>>>>>>>>> adjusted accordingly. For age, if the clock is changed since =
the
> stored issue_date, the problem can't be corrected in this manner.
> >>>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>
> >>>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>>>>>
> >>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
> >>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more I
> >>>>>>>>>>> think about the implications of the age parameter, the less
> >>>>>>>>>>> I like it. Timestamp has been used for many years in the
> >>>>>>>>>>> industry and with reasonable success in relevant
> >>>>>>>>>>> applications. If we change to a new way of trying to sync on
> time I think we run a greater risk of stumbling upon unforeseen issues, s=
uch
> as those outlined above.
> >>>>>>>>>>>
> >>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for
> >>>>>>>>>>>>> that matter)
> >>>>>>>>>>>>>
> >>>>>>>>>>> be dropped from the nonce construction. For providers that
> >>>>>>>>>>> deem it valuable, timestamp can be an optional value (either
> >>>>>>>>>>> as part of the nonce or the overall header, as before).
> >>>>>>>>>>>
> >>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> "example.net"
> >>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
> >>>>>>>>>>>>>> Certainly addresses my
> >>>>>>>>>>>>>>
> >>>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>
> >>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-
> tok
> >>>>>>>>>>>>>>> en
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
> >>>>>>>>>>>>>>> mailing list for the
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> time being, I wanted to give a quick update to those who
> >>>>>>>>>>> have been following this draft which originated on this list.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
> draft
> >>>>>>>>>>>>>>> is now a
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> general purpose HTTP authentication scheme. It does include
> >>>>>>>>>>> an OAuth 2.0 binding which is described in less than a page.
> >>>>>>>>>>> One suggestion would be to move section 5.1 into the OAuth
> >>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
> draft.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> session cookies.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * Removed request URI query normalization. The new
> draft
> >>>>>>>>>>>>>>> uses the
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove
> the
> >>>>>>>>>>>>>>> need for
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> clock sync.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
> >>>>>>>>>>>>>>> text to be
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
> >>>>>>>>>>>>>>> the credentials as
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> an additional protection.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia.
> Inc.
> >>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>>
> >>>>>>>>>>> "Get a free, hosted Drupal 7 site:
> http://www.drupalgardens.com"
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> OAuth mailing list
> >>>>>>>>> OAuth@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From eran@hueniverse.com  Tue May 31 17: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 9BF59E08C9 for ; Tue, 31 May 2011 17:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Level: 
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, 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 8h45TIu5+J+X for ; Tue, 31 May 2011 17:08: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 33F66E08DE for ; Tue, 31 May 2011 17:08:09 -0700 (PDT)
Received: (qmail 13680 invoked from network); 1 Jun 2011 00:08:08 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 00:08:08 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 31 May 2011 17:08:04 -0700
From: Eran Hammer-Lahav 
To: Phil Hunt , Adam Barth 
Date: Tue, 31 May 2011 17:07:36 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: Acwf4wyn8wzgTIqlQ42KdFGl99XvQwADMbIw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA406@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com>
In-Reply-To: <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.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
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 00:08:11 -0000

Adam and I have discussed a proposal which should address everyone's use ca=
ses. I will post shortly. Just FYI so people don't invest too much time in =
this thread...

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday, May 31, 2011 3:35 PM
> To: Adam Barth
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> There seems to be a demonstrated need for both age and timestamp
> tokens.
>
> The list has 2 separate cases with 2 separate proposals that do not solve=
 all
> cases.
>
> Can we at least agree that neither proposal works in all cases?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>
> > You haven't described a problem.
> >
> > On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
> wrote:
> >> First we should agree on a common understanding of the spec. The
> reason why age works with unsynchronized clocks is that the client
> determines issue_date based on the time when it receives the token over
> the wire. This depends on the server and client both recording time this =
way
> and for the transmission of the token to be be not longer than the margin=
 of
> error for validating age. Are we agreed on this understanding?
> >
> > That's not correct.
> >
> > The age allows the server to protect against replay attacks in bounded
> > memory.  With unbounded memory, the server can just remember every
> > nonce it has ever seen associated with a given key and reject replays.
> > With bounded memory, the server eventually needs to evict some of
> > these nonces due to memory pressure.  The age value lets the server
> > reject the nonces with the smallest age values first.  The server then
> > rejects any messages with age values smaller than (or equal to) the
> > largest age value it has ever evicted for the given key.
> >
> > Notice that neither clock synchronization nor transmission time plays
> > a role in that implementation.
> >
> >> The easiest case for me to explain here is client credentials because =
I have
> to assume you've built and registered a Twitter app at some point (or sim=
ilar
> OAuth 1.0a app). You registered your app on the site and were issued a
> client_id and client_secret (called consumer_key and consumer_secret in
> 1.0). You then embedded these values in your client (they were not issued
> programmatically to your app). Assuming the MAC token algorithm is used
> then for establishing client identity (originally one of the uses we, the
> working group, hoped MAC would cover) how then will your client
> determine issue date?
> >
> > I recommend the date at which the developer obtained the credential
> > from Twitter because that is the date when the credential was issued.
> >
> >> After we can establish where you're at on the two above points I'll
> continue with the explanation. But as a preview, the next points would be=
:
> >>
> >> - If issue_date comes form the server, how is it translated to the cli=
ent?
> >
> > The issue_date does not come from the server.
> >
> >> - If you use a server provided issue_date, how do you then translate t=
hat
> a value relative to the local unsyncronized clock?
> >
> > The server does not provide the issue_date.
> >
> >> - If your answer to that is to also provide the current server time to=
 the
> client so the offset on the server provided issue_date can be calculated =
what
> is the difference between all of these values and just using timestamp?
> >
> > My answer is not to provide the current server time to the client.
> >
> > Kind regards,
> > Adam
> >
> >
> >> So don't get wrapped up in those 3 questions until we establish your
> contextual understanding of the first two paragraphs. Feel free to also
> respond to me off the list so we don't trouble everyone else with us gett=
ing
> on the same page (the reason, I thought, why a Skype call would be more
> efficient and painless). I do think my explanations all have been very cl=
ear
> thus far. There must be a contextual confusion that is keeping us from a
> common understanding of the terminology or the use cases.
> >>
> >> skylar
> >>
> >>
> >> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>
> >>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>> caused by age clearly?  I didn't understand your previous
> >>> explanation.  The more concrete you can be, the better.
> >>>
> >>> Thanks,
> >>> Adam
> >>>
> >>>
> >>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward 
> wrote:
> >>>> It seems we're failing to communicate. Or you're not understanding m=
y
> use cases. Age doesn't "just" work. It only works for a limited number of=
 uses
> cases that must include all of yours - and it is brittle at that. It does=
n't work
> for any of our uses cases (where the client can't know issue_date w/o the
> server telling it - in which case we have the equivalent problem as
> timestamp).
> >>>>
> >>>> If you'd like to talk this out over Skype I'm happy to do that, so I=
 can
> help you understand why age doesn't work.
> >>>>
> >>>>
> >>>>
> >>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>
> >>>>> Timestamps don't work when the client doesn't have a synchronized
> >>>>> clock.  It's true that a client could synchronize its clock with
> >>>>> the network, but our implementation experience is that many
> >>>>> clients don't for a variety of reasons.  That means that age
> >>>>> better because, you know, it works.
> >>>>>
> >>>>> Adam
> >>>>>
> >>>>>
> >>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>  wrote:
> >>>>>> I don't think you read my first message on the topic (or I wrote t=
oo
> much).
> >>>>>>
> >>>>>> Age is fragile because if the clock changes between issue_date and
> the time of submission, it will fail. We know many people don't have
> synchronized clocks, but using age only solves this problem if two
> assumptions hold true:
> >>>>>>
> >>>>>> 1) the client is able to guess the issue_date the server is using
> >>>>>> based on the time the credential was issued
> >>>>>> 2) the client system clock doesn't change between issue date and
> submission time.
> >>>>>>
> >>>>>> Timestamp has neither of these issues because the client can alway=
s
> inquire about network time and can effectively correct for inaccuracies i=
n the
> device timekeeping system.
> >>>>>>
> >>>>>> Regarding the first assumption, this fails when a token might be r=
e-
> issued between devices. An example is that we use MAC token for the clien=
t
> credentials, which are issued when a developer registers an application. =
The
> client has no way of determining on its own when the value was actually
> issued (unless we communicate that on the developer website and force
> users to embed that with client_id, which adds usability issues of users
> copying and entering string date values correctly). The same is actually =
true
> for all of our OAuth access tokens because we reissue tokens to the same
> client_id if they were previously issued and are still valid. (The client=
 would
> thus think the issue_date was now() when if fact it was the time of the f=
irst
> issue for client_id+scope+grantor_id). Thus, age is really just a convolu=
ted
> way of trying to communicate the device system offset:
> >>>>>>
> >>>>>>        local_offset =3D current_server_time - current_device_time
> >>>>>>        age =3D current_device_time -
> >>>>>> (server_issue_date-local_offset)
> >>>>>>
> >>>>>> Since the protocol doesn't currently allow for server_issue_date t=
o
> be given with tokens, thus age currently can't have the resilience that
> timestamp does. It also forces servers to issue new tokens on demand just
> to make the convoluted age system work (rather than reuse existing valid
> tokens). Or, you have to modify the protocol to add server_issue_date and
> current_server_time into the token-issue exchange - eg, more complexity.
> >>>>>>
> >>>>>> Timestamp is simpler, proven, it and it has a solution for your us=
e
> case of unsyncronized clocks.
> >>>>>>
> >>>>>> skylar
> >>>>>>
> >>>>>>
> >>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>
> >>>>>>> I can't speak for Mozilla, but I can tell you that many folks
> >>>>>>> don't have synchronized clocks, for a wide variety of reasons.
> >>>>>>> I guess I don't really understand why you view age as
> >>>>>>> problematic.  You reference "fragility of using
> >>>>>>> time-since-credentials-issued" but you don't say what exactly is
> >>>>>>> fragile about it.  There's nothing particularly complex about
> >>>>>>> age, especially when using the monotonic clock provided by all
> modern operating systems.
> >>>>>>>
> >>>>>>> Adam
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>  wrote:
> >>>>>>>> But see, now you are specializing the use of MAC token even
> more - now it's becoming a service mainly for user-agents on home
> desktops? This is further for the original goal of making MAC as flexible=
 is
> possible. In this case you should change the spec name to
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> REFOX - or MTBCRLF for short.
> >>>>>>>>
> >>>>>>>> Sarcasm aside, my point is that timestamp is just as good as you=
r
> offset technique and is more: reliable, straightforward, flexible.
> >>>>>>>>
> >>>>>>>> User agents that care about creating robust behavior for home
> desktops or mobiles (presumably of users and OS not yet sophisticated
> enough to check network time on their own) should be advised to do clock
> correction on their own (by pinging a time service) and trusting the devi=
ce
> clock alone.
> >>>>>>>>
> >>>>>>>> Please change the spec back to using timestamp rather than age.
> >>>>>>>>
> >>>>>>>> I'd also like to hear a convincing argument from the Mozilla co-
> authors about why they think that age is more resilient than the above (I
> believe it is not) and further more why they would find the above
> unattractive or difficult to implement in a modern user-agent.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> skylar
> >>>>>>>>
> >>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - ... =
-.- -.-- .-.. .- .-. - .--
> --- --- -.. .-- .- .-. -..
> >>>>>>>> skylar woodward
> >>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>
> >>>>>>>>> Any kind of clock sync requirement for user-agents (basically,
> home desktops) it completely impractical. The added complexity pales in
> comparison to the difficulty of trying to use timestamps and any kind of =
clock
> sync. No window will be big enough as experience shows some users have
> closes that are off by more than an hour and a half.
> >>>>>>>>>
> >>>>>>>>> The issue here is who is this being optimized for. Server-to-
> server communication should simply use TLS for privacy and MITM protectio=
n
> on top of MAC instead of using nonces to prevent replay. The whole point =
of
> this kind of replay protection is when TLS is not available.
> >>>>>>>>>
> >>>>>>>>> I think a better approach is to simply make checking the nonce
> optional when TLS is used.
> >>>>>>>>>
> >>>>>>>>> EHL
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> bounces@ietf.org]
> >>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element
> -
> >>>>>>>>>> MAC token
> >>>>>>>>>>
> >>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>> time-since-credentials-issued, and also the added complexity
> of specifying this construction.
> >>>>>>>>>>
> >>>>>>>>>> I think it would be preferable to always require a timestamp
> >>>>>>>>>> as part of the authorization header, and maybe even include
> >>>>>>>>>> in the spec a maximum time difference between client and
> >>>>>>>>>> server (e.g. 900 seconds) that can be tolerated.  This makes
> >>>>>>>>>> generating the nonce easier also, since the value need to
> longer be unique over all time.
> >>>>>>>>>>
> >>>>>>>>>> We have such rules in place for an HMAC-based authentication
> >>>>>>>>>> system we use.  Once in a while a client has a local clock so
> >>>>>>>>>> far out of sync that there is an issue, but it's rare.
> >>>>>>>>>>
> >>>>>>>>>> -Peter
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>> 
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>
> >>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>
> >>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth
> WG
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element -
> MAC
> >>>>>>>>>>>> token
> >>>>>>>>>>>>
> >>>>>>>>>>>> So after discussing this today and reflecting on it a bit,
> >>>>>>>>>>>> I would suggest that
> >>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>> without further requirements. It might be suggested that this
> >>>>>>>>>> be composed of an
> >>>>>>>>>> random+timestamp (not age) value, but that seems more of a
> >>>>>>>>>> random+MAY or
> >>>>>>>>>> "recommended" practice. If the expectation is that very few
> >>>>>>>>>> if any providers would actually check the timestamp (or
> >>>>>>>>>> moreover, the nonce itself), why add terminology in the draft
> >>>>>>>>>> that requires it? Developers are doing extra housekeeping
> >>>>>>>>>> (and perhaps for a perceived benefit) but with no payoff or
> added security.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm sending this feedback based on having implemented the
> >>>>>>>>>>>> v3-5 changes
> >>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>> access tokens). After the changes, the nonce creation is now
> >>>>>>>>>> the most complicated part of the normalized request string and
> yet these changes offer the least benefit.
> >>>>>>>>>> What's most important is that nonces are unique on each
> request for an ID.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
> >>>>>>>>>>>> based on receipt, then the internal clock changes
> >>>>>>>>>>>> (presumably w/o knowledge of the software storing the
> >>>>>>>>>>>> dates) then time will also fail. Assuming that a user with
> >>>>>>>>>>>> a bad clock (of by hours or more) will never fix it and
> >>>>>>>>>>>> actually encourages bad user behavior (don't fix your clock
> >>>>>>>>>>>> or Twitterbot will stop working!). Though we say that
> >>>>>>>>>>>> timezones won't bring about the situation of changed clock,
> >>>>>>>>>>>> I'd be to differ. Many users aren't savvy enough to change
> >>>>>>>>>>>> time zone, but just adjust the time to local time anyway.
> >>>>>>>>>>>> Users who are more likely to get it right already have auto
> >>>>>>>>>>>> clock sync enabled (via web, mobile, etc.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>> the issue time has to be obtained from the server and stored
> >>>>>>>>>> on the client then you have the same problem as with a
> >>>>>>>>>> timestamp - the client clock is not sync'd to the server
> >>>>>>>>>> clock and there is no adjustment. You want this to apply to
> >>>>>>>>>> uses outside of just OAuth, but now requiring the client to
> >>>>>>>>>> be able to determine an issue time based on when it receives
> an HTTP request necessarily limits the types of token flows for which thi=
s can
> be used.
> >>>>>>>>>>>>
> >>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>> developer, but it is
> >>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID,
> >>>>>>>>>> it is actually more of a recording of "my personal clock
> >>>>>>>>>> offset value" but obfuscated several times over (one for each
> token) as issue_date.
> >>>>>>>>>>>>
> >>>>>>>>>>>> - This implementation assumes software programs use the
> >>>>>>>>>>>> computer
> >>>>>>>>>> internal clock exclusively for timestamp. A robust program
> >>>>>>>>>> that is dependent on accurate timestamps would ping the
> >>>>>>>>>> origin server (or similar trusted time
> >>>>>>>>>> authority) to ask it the current time. Then it could store a
> >>>>>>>>>> "my device clock offset" value for the lifetime of the
> >>>>>>>>>> program execution. All requests needing timestamp would be
> >>>>>>>>>> adjusted accordingly. For age, if the clock is changed since t=
he
> stored issue_date, the problem can't be corrected in this manner.
> >>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>>
> >>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
> >>>>>>>>>> hack and it certainly isn't a foolproof solution. The more I
> >>>>>>>>>> think about the implications of the age parameter, the less I
> >>>>>>>>>> like it. Timestamp has been used for many years in the
> >>>>>>>>>> industry and with reasonable success in relevant
> >>>>>>>>>> applications. If we change to a new way of trying to sync on
> time I think we run a greater risk of stumbling upon unforeseen issues, s=
uch
> as those outlined above.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I recommend the requirement of an age (or timestamp for
> >>>>>>>>>>>> that matter)
> >>>>>>>>>> be dropped from the nonce construction. For providers that
> >>>>>>>>>> deem it valuable, timestamp can be an optional value (either
> >>>>>>>>>> as part of the nonce or the overall header, as before).
> >>>>>>>>>>>>
> >>>>>>>>>>>> skylar
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> "example.net"
> >>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> All in all, I'm in support of the changes in v2. Certainly
> >>>>>>>>>>>>> addresses my
> >>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-
> toke
> >>>>>>>>>>>>>> n
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
> mailing
> >>>>>>>>>>>>>> list for the
> >>>>>>>>>> time being, I wanted to give a quick update to those who have
> >>>>>>>>>> been following this draft which originated on this list.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Removed OAuth terminology and association. The draft
> is
> >>>>>>>>>>>>>> now a
> >>>>>>>>>> general purpose HTTP authentication scheme. It does include
> >>>>>>>>>> an OAuth 2.0 binding which is described in less than a page.
> >>>>>>>>>> One suggestion would be to move section 5.1 into the OAuth
> >>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
> draft.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> session cookies.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Removed request URI query normalization. The new
> draft
> >>>>>>>>>>>>>> uses the
> >>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove
> the
> >>>>>>>>>>>>>> need for
> >>>>>>>>>> clock sync.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
> text
> >>>>>>>>>>>>>> to be
> >>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
> >>>>>>>>>>>>>> the credentials as
> >>>>>>>>>> an additional protection.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. I=
nc.
> >>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>
> >>>>>>>>>> "Get a free, hosted Drupal 7 site:
> http://www.drupalgardens.com"
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> OAuth mailing list
> >>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> OAuth mailing list
> >>>>>>>> OAuth@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From beaton@google.com  Tue May 31 17:37: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 80104E06F0 for ; Tue, 31 May 2011 17:37: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 8Z3nhLJK0Eyp for ; Tue, 31 May 2011 17:37:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DE020E06DD for ; Tue, 31 May 2011 17:37:24 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p510bNgJ001940 for ; Tue, 31 May 2011 17:37:23 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306888644; bh=l9SjqBLAY0ZVFMgSMapdyYeSZkg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=JKlTTv+NSN3rRTUWAW4VNNHXPoNKrW/ozKXDj1qJgvhSUAMkHEr6ovFjE7On/cAUw 1qttpxEIYMkGD3aOgSBZQ==
Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by kpbe19.cbf.corp.google.com with ESMTP id p510aOWB008428 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 17:37:22 -0700
Received: by pxi11 with SMTP id 11so2917813pxi.21 for ; Tue, 31 May 2011 17:37: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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sgv2PC6GByz6dW0wJT2VGw4NX5gurVxpvrBgNGUymZk=; b=nUSgPnlLxCW2VT8kIH0y5fdn90hncUE4tW+0hPQn3bNr9ZBPsX+ilOeRUzm3ToQ4SR O0nuHL15KYMPEAxQzmrw==
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=Uvq8aufY4fKCGqf8Tw7chSpyRJoM06rlE6VA9NZzYQ/EnIB9I1ieZ7hNi0lvlcIlcI YgSdR/MPIDT4S9fyV7wA==
MIME-Version: 1.0
Received: by 10.142.221.1 with SMTP id t1mr1116065wfg.437.1306888642378; Tue, 31 May 2011 17:37:22 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Tue, 31 May 2011 17:37:22 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry> 
Date: Tue, 31 May 2011 17:37:22 -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 00:37:26 -0000

On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
 wrote:
> Updated in language I just sent out =96 thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances. =A0=A0Facebook in turn uses =
the
> implicit grant type, and simply issues long term access_tokens.
>
> Are there any strong objections to adding optional support for
> referesh_token on the implicit grant along with security considerations?

Is that really necessary?  Why?

The justification of reduced network round trips seems bogus to me.
We're talking about clients that just loaded up an entire web page,
asked the user to login, picked up a redirect, and are about to make
at least one and possibly several other API calls.

I'd prefer to keep the spec simple and consistent.  We can add all
kinds of options and maybes to the language, but long-term it will
just hurt interop.  I'd rather settle on protocol flows that make
sense.

One risk that comes up with returning refresh tokens with the implicit
grant type involves recovering from compromise of client web servers.
That's not strictly relevant to the current distinction (we're talking
about installed apps, different threat model), but it might be worth
thinking about anyway.

Consider what happens when a client web server is compromised and the
client secret and refresh tokens are stolen.
- the attacker can use the tokens until the compromise is discovered.
- the client secret is then changed
- the stolen refresh tokens then become useless

Now, *if* the implicit grant type returns refresh token, that story
changes.  Even if the client secret is changed, the attacker can keep
using the refresh tokens!  They do it by passing them to the victim
client again, through the implicit grant flow.  The victim client will
then link the refresh token to the attacker's account.

From igor.faynberg@alcatel-lucent.com  Tue May 31 18:15: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 90E63E0763 for ; Tue, 31 May 2011 18:15:12 -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, 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 HZCDuKETBH7B for ; Tue, 31 May 2011 18:15:10 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 70290E06B9 for ; Tue, 31 May 2011 18:15:10 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p511F7PP017442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2011 20:15:07 -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 p511F6ks004984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 20:15:06 -0500
Received: from [135.244.19.60] (faynberg.lra.lucent.com [135.244.19.60]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p511F5R6001124; Tue, 31 May 2011 20:15:05 -0500 (CDT)
Message-ID: <4DE59299.2020909@alcatel-lucent.com>
Date: Tue, 31 May 2011 21:15:05 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Eran Hammer-Lahav 
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>				<0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.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.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
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
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: Wed, 01 Jun 2011 01:15:12 -0000

Maybe...  But this information must be captured somewhere, right?

At the moment, there seems to be no record of and consequently no 
reference point to the use case in question. And this is what has 
created all this discussion--with messages coming from all directions.

Igor

Eran Hammer-Lahav wrote:
> I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded.
>
> EHL
>
>   
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Igor Faynberg
>> Sent: Tuesday, May 31, 2011 3:50 PM
>> To: Phil Hunt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> ...Sorry to turn the question around so as to underline my pet peeve:
>> Have we *documented* all cases?  (This is what the Use Cases document is
>> supposed to be all about.)
>>
>> Just to clarify: I am not arguing with Phil's point now. I just stress that as of
>> this moment we don't have anything to check against.
>>
>> Igor
>>
>> Phil Hunt wrote:
>>     
>>> There seems to be a demonstrated need for both age and timestamp
>>>       
>> tokens.
>>     
>>> The list has 2 separate cases with 2 separate proposals that do not solve all
>>>       
>> cases.
>>     
>>> Can we at least agree that neither proposal works in all cases?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>>
>>>
>>>       
>>>> You haven't described a problem.
>>>>
>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
>>>>         
>> wrote:
>>     
>>>>> First we should agree on a common understanding of the spec. The
>>>>>           
>> reason why age works with unsynchronized clocks is that the client
>> determines issue_date based on the time when it receives the token over
>> the wire. This depends on the server and client both recording time this way
>> and for the transmission of the token to be be not longer than the margin of
>> error for validating age. Are we agreed on this understanding?
>>     
>>>> That's not correct.
>>>>
>>>> The age allows the server to protect against replay attacks in
>>>> bounded memory.  With unbounded memory, the server can just
>>>>         
>> remember
>>     
>>>> every nonce it has ever seen associated with a given key and reject
>>>>         
>> replays.
>>     
>>>> With bounded memory, the server eventually needs to evict some of
>>>> these nonces due to memory pressure.  The age value lets the server
>>>> reject the nonces with the smallest age values first.  The server
>>>> then rejects any messages with age values smaller than (or equal to)
>>>> the largest age value it has ever evicted for the given key.
>>>>
>>>> Notice that neither clock synchronization nor transmission time plays
>>>> a role in that implementation.
>>>>
>>>>
>>>>         
>>>>> The easiest case for me to explain here is client credentials because I
>>>>>           
>> have to assume you've built and registered a Twitter app at some point (or
>> similar OAuth 1.0a app). You registered your app on the site and were issued
>> a client_id and client_secret (called consumer_key and consumer_secret in
>> 1.0). You then embedded these values in your client (they were not issued
>> programmatically to your app). Assuming the MAC token algorithm is used
>> then for establishing client identity (originally one of the uses we, the
>> working group, hoped MAC would cover) how then will your client
>> determine issue date?
>>     
>>>> I recommend the date at which the developer obtained the credential
>>>> from Twitter because that is the date when the credential was issued.
>>>>
>>>>
>>>>         
>>>>> After we can establish where you're at on the two above points I'll
>>>>>           
>> continue with the explanation. But as a preview, the next points would be:
>>     
>>>>> - If issue_date comes form the server, how is it translated to the client?
>>>>>
>>>>>           
>>>> The issue_date does not come from the server.
>>>>
>>>>
>>>>         
>>>>> - If you use a server provided issue_date, how do you then translate
>>>>>           
>> that a value relative to the local unsyncronized clock?
>>     
>>>> The server does not provide the issue_date.
>>>>
>>>>
>>>>         
>>>>> - If your answer to that is to also provide the current server time to the
>>>>>           
>> client so the offset on the server provided issue_date can be calculated what
>> is the difference between all of these values and just using timestamp?
>>     
>>>> My answer is not to provide the current server time to the client.
>>>>
>>>> Kind regards,
>>>> Adam
>>>>
>>>>
>>>>
>>>>         
>>>>> So don't get wrapped up in those 3 questions until we establish your
>>>>>           
>> contextual understanding of the first two paragraphs. Feel free to also
>> respond to me off the list so we don't trouble everyone else with us getting
>> on the same page (the reason, I thought, why a Skype call would be more
>> efficient and painless). I do think my explanations all have been very clear
>> thus far. There must be a contextual confusion that is keeping us from a
>> common understanding of the terminology or the use cases.
>>     
>>>>> skylar
>>>>>
>>>>>
>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
>>>>>> caused by age clearly?  I didn't understand your previous
>>>>>> explanation.  The more concrete you can be, the better.
>>>>>>
>>>>>> Thanks,
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward 
>>>>>>             
>> wrote:
>>     
>>>>>>> It seems we're failing to communicate. Or you're not understanding
>>>>>>>               
>> my use cases. Age doesn't "just" work. It only works for a limited number of
>> uses cases that must include all of yours - and it is brittle at that. It doesn't
>> work for any of our uses cases (where the client can't know issue_date w/o
>> the server telling it - in which case we have the equivalent problem as
>> timestamp).
>>     
>>>>>>> If you'd like to talk this out over Skype I'm happy to do that, so I can
>>>>>>>               
>> help you understand why age doesn't work.
>>     
>>>>>>>
>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Timestamps don't work when the client doesn't have a synchronized
>>>>>>>> clock.  It's true that a client could synchronize its clock with
>>>>>>>> the network, but our implementation experience is that many
>>>>>>>> clients don't for a variety of reasons.  That means that age
>>>>>>>> better because, you know, it works.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>>>>>>>>                 
>>  wrote:
>>     
>>>>>>>>> I don't think you read my first message on the topic (or I wrote too
>>>>>>>>>                   
>> much).
>>     
>>>>>>>>> Age is fragile because if the clock changes between issue_date and
>>>>>>>>>                   
>> the time of submission, it will fail. We know many people don't have
>> synchronized clocks, but using age only solves this problem if two
>> assumptions hold true:
>>     
>>>>>>>>> 1) the client is able to guess the issue_date the server is
>>>>>>>>> using based on the time the credential was issued
>>>>>>>>> 2) the client system clock doesn't change between issue date and
>>>>>>>>>                   
>> submission time.
>>     
>>>>>>>>> Timestamp has neither of these issues because the client can
>>>>>>>>>                   
>> always inquire about network time and can effectively correct for
>> inaccuracies in the device timekeeping system.
>>     
>>>>>>>>> Regarding the first assumption, this fails when a token might be re-
>>>>>>>>>                   
>> issued between devices. An example is that we use MAC token for the client
>> credentials, which are issued when a developer registers an application. The
>> client has no way of determining on its own when the value was actually
>> issued (unless we communicate that on the developer website and force
>> users to embed that with client_id, which adds usability issues of users
>> copying and entering string date values correctly). The same is actually true
>> for all of our OAuth access tokens because we reissue tokens to the same
>> client_id if they were previously issued and are still valid. (The client would
>> thus think the issue_date was now() when if fact it was the time of the first
>> issue for client_id+scope+grantor_id). Thus, age is really just a convoluted
>> way of trying to communicate the device system offset:
>>     
>>>>>>>>>        local_offset = current_server_time - current_device_time
>>>>>>>>>        age = current_device_time -
>>>>>>>>> (server_issue_date-local_offset)
>>>>>>>>>
>>>>>>>>> Since the protocol doesn't currently allow for server_issue_date to
>>>>>>>>>                   
>> be given with tokens, thus age currently can't have the resilience that
>> timestamp does. It also forces servers to issue new tokens on demand just
>> to make the convoluted age system work (rather than reuse existing valid
>> tokens). Or, you have to modify the protocol to add server_issue_date and
>> current_server_time into the token-issue exchange - eg, more complexity.
>>     
>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for your use
>>>>>>>>>                   
>> case of unsyncronized clocks.
>>     
>>>>>>>>> skylar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
>>>>>>>>>> don't have synchronized clocks, for a wide variety of reasons.
>>>>>>>>>> I guess I don't really understand why you view age as
>>>>>>>>>> problematic.  You reference "fragility of using
>>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
>>>>>>>>>> is fragile about it.  There's nothing particularly complex
>>>>>>>>>> about age, especially when using the monotonic clock provided by
>>>>>>>>>>                     
>> all modern operating systems.
>>     
>>>>>>>>>> Adam
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>>>>>>>>>>                     
>>  wrote:
>>     
>>>>>>>>>>> But see, now you are specializing the use of MAC token even
>>>>>>>>>>>                       
>> more - now it's becoming a service mainly for user-agents on home
>> desktops? This is further for the original goal of making MAC as flexible is
>> possible. In this case you should change the spec name to
>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
>> REFOX - or MTBCRLF for short.
>>     
>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as your
>>>>>>>>>>>                       
>> offset technique and is more: reliable, straightforward, flexible.
>>     
>>>>>>>>>>> User agents that care about creating robust behavior for home
>>>>>>>>>>>                       
>> desktops or mobiles (presumably of users and OS not yet sophisticated
>> enough to check network time on their own) should be advised to do clock
>> correction on their own (by pinging a time service) and trusting the device
>> clock alone.
>>     
>>>>>>>>>>> Please change the spec back to using timestamp rather than age.
>>>>>>>>>>>
>>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla co-
>>>>>>>>>>>                       
>> authors about why they think that age is more resilient than the above (I
>> believe it is not) and further more why they would find the above
>> unattractive or difficult to implement in a modern user-agent.
>>     
>>>>>>>>>>> Thanks,
>>>>>>>>>>> skylar
>>>>>>>>>>>
>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - ... -.- -.-- .-.. .- .-. - .-
>>>>>>>>>>>                       
>> - --- --- -.. .-- .- .-. -..
>>     
>>>>>>>>>>> skylar woodward
>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> Any kind of clock sync requirement for user-agents (basically,
>>>>>>>>>>>>                         
>> home desktops) it completely impractical. The added complexity pales in
>> comparison to the difficulty of trying to use timestamps and any kind of clock
>> sync. No window will be big enough as experience shows some users have
>> closes that are off by more than an hour and a half.
>>     
>>>>>>>>>>>> The issue here is who is this being optimized for. Server-to-
>>>>>>>>>>>>                         
>> server communication should simply use TLS for privacy and MITM protection
>> on top of MAC instead of using nonces to prevent replay. The whole point of
>> this kind of replay protection is when TLS is not available.
>>     
>>>>>>>>>>>> I think a better approach is to simply make checking the nonce
>>>>>>>>>>>>                         
>> optional when TLS is used.
>>     
>>>>>>>>>>>> EHL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>>>>>>>>>>>>>                           
>> bounces@ietf.org]
>>     
>>>>>>>>>>>>> On Behalf Of Peter Wolanin
>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
>>>>>>>>>>>>>                           
>> element -
>>     
>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am also concerned by the fragility of using
>>>>>>>>>>>>> time-since-credentials-issued, and also the added complexity
>>>>>>>>>>>>>                           
>> of specifying this construction.
>>     
>>>>>>>>>>>>> I think it would be preferable to always require a timestamp
>>>>>>>>>>>>> as part of the authorization header, and maybe even include
>>>>>>>>>>>>> in the spec a maximum time difference between client and
>>>>>>>>>>>>> server (e.g. 900 seconds) that can be tolerated.  This makes
>>>>>>>>>>>>> generating the nonce easier also, since the value need to
>>>>>>>>>>>>>                           
>> longer be unique over all time.
>>     
>>>>>>>>>>>>> We have such rules in place for an HMAC-based
>>>>>>>>>>>>>                           
>> authentication
>>     
>>>>>>>>>>>>> system we use.  Once in a while a client has a local clock
>>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Peter
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
>>>>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth
>>>>>>>>>>>>>>>                               
>> WG
>>     
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element -
>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a bit,
>>>>>>>>>>>>>>> I would suggest that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
>>>>>>>>>>>>> without further requirements. It might be suggested that
>>>>>>>>>>>>> this be composed of an
>>>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a
>>>>>>>>>>>>> random+MAY or
>>>>>>>>>>>>> "recommended" practice. If the expectation is that very few
>>>>>>>>>>>>> if any providers would actually check the timestamp (or
>>>>>>>>>>>>> moreover, the nonce itself), why add terminology in the
>>>>>>>>>>>>> draft that requires it? Developers are doing extra
>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but with
>>>>>>>>>>>>>                           
>> no payoff or added security.
>>     
>>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
>>>>>>>>>>>>>>>                               
>> the
>>     
>>>>>>>>>>>>>>> v3-5 changes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> last night (for both client credentials and requests w/
>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is now
>>>>>>>>>>>>> the most complicated part of the normalized request string
>>>>>>>>>>>>>                           
>> and yet these changes offer the least benefit.
>>     
>>>>>>>>>>>>> What's most important is that nonces are unique on each
>>>>>>>>>>>>>                           
>> request for an ID.
>>     
>>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
>>>>>>>>>>>>>>> based on receipt, then the internal clock changes
>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user with
>>>>>>>>>>>>>>> a bad clock (of by hours or more) will never fix it and
>>>>>>>>>>>>>>> actually encourages bad user behavior (don't fix your
>>>>>>>>>>>>>>> clock or Twitterbot will stop working!). Though we say
>>>>>>>>>>>>>>> that timezones won't bring about the situation of changed
>>>>>>>>>>>>>>> clock, I'd be to differ. Many users aren't savvy enough to
>>>>>>>>>>>>>>> change time zone, but just adjust the time to local time
>>>>>>>>>>>>>>> anyway. Users who are more likely to get it right already
>>>>>>>>>>>>>>> have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - What if the token wasn't originally issued
>>>>>>>>>>>>>>> programmatically? In this case,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> the issue time has to be obtained from the server and stored
>>>>>>>>>>>>> on the client then you have the same problem as with a
>>>>>>>>>>>>> timestamp - the client clock is not sync'd to the server
>>>>>>>>>>>>> clock and there is no adjustment. You want this to apply to
>>>>>>>>>>>>> uses outside of just OAuth, but now requiring the client to
>>>>>>>>>>>>> be able to determine an issue time based on when it receives
>>>>>>>>>>>>>                           
>> an HTTP request necessarily limits the types of token flows for which this can
>> be used.
>>     
>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
>>>>>>>>>>>>>>> developer, but it is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an ID,
>>>>>>>>>>>>> it is actually more of a recording of "my personal clock
>>>>>>>>>>>>> offset value" but obfuscated several times over (one for each
>>>>>>>>>>>>>                           
>> token) as issue_date.
>>     
>>>>>>>>>>>>>>> - This implementation assumes software programs use the
>>>>>>>>>>>>>>> computer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
>>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
>>>>>>>>>>>>> origin server (or similar trusted time
>>>>>>>>>>>>> authority) to ask it the current time. Then it could store a
>>>>>>>>>>>>> "my device clock offset" value for the lifetime of the
>>>>>>>>>>>>> program execution. All requests needing timestamp would be
>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed since the
>>>>>>>>>>>>>                           
>> stored issue_date, the problem can't be corrected in this manner.
>>     
>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>> All in all, this seems like a misguided but
>>>>>>>>>>>>>>> well-intentioned attempt to get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
>>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more I
>>>>>>>>>>>>> think about the implications of the age parameter, the less
>>>>>>>>>>>>> I like it. Timestamp has been used for many years in the
>>>>>>>>>>>>> industry and with reasonable success in relevant
>>>>>>>>>>>>> applications. If we change to a new way of trying to sync on
>>>>>>>>>>>>>                           
>> time I think we run a greater risk of stumbling upon unforeseen issues, such
>> as those outlined above.
>>     
>>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for
>>>>>>>>>>>>>>> that matter)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> be dropped from the nonce construction. For providers that
>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value (either
>>>>>>>>>>>>> as part of the nonce or the overall header, as before).
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
>>>>>>>>>>>>>>>>                                 
>> "example.net"
>>     
>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
>>>>>>>>>>>>>>>> Certainly addresses my
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-
>>>>>>>>>>>>>>>>>                                   
>> tok
>>     
>>>>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
>>>>>>>>>>>>>>>>> mailing list for the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
>>>>>>>>>>>>> have been following this draft which originated on this list.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
>>>>>>>>>>>>>>>>>                                   
>> draft
>>     
>>>>>>>>>>>>>>>>> is now a
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does include
>>>>>>>>>>>>> an OAuth 2.0 binding which is described in less than a page.
>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the OAuth
>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
>>>>>>>>>>>>>                           
>> draft.
>>     
>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
>>>>>>>>>>>>>>>>>                                   
>> session cookies.
>>     
>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
>>>>>>>>>>>>>>>>>                                   
>> draft
>>     
>>>>>>>>>>>>>>>>> uses the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove
>>>>>>>>>>>>>>>>>                                   
>> the
>>     
>>>>>>>>>>>>>>>>> need for
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
>>>>>>>>>>>>>>>>> text to be
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
>>>>>>>>>>>>>>>>> the credentials as
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia.
>>>>>>>>>>>>>                           
>> Inc.
>>     
>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
>>>>>>>>>>>>>                           
>> http://www.drupalgardens.com"
>>     
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>         
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>       
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>     

From d.tangren@gmail.com  Tue May 31 19: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 447C5E0830 for ; Tue, 31 May 2011 19:12:25 -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 fhLIAtBcEEaX for ; Tue, 31 May 2011 19:12:21 -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 64D5BE080E for ; Tue, 31 May 2011 19:12:21 -0700 (PDT)
Received: by iyn15 with SMTP id 15so6711850iyn.31 for ; Tue, 31 May 2011 19:12:21 -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=mENo87geBQgXgGI8oSb7yqpvC73mobJzIKL8SU5VUOw=; b=bIToZbNqCsVYju4LEDR1ToXGWQAV04SL5mw8BL//64Bm++nFIVledVRnQF57tLCxFU yQf6s0g8KnG0bzVwXWKOzmJ4I/lrv+o6Xfmmq6hUvDXeCGFIP60VflvbLim+M/79r+GV Lizw8MRDCH7KcDL5bVxtW1615PFs4zubOpfJs=
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=nAUS8mxsk8n7a6CG/DiE/T5pO5u1c4NIosbquVlrSTQek7CClMYcNDKzOMtsIUYKUK AF6Bc12OOL5IslIXmIBGvIzZorTvbXj5HltLCsmgqjFug8sOaGs8G+F/4yZ1eaJPIUiR L3SDoTVM2F4PUw0l+p0gHOjI/5Oi0e4+XQtWc=
Received: by 10.42.136.129 with SMTP id u1mr11951545ict.459.1306894341060; Tue, 31 May 2011 19:12:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Tue, 31 May 2011 19:12:01 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>  
From: Doug Tangren 
Date: Tue, 31 May 2011 22:12:01 -0400
Message-ID: 
To: Brian Eaton 
Content-Type: multipart/alternative; boundary=90e6ba613594f5369904a49d0c03
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 02:12:25 -0000

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

>
>
>
> Consider what happens when a client web server is compromised and the
> client secret and refresh tokens are stolen.
> - the attacker can use the tokens until the compromise is discovered.
> - the client secret is then changed
> - the stolen refresh tokens then become useless
>
> Now, *if* the implicit grant type returns refresh token, that story
> changes.  Even if the client secret is changed, the attacker can keep
> using the refresh tokens!


I think this is exactly the point! It only makes sense for the auth code
flow where client credentials are supplied in the refresh token request. The
idea behind not issuing a refresh token to a client that can't store
confidential client credentials is there that is no protection against a
compromised refresh token. A refresh token request requires no redirection
and no interaction with a user so if I can grab it, I've got an endless all
access pass to your users' data until they deny your app access to their
data.

I may be a little misinformed when I talk about the implicit flow with
respect to a native client. I was mainly talking about its usage with
respect to browser-based client.

I wasn't aware about the auth code flows without secrets until the recent
suggested flows for native clients included the auth code flow with out a
secret.

There seem to be many recent changes that muddied the original security
considerations behind parameter and credentials requirements for the auth
and implicit flows. Now there is auth code flow server (client secret
required)/auth code flow for native apps (client secret optional) and
implicit flow for browser clients (no refresh token)/implicit flow for
native apps (optional refresh token?).

It feels like there should be a well-defined or at least more
narrowly-scoped flow for each intended usage instead of saying various
clients can use the same flow but in various different ways. This makes it
easy for developers to pick an choose which parameters they want to supply
but difficult for server providers to validate requests.

All that said, I do agree there is a user experience issue with the implicit
flow. From a user's perspective if feels annoying to be asked the same
question multiple times when the answer is always the same. I think I heard
mention of facebook using tokens that don't expire. From their
documentation, it sounds like they did the right thing. They don't do this
by default but provide it as an option that the user has to authorize.

"If your app needs an access token with an infinite expiry time (perhaps to
take actions on the user's behalf after they are not using your app), you
can request the *offline_access *permission."

If I read that right, that says the user has to opt into 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 hacking around them.

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



    

    
Consider what happens when a client web server is compromised and the
    
client secret and refresh tokens are stolen.
    
- the attacker can use the tokens until the compromise is discovered.
    
- the client secret is then changed
    
- the stolen refresh tokens then become useless
    

    
Now, *if* the implicit grant type returns refresh token, that story
    
changes. =C2=A0Even if the client secret is changed, the attacker can keep<=
br>
using the refresh tokens!=C2=A0
    =C2=A0
    I think t=
his is exactly the point! It only makes sense for the auth code flow where =
client credentials are supplied in the refresh token request. The idea behi=
nd not issuing a refresh token to a client that can't store confidentia=
l client credentials is there that is no protection against a compromised r=
efresh token. A refresh token request requires no redirection and no intera=
ction with a user so if I can grab it, I've got an endless all access p=
ass to your users' data until they deny your app access to their data.<=
/div>



    I may be a little misinformed when I talk about the imp=
licit flow with respect to a native client. I was mainly talking about its =
usage with respect to browser-based client.

    I wasn=
't aware about the auth code flows without secrets until the recent sug=
gested flows for native clients included the auth code flow with out a secr=
et.=C2=A0
    



    There seem to be many recent changes that muddied the o=
riginal security considerations behind parameter and credentials requiremen=
ts for the auth and implicit flows. Now there is auth code flow server (cli=
ent secret required)/auth code flow for native apps (client secret optional=
) and implicit flow for browser clients (no refresh token)/implicit flow fo=
r native apps (optional refresh token?).=C2=A0
    



    It feels like there should be a well-defined or at leas=
t more narrowly-scoped flow for each intended usage instead of saying vario=
us clients can use the same flow but in various different ways. This makes =
it easy for developers to pick an choose which parameters they want to supp=
ly but difficult for server providers to validate requests.=C2=A0
    



    All that said, I do agree there is a user experience is=
sue with the implicit flow. From a user's perspective if feels annoying=
 to be asked the same question multiple times when the answer is always the=
 same. I think I heard mention of facebook using tokens that don't expi=
re. From their documentation, it sounds like they did the right thing. They=
 don't do this by default but provide it as an option that the user has=
 to authorize.
    



    "If your app needs an =
access token with an infinite expiry time (perhaps to take actions on the u=
ser's behalf after they are not using your app), you can request the=C2=
=A0offline_access=C2=A0permi=
ssion."
    



    If I read that=
 right, that says the user has to opt into 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 protoco=
l parameters as intended instead of hacking around them.


    

--90e6ba613594f5369904a49d0c03--

From skylar@kiva.org  Tue May 31 22:13: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 A0B2DE06BE for ; Tue, 31 May 2011 22:13:46 -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 UQS5bPt1mevT for ; Tue, 31 May 2011 22:13:44 -0700 (PDT)
Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 77B0BE06B7 for ; Tue, 31 May 2011 22:13:43 -0700 (PDT)
Received: from mail-wy0-f181.google.com ([74.125.82.181]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXKhhVkwNpWpuHOcFAu4QA5EDIxnHvJ@postini.com; Tue, 31 May 2011 22:13:43 PDT
Received: by wyi11 with SMTP id 11so4570805wyi.12 for ; Tue, 31 May 2011 22:13:41 -0700 (PDT)
Received: by 10.216.65.18 with SMTP id e18mr4467774wed.23.1306905220518; Tue, 31 May 2011 22:13:40 -0700 (PDT)
Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id ej7sm485849wbb.2.2011.05.31.22.13.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 22:13:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Skylar Woodward 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 07:13:38 +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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@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 05:13:46 -0000

Yes, but I think my case is very important (eg, being able to use a MAC =
token as a client credential). I don't understand why Adam can't =
comprehend my explanation. My best guess is this is some kind of =
political game on his front to protect the age specification yet I don't =
understand any motivation for being so close-minded. His reply to my =
last thread was completely disrespectful and ignorant. Unless I've made =
him mad or offended him in some way I see no excuse for this behavior.

I'm going to make one more attempt to try to explain this to him over =
email. After that I recommend a Skype call (hopefully brief) or I will =
work offline with Eran to see if we can find some solution.

Btw, in addition to the use case of using MAC tokens for client =
credentials, we also have the use case of re-issuing a valid token =
multiple times to instances of the same client. (eg, the value of ID and =
secret are constant across multiple transmissions to client instances).

Thanks,
skylar

On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote:

> I think the use case document should focus on v2, not on MAC. At some =
point, it becomes impractical to keep every use case discussed on this =
list recorded.
>=20
> EHL
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Igor Faynberg
>> Sent: Tuesday, May 31, 2011 3:50 PM
>> To: Phil Hunt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>=20
>> ...Sorry to turn the question around so as to underline my pet peeve:
>> Have we *documented* all cases?  (This is what the Use Cases document =
is
>> supposed to be all about.)
>>=20
>> Just to clarify: I am not arguing with Phil's point now. I just =
stress that as of
>> this moment we don't have anything to check against.
>>=20
>> Igor
>>=20
>> Phil Hunt wrote:
>>> There seems to be a demonstrated need for both age and timestamp
>> tokens.
>>>=20
>>> The list has 2 separate cases with 2 separate proposals that do not =
solve all
>> cases.
>>>=20
>>> Can we at least agree that neither proposal works in all cases?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>>=20
>>>=20
>>>> You haven't described a problem.
>>>>=20
>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
>> wrote:
>>>>=20
>>>>> First we should agree on a common understanding of the spec. The
>> reason why age works with unsynchronized clocks is that the client
>> determines issue_date based on the time when it receives the token =
over
>> the wire. This depends on the server and client both recording time =
this way
>> and for the transmission of the token to be be not longer than the =
margin of
>> error for validating age. Are we agreed on this understanding?
>>>>>=20
>>>> That's not correct.
>>>>=20
>>>> The age allows the server to protect against replay attacks in
>>>> bounded memory.  With unbounded memory, the server can just
>> remember
>>>> every nonce it has ever seen associated with a given key and reject
>> replays.
>>>> With bounded memory, the server eventually needs to evict some of
>>>> these nonces due to memory pressure.  The age value lets the server
>>>> reject the nonces with the smallest age values first.  The server
>>>> then rejects any messages with age values smaller than (or equal =
to)
>>>> the largest age value it has ever evicted for the given key.
>>>>=20
>>>> Notice that neither clock synchronization nor transmission time =
plays
>>>> a role in that implementation.
>>>>=20
>>>>=20
>>>>> The easiest case for me to explain here is client credentials =
because I
>> have to assume you've built and registered a Twitter app at some =
point (or
>> similar OAuth 1.0a app). You registered your app on the site and were =
issued
>> a client_id and client_secret (called consumer_key and =
consumer_secret in
>> 1.0). You then embedded these values in your client (they were not =
issued
>> programmatically to your app). Assuming the MAC token algorithm is =
used
>> then for establishing client identity (originally one of the uses we, =
the
>> working group, hoped MAC would cover) how then will your client
>> determine issue date?
>>>>>=20
>>>> I recommend the date at which the developer obtained the credential
>>>> from Twitter because that is the date when the credential was =
issued.
>>>>=20
>>>>=20
>>>>> After we can establish where you're at on the two above points =
I'll
>> continue with the explanation. But as a preview, the next points =
would be:
>>>>>=20
>>>>> - If issue_date comes form the server, how is it translated to the =
client?
>>>>>=20
>>>> The issue_date does not come from the server.
>>>>=20
>>>>=20
>>>>> - If you use a server provided issue_date, how do you then =
translate
>> that a value relative to the local unsyncronized clock?
>>>>>=20
>>>> The server does not provide the issue_date.
>>>>=20
>>>>=20
>>>>> - If your answer to that is to also provide the current server =
time to the
>> client so the offset on the server provided issue_date can be =
calculated what
>> is the difference between all of these values and just using =
timestamp?
>>>>>=20
>>>> My answer is not to provide the current server time to the client.
>>>>=20
>>>> Kind regards,
>>>> Adam
>>>>=20
>>>>=20
>>>>=20
>>>>> So don't get wrapped up in those 3 questions until we establish =
your
>> contextual understanding of the first two paragraphs. Feel free to =
also
>> respond to me off the list so we don't trouble everyone else with us =
getting
>> on the same page (the reason, I thought, why a Skype call would be =
more
>> efficient and painless). I do think my explanations all have been =
very clear
>> thus far. There must be a contextual confusion that is keeping us =
from a
>> common understanding of the terminology or the use cases.
>>>>>=20
>>>>> skylar
>>>>>=20
>>>>>=20
>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>>=20
>>>>>=20
>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
>>>>>> caused by age clearly?  I didn't understand your previous
>>>>>> explanation.  The more concrete you can be, the better.
>>>>>>=20
>>>>>> Thanks,
>>>>>> Adam
>>>>>>=20
>>>>>>=20
>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward =

>> wrote:
>>>>>>=20
>>>>>>> It seems we're failing to communicate. Or you're not =
understanding
>> my use cases. Age doesn't "just" work. It only works for a limited =
number of
>> uses cases that must include all of yours - and it is brittle at =
that. It doesn't
>> work for any of our uses cases (where the client can't know =
issue_date w/o
>> the server telling it - in which case we have the equivalent problem =
as
>> timestamp).
>>>>>>>=20
>>>>>>> If you'd like to talk this out over Skype I'm happy to do that, =
so I can
>> help you understand why age doesn't work.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Timestamps don't work when the client doesn't have a =
synchronized
>>>>>>>> clock.  It's true that a client could synchronize its clock =
with
>>>>>>>> the network, but our implementation experience is that many
>>>>>>>> clients don't for a variety of reasons.  That means that age
>>>>>>>> better because, you know, it works.
>>>>>>>>=20
>>>>>>>> Adam
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>>  wrote:
>>>>>>>>=20
>>>>>>>>> I don't think you read my first message on the topic (or I =
wrote too
>> much).
>>>>>>>>>=20
>>>>>>>>> Age is fragile because if the clock changes between issue_date =
and
>> the time of submission, it will fail. We know many people don't have
>> synchronized clocks, but using age only solves this problem if two
>> assumptions hold true:
>>>>>>>>>=20
>>>>>>>>> 1) the client is able to guess the issue_date the server is
>>>>>>>>> using based on the time the credential was issued
>>>>>>>>> 2) the client system clock doesn't change between issue date =
and
>> submission time.
>>>>>>>>>=20
>>>>>>>>> Timestamp has neither of these issues because the client can
>> always inquire about network time and can effectively correct for
>> inaccuracies in the device timekeeping system.
>>>>>>>>>=20
>>>>>>>>> Regarding the first assumption, this fails when a token might =
be re-
>> issued between devices. An example is that we use MAC token for the =
client
>> credentials, which are issued when a developer registers an =
application. The
>> client has no way of determining on its own when the value was =
actually
>> issued (unless we communicate that on the developer website and force
>> users to embed that with client_id, which adds usability issues of =
users
>> copying and entering string date values correctly). The same is =
actually true
>> for all of our OAuth access tokens because we reissue tokens to the =
same
>> client_id if they were previously issued and are still valid. (The =
client would
>> thus think the issue_date was now() when if fact it was the time of =
the first
>> issue for client_id+scope+grantor_id). Thus, age is really just a =
convoluted
>> way of trying to communicate the device system offset:
>>>>>>>>>=20
>>>>>>>>>       local_offset =3D current_server_time - =
current_device_time
>>>>>>>>>       age =3D current_device_time -
>>>>>>>>> (server_issue_date-local_offset)
>>>>>>>>>=20
>>>>>>>>> Since the protocol doesn't currently allow for =
server_issue_date to
>> be given with tokens, thus age currently can't have the resilience =
that
>> timestamp does. It also forces servers to issue new tokens on demand =
just
>> to make the convoluted age system work (rather than reuse existing =
valid
>> tokens). Or, you have to modify the protocol to add server_issue_date =
and
>> current_server_time into the token-issue exchange - eg, more =
complexity.
>>>>>>>>>=20
>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for =
your use
>> case of unsyncronized clocks.
>>>>>>>>>=20
>>>>>>>>> skylar
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
>>>>>>>>>> don't have synchronized clocks, for a wide variety of =
reasons.
>>>>>>>>>> I guess I don't really understand why you view age as
>>>>>>>>>> problematic.  You reference "fragility of using
>>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
>>>>>>>>>> is fragile about it.  There's nothing particularly complex
>>>>>>>>>> about age, especially when using the monotonic clock provided =
by
>> all modern operating systems.
>>>>>>>>>>=20
>>>>>>>>>> Adam
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>>  wrote:
>>>>>>>>>>=20
>>>>>>>>>>> But see, now you are specializing the use of MAC token even
>> more - now it's becoming a service mainly for user-agents on home
>> desktops? This is further for the original goal of making MAC as =
flexible is
>> possible. In this case you should change the spec name to
>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
>> REFOX - or MTBCRLF for short.
>>>>>>>>>>>=20
>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as =
your
>> offset technique and is more: reliable, straightforward, flexible.
>>>>>>>>>>>=20
>>>>>>>>>>> User agents that care about creating robust behavior for =
home
>> desktops or mobiles (presumably of users and OS not yet sophisticated
>> enough to check network time on their own) should be advised to do =
clock
>> correction on their own (by pinging a time service) and trusting the =
device
>> clock alone.
>>>>>>>>>>>=20
>>>>>>>>>>> Please change the spec back to using timestamp rather than =
age.
>>>>>>>>>>>=20
>>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla =
co-
>> authors about why they think that age is more resilient than the =
above (I
>> believe it is not) and further more why they would find the above
>> unattractive or difficult to implement in a modern user-agent.
>>>>>>>>>>>=20
>>>>>>>>>>> Thanks,
>>>>>>>>>>> skylar
>>>>>>>>>>>=20
>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. - =
... -.- -.-- .-.. .- .-. - .-
>> - --- --- -.. .-- .- .-. -..
>>>>>>>>>>> skylar woodward
>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> Any kind of clock sync requirement for user-agents =
(basically,
>> home desktops) it completely impractical. The added complexity pales =
in
>> comparison to the difficulty of trying to use timestamps and any kind =
of clock
>> sync. No window will be big enough as experience shows some users =
have
>> closes that are off by more than an hour and a half.
>>>>>>>>>>>>=20
>>>>>>>>>>>> The issue here is who is this being optimized for. =
Server-to-
>> server communication should simply use TLS for privacy and MITM =
protection
>> on top of MAC instead of using nonces to prevent replay. The whole =
point of
>> this kind of replay protection is when TLS is not available.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I think a better approach is to simply make checking the =
nonce
>> optional when TLS is used.
>>>>>>>>>>>>=20
>>>>>>>>>>>> EHL
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>> bounces@ietf.org]
>>>>>>>>>>>>> On Behalf Of Peter Wolanin
>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
>> element -
>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I am also concerned by the fragility of using
>>>>>>>>>>>>> time-since-credentials-issued, and also the added =
complexity
>> of specifying this construction.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I think it would be preferable to always require a =
timestamp
>>>>>>>>>>>>> as part of the authorization header, and maybe even =
include
>>>>>>>>>>>>> in the spec a maximum time difference between client and
>>>>>>>>>>>>> server (e.g. 900 seconds) that can be tolerated.  This =
makes
>>>>>>>>>>>>> generating the nonce easier also, since the value need to
>> longer be unique over all time.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> We have such rules in place for an HMAC-based
>> authentication
>>>>>>>>>>>>> system we use.  Once in a while a client has a local clock
>>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> -Peter
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
>>>>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav , OAuth
>> WG
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age element -
>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a =
bit,
>>>>>>>>>>>>>>> I would suggest that
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
>>>>>>>>>>>>> without further requirements. It might be suggested that
>>>>>>>>>>>>> this be composed of an
>>>>>>>>>>>>> random+timestamp (not age) value, but that seems more of a
>>>>>>>>>>>>> random+MAY or
>>>>>>>>>>>>> "recommended" practice. If the expectation is that very =
few
>>>>>>>>>>>>> if any providers would actually check the timestamp (or
>>>>>>>>>>>>> moreover, the nonce itself), why add terminology in the
>>>>>>>>>>>>> draft that requires it? Developers are doing extra
>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but =
with
>> no payoff or added security.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
>> the
>>>>>>>>>>>>>>> v3-5 changes
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> last night (for both client credentials and requests w/
>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is =
now
>>>>>>>>>>>>> the most complicated part of the normalized request string
>> and yet these changes offer the least benefit.
>>>>>>>>>>>>> What's most important is that nonces are unique on each
>> request for an ID.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
>>>>>>>>>>>>>>> based on receipt, then the internal clock changes
>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user =
with
>>>>>>>>>>>>>>> a bad clock (of by hours or more) will never fix it and
>>>>>>>>>>>>>>> actually encourages bad user behavior (don't fix your
>>>>>>>>>>>>>>> clock or Twitterbot will stop working!). Though we say
>>>>>>>>>>>>>>> that timezones won't bring about the situation of =
changed
>>>>>>>>>>>>>>> clock, I'd be to differ. Many users aren't savvy enough =
to
>>>>>>>>>>>>>>> change time zone, but just adjust the time to local time
>>>>>>>>>>>>>>> anyway. Users who are more likely to get it right =
already
>>>>>>>>>>>>>>> have auto clock sync enabled (via web, mobile, etc.)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> - What if the token wasn't originally issued
>>>>>>>>>>>>>>> programmatically? In this case,
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> the issue time has to be obtained from the server and =
stored
>>>>>>>>>>>>> on the client then you have the same problem as with a
>>>>>>>>>>>>> timestamp - the client clock is not sync'd to the server
>>>>>>>>>>>>> clock and there is no adjustment. You want this to apply =
to
>>>>>>>>>>>>> uses outside of just OAuth, but now requiring the client =
to
>>>>>>>>>>>>> be able to determine an issue time based on when it =
receives
>> an HTTP request necessarily limits the types of token flows for which =
this can
>> be used.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
>>>>>>>>>>>>>>> developer, but it is
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an =
ID,
>>>>>>>>>>>>> it is actually more of a recording of "my personal clock
>>>>>>>>>>>>> offset value" but obfuscated several times over (one for =
each
>> token) as issue_date.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> - This implementation assumes software programs use the
>>>>>>>>>>>>>>> computer
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
>>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
>>>>>>>>>>>>> origin server (or similar trusted time
>>>>>>>>>>>>> authority) to ask it the current time. Then it could store =
a
>>>>>>>>>>>>> "my device clock offset" value for the lifetime of the
>>>>>>>>>>>>> program execution. All requests needing timestamp would be
>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed =
since the
>> stored issue_date, the problem can't be corrected in this manner.
>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> All in all, this seems like a misguided but
>>>>>>>>>>>>>>> well-intentioned attempt to get
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
>>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more =
I
>>>>>>>>>>>>> think about the implications of the age parameter, the =
less
>>>>>>>>>>>>> I like it. Timestamp has been used for many years in the
>>>>>>>>>>>>> industry and with reasonable success in relevant
>>>>>>>>>>>>> applications. If we change to a new way of trying to sync =
on
>> time I think we run a greater risk of stumbling upon unforeseen =
issues, such
>> as those outlined above.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp for
>>>>>>>>>>>>>>> that matter)
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> be dropped from the nonce construction. For providers that
>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value =
(either
>>>>>>>>>>>>> as part of the nonce or the overall header, as before).
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
>> "example.net"
>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
>>>>>>>>>>>>>>>> Certainly addresses my
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-
>> tok
>>>>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
>>>>>>>>>>>>>>>>> mailing list for the
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
>>>>>>>>>>>>> have been following this draft which originated on this =
list.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
>> draft
>>>>>>>>>>>>>>>>> is now a
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does =
include
>>>>>>>>>>>>> an OAuth 2.0 binding which is described in less than a =
page.
>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the OAuth
>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
>> draft.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
>> session cookies.
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
>> draft
>>>>>>>>>>>>>>>>> uses the
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to remove
>> the
>>>>>>>>>>>>>>>>> need for
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
>>>>>>>>>>>>>>>>> text to be
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
>>>>>>>>>>>>>>>>> the credentials as
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>>>>>=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
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  =
Acquia.
>> Inc.
>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
>> http://www.drupalgardens.com"
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>=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
>>>=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 kris.selden@gmail.com  Tue May 31 22:39: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 E2AE8E072A for ; Tue, 31 May 2011 22:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, 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 nkS-LIaq525z for ; Tue, 31 May 2011 22:39:34 -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 83CE8E0723 for ; Tue, 31 May 2011 22:39:34 -0700 (PDT)
Received: by pwi5 with SMTP id 5so2664382pwi.31 for ; Tue, 31 May 2011 22:39:34 -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=t21b2JNhAVFKkD2foK+UpQJl35ihTLyB383huGPCEy4=; b=XJhoY40htky5JK/F/gpgR0ob7LSlk5A4R8He+fSEyy1BHvhRVforP/On9yHkhnbyTR 9pLfcSYN5ktkOea8yN5k9bEcDRK3bFXN94QEeeRwtJjHT88wjaK5G+K5Pxqd0Whrem5e +z0mRCnL7O3AZEmyFD9OXPdYcDGoJ/XWkApc4=
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=n6+R/Oanz0wwbSdxwKXYJYsQ0C1Bds5RWJdIPeKDp/MMNqc5iAM1Be+qsQTnx7gqeO 5grPl5pP97dLbaXIQ0aRtY3GGUiHFV2I6Xvz+bk/bdJR6ifaEmQXbBkn/tkyJ+ITFXaj GQIK8N2DeYwvK8eKdc0Hd/RC6p3J/01WYA+cI=
Received: by 10.142.127.5 with SMTP id z5mr925044wfc.247.1306906774223; Tue, 31 May 2011 22:39:34 -0700 (PDT)
Received: from [172.16.2.2] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id f10sm455550wfe.0.2011.05.31.22.39.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 22:39:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Kris Selden 
In-Reply-To: 
Date: Tue, 31 May 2011 22:39:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>  
To: Brian Eaton 
X-Mailer: Apple Mail (2.1082)
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 05:39:35 -0000

Why can't you just revoke the refresh token for a client when you change =
the client secret?

Is it not easier to revoke a token than it is to rotate the client =
secret (which is usually configured or embedded in the client whereas =
the token is issued)?

On May 31, 2011, at 5:37 PM, Brian Eaton wrote:
> Consider what happens when a client web server is compromised and the
> client secret and refresh tokens are stolen.
> - the attacker can use the tokens until the compromise is discovered.
> - the client secret is then changed
> - the stolen refresh tokens then become useless
>=20
> Now, *if* the implicit grant type returns refresh token, that story
> changes.  Even if the client secret is changed, the attacker can keep
> using the refresh tokens!  They do it by passing them to the victim
> client again, through the implicit grant flow.  The victim client will
> then link the refresh token to the attacker's account.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


From skylar@kiva.org  Tue May 31 22:54: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 26A9EE070C for ; Tue, 31 May 2011 22:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level: 
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 3aO8cqO6B2sf for ; Tue, 31 May 2011 22:54:12 -0700 (PDT)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 75545E06ED for ; Tue, 31 May 2011 22:54:11 -0700 (PDT)
Received: from mail-ww0-f48.google.com ([74.125.82.48]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXUAro8r7xZJ5Per0MzSn0SNKHe00iP@postini.com; Tue, 31 May 2011 22:54:11 PDT
Received: by mail-ww0-f48.google.com with SMTP id 18so4820426wwi.17 for ; Tue, 31 May 2011 22:54:10 -0700 (PDT)
Received: by 10.227.198.133 with SMTP id eo5mr6970166wbb.38.1306907650592; Tue, 31 May 2011 22:54:10 -0700 (PDT)
Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id o19sm498431wbh.21.2011.05.31.22.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 22:54:09 -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 07:54:08 +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>   
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 05:54:13 -0000

On May 31, 2011, at 11:41 PM, Adam Barth wrote:

> You haven't described a problem.

Maybe so, but I guess you can't see yet where this is going, or you are =
ignoring it intentionally. I did preface this letter that I wanted to =
understand your perspective on this two points before attempting to =
continue the discussion. Let's try to move forward with your answer to =
the second question.

>=20
> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward  =
wrote:
>> First we should agree on a common understanding of the spec. The =
reason why age works with unsynchronized clocks is that the client =
determines issue_date based on the time when it receives the token over =
the wire. This depends on the server and client both recording time this =
way and for the transmission of the token to be be not longer than the =
margin of error for validating age. Are we agreed on this understanding?
>=20
> That's not correct.
>=20
> The age allows the server to protect against replay attacks in bounded
> memory.  With unbounded memory, the server can just remember every
> nonce it has ever seen associated with a given key and reject replays.
> With bounded memory, the server eventually needs to evict some of
> these nonces due to memory pressure.  The age value lets the server
> reject the nonces with the smallest age values first.  The server then
> rejects any messages with age values smaller than (or equal to) the
> largest age value it has ever evicted for the given key.
>=20
> Notice that neither clock synchronization nor transmission time plays
> a role in that implementation.
>=20

Yes, but this isn't a implementation we've yet considered and it isn't =
the one suggested by the spec. The spec states:

"To avoid the need to retain an infinite number of nonce values
         for future checks, the server MAY choose to restrict the time
         period after which a request with an old age is rejected."

This text is analogous to the text originally used for timestamp in =
which case "old" is relative to current time. By this text, I also =
understand age to be relative to the current time of the device =
constructing or validating the value. If "old" means relative to =
previous values seen by the server then the this text should be made =
more clear.

However, if this how you expect age to be used to invalidate old nonce =
history then timestamp is much simpler. The client can use any value so =
long as it makes sure that subsequent values come after previous values. =
It can keep a counter going from 0 upwards, or it can use some upward =
moving counter relative to its device (eg local clock). In fact, this is =
the more common definition used by most protocols using a timestamp. It =
is often merely a suggestion that current time be used for this value to =
avoid extra record-keeping on the part of the client. So if this is your =
intent you can simplify the specification of "age" by suggesting the =
client pick an arbitrary start point, but make no mention of it needing =
to be within a proximity of the server's understanding of the same start =
point.

Unfortunately though, this implementation doesn't help my use cases =
because such sequential requirement of a timestamp/age requires all =
devices with the token to be in sync as to the value of timestamp/age. =
So let's move on.

>> The easiest case for me to explain here is client credentials because =
I have to assume you've built and registered a Twitter app at some point =
(or similar OAuth 1.0a app). You registered your app on the site and =
were issued a client_id and client_secret (called consumer_key and =
consumer_secret in 1.0). You then embedded these values in your client =
(they were not issued programmatically to your app). Assuming the MAC =
token algorithm is used then for establishing client identity =
(originally one of the uses we, the working group, hoped MAC would =
cover) how then will your client determine issue date?
>=20
> I recommend the date at which the developer obtained the credential
> from Twitter because that is the date when the credential was issued.

Okay, so this value was issued from the server to a developer account, =
not directly to the client software. How do you then propose the time is =
communicated to the client software program in a way where the date of =
issuance is relative to the clock on that device (not to the device =
holding the developer account data). For example, if the client =
credential was issued at time 2120 but is then installed with a client =
program on a device who thinks the current time is 630 then age is =
already negative (2120-630). How to translate 2120 from the date the =
developer obtained the credential to the translation of that date on a =
user device where the clock is significantly behind that of the =
developer services server (eg, dev.twitter.com) or even that of the =
local developer's box?

skylar





From eran@hueniverse.com  Tue May 31 22:54: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 0341DE0689 for ; Tue, 31 May 2011 22:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.368
X-Spam-Level: 
X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, 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 1CskhUQ3nxau for ; Tue, 31 May 2011 22:54: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 18C87E0593 for ; Tue, 31 May 2011 22:54:52 -0700 (PDT)
Received: (qmail 2303 invoked from network); 1 Jun 2011 05:54:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 05:54:50 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 31 May 2011 22:54:50 -0700
From: Eran Hammer-Lahav 
To: "igor.faynberg@alcatel-lucent.com" 
Date: Tue, 31 May 2011 22:54:22 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: Acwf+Vq25sDROiZaSdW08HmwUgS3sgAJswhA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE59299.2020909@alcatel-lucent.com>
In-Reply-To: <4DE59299.2020909@alcatel-lucent.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
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 05:54:54 -0000

They are coming in 2-3 directions, the use case isn't really clear (other t=
han claims of some flavors being harder than others), and overall this is m=
ore about general HTTP authentication than OAuth use cases. Don't get me wr=
ong - if you want to put the effort in to capture these, go ahead. I just t=
hink this isn't worth the effort in a formal document.

EHL

> -----Original Message-----
> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
> Sent: Tuesday, May 31, 2011 6:15 PM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Maybe...  But this information must be captured somewhere, right?
>
> At the moment, there seems to be no record of and consequently no
> reference point to the use case in question. And this is what has created=
 all
> this discussion--with messages coming from all directions.
>
> Igor
>
> Eran Hammer-Lahav wrote:
> > I think the use case document should focus on v2, not on MAC. At some
> point, it becomes impractical to keep every use case discussed on this li=
st
> recorded.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Igor Faynberg
> >> Sent: Tuesday, May 31, 2011 3:50 PM
> >> To: Phil Hunt
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >> token
> >>
> >> ...Sorry to turn the question around so as to underline my pet peeve:
> >> Have we *documented* all cases?  (This is what the Use Cases document
> >> is supposed to be all about.)
> >>
> >> Just to clarify: I am not arguing with Phil's point now. I just
> >> stress that as of this moment we don't have anything to check against.
> >>
> >> Igor
> >>
> >> Phil Hunt wrote:
> >>
> >>> There seems to be a demonstrated need for both age and timestamp
> >>>
> >> tokens.
> >>
> >>> The list has 2 separate cases with 2 separate proposals that do not
> >>> solve all
> >>>
> >> cases.
> >>
> >>> Can we at least agree that neither proposal works in all cases?
> >>>
> >>> Phil
> >>>
> >>> @independentid
> >>> www.independentid.com
> >>> phil.hunt@oracle.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
> >>>
> >>>
> >>>
> >>>> You haven't described a problem.
> >>>>
> >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
> >>>>
> >> wrote:
> >>
> >>>>> First we should agree on a common understanding of the spec. The
> >>>>>
> >> reason why age works with unsynchronized clocks is that the client
> >> determines issue_date based on the time when it receives the token
> >> over the wire. This depends on the server and client both recording
> >> time this way and for the transmission of the token to be be not
> >> longer than the margin of error for validating age. Are we agreed on t=
his
> understanding?
> >>
> >>>> That's not correct.
> >>>>
> >>>> The age allows the server to protect against replay attacks in
> >>>> bounded memory.  With unbounded memory, the server can just
> >>>>
> >> remember
> >>
> >>>> every nonce it has ever seen associated with a given key and reject
> >>>>
> >> replays.
> >>
> >>>> With bounded memory, the server eventually needs to evict some of
> >>>> these nonces due to memory pressure.  The age value lets the server
> >>>> reject the nonces with the smallest age values first.  The server
> >>>> then rejects any messages with age values smaller than (or equal
> >>>> to) the largest age value it has ever evicted for the given key.
> >>>>
> >>>> Notice that neither clock synchronization nor transmission time
> >>>> plays a role in that implementation.
> >>>>
> >>>>
> >>>>
> >>>>> The easiest case for me to explain here is client credentials
> >>>>> because I
> >>>>>
> >> have to assume you've built and registered a Twitter app at some
> >> point (or similar OAuth 1.0a app). You registered your app on the
> >> site and were issued a client_id and client_secret (called
> >> consumer_key and consumer_secret in 1.0). You then embedded these
> >> values in your client (they were not issued programmatically to your
> >> app). Assuming the MAC token algorithm is used then for establishing
> >> client identity (originally one of the uses we, the working group,
> >> hoped MAC would cover) how then will your client determine issue date?
> >>
> >>>> I recommend the date at which the developer obtained the credential
> >>>> from Twitter because that is the date when the credential was issued=
.
> >>>>
> >>>>
> >>>>
> >>>>> After we can establish where you're at on the two above points
> >>>>> I'll
> >>>>>
> >> continue with the explanation. But as a preview, the next points would
> be:
> >>
> >>>>> - If issue_date comes form the server, how is it translated to the
> client?
> >>>>>
> >>>>>
> >>>> The issue_date does not come from the server.
> >>>>
> >>>>
> >>>>
> >>>>> - If you use a server provided issue_date, how do you then
> >>>>> translate
> >>>>>
> >> that a value relative to the local unsyncronized clock?
> >>
> >>>> The server does not provide the issue_date.
> >>>>
> >>>>
> >>>>
> >>>>> - If your answer to that is to also provide the current server
> >>>>> time to the
> >>>>>
> >> client so the offset on the server provided issue_date can be
> >> calculated what is the difference between all of these values and just
> using timestamp?
> >>
> >>>> My answer is not to provide the current server time to the client.
> >>>>
> >>>> Kind regards,
> >>>> Adam
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> So don't get wrapped up in those 3 questions until we establish
> >>>>> your
> >>>>>
> >> contextual understanding of the first two paragraphs. Feel free to
> >> also respond to me off the list so we don't trouble everyone else
> >> with us getting on the same page (the reason, I thought, why a Skype
> >> call would be more efficient and painless). I do think my
> >> explanations all have been very clear thus far. There must be a
> >> contextual confusion that is keeping us from a common understanding of
> the terminology or the use cases.
> >>
> >>>>> skylar
> >>>>>
> >>>>>
> >>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>>>>> caused by age clearly?  I didn't understand your previous
> >>>>>> explanation.  The more concrete you can be, the better.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Adam
> >>>>>>
> >>>>>>
> >>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
> >>>>>> 
> >>>>>>
> >> wrote:
> >>
> >>>>>>> It seems we're failing to communicate. Or you're not
> >>>>>>> understanding
> >>>>>>>
> >> my use cases. Age doesn't "just" work. It only works for a limited
> >> number of uses cases that must include all of yours - and it is
> >> brittle at that. It doesn't work for any of our uses cases (where the
> >> client can't know issue_date w/o the server telling it - in which
> >> case we have the equivalent problem as timestamp).
> >>
> >>>>>>> If you'd like to talk this out over Skype I'm happy to do that,
> >>>>>>> so I can
> >>>>>>>
> >> help you understand why age doesn't work.
> >>
> >>>>>>>
> >>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Timestamps don't work when the client doesn't have a
> >>>>>>>> synchronized clock.  It's true that a client could synchronize
> >>>>>>>> its clock with the network, but our implementation experience
> >>>>>>>> is that many clients don't for a variety of reasons.  That
> >>>>>>>> means that age better because, you know, it works.
> >>>>>>>>
> >>>>>>>> Adam
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
> >>>>>>>>
> >>  wrote:
> >>
> >>>>>>>>> I don't think you read my first message on the topic (or I
> >>>>>>>>> wrote too
> >>>>>>>>>
> >> much).
> >>
> >>>>>>>>> Age is fragile because if the clock changes between issue_date
> >>>>>>>>> and
> >>>>>>>>>
> >> the time of submission, it will fail. We know many people don't have
> >> synchronized clocks, but using age only solves this problem if two
> >> assumptions hold true:
> >>
> >>>>>>>>> 1) the client is able to guess the issue_date the server is
> >>>>>>>>> using based on the time the credential was issued
> >>>>>>>>> 2) the client system clock doesn't change between issue date
> >>>>>>>>> and
> >>>>>>>>>
> >> submission time.
> >>
> >>>>>>>>> Timestamp has neither of these issues because the client can
> >>>>>>>>>
> >> always inquire about network time and can effectively correct for
> >> inaccuracies in the device timekeeping system.
> >>
> >>>>>>>>> Regarding the first assumption, this fails when a token might
> >>>>>>>>> be re-
> >>>>>>>>>
> >> issued between devices. An example is that we use MAC token for the
> >> client credentials, which are issued when a developer registers an
> >> application. The client has no way of determining on its own when the
> >> value was actually issued (unless we communicate that on the
> >> developer website and force users to embed that with client_id, which
> >> adds usability issues of users copying and entering string date
> >> values correctly). The same is actually true for all of our OAuth
> >> access tokens because we reissue tokens to the same client_id if they
> >> were previously issued and are still valid. (The client would thus
> >> think the issue_date was now() when if fact it was the time of the
> >> first issue for client_id+scope+grantor_id). Thus, age is really just =
a
> convoluted way of trying to communicate the device system offset:
> >>
> >>>>>>>>>        local_offset =3D current_server_time - current_device_ti=
me
> >>>>>>>>>        age =3D current_device_time -
> >>>>>>>>> (server_issue_date-local_offset)
> >>>>>>>>>
> >>>>>>>>> Since the protocol doesn't currently allow for
> >>>>>>>>> server_issue_date to
> >>>>>>>>>
> >> be given with tokens, thus age currently can't have the resilience
> >> that timestamp does. It also forces servers to issue new tokens on
> >> demand just to make the convoluted age system work (rather than reuse
> >> existing valid tokens). Or, you have to modify the protocol to add
> >> server_issue_date and current_server_time into the token-issue
> exchange - eg, more complexity.
> >>
> >>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
> >>>>>>>>> your use
> >>>>>>>>>
> >> case of unsyncronized clocks.
> >>
> >>>>>>>>> skylar
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
> >>>>>>>>>> don't have synchronized clocks, for a wide variety of reasons.
> >>>>>>>>>> I guess I don't really understand why you view age as
> >>>>>>>>>> problematic.  You reference "fragility of using
> >>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
> >>>>>>>>>> is fragile about it.  There's nothing particularly complex
> >>>>>>>>>> about age, especially when using the monotonic clock provided
> >>>>>>>>>> by
> >>>>>>>>>>
> >> all modern operating systems.
> >>
> >>>>>>>>>> Adam
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
> >>>>>>>>>>
> >>  wrote:
> >>
> >>>>>>>>>>> But see, now you are specializing the use of MAC token even
> >>>>>>>>>>>
> >> more - now it's becoming a service mainly for user-agents on home
> >> desktops? This is further for the original goal of making MAC as
> >> flexible is possible. In this case you should change the spec name to
> >>
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> >> REFOX - or MTBCRLF for short.
> >>
> >>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as
> >>>>>>>>>>> your
> >>>>>>>>>>>
> >> offset technique and is more: reliable, straightforward, flexible.
> >>
> >>>>>>>>>>> User agents that care about creating robust behavior for
> >>>>>>>>>>> home
> >>>>>>>>>>>
> >> desktops or mobiles (presumably of users and OS not yet sophisticated
> >> enough to check network time on their own) should be advised to do
> >> clock correction on their own (by pinging a time service) and
> >> trusting the device clock alone.
> >>
> >>>>>>>>>>> Please change the spec back to using timestamp rather than
> age.
> >>>>>>>>>>>
> >>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla
> >>>>>>>>>>> co-
> >>>>>>>>>>>
> >> authors about why they think that age is more resilient than the
> >> above (I believe it is not) and further more why they would find the
> >> above unattractive or difficult to implement in a modern user-agent.
> >>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> skylar
> >>>>>>>>>>>
> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. -
> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-
> >>>>>>>>>>>
> >> - --- --- -.. .-- .- .-. -..
> >>
> >>>>>>>>>>> skylar woodward
> >>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Any kind of clock sync requirement for user-agents
> >>>>>>>>>>>> (basically,
> >>>>>>>>>>>>
> >> home desktops) it completely impractical. The added complexity pales
> >> in comparison to the difficulty of trying to use timestamps and any
> >> kind of clock sync. No window will be big enough as experience shows
> >> some users have closes that are off by more than an hour and a half.
> >>
> >>>>>>>>>>>> The issue here is who is this being optimized for.
> >>>>>>>>>>>> Server-to-
> >>>>>>>>>>>>
> >> server communication should simply use TLS for privacy and MITM
> >> protection on top of MAC instead of using nonces to prevent replay.
> >> The whole point of this kind of replay protection is when TLS is not
> available.
> >>
> >>>>>>>>>>>> I think a better approach is to simply make checking the
> >>>>>>>>>>>> nonce
> >>>>>>>>>>>>
> >> optional when TLS is used.
> >>
> >>>>>>>>>>>> EHL
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >>>>>>>>>>>>>
> >> bounces@ietf.org]
> >>
> >>>>>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
> >>>>>>>>>>>>>
> >> element -
> >>
> >>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>>>>> time-since-credentials-issued, and also the added
> >>>>>>>>>>>>> complexity
> >>>>>>>>>>>>>
> >> of specifying this construction.
> >>
> >>>>>>>>>>>>> I think it would be preferable to always require a
> >>>>>>>>>>>>> timestamp as part of the authorization header, and maybe
> >>>>>>>>>>>>> even include in the spec a maximum time difference
> between
> >>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
> >>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
> >>>>>>>>>>>>> since the value need to
> >>>>>>>>>>>>>
> >> longer be unique over all time.
> >>
> >>>>>>>>>>>>> We have such rules in place for an HMAC-based
> >>>>>>>>>>>>>
> >> authentication
> >>
> >>>>>>>>>>>>> system we use.  Once in a while a client has a local clock
> >>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Peter
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
> OAuth
> >>>>>>>>>>>>>>>
> >> WG
> >>
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
> element -
> >>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
> >>>>>>>>>>>>>>> bit, I would suggest that
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>>>>> without further requirements. It might be suggested that
> >>>>>>>>>>>>> this be composed of an
> >>>>>>>>>>>>> random+timestamp (not age) value, but that seems more
> of a
> >>>>>>>>>>>>> random+MAY or
> >>>>>>>>>>>>> "recommended" practice. If the expectation is that very
> >>>>>>>>>>>>> few if any providers would actually check the timestamp
> >>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
> >>>>>>>>>>>>> the draft that requires it? Developers are doing extra
> >>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>
> >> no payoff or added security.
> >>
> >>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
> >>>>>>>>>>>>>>>
> >> the
> >>
> >>>>>>>>>>>>>>> v3-5 changes
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
> >>>>>>>>>>>>> now the most complicated part of the normalized request
> >>>>>>>>>>>>> string
> >>>>>>>>>>>>>
> >> and yet these changes offer the least benefit.
> >>
> >>>>>>>>>>>>> What's most important is that nonces are unique on each
> >>>>>>>>>>>>>
> >> request for an ID.
> >>
> >>>>>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
> >>>>>>>>>>>>>>> based on receipt, then the internal clock changes
> >>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
> >>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
> >>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix it
> >>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix
> >>>>>>>>>>>>>>> your clock or Twitterbot will stop working!). Though we
> >>>>>>>>>>>>>>> say that timezones won't bring about the situation of
> >>>>>>>>>>>>>>> changed clock, I'd be to differ. Many users aren't savvy
> >>>>>>>>>>>>>>> enough to change time zone, but just adjust the time to
> >>>>>>>>>>>>>>> local time anyway. Users who are more likely to get it
> >>>>>>>>>>>>>>> right already have auto clock sync enabled (via web,
> >>>>>>>>>>>>>>> mobile, etc.)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> the issue time has to be obtained from the server and
> >>>>>>>>>>>>> stored on the client then you have the same problem as
> >>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
> >>>>>>>>>>>>> server clock and there is no adjustment. You want this to
> >>>>>>>>>>>>> apply to uses outside of just OAuth, but now requiring the
> >>>>>>>>>>>>> client to be able to determine an issue time based on when
> >>>>>>>>>>>>> it receives
> >>>>>>>>>>>>>
> >> an HTTP request necessarily limits the types of token flows for which
> >> this can be used.
> >>
> >>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>>>>> developer, but it is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
> >>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
> >>>>>>>>>>>>> clock offset value" but obfuscated several times over (one
> >>>>>>>>>>>>> for each
> >>>>>>>>>>>>>
> >> token) as issue_date.
> >>
> >>>>>>>>>>>>>>> - This implementation assumes software programs use
> the
> >>>>>>>>>>>>>>> computer
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
> >>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
> >>>>>>>>>>>>> origin server (or similar trusted time
> >>>>>>>>>>>>> authority) to ask it the current time. Then it could store
> >>>>>>>>>>>>> a "my device clock offset" value for the lifetime of the
> >>>>>>>>>>>>> program execution. All requests needing timestamp would
> be
> >>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
> >>>>>>>>>>>>> since the
> >>>>>>>>>>>>>
> >> stored issue_date, the problem can't be corrected in this manner.
> >>
> >>>>>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
> >>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more
> >>>>>>>>>>>>> I think about the implications of the age parameter, the
> >>>>>>>>>>>>> less I like it. Timestamp has been used for many years in
> >>>>>>>>>>>>> the industry and with reasonable success in relevant
> >>>>>>>>>>>>> applications. If we change to a new way of trying to sync
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>
> >> time I think we run a greater risk of stumbling upon unforeseen
> >> issues, such as those outlined above.
> >>
> >>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp
> for
> >>>>>>>>>>>>>>> that matter)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> be dropped from the nonce construction. For providers
> that
> >>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
> >>>>>>>>>>>>> (either as part of the nonce or the overall header, as
> before).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> >>>>>>>>>>>>>>>>
> >> "example.net"
> >>
> >>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
> >>>>>>>>>>>>>>>> Certainly addresses my
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
> mac-
> >>>>>>>>>>>>>>>>>
> >> tok
> >>
> >>>>>>>>>>>>>>>>> en
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
> >>>>>>>>>>>>>>>>> mailing list for the
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> time being, I wanted to give a quick update to those who
> >>>>>>>>>>>>> have been following this draft which originated on this lis=
t.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
> >>>>>>>>>>>>>>>>>
> >> draft
> >>
> >>>>>>>>>>>>>>>>> is now a
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
> >>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less tha=
n
> a page.
> >>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
> OAuth
> >>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
> >>>>>>>>>>>>>
> >> draft.
> >>
> >>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> >>>>>>>>>>>>>>>>>
> >> session cookies.
> >>
> >>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
> >>>>>>>>>>>>>>>>>
> >> draft
> >>
> >>>>>>>>>>>>>>>>> uses the
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
> remove
> >>>>>>>>>>>>>>>>>
> >> the
> >>
> >>>>>>>>>>>>>>>>> need for
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> clock sync.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
> >>>>>>>>>>>>>>>>> text to be
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
> >>>>>>>>>>>>>>>>> the credentials as
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> an additional protection.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia=
.
> >>>>>>>>>>>>>
> >> Inc.
> >>
> >>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
> >>>>>>>>>>>>>
> >> http://www.drupalgardens.com"
> >>
> >>>>>>>>>>>>>
> _______________________________________________
> >>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>

From eran@hueniverse.com  Tue May 31 22:59: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 70AE4E06BF for ; Tue, 31 May 2011 22:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level: 
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, 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 kdvylRiugRZE for ; Tue, 31 May 2011 22:59:36 -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 8320CE0665 for ; Tue, 31 May 2011 22:59:36 -0700 (PDT)
Received: (qmail 10468 invoked from network); 1 Jun 2011 05:59:35 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 05:59:33 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 31 May 2011 22:59:04 -0700
From: Eran Hammer-Lahav 
To: Skylar Woodward 
Date: Tue, 31 May 2011 22:58:37 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwgGq14Le0p0L9aTX++iUOYcp4jzgABcupg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA43C@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@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 05:59:38 -0000

No need to get worked up. I'm sure Adam didn't mean to offend - that's just=
 his style (speaking as someone who is considered much less polite by a lan=
dslide).

I don't think you have made the case why you age is any harder to implement=
 than a timestamp. It is not that your email isn't clear, it's that we're n=
ot convinced that timestamp will produce any better result than age in prac=
tice. This is purely technical, not political.

However, we did come up with a solution that should cover all bases.

I do strongly object to making this protocol configurable. Configurable aut=
hentication schemes are by definition complex and right now MAC is amazingl=
y simple.

EHL

> -----Original Message-----
> From: Skylar Woodward [mailto:skylar@kiva.org]
> Sent: Tuesday, May 31, 2011 10:14 PM
> To: Eran Hammer-Lahav
> Cc: igor.faynberg@alcatel-lucent.com; Phil Hunt; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Yes, but I think my case is very important (eg, being able to use a MAC t=
oken
> as a client credential). I don't understand why Adam can't comprehend my
> explanation. My best guess is this is some kind of political game on his =
front
> to protect the age specification yet I don't understand any motivation fo=
r
> being so close-minded. His reply to my last thread was completely
> disrespectful and ignorant. Unless I've made him mad or offended him in
> some way I see no excuse for this behavior.
>
> I'm going to make one more attempt to try to explain this to him over ema=
il.
> After that I recommend a Skype call (hopefully brief) or I will work offl=
ine
> with Eran to see if we can find some solution.
>
> Btw, in addition to the use case of using MAC tokens for client credentia=
ls,
> we also have the use case of re-issuing a valid token multiple times to
> instances of the same client. (eg, the value of ID and secret are constan=
t
> across multiple transmissions to client instances).
>
> Thanks,
> skylar
>
> On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote:
>
> > I think the use case document should focus on v2, not on MAC. At some
> point, it becomes impractical to keep every use case discussed on this li=
st
> recorded.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Igor Faynberg
> >> Sent: Tuesday, May 31, 2011 3:50 PM
> >> To: Phil Hunt
> >> Cc: OAuth WG
> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >> token
> >>
> >> ...Sorry to turn the question around so as to underline my pet peeve:
> >> Have we *documented* all cases?  (This is what the Use Cases document
> >> is supposed to be all about.)
> >>
> >> Just to clarify: I am not arguing with Phil's point now. I just
> >> stress that as of this moment we don't have anything to check against.
> >>
> >> Igor
> >>
> >> Phil Hunt wrote:
> >>> There seems to be a demonstrated need for both age and timestamp
> >> tokens.
> >>>
> >>> The list has 2 separate cases with 2 separate proposals that do not
> >>> solve all
> >> cases.
> >>>
> >>> Can we at least agree that neither proposal works in all cases?
> >>>
> >>> Phil
> >>>
> >>> @independentid
> >>> www.independentid.com
> >>> phil.hunt@oracle.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
> >>>
> >>>
> >>>> You haven't described a problem.
> >>>>
> >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
> >> wrote:
> >>>>
> >>>>> First we should agree on a common understanding of the spec. The
> >> reason why age works with unsynchronized clocks is that the client
> >> determines issue_date based on the time when it receives the token
> >> over the wire. This depends on the server and client both recording
> >> time this way and for the transmission of the token to be be not
> >> longer than the margin of error for validating age. Are we agreed on t=
his
> understanding?
> >>>>>
> >>>> That's not correct.
> >>>>
> >>>> The age allows the server to protect against replay attacks in
> >>>> bounded memory.  With unbounded memory, the server can just
> >> remember
> >>>> every nonce it has ever seen associated with a given key and reject
> >> replays.
> >>>> With bounded memory, the server eventually needs to evict some of
> >>>> these nonces due to memory pressure.  The age value lets the server
> >>>> reject the nonces with the smallest age values first.  The server
> >>>> then rejects any messages with age values smaller than (or equal
> >>>> to) the largest age value it has ever evicted for the given key.
> >>>>
> >>>> Notice that neither clock synchronization nor transmission time
> >>>> plays a role in that implementation.
> >>>>
> >>>>
> >>>>> The easiest case for me to explain here is client credentials
> >>>>> because I
> >> have to assume you've built and registered a Twitter app at some
> >> point (or similar OAuth 1.0a app). You registered your app on the
> >> site and were issued a client_id and client_secret (called
> >> consumer_key and consumer_secret in 1.0). You then embedded these
> >> values in your client (they were not issued programmatically to your
> >> app). Assuming the MAC token algorithm is used then for establishing
> >> client identity (originally one of the uses we, the working group,
> >> hoped MAC would cover) how then will your client determine issue date?
> >>>>>
> >>>> I recommend the date at which the developer obtained the credential
> >>>> from Twitter because that is the date when the credential was issued=
.
> >>>>
> >>>>
> >>>>> After we can establish where you're at on the two above points
> >>>>> I'll
> >> continue with the explanation. But as a preview, the next points would
> be:
> >>>>>
> >>>>> - If issue_date comes form the server, how is it translated to the
> client?
> >>>>>
> >>>> The issue_date does not come from the server.
> >>>>
> >>>>
> >>>>> - If you use a server provided issue_date, how do you then
> >>>>> translate
> >> that a value relative to the local unsyncronized clock?
> >>>>>
> >>>> The server does not provide the issue_date.
> >>>>
> >>>>
> >>>>> - If your answer to that is to also provide the current server
> >>>>> time to the
> >> client so the offset on the server provided issue_date can be
> >> calculated what is the difference between all of these values and just
> using timestamp?
> >>>>>
> >>>> My answer is not to provide the current server time to the client.
> >>>>
> >>>> Kind regards,
> >>>> Adam
> >>>>
> >>>>
> >>>>
> >>>>> So don't get wrapped up in those 3 questions until we establish
> >>>>> your
> >> contextual understanding of the first two paragraphs. Feel free to
> >> also respond to me off the list so we don't trouble everyone else
> >> with us getting on the same page (the reason, I thought, why a Skype
> >> call would be more efficient and painless). I do think my
> >> explanations all have been very clear thus far. There must be a
> >> contextual confusion that is keeping us from a common understanding of
> the terminology or the use cases.
> >>>>>
> >>>>> skylar
> >>>>>
> >>>>>
> >>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>>>>
> >>>>>
> >>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>>>>> caused by age clearly?  I didn't understand your previous
> >>>>>> explanation.  The more concrete you can be, the better.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Adam
> >>>>>>
> >>>>>>
> >>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
> >>>>>> 
> >> wrote:
> >>>>>>
> >>>>>>> It seems we're failing to communicate. Or you're not
> >>>>>>> understanding
> >> my use cases. Age doesn't "just" work. It only works for a limited
> >> number of uses cases that must include all of yours - and it is
> >> brittle at that. It doesn't work for any of our uses cases (where the
> >> client can't know issue_date w/o the server telling it - in which
> >> case we have the equivalent problem as timestamp).
> >>>>>>>
> >>>>>>> If you'd like to talk this out over Skype I'm happy to do that,
> >>>>>>> so I can
> >> help you understand why age doesn't work.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Timestamps don't work when the client doesn't have a
> >>>>>>>> synchronized clock.  It's true that a client could synchronize
> >>>>>>>> its clock with the network, but our implementation experience
> >>>>>>>> is that many clients don't for a variety of reasons.  That
> >>>>>>>> means that age better because, you know, it works.
> >>>>>>>>
> >>>>>>>> Adam
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
> >>  wrote:
> >>>>>>>>
> >>>>>>>>> I don't think you read my first message on the topic (or I
> >>>>>>>>> wrote too
> >> much).
> >>>>>>>>>
> >>>>>>>>> Age is fragile because if the clock changes between issue_date
> >>>>>>>>> and
> >> the time of submission, it will fail. We know many people don't have
> >> synchronized clocks, but using age only solves this problem if two
> >> assumptions hold true:
> >>>>>>>>>
> >>>>>>>>> 1) the client is able to guess the issue_date the server is
> >>>>>>>>> using based on the time the credential was issued
> >>>>>>>>> 2) the client system clock doesn't change between issue date
> >>>>>>>>> and
> >> submission time.
> >>>>>>>>>
> >>>>>>>>> Timestamp has neither of these issues because the client can
> >> always inquire about network time and can effectively correct for
> >> inaccuracies in the device timekeeping system.
> >>>>>>>>>
> >>>>>>>>> Regarding the first assumption, this fails when a token might
> >>>>>>>>> be re-
> >> issued between devices. An example is that we use MAC token for the
> >> client credentials, which are issued when a developer registers an
> >> application. The client has no way of determining on its own when the
> >> value was actually issued (unless we communicate that on the
> >> developer website and force users to embed that with client_id, which
> >> adds usability issues of users copying and entering string date
> >> values correctly). The same is actually true for all of our OAuth
> >> access tokens because we reissue tokens to the same client_id if they
> >> were previously issued and are still valid. (The client would thus
> >> think the issue_date was now() when if fact it was the time of the
> >> first issue for client_id+scope+grantor_id). Thus, age is really just =
a
> convoluted way of trying to communicate the device system offset:
> >>>>>>>>>
> >>>>>>>>>       local_offset =3D current_server_time - current_device_tim=
e
> >>>>>>>>>       age =3D current_device_time -
> >>>>>>>>> (server_issue_date-local_offset)
> >>>>>>>>>
> >>>>>>>>> Since the protocol doesn't currently allow for
> >>>>>>>>> server_issue_date to
> >> be given with tokens, thus age currently can't have the resilience
> >> that timestamp does. It also forces servers to issue new tokens on
> >> demand just to make the convoluted age system work (rather than reuse
> >> existing valid tokens). Or, you have to modify the protocol to add
> >> server_issue_date and current_server_time into the token-issue
> exchange - eg, more complexity.
> >>>>>>>>>
> >>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
> >>>>>>>>> your use
> >> case of unsyncronized clocks.
> >>>>>>>>>
> >>>>>>>>> skylar
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
> >>>>>>>>>> don't have synchronized clocks, for a wide variety of reasons.
> >>>>>>>>>> I guess I don't really understand why you view age as
> >>>>>>>>>> problematic.  You reference "fragility of using
> >>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
> >>>>>>>>>> is fragile about it.  There's nothing particularly complex
> >>>>>>>>>> about age, especially when using the monotonic clock provided
> >>>>>>>>>> by
> >> all modern operating systems.
> >>>>>>>>>>
> >>>>>>>>>> Adam
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
> >>  wrote:
> >>>>>>>>>>
> >>>>>>>>>>> But see, now you are specializing the use of MAC token even
> >> more - now it's becoming a service mainly for user-agents on home
> >> desktops? This is further for the original goal of making MAC as
> >> flexible is possible. In this case you should change the spec name to
> >>
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> >> REFOX - or MTBCRLF for short.
> >>>>>>>>>>>
> >>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as
> >>>>>>>>>>> your
> >> offset technique and is more: reliable, straightforward, flexible.
> >>>>>>>>>>>
> >>>>>>>>>>> User agents that care about creating robust behavior for
> >>>>>>>>>>> home
> >> desktops or mobiles (presumably of users and OS not yet sophisticated
> >> enough to check network time on their own) should be advised to do
> >> clock correction on their own (by pinging a time service) and
> >> trusting the device clock alone.
> >>>>>>>>>>>
> >>>>>>>>>>> Please change the spec back to using timestamp rather than
> age.
> >>>>>>>>>>>
> >>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla
> >>>>>>>>>>> co-
> >> authors about why they think that age is more resilient than the
> >> above (I believe it is not) and further more why they would find the
> >> above unattractive or difficult to implement in a modern user-agent.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> skylar
> >>>>>>>>>>>
> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. -
> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-
> >> - --- --- -.. .-- .- .-. -..
> >>>>>>>>>>> skylar woodward
> >>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Any kind of clock sync requirement for user-agents
> >>>>>>>>>>>> (basically,
> >> home desktops) it completely impractical. The added complexity pales
> >> in comparison to the difficulty of trying to use timestamps and any
> >> kind of clock sync. No window will be big enough as experience shows
> >> some users have closes that are off by more than an hour and a half.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The issue here is who is this being optimized for.
> >>>>>>>>>>>> Server-to-
> >> server communication should simply use TLS for privacy and MITM
> >> protection on top of MAC instead of using nonces to prevent replay.
> >> The whole point of this kind of replay protection is when TLS is not
> available.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think a better approach is to simply make checking the
> >>>>>>>>>>>> nonce
> >> optional when TLS is used.
> >>>>>>>>>>>>
> >>>>>>>>>>>> EHL
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >> bounces@ietf.org]
> >>>>>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
> >> element -
> >>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>>>>> time-since-credentials-issued, and also the added
> >>>>>>>>>>>>> complexity
> >> of specifying this construction.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think it would be preferable to always require a
> >>>>>>>>>>>>> timestamp as part of the authorization header, and maybe
> >>>>>>>>>>>>> even include in the spec a maximum time difference
> between
> >>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
> >>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
> >>>>>>>>>>>>> since the value need to
> >> longer be unique over all time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We have such rules in place for an HMAC-based
> >> authentication
> >>>>>>>>>>>>> system we use.  Once in a while a client has a local clock
> >>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Peter
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
> OAuth
> >> WG
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
> element -
> >>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
> >>>>>>>>>>>>>>> bit, I would suggest that
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>>>>> without further requirements. It might be suggested that
> >>>>>>>>>>>>> this be composed of an
> >>>>>>>>>>>>> random+timestamp (not age) value, but that seems more
> of a
> >>>>>>>>>>>>> random+MAY or
> >>>>>>>>>>>>> "recommended" practice. If the expectation is that very
> >>>>>>>>>>>>> few if any providers would actually check the timestamp
> >>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
> >>>>>>>>>>>>> the draft that requires it? Developers are doing extra
> >>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
> >>>>>>>>>>>>> with
> >> no payoff or added security.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
> >> the
> >>>>>>>>>>>>>>> v3-5 changes
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
> >>>>>>>>>>>>> now the most complicated part of the normalized request
> >>>>>>>>>>>>> string
> >> and yet these changes offer the least benefit.
> >>>>>>>>>>>>> What's most important is that nonces are unique on each
> >> request for an ID.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
> >>>>>>>>>>>>>>> based on receipt, then the internal clock changes
> >>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
> >>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
> >>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix it
> >>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix
> >>>>>>>>>>>>>>> your clock or Twitterbot will stop working!). Though we
> >>>>>>>>>>>>>>> say that timezones won't bring about the situation of
> >>>>>>>>>>>>>>> changed clock, I'd be to differ. Many users aren't savvy
> >>>>>>>>>>>>>>> enough to change time zone, but just adjust the time to
> >>>>>>>>>>>>>>> local time anyway. Users who are more likely to get it
> >>>>>>>>>>>>>>> right already have auto clock sync enabled (via web,
> >>>>>>>>>>>>>>> mobile, etc.)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> the issue time has to be obtained from the server and
> >>>>>>>>>>>>> stored on the client then you have the same problem as
> >>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
> >>>>>>>>>>>>> server clock and there is no adjustment. You want this to
> >>>>>>>>>>>>> apply to uses outside of just OAuth, but now requiring the
> >>>>>>>>>>>>> client to be able to determine an issue time based on when
> >>>>>>>>>>>>> it receives
> >> an HTTP request necessarily limits the types of token flows for which
> >> this can be used.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>>>>> developer, but it is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
> >>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
> >>>>>>>>>>>>> clock offset value" but obfuscated several times over (one
> >>>>>>>>>>>>> for each
> >> token) as issue_date.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - This implementation assumes software programs use
> the
> >>>>>>>>>>>>>>> computer
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
> >>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
> >>>>>>>>>>>>> origin server (or similar trusted time
> >>>>>>>>>>>>> authority) to ask it the current time. Then it could store
> >>>>>>>>>>>>> a "my device clock offset" value for the lifetime of the
> >>>>>>>>>>>>> program execution. All requests needing timestamp would
> be
> >>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
> >>>>>>>>>>>>> since the
> >> stored issue_date, the problem can't be corrected in this manner.
> >>>>>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
> >>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more
> >>>>>>>>>>>>> I think about the implications of the age parameter, the
> >>>>>>>>>>>>> less I like it. Timestamp has been used for many years in
> >>>>>>>>>>>>> the industry and with reasonable success in relevant
> >>>>>>>>>>>>> applications. If we change to a new way of trying to sync
> >>>>>>>>>>>>> on
> >> time I think we run a greater risk of stumbling upon unforeseen
> >> issues, such as those outlined above.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp
> for
> >>>>>>>>>>>>>>> that matter)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> be dropped from the nonce construction. For providers
> that
> >>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
> >>>>>>>>>>>>> (either as part of the nonce or the overall header, as
> before).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> >> "example.net"
> >>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
> >>>>>>>>>>>>>>>> Certainly addresses my
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
> mac-
> >> tok
> >>>>>>>>>>>>>>>>> en
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
> >>>>>>>>>>>>>>>>> mailing list for the
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> time being, I wanted to give a quick update to those who
> >>>>>>>>>>>>> have been following this draft which originated on this lis=
t.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
> >> draft
> >>>>>>>>>>>>>>>>> is now a
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
> >>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less tha=
n
> a page.
> >>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
> OAuth
> >>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
> >> draft.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> >> session cookies.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
> >> draft
> >>>>>>>>>>>>>>>>> uses the
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
> remove
> >> the
> >>>>>>>>>>>>>>>>> need for
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> clock sync.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
> >>>>>>>>>>>>>>>>> text to be
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
> >>>>>>>>>>>>>>>>> the credentials as
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> an additional protection.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia=
.
> >> Inc.
> >>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
> >> http://www.drupalgardens.com"
> >>>>>>>>>>>>>
> _______________________________________________
> >>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth


From skylar@kiva.org  Tue May 31 23:03: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 000A0E0697 for ; Tue, 31 May 2011 23:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level: 
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=-0.467, 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 8bclgVGZ9wr8 for ; Tue, 31 May 2011 23:03:41 -0700 (PDT)
Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 08AE6E062A for ; Tue, 31 May 2011 23:03:39 -0700 (PDT)
Received: from mail-ww0-f43.google.com ([74.125.82.43]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXWOtmNK9O3Ijoocw8ibbCa551Jr+FE@postini.com; Tue, 31 May 2011 23:03:40 PDT
Received: by wwb17 with SMTP id 17so5303033wwb.0 for ; Tue, 31 May 2011 23:03:37 -0700 (PDT)
Received: by 10.216.235.133 with SMTP id u5mr4291275weq.101.1306908216521; Tue, 31 May 2011 23:03:36 -0700 (PDT)
Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id w58sm413466weq.25.2011.05.31.23.03.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 23:03:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Skylar Woodward 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 08:03:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <67CC0F44-B79E-4A94-8A7C-FDCC1EC74B9D@kiva.org>
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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE59299.2020909@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@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 06:03:44 -0000

Eran, sorry, where should use cases be officially documented?=20

I assume the use cases being more like "HTTP Auth" are not in reference =
to the ones I've been describing. For my part, I'm focused on OAuth use =
cases. Both that of a single token being used on multiple devices (or =
app instances) and that of tokens being presented for client credentials =
in the OAuth flow. I thought we had already agreed from a previous =
thread that the MAC token spec should be extensible beyond just use of =
access tokens and at least to that of client credentials.

skylar


On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:

> They are coming in 2-3 directions, the use case isn't really clear =
(other than claims of some flavors being harder than others), and =
overall this is more about general HTTP authentication than OAuth use =
cases. Don't get me wrong - if you want to put the effort in to capture =
these, go ahead. I just think this isn't worth the effort in a formal =
document.
>=20
> EHL
>=20
>> -----Original Message-----
>> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
>> Sent: Tuesday, May 31, 2011 6:15 PM
>> To: Eran Hammer-Lahav
>> Cc: Phil Hunt; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC =
token
>>=20
>> Maybe...  But this information must be captured somewhere, right?
>>=20
>> At the moment, there seems to be no record of and consequently no
>> reference point to the use case in question. And this is what has =
created all
>> this discussion--with messages coming from all directions.
>>=20
>> Igor
>>=20
>> Eran Hammer-Lahav wrote:
>>> I think the use case document should focus on v2, not on MAC. At =
some
>> point, it becomes impractical to keep every use case discussed on =
this list
>> recorded.
>>>=20
>>> EHL
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of Igor Faynberg
>>>> Sent: Tuesday, May 31, 2011 3:50 PM
>>>> To: Phil Hunt
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
>>>> token
>>>>=20
>>>> ...Sorry to turn the question around so as to underline my pet =
peeve:
>>>> Have we *documented* all cases?  (This is what the Use Cases =
document
>>>> is supposed to be all about.)
>>>>=20
>>>> Just to clarify: I am not arguing with Phil's point now. I just
>>>> stress that as of this moment we don't have anything to check =
against.
>>>>=20
>>>> Igor
>>>>=20
>>>> Phil Hunt wrote:
>>>>=20
>>>>> There seems to be a demonstrated need for both age and timestamp
>>>>>=20
>>>> tokens.
>>>>=20
>>>>> The list has 2 separate cases with 2 separate proposals that do =
not
>>>>> solve all
>>>>>=20
>>>> cases.
>>>>=20
>>>>> Can we at least agree that neither proposal works in all cases?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> You haven't described a problem.
>>>>>>=20
>>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward =

>>>>>>=20
>>>> wrote:
>>>>=20
>>>>>>> First we should agree on a common understanding of the spec. The
>>>>>>>=20
>>>> reason why age works with unsynchronized clocks is that the client
>>>> determines issue_date based on the time when it receives the token
>>>> over the wire. This depends on the server and client both recording
>>>> time this way and for the transmission of the token to be be not
>>>> longer than the margin of error for validating age. Are we agreed =
on this
>> understanding?
>>>>=20
>>>>>> That's not correct.
>>>>>>=20
>>>>>> The age allows the server to protect against replay attacks in
>>>>>> bounded memory.  With unbounded memory, the server can just
>>>>>>=20
>>>> remember
>>>>=20
>>>>>> every nonce it has ever seen associated with a given key and =
reject
>>>>>>=20
>>>> replays.
>>>>=20
>>>>>> With bounded memory, the server eventually needs to evict some of
>>>>>> these nonces due to memory pressure.  The age value lets the =
server
>>>>>> reject the nonces with the smallest age values first.  The server
>>>>>> then rejects any messages with age values smaller than (or equal
>>>>>> to) the largest age value it has ever evicted for the given key.
>>>>>>=20
>>>>>> Notice that neither clock synchronization nor transmission time
>>>>>> plays a role in that implementation.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> The easiest case for me to explain here is client credentials
>>>>>>> because I
>>>>>>>=20
>>>> have to assume you've built and registered a Twitter app at some
>>>> point (or similar OAuth 1.0a app). You registered your app on the
>>>> site and were issued a client_id and client_secret (called
>>>> consumer_key and consumer_secret in 1.0). You then embedded these
>>>> values in your client (they were not issued programmatically to =
your
>>>> app). Assuming the MAC token algorithm is used then for =
establishing
>>>> client identity (originally one of the uses we, the working group,
>>>> hoped MAC would cover) how then will your client determine issue =
date?
>>>>=20
>>>>>> I recommend the date at which the developer obtained the =
credential
>>>>>> from Twitter because that is the date when the credential was =
issued.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> After we can establish where you're at on the two above points
>>>>>>> I'll
>>>>>>>=20
>>>> continue with the explanation. But as a preview, the next points =
would
>> be:
>>>>=20
>>>>>>> - If issue_date comes form the server, how is it translated to =
the
>> client?
>>>>>>>=20
>>>>>>>=20
>>>>>> The issue_date does not come from the server.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> - If you use a server provided issue_date, how do you then
>>>>>>> translate
>>>>>>>=20
>>>> that a value relative to the local unsyncronized clock?
>>>>=20
>>>>>> The server does not provide the issue_date.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> - If your answer to that is to also provide the current server
>>>>>>> time to the
>>>>>>>=20
>>>> client so the offset on the server provided issue_date can be
>>>> calculated what is the difference between all of these values and =
just
>> using timestamp?
>>>>=20
>>>>>> My answer is not to provide the current server time to the =
client.
>>>>>>=20
>>>>>> Kind regards,
>>>>>> Adam
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> So don't get wrapped up in those 3 questions until we establish
>>>>>>> your
>>>>>>>=20
>>>> contextual understanding of the first two paragraphs. Feel free to
>>>> also respond to me off the list so we don't trouble everyone else
>>>> with us getting on the same page (the reason, I thought, why a =
Skype
>>>> call would be more efficient and painless). I do think my
>>>> explanations all have been very clear thus far. There must be a
>>>> contextual confusion that is keeping us from a common understanding =
of
>> the terminology or the use cases.
>>>>=20
>>>>>>> skylar
>>>>>>>=20
>>>>>>>=20
>>>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
>>>>>>>> caused by age clearly?  I didn't understand your previous
>>>>>>>> explanation.  The more concrete you can be, the better.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> Adam
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
>>>>>>>> 
>>>>>>>>=20
>>>> wrote:
>>>>=20
>>>>>>>>> It seems we're failing to communicate. Or you're not
>>>>>>>>> understanding
>>>>>>>>>=20
>>>> my use cases. Age doesn't "just" work. It only works for a limited
>>>> number of uses cases that must include all of yours - and it is
>>>> brittle at that. It doesn't work for any of our uses cases (where =
the
>>>> client can't know issue_date w/o the server telling it - in which
>>>> case we have the equivalent problem as timestamp).
>>>>=20
>>>>>>>>> If you'd like to talk this out over Skype I'm happy to do =
that,
>>>>>>>>> so I can
>>>>>>>>>=20
>>>> help you understand why age doesn't work.
>>>>=20
>>>>>>>>>=20
>>>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> Timestamps don't work when the client doesn't have a
>>>>>>>>>> synchronized clock.  It's true that a client could =
synchronize
>>>>>>>>>> its clock with the network, but our implementation experience
>>>>>>>>>> is that many clients don't for a variety of reasons.  That
>>>>>>>>>> means that age better because, you know, it works.
>>>>>>>>>>=20
>>>>>>>>>> Adam
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>>>>>>>>>>=20
>>>>  wrote:
>>>>=20
>>>>>>>>>>> I don't think you read my first message on the topic (or I
>>>>>>>>>>> wrote too
>>>>>>>>>>>=20
>>>> much).
>>>>=20
>>>>>>>>>>> Age is fragile because if the clock changes between =
issue_date
>>>>>>>>>>> and
>>>>>>>>>>>=20
>>>> the time of submission, it will fail. We know many people don't =
have
>>>> synchronized clocks, but using age only solves this problem if two
>>>> assumptions hold true:
>>>>=20
>>>>>>>>>>> 1) the client is able to guess the issue_date the server is
>>>>>>>>>>> using based on the time the credential was issued
>>>>>>>>>>> 2) the client system clock doesn't change between issue date
>>>>>>>>>>> and
>>>>>>>>>>>=20
>>>> submission time.
>>>>=20
>>>>>>>>>>> Timestamp has neither of these issues because the client can
>>>>>>>>>>>=20
>>>> always inquire about network time and can effectively correct for
>>>> inaccuracies in the device timekeeping system.
>>>>=20
>>>>>>>>>>> Regarding the first assumption, this fails when a token =
might
>>>>>>>>>>> be re-
>>>>>>>>>>>=20
>>>> issued between devices. An example is that we use MAC token for the
>>>> client credentials, which are issued when a developer registers an
>>>> application. The client has no way of determining on its own when =
the
>>>> value was actually issued (unless we communicate that on the
>>>> developer website and force users to embed that with client_id, =
which
>>>> adds usability issues of users copying and entering string date
>>>> values correctly). The same is actually true for all of our OAuth
>>>> access tokens because we reissue tokens to the same client_id if =
they
>>>> were previously issued and are still valid. (The client would thus
>>>> think the issue_date was now() when if fact it was the time of the
>>>> first issue for client_id+scope+grantor_id). Thus, age is really =
just a
>> convoluted way of trying to communicate the device system offset:
>>>>=20
>>>>>>>>>>>       local_offset =3D current_server_time - =
current_device_time
>>>>>>>>>>>       age =3D current_device_time -
>>>>>>>>>>> (server_issue_date-local_offset)
>>>>>>>>>>>=20
>>>>>>>>>>> Since the protocol doesn't currently allow for
>>>>>>>>>>> server_issue_date to
>>>>>>>>>>>=20
>>>> be given with tokens, thus age currently can't have the resilience
>>>> that timestamp does. It also forces servers to issue new tokens on
>>>> demand just to make the convoluted age system work (rather than =
reuse
>>>> existing valid tokens). Or, you have to modify the protocol to add
>>>> server_issue_date and current_server_time into the token-issue
>> exchange - eg, more complexity.
>>>>=20
>>>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
>>>>>>>>>>> your use
>>>>>>>>>>>=20
>>>> case of unsyncronized clocks.
>>>>=20
>>>>>>>>>>> skylar
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many =
folks
>>>>>>>>>>>> don't have synchronized clocks, for a wide variety of =
reasons.
>>>>>>>>>>>> I guess I don't really understand why you view age as
>>>>>>>>>>>> problematic.  You reference "fragility of using
>>>>>>>>>>>> time-since-credentials-issued" but you don't say what =
exactly
>>>>>>>>>>>> is fragile about it.  There's nothing particularly complex
>>>>>>>>>>>> about age, especially when using the monotonic clock =
provided
>>>>>>>>>>>> by
>>>>>>>>>>>>=20
>>>> all modern operating systems.
>>>>=20
>>>>>>>>>>>> Adam
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>>>>>>>>>>>>=20
>>>>  wrote:
>>>>=20
>>>>>>>>>>>>> But see, now you are specializing the use of MAC token =
even
>>>>>>>>>>>>>=20
>>>> more - now it's becoming a service mainly for user-agents on home
>>>> desktops? This is further for the original goal of making MAC as
>>>> flexible is possible. In this case you should change the spec name =
to
>>>>=20
>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
>>>> REFOX - or MTBCRLF for short.
>>>>=20
>>>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good =
as
>>>>>>>>>>>>> your
>>>>>>>>>>>>>=20
>>>> offset technique and is more: reliable, straightforward, flexible.
>>>>=20
>>>>>>>>>>>>> User agents that care about creating robust behavior for
>>>>>>>>>>>>> home
>>>>>>>>>>>>>=20
>>>> desktops or mobiles (presumably of users and OS not yet =
sophisticated
>>>> enough to check network time on their own) should be advised to do
>>>> clock correction on their own (by pinging a time service) and
>>>> trusting the device clock alone.
>>>>=20
>>>>>>>>>>>>> Please change the spec back to using timestamp rather than
>> age.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I'd also like to hear a convincing argument from the =
Mozilla
>>>>>>>>>>>>> co-
>>>>>>>>>>>>>=20
>>>> authors about why they think that age is more resilient than the
>>>> above (I believe it is not) and further more why they would find =
the
>>>> above unattractive or difficult to implement in a modern =
user-agent.
>>>>=20
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. =
-
>>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-
>>>>>>>>>>>>>=20
>>>> - --- --- -.. .-- .- .-. -..
>>>>=20
>>>>>>>>>>>>> skylar woodward
>>>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Any kind of clock sync requirement for user-agents
>>>>>>>>>>>>>> (basically,
>>>>>>>>>>>>>>=20
>>>> home desktops) it completely impractical. The added complexity =
pales
>>>> in comparison to the difficulty of trying to use timestamps and any
>>>> kind of clock sync. No window will be big enough as experience =
shows
>>>> some users have closes that are off by more than an hour and a =
half.
>>>>=20
>>>>>>>>>>>>>> The issue here is who is this being optimized for.
>>>>>>>>>>>>>> Server-to-
>>>>>>>>>>>>>>=20
>>>> server communication should simply use TLS for privacy and MITM
>>>> protection on top of MAC instead of using nonces to prevent replay.
>>>> The whole point of this kind of replay protection is when TLS is =
not
>> available.
>>>>=20
>>>>>>>>>>>>>> I think a better approach is to simply make checking the
>>>>>>>>>>>>>> nonce
>>>>>>>>>>>>>>=20
>>>> optional when TLS is used.
>>>>=20
>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>>>>>>>>>>>>>>>=20
>>>> bounces@ietf.org]
>>>>=20
>>>>>>>>>>>>>>> On Behalf Of Peter Wolanin
>>>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
>>>>>>>>>>>>>>>=20
>>>> element -
>>>>=20
>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> I am also concerned by the fragility of using
>>>>>>>>>>>>>>> time-since-credentials-issued, and also the added
>>>>>>>>>>>>>>> complexity
>>>>>>>>>>>>>>>=20
>>>> of specifying this construction.
>>>>=20
>>>>>>>>>>>>>>> I think it would be preferable to always require a
>>>>>>>>>>>>>>> timestamp as part of the authorization header, and maybe
>>>>>>>>>>>>>>> even include in the spec a maximum time difference
>> between
>>>>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
>>>>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
>>>>>>>>>>>>>>> since the value need to
>>>>>>>>>>>>>>>=20
>>>> longer be unique over all time.
>>>>=20
>>>>>>>>>>>>>>> We have such rules in place for an HMAC-based
>>>>>>>>>>>>>>>=20
>>>> authentication
>>>>=20
>>>>>>>>>>>>>>> system we use.  Once in a while a client has a local =
clock
>>>>>>>>>>>>>>> so far out of sync that there is an issue, but it's =
rare.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> -Peter
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
>> OAuth
>>>>>>>>>>>>>>>>>=20
>>>> WG
>>>>=20
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
>> element -
>>>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
>>>>>>>>>>>>>>>>> bit, I would suggest that
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
>>>>>>>>>>>>>>> without further requirements. It might be suggested that
>>>>>>>>>>>>>>> this be composed of an
>>>>>>>>>>>>>>> random+timestamp (not age) value, but that seems more
>> of a
>>>>>>>>>>>>>>> random+MAY or
>>>>>>>>>>>>>>> "recommended" practice. If the expectation is that very
>>>>>>>>>>>>>>> few if any providers would actually check the timestamp
>>>>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
>>>>>>>>>>>>>>> the draft that requires it? Developers are doing extra
>>>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>=20
>>>> no payoff or added security.
>>>>=20
>>>>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
>>>>>>>>>>>>>>>>>=20
>>>> the
>>>>=20
>>>>>>>>>>>>>>>>> v3-5 changes
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> last night (for both client credentials and requests w/
>>>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
>>>>>>>>>>>>>>> now the most complicated part of the normalized request
>>>>>>>>>>>>>>> string
>>>>>>>>>>>>>>>=20
>>>> and yet these changes offer the least benefit.
>>>>=20
>>>>>>>>>>>>>>> What's most important is that nonces are unique on each
>>>>>>>>>>>>>>>=20
>>>> request for an ID.
>>>>=20
>>>>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue =
time
>>>>>>>>>>>>>>>>> based on receipt, then the internal clock changes
>>>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
>>>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
>>>>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix =
it
>>>>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix
>>>>>>>>>>>>>>>>> your clock or Twitterbot will stop working!). Though =
we
>>>>>>>>>>>>>>>>> say that timezones won't bring about the situation of
>>>>>>>>>>>>>>>>> changed clock, I'd be to differ. Many users aren't =
savvy
>>>>>>>>>>>>>>>>> enough to change time zone, but just adjust the time =
to
>>>>>>>>>>>>>>>>> local time anyway. Users who are more likely to get it
>>>>>>>>>>>>>>>>> right already have auto clock sync enabled (via web,
>>>>>>>>>>>>>>>>> mobile, etc.)
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> - What if the token wasn't originally issued
>>>>>>>>>>>>>>>>> programmatically? In this case,
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> the issue time has to be obtained from the server and
>>>>>>>>>>>>>>> stored on the client then you have the same problem as
>>>>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
>>>>>>>>>>>>>>> server clock and there is no adjustment. You want this =
to
>>>>>>>>>>>>>>> apply to uses outside of just OAuth, but now requiring =
the
>>>>>>>>>>>>>>> client to be able to determine an issue time based on =
when
>>>>>>>>>>>>>>> it receives
>>>>>>>>>>>>>>>=20
>>>> an HTTP request necessarily limits the types of token flows for =
which
>>>> this can be used.
>>>>=20
>>>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
>>>>>>>>>>>>>>>>> developer, but it is
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
>>>>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
>>>>>>>>>>>>>>> clock offset value" but obfuscated several times over =
(one
>>>>>>>>>>>>>>> for each
>>>>>>>>>>>>>>>=20
>>>> token) as issue_date.
>>>>=20
>>>>>>>>>>>>>>>>> - This implementation assumes software programs use
>> the
>>>>>>>>>>>>>>>>> computer
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust =
program
>>>>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
>>>>>>>>>>>>>>> origin server (or similar trusted time
>>>>>>>>>>>>>>> authority) to ask it the current time. Then it could =
store
>>>>>>>>>>>>>>> a "my device clock offset" value for the lifetime of the
>>>>>>>>>>>>>>> program execution. All requests needing timestamp would
>> be
>>>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
>>>>>>>>>>>>>>> since the
>>>>>>>>>>>>>>>=20
>>>> stored issue_date, the problem can't be corrected in this manner.
>>>>=20
>>>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> All in all, this seems like a misguided but
>>>>>>>>>>>>>>>>> well-intentioned attempt to get
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like =
a
>>>>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The =
more
>>>>>>>>>>>>>>> I think about the implications of the age parameter, the
>>>>>>>>>>>>>>> less I like it. Timestamp has been used for many years =
in
>>>>>>>>>>>>>>> the industry and with reasonable success in relevant
>>>>>>>>>>>>>>> applications. If we change to a new way of trying to =
sync
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>=20
>>>> time I think we run a greater risk of stumbling upon unforeseen
>>>> issues, such as those outlined above.
>>>>=20
>>>>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp
>> for
>>>>>>>>>>>>>>>>> that matter)
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> be dropped from the nonce construction. For providers
>> that
>>>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
>>>>>>>>>>>>>>> (either as part of the nonce or the overall header, as
>> before).
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
>>>>>>>>>>>>>>>>>>=20
>>>> "example.net"
>>>>=20
>>>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
>>>>>>>>>>>>>>>>>> Certainly addresses my
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
>> wrote:
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
>> mac-
>>>>>>>>>>>>>>>>>>>=20
>>>> tok
>>>>=20
>>>>>>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
>>>>>>>>>>>>>>>>>>> mailing list for the
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
>>>>>>>>>>>>>>> have been following this draft which originated on this =
list.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
>>>>>>>>>>>>>>>>>>>=20
>>>> draft
>>>>=20
>>>>>>>>>>>>>>>>>>> is now a
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
>>>>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less =
than
>> a page.
>>>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
>> OAuth
>>>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the =
MAC
>>>>>>>>>>>>>>>=20
>>>> draft.
>>>>=20
>>>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
>>>>>>>>>>>>>>>>>>>=20
>>>> session cookies.
>>>>=20
>>>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
>>>>>>>>>>>>>>>>>>>=20
>>>> draft
>>>>=20
>>>>>>>>>>>>>>>>>>> uses the
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
>> remove
>>>>>>>>>>>>>>>>>>>=20
>>>> the
>>>>=20
>>>>>>>>>>>>>>>>>>> need for
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
>>>>>>>>>>>>>>>>>>> text to be
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source =
of
>>>>>>>>>>>>>>>>>>> the credentials as
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>=20
>>>> _______________________________________________
>>>>=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
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  =
Acquia.
>>>>>>>>>>>>>>>=20
>>>> Inc.
>>>>=20
>>>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
>>>>>>>>>>>>>>>=20
>>>> http://www.drupalgardens.com"
>>>>=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
>>>>>>>>>>>>>=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
>>>>>=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 beaton@google.com  Tue May 31 23:05: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 978ADE06DD for ; Tue, 31 May 2011 23:05:15 -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 cyHQbiuhQNAj for ; Tue, 31 May 2011 23:05:14 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADC1E06BF for ; Tue, 31 May 2011 23:05:14 -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 p5165Dqe018424 for ; Tue, 31 May 2011 23:05:13 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306908313; bh=PQZKLZ8PvjxwYJGyCCwqezwVpfw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=iSXYSyH9jofmO9A96MQF7SJNXvfemmqoYCwgmZbKXJ/4Jhaz717oenz9oLe+MuQ41 ZN5JO6SDreES5aJYJSd7A==
Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by wpaz24.hot.corp.google.com with ESMTP id p5165BMC008724 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 23:05:12 -0700
Received: by pxi7 with SMTP id 7so3568663pxi.16 for ; Tue, 31 May 2011 23:05:11 -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=YVfkZ3JL+daOKS0fFBAnraC+QGJeqtoN+1/JYqX2/Co=; b=qfiVxF7d+MR4AlQis9zq5CfjEw7wMrnPxqrXgR1Qsv9VO/Mzb3ffiqbMLCJt7Oxr8G 8vn78EadOCeb8JN/p6zQ==
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=HD+2I1CBeGwlF04AWFRZtDojR0MSAi5IdeX+GkJb2ut+Gv0qi8C/UhEwfp2KeU9t7I d2EmLe2g4CtUXS2JS9JA==
MIME-Version: 1.0
Received: by 10.142.248.41 with SMTP id v41mr1169820wfh.323.1306908311537; Tue, 31 May 2011 23:05:11 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Tue, 31 May 2011 23:05:11 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>   
Date: Tue, 31 May 2011 23:05:11 -0700
Message-ID: 
From: Brian Eaton 
To: Kris Selden 
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 06:05:15 -0000

On Tue, May 31, 2011 at 10:39 PM, Kris Selden  wrote:
> Why can't you just revoke the refresh token for a client when you change the client secret?
>
> Is it not easier to revoke a token than it is to rotate the client secret (which is usually configured or embedded in the client whereas the token is issued)?

As I noted in my original e-mail on this thread, I was talking
specifically about the web server flow.

This is one area where the security considerations for installed
applications are different than for web servers.

From skylar@kiva.org  Tue May 31 23: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 1FA6FE0662 for ; Tue, 31 May 2011 23:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.699
X-Spam-Level: 
X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 uSn4fcnGPDna for ; Tue, 31 May 2011 23:07:43 -0700 (PDT)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id 0EC30E062A for ; Tue, 31 May 2011 23:07:42 -0700 (PDT)
Received: from mail-wy0-f179.google.com ([74.125.82.179]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTeXXLtEoguC9jQuieoWTGIYwMH6SYIhT@postini.com; Tue, 31 May 2011 23:07:43 PDT
Received: by wyg36 with SMTP id 36so3833634wyg.10 for ; Tue, 31 May 2011 23:07:41 -0700 (PDT)
Received: by 10.227.167.129 with SMTP id q1mr6831694wby.101.1306908461076; Tue, 31 May 2011 23:07:41 -0700 (PDT)
Received: from [78.250.139.245] ([78.250.139.245]) by mx.google.com with ESMTPS id d19sm503554wbh.25.2011.05.31.23.07.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 23:07:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Skylar Woodward 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA43C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 08:07:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0157F4BF-7B48-4BFE-9687-2CA9FF058C2A@kiva.org>
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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723447583CA43C@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 06:07:44 -0000

On Jun 1, 2011, at 7:58 AM, Eran Hammer-Lahav wrote:

> I don't think you have made the case why you age is any harder to =
implement than a timestamp. It is not that your email isn't clear, it's =
that we're not convinced that timestamp will produce any better result =
than age in practice. This is purely technical, not political.

That's no longer my point. I've now realized it doesn't work for all of =
my uses for MAC token (assuming we validate age, either by the =
implementation Adam suggested or by the one I had assumed where age is =
judged "old" by comparing to a device system time).

Let me know if my latest response to Adam doesn't it make it clear why =
this does not work for either client credentials or a token issued to =
multiple instances of a client. If not, I'll continue attempting to =
explain myself.

I also would like to see the specification not to be configurable.=

From igor.faynberg@alcatel-lucent.com  Tue May 31 23:13: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 6FDC3E0665 for ; Tue, 31 May 2011 23:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 wkQWvSvtGFVg for ; Tue, 31 May 2011 23:13:50 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9A06EE0662 for ; Tue, 31 May 2011 23:13:49 -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 p516Djxd002761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 01:13:45 -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 p516Djr3023011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 01:13:45 -0500
Received: from [135.244.19.60] (faynberg.lra.lucent.com [135.244.19.60]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p516Dh3k012412; Wed, 1 Jun 2011 01:13:44 -0500 (CDT)
Message-ID: <4DE5D898.7090306@alcatel-lucent.com>
Date: Wed, 01 Jun 2011 02:13:44 -0400
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Eran Hammer-Lahav 
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>				<0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE59299.2020909@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@P3PW5EX1MB01.EX1.SECURESERVER.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.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
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
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: Wed, 01 Jun 2011 06:13:53 -0000

No, no, my little "I told you so" aside, I don't insist on putting this 
in the document, especially that we have already agreed that the use 
case document is a post-2.0 issue.

I think that for the purposes of the discussion on this thread it would 
help if all the use cases in question were clearly described--if only in 
an e-mail for now.  Then it would be a matter of logic to see if there 
is a problem, and if there is one, what the solutions to it might be.

Igor

Eran Hammer-Lahav wrote:
> They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document.
>
> EHL
>
>   
>> -----Original Message-----
>> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
>> Sent: Tuesday, May 31, 2011 6:15 PM
>> To: Eran Hammer-Lahav
>> Cc: Phil Hunt; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> Maybe...  But this information must be captured somewhere, right?
>>
>> At the moment, there seems to be no record of and consequently no
>> reference point to the use case in question. And this is what has created all
>> this discussion--with messages coming from all directions.
>>
>> Igor
>>
>> Eran Hammer-Lahav wrote:
>>     
>>> I think the use case document should focus on v2, not on MAC. At some
>>>       
>> point, it becomes impractical to keep every use case discussed on this list
>> recorded.
>>     
>>> EHL
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of Igor Faynberg
>>>> Sent: Tuesday, May 31, 2011 3:50 PM
>>>> To: Phil Hunt
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
>>>> token
>>>>
>>>> ...Sorry to turn the question around so as to underline my pet peeve:
>>>> Have we *documented* all cases?  (This is what the Use Cases document
>>>> is supposed to be all about.)
>>>>
>>>> Just to clarify: I am not arguing with Phil's point now. I just
>>>> stress that as of this moment we don't have anything to check against.
>>>>
>>>> Igor
>>>>
>>>> Phil Hunt wrote:
>>>>
>>>>         
>>>>> There seems to be a demonstrated need for both age and timestamp
>>>>>
>>>>>           
>>>> tokens.
>>>>
>>>>         
>>>>> The list has 2 separate cases with 2 separate proposals that do not
>>>>> solve all
>>>>>
>>>>>           
>>>> cases.
>>>>
>>>>         
>>>>> Can we at least agree that neither proposal works in all cases?
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> You haven't described a problem.
>>>>>>
>>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
>>>>>>
>>>>>>             
>>>> wrote:
>>>>
>>>>         
>>>>>>> First we should agree on a common understanding of the spec. The
>>>>>>>
>>>>>>>               
>>>> reason why age works with unsynchronized clocks is that the client
>>>> determines issue_date based on the time when it receives the token
>>>> over the wire. This depends on the server and client both recording
>>>> time this way and for the transmission of the token to be be not
>>>> longer than the margin of error for validating age. Are we agreed on this
>>>>         
>> understanding?
>>     
>>>>>> That's not correct.
>>>>>>
>>>>>> The age allows the server to protect against replay attacks in
>>>>>> bounded memory.  With unbounded memory, the server can just
>>>>>>
>>>>>>             
>>>> remember
>>>>
>>>>         
>>>>>> every nonce it has ever seen associated with a given key and reject
>>>>>>
>>>>>>             
>>>> replays.
>>>>
>>>>         
>>>>>> With bounded memory, the server eventually needs to evict some of
>>>>>> these nonces due to memory pressure.  The age value lets the server
>>>>>> reject the nonces with the smallest age values first.  The server
>>>>>> then rejects any messages with age values smaller than (or equal
>>>>>> to) the largest age value it has ever evicted for the given key.
>>>>>>
>>>>>> Notice that neither clock synchronization nor transmission time
>>>>>> plays a role in that implementation.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> The easiest case for me to explain here is client credentials
>>>>>>> because I
>>>>>>>
>>>>>>>               
>>>> have to assume you've built and registered a Twitter app at some
>>>> point (or similar OAuth 1.0a app). You registered your app on the
>>>> site and were issued a client_id and client_secret (called
>>>> consumer_key and consumer_secret in 1.0). You then embedded these
>>>> values in your client (they were not issued programmatically to your
>>>> app). Assuming the MAC token algorithm is used then for establishing
>>>> client identity (originally one of the uses we, the working group,
>>>> hoped MAC would cover) how then will your client determine issue date?
>>>>
>>>>         
>>>>>> I recommend the date at which the developer obtained the credential
>>>>>> from Twitter because that is the date when the credential was issued.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> After we can establish where you're at on the two above points
>>>>>>> I'll
>>>>>>>
>>>>>>>               
>>>> continue with the explanation. But as a preview, the next points would
>>>>         
>> be:
>>     
>>>>>>> - If issue_date comes form the server, how is it translated to the
>>>>>>>               
>> client?
>>     
>>>>>>>               
>>>>>> The issue_date does not come from the server.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> - If you use a server provided issue_date, how do you then
>>>>>>> translate
>>>>>>>
>>>>>>>               
>>>> that a value relative to the local unsyncronized clock?
>>>>
>>>>         
>>>>>> The server does not provide the issue_date.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> - If your answer to that is to also provide the current server
>>>>>>> time to the
>>>>>>>
>>>>>>>               
>>>> client so the offset on the server provided issue_date can be
>>>> calculated what is the difference between all of these values and just
>>>>         
>> using timestamp?
>>     
>>>>>> My answer is not to provide the current server time to the client.
>>>>>>
>>>>>> Kind regards,
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> So don't get wrapped up in those 3 questions until we establish
>>>>>>> your
>>>>>>>
>>>>>>>               
>>>> contextual understanding of the first two paragraphs. Feel free to
>>>> also respond to me off the list so we don't trouble everyone else
>>>> with us getting on the same page (the reason, I thought, why a Skype
>>>> call would be more efficient and painless). I do think my
>>>> explanations all have been very clear thus far. There must be a
>>>> contextual confusion that is keeping us from a common understanding of
>>>>         
>> the terminology or the use cases.
>>     
>>>>>>> skylar
>>>>>>>
>>>>>>>
>>>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
>>>>>>>> caused by age clearly?  I didn't understand your previous
>>>>>>>> explanation.  The more concrete you can be, the better.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
>>>>>>>> 
>>>>>>>>
>>>>>>>>                 
>>>> wrote:
>>>>
>>>>         
>>>>>>>>> It seems we're failing to communicate. Or you're not
>>>>>>>>> understanding
>>>>>>>>>
>>>>>>>>>                   
>>>> my use cases. Age doesn't "just" work. It only works for a limited
>>>> number of uses cases that must include all of yours - and it is
>>>> brittle at that. It doesn't work for any of our uses cases (where the
>>>> client can't know issue_date w/o the server telling it - in which
>>>> case we have the equivalent problem as timestamp).
>>>>
>>>>         
>>>>>>>>> If you'd like to talk this out over Skype I'm happy to do that,
>>>>>>>>> so I can
>>>>>>>>>
>>>>>>>>>                   
>>>> help you understand why age doesn't work.
>>>>
>>>>         
>>>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Timestamps don't work when the client doesn't have a
>>>>>>>>>> synchronized clock.  It's true that a client could synchronize
>>>>>>>>>> its clock with the network, but our implementation experience
>>>>>>>>>> is that many clients don't for a variety of reasons.  That
>>>>>>>>>> means that age better because, you know, it works.
>>>>>>>>>>
>>>>>>>>>> Adam
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>>>>>>>>>>
>>>>>>>>>>                     
>>>>  wrote:
>>>>
>>>>         
>>>>>>>>>>> I don't think you read my first message on the topic (or I
>>>>>>>>>>> wrote too
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> much).
>>>>
>>>>         
>>>>>>>>>>> Age is fragile because if the clock changes between issue_date
>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> the time of submission, it will fail. We know many people don't have
>>>> synchronized clocks, but using age only solves this problem if two
>>>> assumptions hold true:
>>>>
>>>>         
>>>>>>>>>>> 1) the client is able to guess the issue_date the server is
>>>>>>>>>>> using based on the time the credential was issued
>>>>>>>>>>> 2) the client system clock doesn't change between issue date
>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> submission time.
>>>>
>>>>         
>>>>>>>>>>> Timestamp has neither of these issues because the client can
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> always inquire about network time and can effectively correct for
>>>> inaccuracies in the device timekeeping system.
>>>>
>>>>         
>>>>>>>>>>> Regarding the first assumption, this fails when a token might
>>>>>>>>>>> be re-
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> issued between devices. An example is that we use MAC token for the
>>>> client credentials, which are issued when a developer registers an
>>>> application. The client has no way of determining on its own when the
>>>> value was actually issued (unless we communicate that on the
>>>> developer website and force users to embed that with client_id, which
>>>> adds usability issues of users copying and entering string date
>>>> values correctly). The same is actually true for all of our OAuth
>>>> access tokens because we reissue tokens to the same client_id if they
>>>> were previously issued and are still valid. (The client would thus
>>>> think the issue_date was now() when if fact it was the time of the
>>>> first issue for client_id+scope+grantor_id). Thus, age is really just a
>>>>         
>> convoluted way of trying to communicate the device system offset:
>>     
>>>>>>>>>>>        local_offset = current_server_time - current_device_time
>>>>>>>>>>>        age = current_device_time -
>>>>>>>>>>> (server_issue_date-local_offset)
>>>>>>>>>>>
>>>>>>>>>>> Since the protocol doesn't currently allow for
>>>>>>>>>>> server_issue_date to
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> be given with tokens, thus age currently can't have the resilience
>>>> that timestamp does. It also forces servers to issue new tokens on
>>>> demand just to make the convoluted age system work (rather than reuse
>>>> existing valid tokens). Or, you have to modify the protocol to add
>>>> server_issue_date and current_server_time into the token-issue
>>>>         
>> exchange - eg, more complexity.
>>     
>>>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
>>>>>>>>>>> your use
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>> case of unsyncronized clocks.
>>>>
>>>>         
>>>>>>>>>>> skylar
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
>>>>>>>>>>>> don't have synchronized clocks, for a wide variety of reasons.
>>>>>>>>>>>> I guess I don't really understand why you view age as
>>>>>>>>>>>> problematic.  You reference "fragility of using
>>>>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
>>>>>>>>>>>> is fragile about it.  There's nothing particularly complex
>>>>>>>>>>>> about age, especially when using the monotonic clock provided
>>>>>>>>>>>> by
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>> all modern operating systems.
>>>>
>>>>         
>>>>>>>>>>>> Adam
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>  wrote:
>>>>
>>>>         
>>>>>>>>>>>>> But see, now you are specializing the use of MAC token even
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>> more - now it's becoming a service mainly for user-agents on home
>>>> desktops? This is further for the original goal of making MAC as
>>>> flexible is possible. In this case you should change the spec name to
>>>>
>>>>         
>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
>>     
>>>> REFOX - or MTBCRLF for short.
>>>>
>>>>         
>>>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as
>>>>>>>>>>>>> your
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>> offset technique and is more: reliable, straightforward, flexible.
>>>>
>>>>         
>>>>>>>>>>>>> User agents that care about creating robust behavior for
>>>>>>>>>>>>> home
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>> desktops or mobiles (presumably of users and OS not yet sophisticated
>>>> enough to check network time on their own) should be advised to do
>>>> clock correction on their own (by pinging a time service) and
>>>> trusting the device clock alone.
>>>>
>>>>         
>>>>>>>>>>>>> Please change the spec back to using timestamp rather than
>>>>>>>>>>>>>                           
>> age.
>>     
>>>>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla
>>>>>>>>>>>>> co-
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>> authors about why they think that age is more resilient than the
>>>> above (I believe it is not) and further more why they would find the
>>>> above unattractive or difficult to implement in a modern user-agent.
>>>>
>>>>         
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. -
>>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>> - --- --- -.. .-- .- .-. -..
>>>>
>>>>         
>>>>>>>>>>>>> skylar woodward
>>>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> Any kind of clock sync requirement for user-agents
>>>>>>>>>>>>>> (basically,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>> home desktops) it completely impractical. The added complexity pales
>>>> in comparison to the difficulty of trying to use timestamps and any
>>>> kind of clock sync. No window will be big enough as experience shows
>>>> some users have closes that are off by more than an hour and a half.
>>>>
>>>>         
>>>>>>>>>>>>>> The issue here is who is this being optimized for.
>>>>>>>>>>>>>> Server-to-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>> server communication should simply use TLS for privacy and MITM
>>>> protection on top of MAC instead of using nonces to prevent replay.
>>>> The whole point of this kind of replay protection is when TLS is not
>>>>         
>> available.
>>     
>>>>>>>>>>>>>> I think a better approach is to simply make checking the
>>>>>>>>>>>>>> nonce
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>> optional when TLS is used.
>>>>
>>>>         
>>>>>>>>>>>>>> EHL
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> bounces@ietf.org]
>>>>
>>>>         
>>>>>>>>>>>>>>> On Behalf Of Peter Wolanin
>>>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>>>>>>>>>>>>>>> To: Skylar Woodward
>>>>>>>>>>>>>>> Cc: OAuth WG
>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> element -
>>>>
>>>>         
>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am also concerned by the fragility of using
>>>>>>>>>>>>>>> time-since-credentials-issued, and also the added
>>>>>>>>>>>>>>> complexity
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> of specifying this construction.
>>>>
>>>>         
>>>>>>>>>>>>>>> I think it would be preferable to always require a
>>>>>>>>>>>>>>> timestamp as part of the authorization header, and maybe
>>>>>>>>>>>>>>> even include in the spec a maximum time difference
>>>>>>>>>>>>>>>                               
>> between
>>     
>>>>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
>>>>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
>>>>>>>>>>>>>>> since the value need to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> longer be unique over all time.
>>>>
>>>>         
>>>>>>>>>>>>>>> We have such rules in place for an HMAC-based
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> authentication
>>>>
>>>>         
>>>>>>>>>>>>>>> system we use.  Once in a while a client has a local clock
>>>>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Peter
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>> Resending to the list from my subscribed account...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>>>> From: Skylar Woodward 
>>>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>>>>>>>>>>>>>>>>> To: Skylar Woodward 
>>>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
>>>>>>>>>>>>>>>>>                                   
>> OAuth
>>     
>>>> WG
>>>>
>>>>         
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
>>>>>>>>>>>>>>>>>                                   
>> element -
>>     
>>>>>>>>>>>>>>>>> MAC token
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
>>>>>>>>>>>>>>>>> bit, I would suggest that
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
>>>>>>>>>>>>>>> without further requirements. It might be suggested that
>>>>>>>>>>>>>>> this be composed of an
>>>>>>>>>>>>>>> random+timestamp (not age) value, but that seems more
>>>>>>>>>>>>>>>                               
>> of a
>>     
>>>>>>>>>>>>>>> random+MAY or
>>>>>>>>>>>>>>> "recommended" practice. If the expectation is that very
>>>>>>>>>>>>>>> few if any providers would actually check the timestamp
>>>>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
>>>>>>>>>>>>>>> the draft that requires it? Developers are doing extra
>>>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> no payoff or added security.
>>>>
>>>>         
>>>>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>> the
>>>>
>>>>         
>>>>>>>>>>>>>>>>> v3-5 changes
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> last night (for both client credentials and requests w/
>>>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
>>>>>>>>>>>>>>> now the most complicated part of the normalized request
>>>>>>>>>>>>>>> string
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> and yet these changes offer the least benefit.
>>>>
>>>>         
>>>>>>>>>>>>>>> What's most important is that nonces are unique on each
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> request for an ID.
>>>>
>>>>         
>>>>>>>>>>>>>>>>> There are issues with age as well:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
>>>>>>>>>>>>>>>>> based on receipt, then the internal clock changes
>>>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
>>>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
>>>>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix it
>>>>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix
>>>>>>>>>>>>>>>>> your clock or Twitterbot will stop working!). Though we
>>>>>>>>>>>>>>>>> say that timezones won't bring about the situation of
>>>>>>>>>>>>>>>>> changed clock, I'd be to differ. Many users aren't savvy
>>>>>>>>>>>>>>>>> enough to change time zone, but just adjust the time to
>>>>>>>>>>>>>>>>> local time anyway. Users who are more likely to get it
>>>>>>>>>>>>>>>>> right already have auto clock sync enabled (via web,
>>>>>>>>>>>>>>>>> mobile, etc.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - What if the token wasn't originally issued
>>>>>>>>>>>>>>>>> programmatically? In this case,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> the issue time has to be obtained from the server and
>>>>>>>>>>>>>>> stored on the client then you have the same problem as
>>>>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
>>>>>>>>>>>>>>> server clock and there is no adjustment. You want this to
>>>>>>>>>>>>>>> apply to uses outside of just OAuth, but now requiring the
>>>>>>>>>>>>>>> client to be able to determine an issue time based on when
>>>>>>>>>>>>>>> it receives
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> an HTTP request necessarily limits the types of token flows for which
>>>> this can be used.
>>>>
>>>>         
>>>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
>>>>>>>>>>>>>>>>> developer, but it is
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
>>>>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
>>>>>>>>>>>>>>> clock offset value" but obfuscated several times over (one
>>>>>>>>>>>>>>> for each
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> token) as issue_date.
>>>>
>>>>         
>>>>>>>>>>>>>>>>> - This implementation assumes software programs use
>>>>>>>>>>>>>>>>>                                   
>> the
>>     
>>>>>>>>>>>>>>>>> computer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
>>>>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
>>>>>>>>>>>>>>> origin server (or similar trusted time
>>>>>>>>>>>>>>> authority) to ask it the current time. Then it could store
>>>>>>>>>>>>>>> a "my device clock offset" value for the lifetime of the
>>>>>>>>>>>>>>> program execution. All requests needing timestamp would
>>>>>>>>>>>>>>>                               
>> be
>>     
>>>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
>>>>>>>>>>>>>>> since the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> stored issue_date, the problem can't be corrected in this manner.
>>>>
>>>>         
>>>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>> All in all, this seems like a misguided but
>>>>>>>>>>>>>>>>> well-intentioned attempt to get
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
>>>>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more
>>>>>>>>>>>>>>> I think about the implications of the age parameter, the
>>>>>>>>>>>>>>> less I like it. Timestamp has been used for many years in
>>>>>>>>>>>>>>> the industry and with reasonable success in relevant
>>>>>>>>>>>>>>> applications. If we change to a new way of trying to sync
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> time I think we run a greater risk of stumbling upon unforeseen
>>>> issues, such as those outlined above.
>>>>
>>>>         
>>>>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp
>>>>>>>>>>>>>>>>>                                   
>> for
>>     
>>>>>>>>>>>>>>>>> that matter)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>> be dropped from the nonce construction. For providers
>>>>>>>>>>>>>>>                               
>> that
>>     
>>>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
>>>>>>>>>>>>>>> (either as part of the nonce or the overall header, as
>>>>>>>>>>>>>>>                               
>> before).
>>     
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                   
>>>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                     
>>>> "example.net"
>>>>
>>>>         
>>>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
>>>>>>>>>>>>>>>>>> Certainly addresses my
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                     
>>>>>>>>>>>>>>> hesitations from v2.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>> skylar
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
>>>>>>>>>>>>>>>>>>                                     
>> wrote:
>>     
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                     
>>>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>>>>>>>>>>>>>>>>>>>  mailing list)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
>>>>>>>>>>>>>>>>>>>                                       
>> mac-
>>     
>>>> tok
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
>>>>>>>>>>>>>>>>>>> mailing list for the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
>>>>>>>>>>>>>>> have been following this draft which originated on this list.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>>> The major changes since -02 are:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>> draft
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> is now a
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
>>>>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less than
>>>>>>>>>>>>>>>                               
>> a page.
>>     
>>>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
>>>>>>>>>>>>>>>                               
>> OAuth
>>     
>>>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> draft.
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>> session cookies.
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>> draft
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> uses the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> raw request URI unchanged.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
>>>>>>>>>>>>>>>>>>>                                       
>> remove
>>     
>>>> the
>>>>
>>>>         
>>>>>>>>>>>>>>>>>>> need for
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> clock sync.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
>>>>>>>>>>>>>>>>>>> text to be
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> included in the request and MAC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
>>>>>>>>>>>>>>>>>>> the credentials as
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                       
>>>>>>>>>>>>>>> an additional protection.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> Inc.
>>>>
>>>>         
>>>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>> http://www.drupalgardens.com"
>>>>
>>>>         
>> _______________________________________________
>>     
>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>             
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>         

From ietf@adambarth.com  Tue May 31 23:22: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 83AE5E06AD for ; Tue, 31 May 2011 23:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_63=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 W-7shinPocFo for ; Tue, 31 May 2011 23:22:38 -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 6A8E8E066A for ; Tue, 31 May 2011 23:22:38 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2840590gxk.31 for ; Tue, 31 May 2011 23:22:38 -0700 (PDT)
Received: by 10.236.189.35 with SMTP id b23mr3530421yhn.21.1306909356389; Tue, 31 May 2011 23:22:36 -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 n29sm867984yhj.82.2011.05.31.23.22.34 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 23:22:35 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2840570gxk.31 for ; Tue, 31 May 2011 23:22:34 -0700 (PDT)
Received: by 10.91.207.11 with SMTP id j11mr5275856agq.17.1306909354488; Tue, 31 May 2011 23:22:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.36.10 with HTTP; Tue, 31 May 2011 23:22:04 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA43C@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723447583CA43C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Adam Barth 
Date: Tue, 31 May 2011 23:22:04 -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] 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 06:22:40 -0000

Yeah, sorry, I didn't mean to offend you Skylar.  Your suggested
approach is similar to the approach Eran alluded to earlier.
Hopefully he'll have some new text that will work for your use case
(which I still don't fully understand).

Adam


On Tue, May 31, 2011 at 10:58 PM, Eran Hammer-Lahav  w=
rote:
> No need to get worked up. I'm sure Adam didn't mean to offend - that's ju=
st his style (speaking as someone who is considered much less polite by a l=
andslide).
>
> I don't think you have made the case why you age is any harder to impleme=
nt than a timestamp. It is not that your email isn't clear, it's that we're=
 not convinced that timestamp will produce any better result than age in pr=
actice. This is purely technical, not political.
>
> However, we did come up with a solution that should cover all bases.
>
> I do strongly object to making this protocol configurable. Configurable a=
uthentication schemes are by definition complex and right now MAC is amazin=
gly simple.
>
> EHL
>
>> -----Original Message-----
>> From: Skylar Woodward [mailto:skylar@kiva.org]
>> Sent: Tuesday, May 31, 2011 10:14 PM
>> To: Eran Hammer-Lahav
>> Cc: igor.faynberg@alcatel-lucent.com; Phil Hunt; OAuth WG
>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>>
>> Yes, but I think my case is very important (eg, being able to use a MAC =
token
>> as a client credential). I don't understand why Adam can't comprehend my
>> explanation. My best guess is this is some kind of political game on his=
 front
>> to protect the age specification yet I don't understand any motivation f=
or
>> being so close-minded. His reply to my last thread was completely
>> disrespectful and ignorant. Unless I've made him mad or offended him in
>> some way I see no excuse for this behavior.
>>
>> I'm going to make one more attempt to try to explain this to him over em=
ail.
>> After that I recommend a Skype call (hopefully brief) or I will work off=
line
>> with Eran to see if we can find some solution.
>>
>> Btw, in addition to the use case of using MAC tokens for client credenti=
als,
>> we also have the use case of re-issuing a valid token multiple times to
>> instances of the same client. (eg, the value of ID and secret are consta=
nt
>> across multiple transmissions to client instances).
>>
>> Thanks,
>> skylar
>>
>> On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote:
>>
>> > I think the use case document should focus on v2, not on MAC. At some
>> point, it becomes impractical to keep every use case discussed on this l=
ist
>> recorded.
>> >
>> > EHL
>> >
>> >> -----Original Message-----
>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> >> Behalf Of Igor Faynberg
>> >> Sent: Tuesday, May 31, 2011 3:50 PM
>> >> To: Phil Hunt
>> >> Cc: OAuth WG
>> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
>> >> token
>> >>
>> >> ...Sorry to turn the question around so as to underline my pet peeve:
>> >> Have we *documented* all cases? =A0(This is what the Use Cases docume=
nt
>> >> is supposed to be all about.)
>> >>
>> >> Just to clarify: I am not arguing with Phil's point now. I just
>> >> stress that as of this moment we don't have anything to check against=
.
>> >>
>> >> Igor
>> >>
>> >> Phil Hunt wrote:
>> >>> There seems to be a demonstrated need for both age and timestamp
>> >> tokens.
>> >>>
>> >>> The list has 2 separate cases with 2 separate proposals that do not
>> >>> solve all
>> >> cases.
>> >>>
>> >>> Can we at least agree that neither proposal works in all cases?
>> >>>
>> >>> Phil
>> >>>
>> >>> @independentid
>> >>> www.independentid.com
>> >>> phil.hunt@oracle.com
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
>> >>>
>> >>>
>> >>>> You haven't described a problem.
>> >>>>
>> >>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward 
>> >> wrote:
>> >>>>
>> >>>>> First we should agree on a common understanding of the spec. The
>> >> reason why age works with unsynchronized clocks is that the client
>> >> determines issue_date based on the time when it receives the token
>> >> over the wire. This depends on the server and client both recording
>> >> time this way and for the transmission of the token to be be not
>> >> longer than the margin of error for validating age. Are we agreed on =
this
>> understanding?
>> >>>>>
>> >>>> That's not correct.
>> >>>>
>> >>>> The age allows the server to protect against replay attacks in
>> >>>> bounded memory. =A0With unbounded memory, the server can just
>> >> remember
>> >>>> every nonce it has ever seen associated with a given key and reject
>> >> replays.
>> >>>> With bounded memory, the server eventually needs to evict some of
>> >>>> these nonces due to memory pressure. =A0The age value lets the serv=
er
>> >>>> reject the nonces with the smallest age values first. =A0The server
>> >>>> then rejects any messages with age values smaller than (or equal
>> >>>> to) the largest age value it has ever evicted for the given key.
>> >>>>
>> >>>> Notice that neither clock synchronization nor transmission time
>> >>>> plays a role in that implementation.
>> >>>>
>> >>>>
>> >>>>> The easiest case for me to explain here is client credentials
>> >>>>> because I
>> >> have to assume you've built and registered a Twitter app at some
>> >> point (or similar OAuth 1.0a app). You registered your app on the
>> >> site and were issued a client_id and client_secret (called
>> >> consumer_key and consumer_secret in 1.0). You then embedded these
>> >> values in your client (they were not issued programmatically to your
>> >> app). Assuming the MAC token algorithm is used then for establishing
>> >> client identity (originally one of the uses we, the working group,
>> >> hoped MAC would cover) how then will your client determine issue date=
?
>> >>>>>
>> >>>> I recommend the date at which the developer obtained the credential
>> >>>> from Twitter because that is the date when the credential was issue=
d.
>> >>>>
>> >>>>
>> >>>>> After we can establish where you're at on the two above points
>> >>>>> I'll
>> >> continue with the explanation. But as a preview, the next points woul=
d
>> be:
>> >>>>>
>> >>>>> - If issue_date comes form the server, how is it translated to the
>> client?
>> >>>>>
>> >>>> The issue_date does not come from the server.
>> >>>>
>> >>>>
>> >>>>> - If you use a server provided issue_date, how do you then
>> >>>>> translate
>> >> that a value relative to the local unsyncronized clock?
>> >>>>>
>> >>>> The server does not provide the issue_date.
>> >>>>
>> >>>>
>> >>>>> - If your answer to that is to also provide the current server
>> >>>>> time to the
>> >> client so the offset on the server provided issue_date can be
>> >> calculated what is the difference between all of these values and jus=
t
>> using timestamp?
>> >>>>>
>> >>>> My answer is not to provide the current server time to the client.
>> >>>>
>> >>>> Kind regards,
>> >>>> Adam
>> >>>>
>> >>>>
>> >>>>
>> >>>>> So don't get wrapped up in those 3 questions until we establish
>> >>>>> your
>> >> contextual understanding of the first two paragraphs. Feel free to
>> >> also respond to me off the list so we don't trouble everyone else
>> >> with us getting on the same page (the reason, I thought, why a Skype
>> >> call would be more efficient and painless). I do think my
>> >> explanations all have been very clear thus far. There must be a
>> >> contextual confusion that is keeping us from a common understanding o=
f
>> the terminology or the use cases.
>> >>>>>
>> >>>>> skylar
>> >>>>>
>> >>>>>
>> >>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
>> >>>>>
>> >>>>>
>> >>>>>> I'm not sure we need a Skype call. =A0Can you explain the trouble
>> >>>>>> caused by age clearly? =A0I didn't understand your previous
>> >>>>>> explanation. =A0The more concrete you can be, the better.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Adam
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
>> >>>>>> 
>> >> wrote:
>> >>>>>>
>> >>>>>>> It seems we're failing to communicate. Or you're not
>> >>>>>>> understanding
>> >> my use cases. Age doesn't "just" work. It only works for a limited
>> >> number of uses cases that must include all of yours - and it is
>> >> brittle at that. It doesn't work for any of our uses cases (where the
>> >> client can't know issue_date w/o the server telling it - in which
>> >> case we have the equivalent problem as timestamp).
>> >>>>>>>
>> >>>>>>> If you'd like to talk this out over Skype I'm happy to do that,
>> >>>>>>> so I can
>> >> help you understand why age doesn't work.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Timestamps don't work when the client doesn't have a
>> >>>>>>>> synchronized clock. =A0It's true that a client could synchroniz=
e
>> >>>>>>>> its clock with the network, but our implementation experience
>> >>>>>>>> is that many clients don't for a variety of reasons. =A0That
>> >>>>>>>> means that age better because, you know, it works.
>> >>>>>>>>
>> >>>>>>>> Adam
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
>> >>  wrote:
>> >>>>>>>>
>> >>>>>>>>> I don't think you read my first message on the topic (or I
>> >>>>>>>>> wrote too
>> >> much).
>> >>>>>>>>>
>> >>>>>>>>> Age is fragile because if the clock changes between issue_date
>> >>>>>>>>> and
>> >> the time of submission, it will fail. We know many people don't have
>> >> synchronized clocks, but using age only solves this problem if two
>> >> assumptions hold true:
>> >>>>>>>>>
>> >>>>>>>>> 1) the client is able to guess the issue_date the server is
>> >>>>>>>>> using based on the time the credential was issued
>> >>>>>>>>> 2) the client system clock doesn't change between issue date
>> >>>>>>>>> and
>> >> submission time.
>> >>>>>>>>>
>> >>>>>>>>> Timestamp has neither of these issues because the client can
>> >> always inquire about network time and can effectively correct for
>> >> inaccuracies in the device timekeeping system.
>> >>>>>>>>>
>> >>>>>>>>> Regarding the first assumption, this fails when a token might
>> >>>>>>>>> be re-
>> >> issued between devices. An example is that we use MAC token for the
>> >> client credentials, which are issued when a developer registers an
>> >> application. The client has no way of determining on its own when the
>> >> value was actually issued (unless we communicate that on the
>> >> developer website and force users to embed that with client_id, which
>> >> adds usability issues of users copying and entering string date
>> >> values correctly). The same is actually true for all of our OAuth
>> >> access tokens because we reissue tokens to the same client_id if they
>> >> were previously issued and are still valid. (The client would thus
>> >> think the issue_date was now() when if fact it was the time of the
>> >> first issue for client_id+scope+grantor_id). Thus, age is really just=
 a
>> convoluted way of trying to communicate the device system offset:
>> >>>>>>>>>
>> >>>>>>>>> =A0 =A0 =A0 local_offset =3D current_server_time - current_dev=
ice_time
>> >>>>>>>>> =A0 =A0 =A0 age =3D current_device_time -
>> >>>>>>>>> (server_issue_date-local_offset)
>> >>>>>>>>>
>> >>>>>>>>> Since the protocol doesn't currently allow for
>> >>>>>>>>> server_issue_date to
>> >> be given with tokens, thus age currently can't have the resilience
>> >> that timestamp does. It also forces servers to issue new tokens on
>> >> demand just to make the convoluted age system work (rather than reuse
>> >> existing valid tokens). Or, you have to modify the protocol to add
>> >> server_issue_date and current_server_time into the token-issue
>> exchange - eg, more complexity.
>> >>>>>>>>>
>> >>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
>> >>>>>>>>> your use
>> >> case of unsyncronized clocks.
>> >>>>>>>>>
>> >>>>>>>>> skylar
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> I can't speak for Mozilla, but I can tell you that many folks
>> >>>>>>>>>> don't have synchronized clocks, for a wide variety of reasons=
.
>> >>>>>>>>>> I guess I don't really understand why you view age as
>> >>>>>>>>>> problematic. =A0You reference "fragility of using
>> >>>>>>>>>> time-since-credentials-issued" but you don't say what exactly
>> >>>>>>>>>> is fragile about it. =A0There's nothing particularly complex
>> >>>>>>>>>> about age, especially when using the monotonic clock provided
>> >>>>>>>>>> by
>> >> all modern operating systems.
>> >>>>>>>>>>
>> >>>>>>>>>> Adam
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
>> >>  wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> But see, now you are specializing the use of MAC token even
>> >> more - now it's becoming a service mainly for user-agents on home
>> >> desktops? This is further for the original goal of making MAC as
>> >> flexible is possible. In this case you should change the spec name to
>> >>
>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
>> >> REFOX - or MTBCRLF for short.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good as
>> >>>>>>>>>>> your
>> >> offset technique and is more: reliable, straightforward, flexible.
>> >>>>>>>>>>>
>> >>>>>>>>>>> User agents that care about creating robust behavior for
>> >>>>>>>>>>> home
>> >> desktops or mobiles (presumably of users and OS not yet sophisticated
>> >> enough to check network time on their own) should be advised to do
>> >> clock correction on their own (by pinging a time service) and
>> >> trusting the device clock alone.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please change the spec back to using timestamp rather than
>> age.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I'd also like to hear a convincing argument from the Mozilla
>> >>>>>>>>>>> co-
>> >> authors about why they think that age is more resilient than the
>> >> above (I believe it is not) and further more why they would find the
>> >> above unattractive or difficult to implement in a modern user-agent.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks,
>> >>>>>>>>>>> skylar
>> >>>>>>>>>>>
>> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. -
>> >>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-
>> >> - --- --- -.. .-- .- .-. -..
>> >>>>>>>>>>> skylar woodward
>> >>>>>>>>>>> Kiva Developer Program =A0/ =A0build.kiva.org =A0/ =A0@build=
kiva
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Any kind of clock sync requirement for user-agents
>> >>>>>>>>>>>> (basically,
>> >> home desktops) it completely impractical. The added complexity pales
>> >> in comparison to the difficulty of trying to use timestamps and any
>> >> kind of clock sync. No window will be big enough as experience shows
>> >> some users have closes that are off by more than an hour and a half.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> The issue here is who is this being optimized for.
>> >>>>>>>>>>>> Server-to-
>> >> server communication should simply use TLS for privacy and MITM
>> >> protection on top of MAC instead of using nonces to prevent replay.
>> >> The whole point of this kind of replay protection is when TLS is not
>> available.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think a better approach is to simply make checking the
>> >>>>>>>>>>>> nonce
>> >> optional when TLS is used.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> EHL
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
>> >> bounces@ietf.org]
>> >>>>>>>>>>>>> On Behalf Of Peter Wolanin
>> >>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
>> >>>>>>>>>>>>> To: Skylar Woodward
>> >>>>>>>>>>>>> Cc: OAuth WG
>> >>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
>> >> element -
>> >>>>>>>>>>>>> MAC token
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I am also concerned by the fragility of using
>> >>>>>>>>>>>>> time-since-credentials-issued, and also the added
>> >>>>>>>>>>>>> complexity
>> >> of specifying this construction.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I think it would be preferable to always require a
>> >>>>>>>>>>>>> timestamp as part of the authorization header, and maybe
>> >>>>>>>>>>>>> even include in the spec a maximum time difference
>> between
>> >>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
>> >>>>>>>>>>>>> tolerated. =A0This makes generating the nonce easier also,
>> >>>>>>>>>>>>> since the value need to
>> >> longer be unique over all time.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> We have such rules in place for an HMAC-based
>> >> authentication
>> >>>>>>>>>>>>> system we use. =A0Once in a while a client has a local clo=
ck
>> >>>>>>>>>>>>> so far out of sync that there is an issue, but it's rare.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> -Peter
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
>> >>>>>>>>>>>>> 
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Resending to the list from my subscribed account...
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Begin forwarded message:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> From: Skylar Woodward 
>> >>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
>> >>>>>>>>>>>>>>> To: Skylar Woodward 
>> >>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
>> OAuth
>> >> WG
>> >>>>>>>>>>>>>>> 
>> >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
>> element -
>> >>>>>>>>>>>>>>> MAC token
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
>> >>>>>>>>>>>>>>> bit, I would suggest that
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
>> >>>>>>>>>>>>> without further requirements. It might be suggested that
>> >>>>>>>>>>>>> this be composed of an
>> >>>>>>>>>>>>> random+timestamp (not age) value, but that seems more
>> of a
>> >>>>>>>>>>>>> random+MAY or
>> >>>>>>>>>>>>> "recommended" practice. If the expectation is that very
>> >>>>>>>>>>>>> few if any providers would actually check the timestamp
>> >>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
>> >>>>>>>>>>>>> the draft that requires it? Developers are doing extra
>> >>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
>> >>>>>>>>>>>>> with
>> >> no payoff or added security.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I'm sending this feedback based on having implemented
>> >> the
>> >>>>>>>>>>>>>>> v3-5 changes
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> last night (for both client credentials and requests w/
>> >>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
>> >>>>>>>>>>>>> now the most complicated part of the normalized request
>> >>>>>>>>>>>>> string
>> >> and yet these changes offer the least benefit.
>> >>>>>>>>>>>>> What's most important is that nonces are unique on each
>> >> request for an ID.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> There are issues with age as well:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue time
>> >>>>>>>>>>>>>>> based on receipt, then the internal clock changes
>> >>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing the
>> >>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
>> >>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix it
>> >>>>>>>>>>>>>>> and actually encourages bad user behavior (don't fix
>> >>>>>>>>>>>>>>> your clock or Twitterbot will stop working!). Though we
>> >>>>>>>>>>>>>>> say that timezones won't bring about the situation of
>> >>>>>>>>>>>>>>> changed clock, I'd be to differ. Many users aren't savvy
>> >>>>>>>>>>>>>>> enough to change time zone, but just adjust the time to
>> >>>>>>>>>>>>>>> local time anyway. Users who are more likely to get it
>> >>>>>>>>>>>>>>> right already have auto clock sync enabled (via web,
>> >>>>>>>>>>>>>>> mobile, etc.)
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - What if the token wasn't originally issued
>> >>>>>>>>>>>>>>> programmatically? In this case,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> the issue time has to be obtained from the server and
>> >>>>>>>>>>>>> stored on the client then you have the same problem as
>> >>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
>> >>>>>>>>>>>>> server clock and there is no adjustment. You want this to
>> >>>>>>>>>>>>> apply to uses outside of just OAuth, but now requiring the
>> >>>>>>>>>>>>> client to be able to determine an issue time based on when
>> >>>>>>>>>>>>> it receives
>> >> an HTTP request necessarily limits the types of token flows for which
>> >> this can be used.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
>> >>>>>>>>>>>>>>> developer, but it is
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
>> >>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
>> >>>>>>>>>>>>> clock offset value" but obfuscated several times over (one
>> >>>>>>>>>>>>> for each
>> >> token) as issue_date.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - This implementation assumes software programs use
>> the
>> >>>>>>>>>>>>>>> computer
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> internal clock exclusively for timestamp. A robust program
>> >>>>>>>>>>>>> that is dependent on accurate timestamps would ping the
>> >>>>>>>>>>>>> origin server (or similar trusted time
>> >>>>>>>>>>>>> authority) to ask it the current time. Then it could store
>> >>>>>>>>>>>>> a "my device clock offset" value for the lifetime of the
>> >>>>>>>>>>>>> program execution. All requests needing timestamp would
>> be
>> >>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
>> >>>>>>>>>>>>> since the
>> >> stored issue_date, the problem can't be corrected in this manner.
>> >>>>>>>>>>>>> Thus, a significant advantage for timestamp.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> All in all, this seems like a misguided but
>> >>>>>>>>>>>>>>> well-intentioned attempt to get
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like a
>> >>>>>>>>>>>>> hack and it certainly isn't a foolproof solution. The more
>> >>>>>>>>>>>>> I think about the implications of the age parameter, the
>> >>>>>>>>>>>>> less I like it. Timestamp has been used for many years in
>> >>>>>>>>>>>>> the industry and with reasonable success in relevant
>> >>>>>>>>>>>>> applications. If we change to a new way of trying to sync
>> >>>>>>>>>>>>> on
>> >> time I think we run a greater risk of stumbling upon unforeseen
>> >> issues, such as those outlined above.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I recommend the requirement of an age (or timestamp
>> for
>> >>>>>>>>>>>>>>> that matter)
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> be dropped from the nonce construction. For providers
>> that
>> >>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
>> >>>>>>>>>>>>> (either as part of the nonce or the overall header, as
>> before).
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> skylar
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
>> >> "example.net"
>> >>>>>>>>>>>>>>>> - should be example.com, I believe. =A0(draft v5)
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
>> >>>>>>>>>>>>>>>> Certainly addresses my
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> hesitations from v2.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> skylar
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
>> >>>>>>>>>>>>>>>>>  mailing list)
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
>> mac-
>> >> tok
>> >>>>>>>>>>>>>>>>> en
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> While this document has moved to the Apps-Discuss
>> >>>>>>>>>>>>>>>>> mailing list for the
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> time being, I wanted to give a quick update to those who
>> >>>>>>>>>>>>> have been following this draft which originated on this li=
st.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> The major changes since -02 are:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. The
>> >> draft
>> >>>>>>>>>>>>>>>>> is now a
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
>> >>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less th=
an
>> a page.
>> >>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
>> OAuth
>> >>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the MAC
>> >> draft.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
>> >> session cookies.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Removed request URI query normalization. The new
>> >> draft
>> >>>>>>>>>>>>>>>>> uses the
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> raw request URI unchanged.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
>> remove
>> >> the
>> >>>>>>>>>>>>>>>>> need for
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> clock sync.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing random
>> >>>>>>>>>>>>>>>>> text to be
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> included in the request and MAC.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source of
>> >>>>>>>>>>>>>>>>> the credentials as
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>> an additional protection.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>>> Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist, =
=A0Acquia.
>> >> Inc.
>> >>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
>> >> http://www.drupalgardens.com"
>> >>>>>>>>>>>>>
>> _______________________________________________
>> >>>>>>>>>>>>> OAuth mailing list
>> >>>>>>>>>>>>> OAuth@ietf.org
>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> OAuth mailing list
>> >>>>>>>>>>> OAuth@ietf.org
>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>> _______________________________________________
>> >>>> OAuth mailing list
>> >>>> OAuth@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> OAuth@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> > _______________________________________________
>> > OAuth 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 cmortimore@salesforce.com  Tue May 31 23:32: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 5D8FBE0665 for ; Tue, 31 May 2011 23:32:09 -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 8IKECm6A5xom for ; Tue, 31 May 2011 23:32:07 -0700 (PDT)
Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by ietfa.amsl.com (Postfix) with SMTP id 1D46BE065D for ; Tue, 31 May 2011 23:32:07 -0700 (PDT)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKTeXc5iFwORO0VqHdJ84VMacYUzzpQ91d@postini.com; Tue, 31 May 2011 23:32:07 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Tue, 31 May 2011 23:32:06 -0700
From: Chuck Mortimore 
To: Dave Nelson , "oauth@ietf.org" 
Date: Tue, 31 May 2011 23:32:04 -0700
Thread-Topic: [OAUTH-WG] Text for Native Applications
Thread-Index: Acwf2DR9dyqVclejSoqfD90JY6RUawATWp/8
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_CA0B2AF41AA8Acmortimoresalesforcecom_"
MIME-Version: 1.0
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 06:32:09 -0000

--_000_CA0B2AF41AA8Acmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The distinction is that the client_secret tends to be a global secret, and =
there is little ability to protect this type of secret in many common means=
 of application distribution.

For example, a iOS app that is shipped through iTunes certainly has access =
to reasonably secure storage via KeyChain for secrets issued to the applica=
tion at runtime, such as the referesh_token, but it can't do a good job of =
protecting the client_secret, since this must be embeded in the binary that=
 is distributed to everyone.

-cmort


On 5/31/11 2:17 PM, "Dave Nelson"  wrote:

This issue has likely been discussed "long ago", but I'd like to
potentially re-open the discussion.

>    o  Native 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.

I understand that, in a strict sense, a software component running in
a non-embedded environment cannot be guaranteed to maintain the
confidentiality of credentials entrusted to it.  On the other hand, I
think this proscription may go too far.  All security is a matter of
providing sufficient counter-measures to identified attack vectors,
and I believe that native applications probably *can* keep secrets
well enough to resist the types of attacks they are likely to be
subject to in certain specified use cases.  Perhaps the "SHOULD"
wording leaves enough room for implementations with credential hiding
mechanisms that are deemed appropriate in a given use scenario to
include the use of a client password.  I think it would be more
accurate to say that native applications SHOULD NOT include the client
password in the authorization grant type flow, *unless* the design of
the application can provide a sufficient level of protection for said
password storage to meet the risks identified in association with the
deployment scenario.

Thoughts?

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


--_000_CA0B2AF41AA8Acmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: [OAUTH-WG] Text for Native Applications


The distinction=
 is that the client_secret tends to be a global secret, and there is little=
 ability to protect this type of secret in many common means of application=
 distribution.
    

    
For example, a iOS app that is shipped through iTunes certainly has access =
to reasonably secure storage via KeyChain for secrets issued to the applica=
tion at runtime, such as the referesh_token, but it can’t do a good j=
ob of protecting the client_secret, since this must be embeded in the binar=
y that is distributed to everyone.
    

    
-cmort
    

    

    
On 5/31/11 2:17 PM, "Dave Nelson" <dnelson@elbrys.com> wrote:
    

    

    This issue has likely been discussed "long ago", but I=
'd like to
    
potentially re-open the discussion.
    

    
> =A0=A0=A0o =A0Native applications that use the authorization code gran=
t type flow
    
> SHOULD do so without client password credentials, due to their inabili=
ty to
    
> keep those credentials confidential.
    

    
I understand that, in a strict sense, a software component running in
    
a non-embedded environment cannot be guaranteed to maintain the
    
confidentiality of credentials entrusted to it.  On the other hand, I<=
BR>
think this proscription may go too far.  All security is a matter of
providing sufficient counter-measures to identified attack vectors,
    
and I believe that native applications probably *can* keep secrets
    
well enough to resist the types of attacks they are likely to be
    
subject to in certain specified use cases.  Perhaps the "SHOULD&q=
uot;
    
wording leaves enough room for implementations with credential hiding
    
mechanisms that are deemed appropriate in a given use scenario to
    
include the use of a client password.  I think it would be more
    
accurate to say that native applications SHOULD NOT include the client
    
password in the authorization grant type flow, *unless* the design of
    
the application can provide a sufficient level of protection for said
    
password storage to meet the risks identified in association with the
    
deployment scenario.
    

    
Thoughts?
    

    
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.or=
g/mailman/listinfo/oauth
    

    

    




--_000_CA0B2AF41AA8Acmortimoresalesforcecom_--

From d.tangren@gmail.com  Tue May 31 23:32: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 75593E074F for ; Tue, 31 May 2011 23:32: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 oDPzhBR7dMN3 for ; Tue, 31 May 2011 23:32:53 -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 B6077E0665 for ; Tue, 31 May 2011 23:32:53 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6809412iwn.31 for ; Tue, 31 May 2011 23:32:53 -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=XAa6/tDzdk9vk6AR/y/XQNwusKlfjbbFoykXCVw9TTI=; b=iFqGQ8JubWxsOmXUTEkvY2fZoO6jwx7Gi/iw61cJvq/KNW0RQPiyaP8MvZitnJkSGW vpoJKAyFsSJqYbtaCHJAVHUQJRjiKfE/NI9iGwIsvJAkYZVzEcJw9oXVg0Sfig9n7LwC 4K5j+Jy6YcBXljXGimmQIkVh0fGUlI/CL/NYY=
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=Is/O5QtQd6Ee8p1pMdN0ComVnQak0VXOh6IPa1cchnZxmCpQHNHRNZFp+WoTVYmK57 W37//dH5kRGLJdBIRa5qojdL91F0YKwYd6KERyzmaKjBVFbytUBzZneJL0ZKhj3kBKf2 CrxuEUxRV9hIv3Ey8rDhNQPy8k4wKESDJXpdw=
Received: by 10.42.243.7 with SMTP id lk7mr10917903icb.191.1306909973045; Tue, 31 May 2011 23:32:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Tue, 31 May 2011 23:32:33 -0700 (PDT)
In-Reply-To: 
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>   
From: Doug Tangren 
Date: Wed, 1 Jun 2011 02:32:33 -0400
Message-ID: 
To: Kris Selden 
Content-Type: multipart/alternative; boundary=90e6ba3fcc1fb260f604a4a0b069
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 06:32:54 -0000

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

-Doug Tangren
http://lessis.me


On Wed, Jun 1, 2011 at 1:39 AM, Kris Selden  wrote:

> Why can't you just revoke the refresh token for a client when you change
> the client secret?
>
>
This makes sense for a server implementation for added precaution but in
practice, most clients dont change client secrets often.


> Is it not easier to revoke a token than it is to rotate the client secret
> (which is usually configured or embedded in the client whereas the token is
> issued)?
>
>
Yes, providing a user means to revoke a token or to break a "connection" is
a defacto feature of most server implementations. However, most users will
accept the authorization for an app and forget about it.

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


    -Doug Tangren
    http://lessis.me
    


    On Wed, Jun 1, 2011 at 1:39 AM, Kris Sel=
den <kris.sel=
den@gmail.com> wrote:
    

Why can't you just revoke the refresh token for a client when you chang=
e the client secret?
    


    This makes sense for a server implemen=
tation for added precaution but in practice, most clients dont change clien=
t secrets often.
    =C2=A0
    


Is it not easier to revoke a token than it is to rotate the client secret (=
which is usually configured or embedded in the client whereas the token is =
issued)?
    



    Yes, providing a user means to revoke a token or to break a "c=
onnection" is a defacto feature of most server implementations. Howeve=
r, most users will accept the authorization for an app and forget about it.=

    


    

--90e6ba3fcc1fb260f604a4a0b069--

From eran@hueniverse.com  Tue May 31 23:38: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 6A514E06CD for ; Tue, 31 May 2011 23:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level: 
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 irlL-KHXnkfz for ; Tue, 31 May 2011 23:38: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 DB1B5E065D for ; Tue, 31 May 2011 23:38:03 -0700 (PDT)
Received: (qmail 28939 invoked from network); 1 Jun 2011 06:38:03 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 06:38:03 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 31 May 2011 23:36:46 -0700
From: Eran Hammer-Lahav 
To: Skylar Woodward , Adam Barth 
Date: Tue, 31 May 2011 23:36:18 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwgIFYN9cr+ZkXjS0aa0XqbWQ35SwAALyng
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA43E@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>    
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 06:38:04 -0000

> -----Original Message-----
> From: Skylar Woodward [mailto:skylar@kiva.org]
> Sent: Tuesday, May 31, 2011 10:54 PM

> Unfortunately though, this implementation doesn't help my use cases
> because such sequential requirement of a timestamp/age requires all
> devices with the token to be in sync as to the value of timestamp/age. So
> let's move on.

This is not true.

The age value has to be monotonically increasing, but not necessarily uniqu=
e. Really, any counter will do. The reason why timestamp isn't any better t=
han age or sequence is because ultimately, it is the server's memory restri=
ction which determines the nonces storage size, not anything else (like a t=
ime limit).

I am going to change the spec to define age as any 'monotonically increasin=
g, but not necessarily unique' positive numerical value, and give timestamp=
 and time-since-received as two examples, along with a counter. It will als=
o specify that if the numerical value is time-based, it MUST use seconds pr=
ecision. This should provide a practical solution to everyone.

When the first request comes in, it goes into storage. When the second one =
comes, you check if its numerical part is equal or greater than the one you=
 previously received. If the number is smaller, you should allow for some m=
argin in case the client is using time-based value, otherwise you reject th=
e request. Once the storage fills, you evict the nonces with the smallest n=
umerical values as needed. The storage size should match the speed in which=
 clients transmit requests.

Unlike timestamps, the margin can be very small, like 60 seconds, because t=
his is time-sync across *client* machines, not the client and server. It is=
 perfectly reasonable to expect a client sharing the same MAC credentials a=
cross multiple machines to implement clock sync keeping all machines less t=
han a minute apart.

Any kind of storage-limited nonce-checking is going to fail sometimes even =
for valid requests because of how the numerical part is generated and how m=
uch storage the server has (across all clients). I think this is a very rea=
sonable compromise that in practice, will produce good results with little =
complexity and plenty of flexibility.

The alternatives presented so far (using timestamps or offering multiple op=
tions) will fail completely for the primary use cases this specification wa=
s written for.

EHL

From eran@hueniverse.com  Tue May 31 23:40: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 99754E071B for ; Tue, 31 May 2011 23:40:17 -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.340, BAYES_00=-2.599, 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 fjj3sIAYRF8h for ; Tue, 31 May 2011 23:40: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 BCEF5E06CD for ; Tue, 31 May 2011 23:40:14 -0700 (PDT)
Received: (qmail 8381 invoked from network); 1 Jun 2011 06:40:14 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 06:40:13 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 31 May 2011 23:39:23 -0700
From: Eran Hammer-Lahav 
To: Skylar Woodward 
Date: Tue, 31 May 2011 23:38:55 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwgIagoracZXDPTSqS3VP/jByCbBwABKeDA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA440@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE59299.2020909@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <67CC0F44-B79E-4A94-8A7C-FDCC1EC74B9D@kiva.org>
In-Reply-To: <67CC0F44-B79E-4A94-8A7C-FDCC1EC74B9D@kiva.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 
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 06:40:17 -0000

> -----Original Message-----
> From: Skylar Woodward [mailto:skylar@kiva.org]
> Sent: Tuesday, May 31, 2011 11:03 PM
> To: Eran Hammer-Lahav
> Cc: igor.faynberg@alcatel-lucent.com; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> Eran, sorry, where should use cases be officially documented?

This list seems a fine enough place. I have no problem keeping track.

> I assume the use cases being more like "HTTP Auth" are not in reference t=
o
> the ones I've been describing. For my part, I'm focused on OAuth use case=
s.
> Both that of a single token being used on multiple devices (or app instan=
ces)
> and that of tokens being presented for client credentials in the OAuth fl=
ow. I
> thought we had already agreed from a previous thread that the MAC token
> spec should be extensible beyond just use of access tokens and at least t=
o
> that of client credentials.

Useful for, yes. Extensible, no. The only extensible part if the choice of =
algorithm.

> skylar
>
>
> On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
>
> > They are coming in 2-3 directions, the use case isn't really clear (oth=
er than
> claims of some flavors being harder than others), and overall this is mor=
e
> about general HTTP authentication than OAuth use cases. Don't get me
> wrong - if you want to put the effort in to capture these, go ahead. I ju=
st
> think this isn't worth the effort in a formal document.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
> >> Sent: Tuesday, May 31, 2011 6:15 PM
> >> To: Eran Hammer-Lahav
> >> Cc: Phil Hunt; OAuth WG
> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >> token
> >>
> >> Maybe...  But this information must be captured somewhere, right?
> >>
> >> At the moment, there seems to be no record of and consequently no
> >> reference point to the use case in question. And this is what has
> >> created all this discussion--with messages coming from all directions.
> >>
> >> Igor
> >>
> >> Eran Hammer-Lahav wrote:
> >>> I think the use case document should focus on v2, not on MAC. At
> >>> some
> >> point, it becomes impractical to keep every use case discussed on
> >> this list recorded.
> >>>
> >>> EHL
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>> Behalf Of Igor Faynberg
> >>>> Sent: Tuesday, May 31, 2011 3:50 PM
> >>>> To: Phil Hunt
> >>>> Cc: OAuth WG
> >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >>>> token
> >>>>
> >>>> ...Sorry to turn the question around so as to underline my pet peeve=
:
> >>>> Have we *documented* all cases?  (This is what the Use Cases
> >>>> document is supposed to be all about.)
> >>>>
> >>>> Just to clarify: I am not arguing with Phil's point now. I just
> >>>> stress that as of this moment we don't have anything to check agains=
t.
> >>>>
> >>>> Igor
> >>>>
> >>>> Phil Hunt wrote:
> >>>>
> >>>>> There seems to be a demonstrated need for both age and timestamp
> >>>>>
> >>>> tokens.
> >>>>
> >>>>> The list has 2 separate cases with 2 separate proposals that do
> >>>>> not solve all
> >>>>>
> >>>> cases.
> >>>>
> >>>>> Can we at least agree that neither proposal works in all cases?
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>> @independentid
> >>>>> www.independentid.com
> >>>>> phil.hunt@oracle.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> You haven't described a problem.
> >>>>>>
> >>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward
> >>>>>> 
> >>>>>>
> >>>> wrote:
> >>>>
> >>>>>>> First we should agree on a common understanding of the spec. The
> >>>>>>>
> >>>> reason why age works with unsynchronized clocks is that the client
> >>>> determines issue_date based on the time when it receives the token
> >>>> over the wire. This depends on the server and client both recording
> >>>> time this way and for the transmission of the token to be be not
> >>>> longer than the margin of error for validating age. Are we agreed
> >>>> on this
> >> understanding?
> >>>>
> >>>>>> That's not correct.
> >>>>>>
> >>>>>> The age allows the server to protect against replay attacks in
> >>>>>> bounded memory.  With unbounded memory, the server can just
> >>>>>>
> >>>> remember
> >>>>
> >>>>>> every nonce it has ever seen associated with a given key and
> >>>>>> reject
> >>>>>>
> >>>> replays.
> >>>>
> >>>>>> With bounded memory, the server eventually needs to evict some
> of
> >>>>>> these nonces due to memory pressure.  The age value lets the
> >>>>>> server reject the nonces with the smallest age values first.  The
> >>>>>> server then rejects any messages with age values smaller than (or
> >>>>>> equal
> >>>>>> to) the largest age value it has ever evicted for the given key.
> >>>>>>
> >>>>>> Notice that neither clock synchronization nor transmission time
> >>>>>> plays a role in that implementation.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> The easiest case for me to explain here is client credentials
> >>>>>>> because I
> >>>>>>>
> >>>> have to assume you've built and registered a Twitter app at some
> >>>> point (or similar OAuth 1.0a app). You registered your app on the
> >>>> site and were issued a client_id and client_secret (called
> >>>> consumer_key and consumer_secret in 1.0). You then embedded
> these
> >>>> values in your client (they were not issued programmatically to
> >>>> your app). Assuming the MAC token algorithm is used then for
> >>>> establishing client identity (originally one of the uses we, the
> >>>> working group, hoped MAC would cover) how then will your client
> determine issue date?
> >>>>
> >>>>>> I recommend the date at which the developer obtained the
> >>>>>> credential from Twitter because that is the date when the credenti=
al
> was issued.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> After we can establish where you're at on the two above points
> >>>>>>> I'll
> >>>>>>>
> >>>> continue with the explanation. But as a preview, the next points
> >>>> would
> >> be:
> >>>>
> >>>>>>> - If issue_date comes form the server, how is it translated to
> >>>>>>> the
> >> client?
> >>>>>>>
> >>>>>>>
> >>>>>> The issue_date does not come from the server.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - If you use a server provided issue_date, how do you then
> >>>>>>> translate
> >>>>>>>
> >>>> that a value relative to the local unsyncronized clock?
> >>>>
> >>>>>> The server does not provide the issue_date.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - If your answer to that is to also provide the current server
> >>>>>>> time to the
> >>>>>>>
> >>>> client so the offset on the server provided issue_date can be
> >>>> calculated what is the difference between all of these values and
> >>>> just
> >> using timestamp?
> >>>>
> >>>>>> My answer is not to provide the current server time to the client.
> >>>>>>
> >>>>>> Kind regards,
> >>>>>> Adam
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> So don't get wrapped up in those 3 questions until we establish
> >>>>>>> your
> >>>>>>>
> >>>> contextual understanding of the first two paragraphs. Feel free to
> >>>> also respond to me off the list so we don't trouble everyone else
> >>>> with us getting on the same page (the reason, I thought, why a
> >>>> Skype call would be more efficient and painless). I do think my
> >>>> explanations all have been very clear thus far. There must be a
> >>>> contextual confusion that is keeping us from a common understanding
> >>>> of
> >> the terminology or the use cases.
> >>>>
> >>>>>>> skylar
> >>>>>>>
> >>>>>>>
> >>>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>>>>>>> caused by age clearly?  I didn't understand your previous
> >>>>>>>> explanation.  The more concrete you can be, the better.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Adam
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
> >>>>>>>> 
> >>>>>>>>
> >>>> wrote:
> >>>>
> >>>>>>>>> It seems we're failing to communicate. Or you're not
> >>>>>>>>> understanding
> >>>>>>>>>
> >>>> my use cases. Age doesn't "just" work. It only works for a limited
> >>>> number of uses cases that must include all of yours - and it is
> >>>> brittle at that. It doesn't work for any of our uses cases (where
> >>>> the client can't know issue_date w/o the server telling it - in
> >>>> which case we have the equivalent problem as timestamp).
> >>>>
> >>>>>>>>> If you'd like to talk this out over Skype I'm happy to do
> >>>>>>>>> that, so I can
> >>>>>>>>>
> >>>> help you understand why age doesn't work.
> >>>>
> >>>>>>>>>
> >>>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Timestamps don't work when the client doesn't have a
> >>>>>>>>>> synchronized clock.  It's true that a client could
> >>>>>>>>>> synchronize its clock with the network, but our
> >>>>>>>>>> implementation experience is that many clients don't for a
> >>>>>>>>>> variety of reasons.  That means that age better because, you
> know, it works.
> >>>>>>>>>>
> >>>>>>>>>> Adam
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
> >>>>>>>>>>
> >>>>  wrote:
> >>>>
> >>>>>>>>>>> I don't think you read my first message on the topic (or I
> >>>>>>>>>>> wrote too
> >>>>>>>>>>>
> >>>> much).
> >>>>
> >>>>>>>>>>> Age is fragile because if the clock changes between
> >>>>>>>>>>> issue_date and
> >>>>>>>>>>>
> >>>> the time of submission, it will fail. We know many people don't
> >>>> have synchronized clocks, but using age only solves this problem if
> >>>> two assumptions hold true:
> >>>>
> >>>>>>>>>>> 1) the client is able to guess the issue_date the server is
> >>>>>>>>>>> using based on the time the credential was issued
> >>>>>>>>>>> 2) the client system clock doesn't change between issue date
> >>>>>>>>>>> and
> >>>>>>>>>>>
> >>>> submission time.
> >>>>
> >>>>>>>>>>> Timestamp has neither of these issues because the client can
> >>>>>>>>>>>
> >>>> always inquire about network time and can effectively correct for
> >>>> inaccuracies in the device timekeeping system.
> >>>>
> >>>>>>>>>>> Regarding the first assumption, this fails when a token
> >>>>>>>>>>> might be re-
> >>>>>>>>>>>
> >>>> issued between devices. An example is that we use MAC token for the
> >>>> client credentials, which are issued when a developer registers an
> >>>> application. The client has no way of determining on its own when
> >>>> the value was actually issued (unless we communicate that on the
> >>>> developer website and force users to embed that with client_id,
> >>>> which adds usability issues of users copying and entering string
> >>>> date values correctly). The same is actually true for all of our
> >>>> OAuth access tokens because we reissue tokens to the same client_id
> >>>> if they were previously issued and are still valid. (The client
> >>>> would thus think the issue_date was now() when if fact it was the
> >>>> time of the first issue for client_id+scope+grantor_id). Thus, age
> >>>> is really just a
> >> convoluted way of trying to communicate the device system offset:
> >>>>
> >>>>>>>>>>>       local_offset =3D current_server_time - current_device_t=
ime
> >>>>>>>>>>>       age =3D current_device_time -
> >>>>>>>>>>> (server_issue_date-local_offset)
> >>>>>>>>>>>
> >>>>>>>>>>> Since the protocol doesn't currently allow for
> >>>>>>>>>>> server_issue_date to
> >>>>>>>>>>>
> >>>> be given with tokens, thus age currently can't have the resilience
> >>>> that timestamp does. It also forces servers to issue new tokens on
> >>>> demand just to make the convoluted age system work (rather than
> >>>> reuse existing valid tokens). Or, you have to modify the protocol
> >>>> to add server_issue_date and current_server_time into the
> >>>> token-issue
> >> exchange - eg, more complexity.
> >>>>
> >>>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
> >>>>>>>>>>> your use
> >>>>>>>>>>>
> >>>> case of unsyncronized clocks.
> >>>>
> >>>>>>>>>>> skylar
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many
> >>>>>>>>>>>> folks don't have synchronized clocks, for a wide variety of
> reasons.
> >>>>>>>>>>>> I guess I don't really understand why you view age as
> >>>>>>>>>>>> problematic.  You reference "fragility of using
> >>>>>>>>>>>> time-since-credentials-issued" but you don't say what
> >>>>>>>>>>>> exactly is fragile about it.  There's nothing particularly
> >>>>>>>>>>>> complex about age, especially when using the monotonic
> >>>>>>>>>>>> clock provided by
> >>>>>>>>>>>>
> >>>> all modern operating systems.
> >>>>
> >>>>>>>>>>>> Adam
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
> >>>>>>>>>>>>
> >>>>  wrote:
> >>>>
> >>>>>>>>>>>>> But see, now you are specializing the use of MAC token
> >>>>>>>>>>>>> even
> >>>>>>>>>>>>>
> >>>> more - now it's becoming a service mainly for user-agents on home
> >>>> desktops? This is further for the original goal of making MAC as
> >>>> flexible is possible. In this case you should change the spec name
> >>>> to
> >>>>
> >>
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> >>>> REFOX - or MTBCRLF for short.
> >>>>
> >>>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good
> >>>>>>>>>>>>> as your
> >>>>>>>>>>>>>
> >>>> offset technique and is more: reliable, straightforward, flexible.
> >>>>
> >>>>>>>>>>>>> User agents that care about creating robust behavior for
> >>>>>>>>>>>>> home
> >>>>>>>>>>>>>
> >>>> desktops or mobiles (presumably of users and OS not yet
> >>>> sophisticated enough to check network time on their own) should be
> >>>> advised to do clock correction on their own (by pinging a time
> >>>> service) and trusting the device clock alone.
> >>>>
> >>>>>>>>>>>>> Please change the spec back to using timestamp rather
> than
> >> age.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'd also like to hear a convincing argument from the
> >>>>>>>>>>>>> Mozilla
> >>>>>>>>>>>>> co-
> >>>>>>>>>>>>>
> >>>> authors about why they think that age is more resilient than the
> >>>> above (I believe it is not) and further more why they would find
> >>>> the above unattractive or difficult to implement in a modern user-
> agent.
> >>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -..
> >>>>>>>>>>>>> - ... -.- -.-- .-.. .- .-. - .-
> >>>>>>>>>>>>>
> >>>> - --- --- -.. .-- .- .-. -..
> >>>>
> >>>>>>>>>>>>> skylar woodward
> >>>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Any kind of clock sync requirement for user-agents
> >>>>>>>>>>>>>> (basically,
> >>>>>>>>>>>>>>
> >>>> home desktops) it completely impractical. The added complexity
> >>>> pales in comparison to the difficulty of trying to use timestamps
> >>>> and any kind of clock sync. No window will be big enough as
> >>>> experience shows some users have closes that are off by more than an
> hour and a half.
> >>>>
> >>>>>>>>>>>>>> The issue here is who is this being optimized for.
> >>>>>>>>>>>>>> Server-to-
> >>>>>>>>>>>>>>
> >>>> server communication should simply use TLS for privacy and MITM
> >>>> protection on top of MAC instead of using nonces to prevent replay.
> >>>> The whole point of this kind of replay protection is when TLS is
> >>>> not
> >> available.
> >>>>
> >>>>>>>>>>>>>> I think a better approach is to simply make checking the
> >>>>>>>>>>>>>> nonce
> >>>>>>>>>>>>>>
> >>>> optional when TLS is used.
> >>>>
> >>>>>>>>>>>>>> EHL
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >>>>>>>>>>>>>>>
> >>>> bounces@ietf.org]
> >>>>
> >>>>>>>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
> >>>>>>>>>>>>>>>
> >>>> element -
> >>>>
> >>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>>>>>>> time-since-credentials-issued, and also the added
> >>>>>>>>>>>>>>> complexity
> >>>>>>>>>>>>>>>
> >>>> of specifying this construction.
> >>>>
> >>>>>>>>>>>>>>> I think it would be preferable to always require a
> >>>>>>>>>>>>>>> timestamp as part of the authorization header, and
> maybe
> >>>>>>>>>>>>>>> even include in the spec a maximum time difference
> >> between
> >>>>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
> >>>>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
> >>>>>>>>>>>>>>> since the value need to
> >>>>>>>>>>>>>>>
> >>>> longer be unique over all time.
> >>>>
> >>>>>>>>>>>>>>> We have such rules in place for an HMAC-based
> >>>>>>>>>>>>>>>
> >>>> authentication
> >>>>
> >>>>>>>>>>>>>>> system we use.  Once in a while a client has a local
> >>>>>>>>>>>>>>> clock so far out of sync that there is an issue, but it's=
 rare.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Peter
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
> >> OAuth
> >>>>>>>>>>>>>>>>>
> >>>> WG
> >>>>
> >>>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
> >> element -
> >>>>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
> >>>>>>>>>>>>>>>>> bit, I would suggest that
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>>>>>>> without further requirements. It might be suggested
> that
> >>>>>>>>>>>>>>> this be composed of an
> >>>>>>>>>>>>>>> random+timestamp (not age) value, but that seems
> more
> >> of a
> >>>>>>>>>>>>>>> random+MAY or
> >>>>>>>>>>>>>>> "recommended" practice. If the expectation is that very
> >>>>>>>>>>>>>>> few if any providers would actually check the timestamp
> >>>>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
> >>>>>>>>>>>>>>> the draft that requires it? Developers are doing extra
> >>>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>
> >>>> no payoff or added security.
> >>>>
> >>>>>>>>>>>>>>>>> I'm sending this feedback based on having
> implemented
> >>>>>>>>>>>>>>>>>
> >>>> the
> >>>>
> >>>>>>>>>>>>>>>>> v3-5 changes
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
> >>>>>>>>>>>>>>> now the most complicated part of the normalized
> request
> >>>>>>>>>>>>>>> string
> >>>>>>>>>>>>>>>
> >>>> and yet these changes offer the least benefit.
> >>>>
> >>>>>>>>>>>>>>> What's most important is that nonces are unique on each
> >>>>>>>>>>>>>>>
> >>>> request for an ID.
> >>>>
> >>>>>>>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue
> >>>>>>>>>>>>>>>>> time based on receipt, then the internal clock changes
> >>>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing
> the
> >>>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
> >>>>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix
> >>>>>>>>>>>>>>>>> it and actually encourages bad user behavior (don't
> >>>>>>>>>>>>>>>>> fix your clock or Twitterbot will stop working!).
> >>>>>>>>>>>>>>>>> Though we say that timezones won't bring about the
> >>>>>>>>>>>>>>>>> situation of changed clock, I'd be to differ. Many
> >>>>>>>>>>>>>>>>> users aren't savvy enough to change time zone, but
> >>>>>>>>>>>>>>>>> just adjust the time to local time anyway. Users who
> >>>>>>>>>>>>>>>>> are more likely to get it right already have auto
> >>>>>>>>>>>>>>>>> clock sync enabled (via web, mobile, etc.)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the issue time has to be obtained from the server and
> >>>>>>>>>>>>>>> stored on the client then you have the same problem as
> >>>>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
> >>>>>>>>>>>>>>> server clock and there is no adjustment. You want this
> >>>>>>>>>>>>>>> to apply to uses outside of just OAuth, but now
> >>>>>>>>>>>>>>> requiring the client to be able to determine an issue
> >>>>>>>>>>>>>>> time based on when it receives
> >>>>>>>>>>>>>>>
> >>>> an HTTP request necessarily limits the types of token flows for
> >>>> which this can be used.
> >>>>
> >>>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>>>>>>> developer, but it is
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
> >>>>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
> >>>>>>>>>>>>>>> clock offset value" but obfuscated several times over
> >>>>>>>>>>>>>>> (one for each
> >>>>>>>>>>>>>>>
> >>>> token) as issue_date.
> >>>>
> >>>>>>>>>>>>>>>>> - This implementation assumes software programs
> use
> >> the
> >>>>>>>>>>>>>>>>> computer
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust
> >>>>>>>>>>>>>>> program that is dependent on accurate timestamps
> would
> >>>>>>>>>>>>>>> ping the origin server (or similar trusted time
> >>>>>>>>>>>>>>> authority) to ask it the current time. Then it could
> >>>>>>>>>>>>>>> store a "my device clock offset" value for the lifetime
> >>>>>>>>>>>>>>> of the program execution. All requests needing
> timestamp
> >>>>>>>>>>>>>>> would
> >> be
> >>>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
> >>>>>>>>>>>>>>> since the
> >>>>>>>>>>>>>>>
> >>>> stored issue_date, the problem can't be corrected in this manner.
> >>>>
> >>>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like
> >>>>>>>>>>>>>>> a hack and it certainly isn't a foolproof solution. The
> >>>>>>>>>>>>>>> more I think about the implications of the age
> >>>>>>>>>>>>>>> parameter, the less I like it. Timestamp has been used
> >>>>>>>>>>>>>>> for many years in the industry and with reasonable
> >>>>>>>>>>>>>>> success in relevant applications. If we change to a new
> >>>>>>>>>>>>>>> way of trying to sync on
> >>>>>>>>>>>>>>>
> >>>> time I think we run a greater risk of stumbling upon unforeseen
> >>>> issues, such as those outlined above.
> >>>>
> >>>>>>>>>>>>>>>>> I recommend the requirement of an age (or
> timestamp
> >> for
> >>>>>>>>>>>>>>>>> that matter)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be dropped from the nonce construction. For providers
> >> that
> >>>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
> >>>>>>>>>>>>>>> (either as part of the nonce or the overall header, as
> >> before).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> >>>>>>>>>>>>>>>>>>
> >>>> "example.net"
> >>>>
> >>>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
> >>>>>>>>>>>>>>>>>> Certainly addresses my
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
> >> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
> >> mac-
> >>>>>>>>>>>>>>>>>>>
> >>>> tok
> >>>>
> >>>>>>>>>>>>>>>>>>> en
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> While this document has moved to the Apps-
> Discuss
> >>>>>>>>>>>>>>>>>>> mailing list for the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
> >>>>>>>>>>>>>>> have been following this draft which originated on this
> list.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association.
> The
> >>>>>>>>>>>>>>>>>>>
> >>>> draft
> >>>>
> >>>>>>>>>>>>>>>>>>> is now a
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
> >>>>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less
> >>>>>>>>>>>>>>> than
> >> a page.
> >>>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
> >> OAuth
> >>>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the
> >>>>>>>>>>>>>>> MAC
> >>>>>>>>>>>>>>>
> >>>> draft.
> >>>>
> >>>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> >>>>>>>>>>>>>>>>>>>
> >>>> session cookies.
> >>>>
> >>>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The
> new
> >>>>>>>>>>>>>>>>>>>
> >>>> draft
> >>>>
> >>>>>>>>>>>>>>>>>>> uses the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
> >> remove
> >>>>>>>>>>>>>>>>>>>
> >>>> the
> >>>>
> >>>>>>>>>>>>>>>>>>> need for
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> clock sync.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing
> random
> >>>>>>>>>>>>>>>>>>> text to be
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source
> >>>>>>>>>>>>>>>>>>> of the credentials as
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> an additional protection.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,
> Acquia.
> >>>>>>>>>>>>>>>
> >>>> Inc.
> >>>>
> >>>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
> >>>>>>>>>>>>>>>
> >>>> http://www.drupalgardens.com"
> >>>>
> >>>>>>>>>>>>>>>
> >> _______________________________________________
> >>>>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> _______________________________________________
> >>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>> _______________________________________________
> >>>>>> OAuth mailing list
> >>>>>> OAuth@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth


From cmortimore@salesforce.com  Tue May 31 23:41: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 289CCE071B for ; Tue, 31 May 2011 23:41:45 -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 xs263QPxm136 for ; Tue, 31 May 2011 23:41:43 -0700 (PDT)
Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by ietfa.amsl.com (Postfix) with SMTP id CB513E06CD for ; Tue, 31 May 2011 23:41:42 -0700 (PDT)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKTeXfJr8MjAArAbCrj/frEPq+FVqQ798o@postini.com; Tue, 31 May 2011 23:41:42 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Tue, 31 May 2011 23:41:41 -0700
From: Chuck Mortimore 
To: Brian Eaton 
Date: Tue, 31 May 2011 23:41:40 -0700
Thread-Topic: [OAUTH-WG] Text for Native Applications
Thread-Index: Acwf9B4Rb6TN5E9vRquPiONg6koC5QAMtg8B
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_CA0B2D341AA93cmortimoresalesforcecom_"
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 06:41:45 -0000

--_000_CA0B2D341AA93cmortimoresalesforcecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 flo=
w 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 creden=
tials on the web server flow.  In terms of your example, wouldn't basic XSR=
F protection in the state param protect?

-cmort

On 5/31/11 5:37 PM, "Brian Eaton"  wrote:

On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
 wrote:
> Updated in language I just sent out - thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances.   Facebook in turn uses the
> implicit grant type, and simply issues long term access_tokens.
>
> Are there any strong objections to adding optional support for
> referesh_token on the implicit grant along with security considerations?

Is that really necessary?  Why?

The justification of reduced network round trips seems bogus to me.
We're talking about clients that just loaded up an entire web page,
asked the user to login, picked up a redirect, and are about to make
at least one and possibly several other API calls.

I'd prefer to keep the spec simple and consistent.  We can add all
kinds of options and maybes to the language, but long-term it will
just hurt interop.  I'd rather settle on protocol flows that make
sense.

One risk that comes up with returning refresh tokens with the implicit
grant type involves recovering from compromise of client web servers.
That's not strictly relevant to the current distinction (we're talking
about installed apps, different threat model), but it might be worth
thinking about anyway.

Consider what happens when a client web server is compromised and the
client secret and refresh tokens are stolen.
- the attacker can use the tokens until the compromise is discovered.
- the client secret is then changed
- the stolen refresh tokens then become useless

Now, *if* the implicit grant type returns refresh token, that story
changes.  Even if the client secret is changed, the attacker can keep
using the refresh tokens!  They do it by passing them to the victim
client again, through the implicit grant flow.  The victim client will
then link the refresh token to the attacker's account.


--_000_CA0B2D341AA93cmortimoresalesforcecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: [OAUTH-WG] Text for Native Applications


It’s not =
entirely necessary; I’m just having a tough time figuring out any pra=
ctical difference between the implicit grant flow, and the webserver flow w=
ith 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.  In terms of your example, wouldn=
’t basic XSRF protection in the state param protect?   
    

    
-cmort
    

    
On 5/31/11 5:37 PM, "Brian Eaton" <beaton@google.com> wrote:
    

    

    On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
    
<cmortimore@salesforce.com>=
 wrote:
    
> Updated in language I just sent out – thanks.
    
>
    
> On that note, we currently return refresh_token using the implicit gra=
nt
    
> type under certain controlled circumstances. =A0=A0Facebook in turn us=
es the
    
> implicit grant type, and simply issues long term access_tokens.
    
>
    
> Are there any strong objections to adding optional support for
    
> referesh_token on the implicit grant along with security consideration=
s?
    

    
Is that really necessary?  Why?
    

    
The justification of reduced network round trips seems bogus to me.
    
We're talking about clients that just loaded up an entire web page,
    
asked the user to login, picked up a redirect, and are about to make
    
at least one and possibly several other API calls.
    

    
I'd prefer to keep the spec simple and consistent.  We can add all
    
kinds of options and maybes to the language, but long-term it will
    
just hurt interop.  I'd rather settle on protocol flows that make
    
sense.
    

    
One risk that comes up with returning refresh tokens with the implicit
    
grant type involves recovering from compromise of client web servers.
    
That's not strictly relevant to the current distinction (we're talking
    
about installed apps, different threat model), but it might be worth
    
thinking about anyway.
    

    
Consider what happens when a client web server is compromised and the
    
client secret and refresh tokens are stolen.
    
- the attacker can use the tokens until the compromise is discovered.
    
- the client secret is then changed
    
- the stolen refresh tokens then become useless
    

    
Now, *if* the implicit grant type returns refresh token, that story
    
changes.  Even if the client secret is changed, the attacker can keep<=
BR>
using the refresh tokens!  They do it by passing them to the victim
client again, through the implicit grant flow.  The victim client will=

    
then link the refresh token to the attacker's account.
    

    

    




--_000_CA0B2D341AA93cmortimoresalesforcecom_--

From d.tangren@gmail.com  Tue May 31 23:44: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 DBB18E06CD for ; Tue, 31 May 2011 23:44:45 -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 VnloHgY7DzCS for ; Tue, 31 May 2011 23:44:45 -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 F2360E06B3 for ; Tue, 31 May 2011 23:44:44 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6816913iwn.31 for ; Tue, 31 May 2011 23:44:44 -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=3ZFTPDIp+R4XSvmVka4vQcynfCY7CzaSrXf50gB7TvY=; b=qZwX+08gsTjT8KA5B/6qmKQ+fCT5MYSwECrUHHXyyibcRNJqbWO3qCUX4OOXYaf2tT Q1Z4diaGC0SCvCqTFSChE3AnLSy7WzjZcbfqM7PW+OZaPDrpewAcJF+2cktQ9/KBtRKG j7Fk8HJXADUpvBxv0K4Q3ffOJAcKYKNWaqm3w=
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=mWHRO0PAELnIL5SgrFrsUCJAhGQF8w08nr0alLyV1f5JhNeJibJ+kStfxiWTLRkBPv nD0PmNttWjn9tcW52Fm93yq4wUFENpDeQ9B2Ad0EfjSmP3c5Z+evnfb71FR4WoovMCvW th5A0S33WRtXkDpJp70kNmDNSjEV+ELZMHg4k=
Received: by 10.42.2.137 with SMTP id 9mr5701316ick.392.1306910684480; Tue, 31 May 2011 23:44:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.158.74 with HTTP; Tue, 31 May 2011 23:44:24 -0700 (PDT)
In-Reply-To: 
References:  
From: Doug Tangren 
Date: Wed, 1 Jun 2011 02:44:24 -0400
Message-ID: 
To: Chuck Mortimore 
Content-Type: multipart/alternative; boundary=00504502c2371a067904a4a0db7f
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 06:44:46 -0000

--00504502c2371a067904a4a0db7f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

-Doug Tangren
http://lessis.me


For example, a iOS app that is shipped through iTunes certainly has access
> to reasonably secure storage via KeyChain for secrets issued to the
> application at runtime, such as the referesh_token, but it can=E2=80=99t =
do a good
> job of protecting the client_secret, since this must be embeded in the
> binary that is distributed to everyone.
>

Neither can anything that runs in you browser [1]

[1]:
https://github.com/cezarsa/silver_bird/commit/6c0c0b439d49f716ba5ea8ae2e13d=
15f2096c6fa

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


    -Doug Tangren
    http://lessis.me
    


    
For example, a iOS app that is shipped through iTunes certainly has access =
to reasonably secure storage via KeyChain for secrets issued to the applica=
tion at runtime, such as the referesh_token, but it can=E2=80=99t do a good=
 job of protecting the client_secret, since this must be embeded in the bin=
ary that is distributed to everyone.
    



    Neither can anything t=
hat runs in you browser [1]

    


    

--00504502c2371a067904a4a0db7f--

From eran@hueniverse.com  Tue May 31 23:45: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 A6AAFE071B for ; Tue, 31 May 2011 23:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level: 
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, 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 U8JwV3qhAzkC for ; Tue, 31 May 2011 23:45: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 C81F7E06B3 for ; Tue, 31 May 2011 23:45:02 -0700 (PDT)
Received: (qmail 674 invoked from network); 1 Jun 2011 06:45:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 06:45:01 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 31 May 2011 23:44:50 -0700
From: Eran Hammer-Lahav 
To: "igor.faynberg@alcatel-lucent.com" 
Date: Tue, 31 May 2011 23:44:22 -0700
Thread-Topic: [OAUTH-WG] Fwd: issues with token age element - MAC token
Thread-Index: AcwgIxLaaJKQR+/yRSCQz2qD1pQarQAA6VVQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA441@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>    <0EF19CB1-DD05-412F-876B-B997EC954C05@oracle.com> <4DE5708B.9090505@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA402@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE59299.2020909@alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E723447583CA43B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DE5D898.7090306@alcatel-lucent.com>
In-Reply-To: <4DE5D898.7090306@alcatel-lucent.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
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 06:45:05 -0000

I think the use cases are pretty well understood (the issue here was not la=
ck of use-case understanding).

Basically, when it comes to client and server deployment, you can have one-=
to-one, one-to-many, many-to-one, and many-to-many. Each setup presents is =
own challenges on how to produce unique nonces on the client side (for all =
requests with the same MAC credentials / access token), and how to store an=
d check on the server side. Once you go beyond one-to-one, it can be extrem=
ely hard (which is why most large providers don't check it).

The discussion here was mostly about the "matter of logic"... which is neve=
r as easy as it should be. :-)

EHL

> -----Original Message-----
> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
> Sent: Tuesday, May 31, 2011 11:14 PM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
>
> No, no, my little "I told you so" aside, I don't insist on putting this i=
n the
> document, especially that we have already agreed that the use case
> document is a post-2.0 issue.
>
> I think that for the purposes of the discussion on this thread it would h=
elp if
> all the use cases in question were clearly described--if only in an e-mai=
l for
> now.  Then it would be a matter of logic to see if there is a problem, an=
d if
> there is one, what the solutions to it might be.
>
> Igor
>
> Eran Hammer-Lahav wrote:
> > They are coming in 2-3 directions, the use case isn't really clear (oth=
er than
> claims of some flavors being harder than others), and overall this is mor=
e
> about general HTTP authentication than OAuth use cases. Don't get me
> wrong - if you want to put the effort in to capture these, go ahead. I ju=
st
> think this isn't worth the effort in a formal document.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
> >> Sent: Tuesday, May 31, 2011 6:15 PM
> >> To: Eran Hammer-Lahav
> >> Cc: Phil Hunt; OAuth WG
> >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >> token
> >>
> >> Maybe...  But this information must be captured somewhere, right?
> >>
> >> At the moment, there seems to be no record of and consequently no
> >> reference point to the use case in question. And this is what has
> >> created all this discussion--with messages coming from all directions.
> >>
> >> Igor
> >>
> >> Eran Hammer-Lahav wrote:
> >>
> >>> I think the use case document should focus on v2, not on MAC. At
> >>> some
> >>>
> >> point, it becomes impractical to keep every use case discussed on
> >> this list recorded.
> >>
> >>> EHL
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >>>> Behalf Of Igor Faynberg
> >>>> Sent: Tuesday, May 31, 2011 3:50 PM
> >>>> To: Phil Hunt
> >>>> Cc: OAuth WG
> >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC
> >>>> token
> >>>>
> >>>> ...Sorry to turn the question around so as to underline my pet peeve=
:
> >>>> Have we *documented* all cases?  (This is what the Use Cases
> >>>> document is supposed to be all about.)
> >>>>
> >>>> Just to clarify: I am not arguing with Phil's point now. I just
> >>>> stress that as of this moment we don't have anything to check agains=
t.
> >>>>
> >>>> Igor
> >>>>
> >>>> Phil Hunt wrote:
> >>>>
> >>>>
> >>>>> There seems to be a demonstrated need for both age and timestamp
> >>>>>
> >>>>>
> >>>> tokens.
> >>>>
> >>>>
> >>>>> The list has 2 separate cases with 2 separate proposals that do
> >>>>> not solve all
> >>>>>
> >>>>>
> >>>> cases.
> >>>>
> >>>>
> >>>>> Can we at least agree that neither proposal works in all cases?
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>> @independentid
> >>>>> www.independentid.com
> >>>>> phil.hunt@oracle.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> You haven't described a problem.
> >>>>>>
> >>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward
> >>>>>> 
> >>>>>>
> >>>>>>
> >>>> wrote:
> >>>>
> >>>>
> >>>>>>> First we should agree on a common understanding of the spec. The
> >>>>>>>
> >>>>>>>
> >>>> reason why age works with unsynchronized clocks is that the client
> >>>> determines issue_date based on the time when it receives the token
> >>>> over the wire. This depends on the server and client both recording
> >>>> time this way and for the transmission of the token to be be not
> >>>> longer than the margin of error for validating age. Are we agreed
> >>>> on this
> >>>>
> >> understanding?
> >>
> >>>>>> That's not correct.
> >>>>>>
> >>>>>> The age allows the server to protect against replay attacks in
> >>>>>> bounded memory.  With unbounded memory, the server can just
> >>>>>>
> >>>>>>
> >>>> remember
> >>>>
> >>>>
> >>>>>> every nonce it has ever seen associated with a given key and
> >>>>>> reject
> >>>>>>
> >>>>>>
> >>>> replays.
> >>>>
> >>>>
> >>>>>> With bounded memory, the server eventually needs to evict some
> of
> >>>>>> these nonces due to memory pressure.  The age value lets the
> >>>>>> server reject the nonces with the smallest age values first.  The
> >>>>>> server then rejects any messages with age values smaller than (or
> >>>>>> equal
> >>>>>> to) the largest age value it has ever evicted for the given key.
> >>>>>>
> >>>>>> Notice that neither clock synchronization nor transmission time
> >>>>>> plays a role in that implementation.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> The easiest case for me to explain here is client credentials
> >>>>>>> because I
> >>>>>>>
> >>>>>>>
> >>>> have to assume you've built and registered a Twitter app at some
> >>>> point (or similar OAuth 1.0a app). You registered your app on the
> >>>> site and were issued a client_id and client_secret (called
> >>>> consumer_key and consumer_secret in 1.0). You then embedded
> these
> >>>> values in your client (they were not issued programmatically to
> >>>> your app). Assuming the MAC token algorithm is used then for
> >>>> establishing client identity (originally one of the uses we, the
> >>>> working group, hoped MAC would cover) how then will your client
> determine issue date?
> >>>>
> >>>>
> >>>>>> I recommend the date at which the developer obtained the
> >>>>>> credential from Twitter because that is the date when the credenti=
al
> was issued.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> After we can establish where you're at on the two above points
> >>>>>>> I'll
> >>>>>>>
> >>>>>>>
> >>>> continue with the explanation. But as a preview, the next points
> >>>> would
> >>>>
> >> be:
> >>
> >>>>>>> - If issue_date comes form the server, how is it translated to
> >>>>>>> the
> >>>>>>>
> >> client?
> >>
> >>>>>>>
> >>>>>> The issue_date does not come from the server.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - If you use a server provided issue_date, how do you then
> >>>>>>> translate
> >>>>>>>
> >>>>>>>
> >>>> that a value relative to the local unsyncronized clock?
> >>>>
> >>>>
> >>>>>> The server does not provide the issue_date.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - If your answer to that is to also provide the current server
> >>>>>>> time to the
> >>>>>>>
> >>>>>>>
> >>>> client so the offset on the server provided issue_date can be
> >>>> calculated what is the difference between all of these values and
> >>>> just
> >>>>
> >> using timestamp?
> >>
> >>>>>> My answer is not to provide the current server time to the client.
> >>>>>>
> >>>>>> Kind regards,
> >>>>>> Adam
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> So don't get wrapped up in those 3 questions until we establish
> >>>>>>> your
> >>>>>>>
> >>>>>>>
> >>>> contextual understanding of the first two paragraphs. Feel free to
> >>>> also respond to me off the list so we don't trouble everyone else
> >>>> with us getting on the same page (the reason, I thought, why a
> >>>> Skype call would be more efficient and painless). I do think my
> >>>> explanations all have been very clear thus far. There must be a
> >>>> contextual confusion that is keeping us from a common understanding
> >>>> of
> >>>>
> >> the terminology or the use cases.
> >>
> >>>>>>> skylar
> >>>>>>>
> >>>>>>>
> >>>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> I'm not sure we need a Skype call.  Can you explain the trouble
> >>>>>>>> caused by age clearly?  I didn't understand your previous
> >>>>>>>> explanation.  The more concrete you can be, the better.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Adam
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward
> >>>>>>>> 
> >>>>>>>>
> >>>>>>>>
> >>>> wrote:
> >>>>
> >>>>
> >>>>>>>>> It seems we're failing to communicate. Or you're not
> >>>>>>>>> understanding
> >>>>>>>>>
> >>>>>>>>>
> >>>> my use cases. Age doesn't "just" work. It only works for a limited
> >>>> number of uses cases that must include all of yours - and it is
> >>>> brittle at that. It doesn't work for any of our uses cases (where
> >>>> the client can't know issue_date w/o the server telling it - in
> >>>> which case we have the equivalent problem as timestamp).
> >>>>
> >>>>
> >>>>>>>>> If you'd like to talk this out over Skype I'm happy to do
> >>>>>>>>> that, so I can
> >>>>>>>>>
> >>>>>>>>>
> >>>> help you understand why age doesn't work.
> >>>>
> >>>>
> >>>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Timestamps don't work when the client doesn't have a
> >>>>>>>>>> synchronized clock.  It's true that a client could
> >>>>>>>>>> synchronize its clock with the network, but our
> >>>>>>>>>> implementation experience is that many clients don't for a
> >>>>>>>>>> variety of reasons.  That means that age better because, you
> know, it works.
> >>>>>>>>>>
> >>>>>>>>>> Adam
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>  wrote:
> >>>>
> >>>>
> >>>>>>>>>>> I don't think you read my first message on the topic (or I
> >>>>>>>>>>> wrote too
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> much).
> >>>>
> >>>>
> >>>>>>>>>>> Age is fragile because if the clock changes between
> >>>>>>>>>>> issue_date and
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> the time of submission, it will fail. We know many people don't
> >>>> have synchronized clocks, but using age only solves this problem if
> >>>> two assumptions hold true:
> >>>>
> >>>>
> >>>>>>>>>>> 1) the client is able to guess the issue_date the server is
> >>>>>>>>>>> using based on the time the credential was issued
> >>>>>>>>>>> 2) the client system clock doesn't change between issue date
> >>>>>>>>>>> and
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> submission time.
> >>>>
> >>>>
> >>>>>>>>>>> Timestamp has neither of these issues because the client can
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> always inquire about network time and can effectively correct for
> >>>> inaccuracies in the device timekeeping system.
> >>>>
> >>>>
> >>>>>>>>>>> Regarding the first assumption, this fails when a token
> >>>>>>>>>>> might be re-
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> issued between devices. An example is that we use MAC token for the
> >>>> client credentials, which are issued when a developer registers an
> >>>> application. The client has no way of determining on its own when
> >>>> the value was actually issued (unless we communicate that on the
> >>>> developer website and force users to embed that with client_id,
> >>>> which adds usability issues of users copying and entering string
> >>>> date values correctly). The same is actually true for all of our
> >>>> OAuth access tokens because we reissue tokens to the same client_id
> >>>> if they were previously issued and are still valid. (The client
> >>>> would thus think the issue_date was now() when if fact it was the
> >>>> time of the first issue for client_id+scope+grantor_id). Thus, age
> >>>> is really just a
> >>>>
> >> convoluted way of trying to communicate the device system offset:
> >>
> >>>>>>>>>>>        local_offset =3D current_server_time - current_device_=
time
> >>>>>>>>>>>        age =3D current_device_time -
> >>>>>>>>>>> (server_issue_date-local_offset)
> >>>>>>>>>>>
> >>>>>>>>>>> Since the protocol doesn't currently allow for
> >>>>>>>>>>> server_issue_date to
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> be given with tokens, thus age currently can't have the resilience
> >>>> that timestamp does. It also forces servers to issue new tokens on
> >>>> demand just to make the convoluted age system work (rather than
> >>>> reuse existing valid tokens). Or, you have to modify the protocol
> >>>> to add server_issue_date and current_server_time into the
> >>>> token-issue
> >>>>
> >> exchange - eg, more complexity.
> >>
> >>>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for
> >>>>>>>>>>> your use
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> case of unsyncronized clocks.
> >>>>
> >>>>
> >>>>>>>>>>> skylar
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many
> >>>>>>>>>>>> folks don't have synchronized clocks, for a wide variety of
> reasons.
> >>>>>>>>>>>> I guess I don't really understand why you view age as
> >>>>>>>>>>>> problematic.  You reference "fragility of using
> >>>>>>>>>>>> time-since-credentials-issued" but you don't say what
> >>>>>>>>>>>> exactly is fragile about it.  There's nothing particularly
> >>>>>>>>>>>> complex about age, especially when using the monotonic
> >>>>>>>>>>>> clock provided by
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>> all modern operating systems.
> >>>>
> >>>>
> >>>>>>>>>>>> Adam
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>  wrote:
> >>>>
> >>>>
> >>>>>>>>>>>>> But see, now you are specializing the use of MAC token
> >>>>>>>>>>>>> even
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> more - now it's becoming a service mainly for user-agents on home
> >>>> desktops? This is further for the original goal of making MAC as
> >>>> flexible is possible. In this case you should change the spec name
> >>>> to
> >>>>
> >>>>
> >>
> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI
> >>
> >>>> REFOX - or MTBCRLF for short.
> >>>>
> >>>>
> >>>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good
> >>>>>>>>>>>>> as your
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> offset technique and is more: reliable, straightforward, flexible.
> >>>>
> >>>>
> >>>>>>>>>>>>> User agents that care about creating robust behavior for
> >>>>>>>>>>>>> home
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> desktops or mobiles (presumably of users and OS not yet
> >>>> sophisticated enough to check network time on their own) should be
> >>>> advised to do clock correction on their own (by pinging a time
> >>>> service) and trusting the device clock alone.
> >>>>
> >>>>
> >>>>>>>>>>>>> Please change the spec back to using timestamp rather
> than
> >>>>>>>>>>>>>
> >> age.
> >>
> >>>>>>>>>>>>> I'd also like to hear a convincing argument from the
> >>>>>>>>>>>>> Mozilla
> >>>>>>>>>>>>> co-
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> authors about why they think that age is more resilient than the
> >>>> above (I believe it is not) and further more why they would find
> >>>> the above unattractive or difficult to implement in a modern user-
> agent.
> >>>>
> >>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -..
> >>>>>>>>>>>>> - ... -.- -.-- .-.. .- .-. - .-
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>> - --- --- -.. .-- .- .-. -..
> >>>>
> >>>>
> >>>>>>>>>>>>> skylar woodward
> >>>>>>>>>>>>> Kiva Developer Program  /  build.kiva.org  /  @buildkiva
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Any kind of clock sync requirement for user-agents
> >>>>>>>>>>>>>> (basically,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>> home desktops) it completely impractical. The added complexity
> >>>> pales in comparison to the difficulty of trying to use timestamps
> >>>> and any kind of clock sync. No window will be big enough as
> >>>> experience shows some users have closes that are off by more than an
> hour and a half.
> >>>>
> >>>>
> >>>>>>>>>>>>>> The issue here is who is this being optimized for.
> >>>>>>>>>>>>>> Server-to-
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>> server communication should simply use TLS for privacy and MITM
> >>>> protection on top of MAC instead of using nonces to prevent replay.
> >>>> The whole point of this kind of replay protection is when TLS is
> >>>> not
> >>>>
> >> available.
> >>
> >>>>>>>>>>>>>> I think a better approach is to simply make checking the
> >>>>>>>>>>>>>> nonce
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>> optional when TLS is used.
> >>>>
> >>>>
> >>>>>>>>>>>>>> EHL
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> bounces@ietf.org]
> >>>>
> >>>>
> >>>>>>>>>>>>>>> On Behalf Of Peter Wolanin
> >>>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM
> >>>>>>>>>>>>>>> To: Skylar Woodward
> >>>>>>>>>>>>>>> Cc: OAuth WG
> >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> element -
> >>>>
> >>>>
> >>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am also concerned by the fragility of using
> >>>>>>>>>>>>>>> time-since-credentials-issued, and also the added
> >>>>>>>>>>>>>>> complexity
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> of specifying this construction.
> >>>>
> >>>>
> >>>>>>>>>>>>>>> I think it would be preferable to always require a
> >>>>>>>>>>>>>>> timestamp as part of the authorization header, and
> maybe
> >>>>>>>>>>>>>>> even include in the spec a maximum time difference
> >>>>>>>>>>>>>>>
> >> between
> >>
> >>>>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be
> >>>>>>>>>>>>>>> tolerated.  This makes generating the nonce easier also,
> >>>>>>>>>>>>>>> since the value need to
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> longer be unique over all time.
> >>>>
> >>>>
> >>>>>>>>>>>>>>> We have such rules in place for an HMAC-based
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> authentication
> >>>>
> >>>>
> >>>>>>>>>>>>>>> system we use.  Once in a while a client has a local
> >>>>>>>>>>>>>>> clock so far out of sync that there is an issue, but it's=
 rare.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Peter
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward
> >>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Resending to the list from my subscribed account...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> From: Skylar Woodward 
> >>>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT
> >>>>>>>>>>>>>>>>> To: Skylar Woodward 
> >>>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav ,
> >>>>>>>>>>>>>>>>>
> >> OAuth
> >>
> >>>> WG
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age
> >>>>>>>>>>>>>>>>>
> >> element -
> >>
> >>>>>>>>>>>>>>>>> MAC token
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a
> >>>>>>>>>>>>>>>>> bit, I would suggest that
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named)
> >>>>>>>>>>>>>>> without further requirements. It might be suggested
> that
> >>>>>>>>>>>>>>> this be composed of an
> >>>>>>>>>>>>>>> random+timestamp (not age) value, but that seems
> more
> >>>>>>>>>>>>>>>
> >> of a
> >>
> >>>>>>>>>>>>>>> random+MAY or
> >>>>>>>>>>>>>>> "recommended" practice. If the expectation is that very
> >>>>>>>>>>>>>>> few if any providers would actually check the timestamp
> >>>>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in
> >>>>>>>>>>>>>>> the draft that requires it? Developers are doing extra
> >>>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> no payoff or added security.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> I'm sending this feedback based on having
> implemented
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>> the
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> v3-5 changes
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> last night (for both client credentials and requests w/
> >>>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is
> >>>>>>>>>>>>>>> now the most complicated part of the normalized
> request
> >>>>>>>>>>>>>>> string
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> and yet these changes offer the least benefit.
> >>>>
> >>>>
> >>>>>>>>>>>>>>> What's most important is that nonces are unique on each
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> request for an ID.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> There are issues with age as well:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue
> >>>>>>>>>>>>>>>>> time based on receipt, then the internal clock changes
> >>>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing
> the
> >>>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user
> >>>>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix
> >>>>>>>>>>>>>>>>> it and actually encourages bad user behavior (don't
> >>>>>>>>>>>>>>>>> fix your clock or Twitterbot will stop working!).
> >>>>>>>>>>>>>>>>> Though we say that timezones won't bring about the
> >>>>>>>>>>>>>>>>> situation of changed clock, I'd be to differ. Many
> >>>>>>>>>>>>>>>>> users aren't savvy enough to change time zone, but
> >>>>>>>>>>>>>>>>> just adjust the time to local time anyway. Users who
> >>>>>>>>>>>>>>>>> are more likely to get it right already have auto
> >>>>>>>>>>>>>>>>> clock sync enabled (via web, mobile, etc.)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - What if the token wasn't originally issued
> >>>>>>>>>>>>>>>>> programmatically? In this case,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the issue time has to be obtained from the server and
> >>>>>>>>>>>>>>> stored on the client then you have the same problem as
> >>>>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the
> >>>>>>>>>>>>>>> server clock and there is no adjustment. You want this
> >>>>>>>>>>>>>>> to apply to uses outside of just OAuth, but now
> >>>>>>>>>>>>>>> requiring the client to be able to determine an issue
> >>>>>>>>>>>>>>> time based on when it receives
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> an HTTP request necessarily limits the types of token flows for
> >>>> which this can be used.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a
> >>>>>>>>>>>>>>>>> developer, but it is
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an
> >>>>>>>>>>>>>>> ID, it is actually more of a recording of "my personal
> >>>>>>>>>>>>>>> clock offset value" but obfuscated several times over
> >>>>>>>>>>>>>>> (one for each
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> token) as issue_date.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> - This implementation assumes software programs
> use
> >>>>>>>>>>>>>>>>>
> >> the
> >>
> >>>>>>>>>>>>>>>>> computer
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust
> >>>>>>>>>>>>>>> program that is dependent on accurate timestamps
> would
> >>>>>>>>>>>>>>> ping the origin server (or similar trusted time
> >>>>>>>>>>>>>>> authority) to ask it the current time. Then it could
> >>>>>>>>>>>>>>> store a "my device clock offset" value for the lifetime
> >>>>>>>>>>>>>>> of the program execution. All requests needing
> timestamp
> >>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>
> >> be
> >>
> >>>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed
> >>>>>>>>>>>>>>> since the
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> stored issue_date, the problem can't be corrected in this manner.
> >>>>
> >>>>
> >>>>>>>>>>>>>>> Thus, a significant advantage for timestamp.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> All in all, this seems like a misguided but
> >>>>>>>>>>>>>>>>> well-intentioned attempt to get
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like
> >>>>>>>>>>>>>>> a hack and it certainly isn't a foolproof solution. The
> >>>>>>>>>>>>>>> more I think about the implications of the age
> >>>>>>>>>>>>>>> parameter, the less I like it. Timestamp has been used
> >>>>>>>>>>>>>>> for many years in the industry and with reasonable
> >>>>>>>>>>>>>>> success in relevant applications. If we change to a new
> >>>>>>>>>>>>>>> way of trying to sync on
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> time I think we run a greater risk of stumbling upon unforeseen
> >>>> issues, such as those outlined above.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>> I recommend the requirement of an age (or
> timestamp
> >>>>>>>>>>>>>>>>>
> >> for
> >>
> >>>>>>>>>>>>>>>>> that matter)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> be dropped from the nonce construction. For providers
> >>>>>>>>>>>>>>>
> >> that
> >>
> >>>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value
> >>>>>>>>>>>>>>> (either as part of the nonce or the overall header, as
> >>>>>>>>>>>>>>>
> >> before).
> >>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>> "example.net"
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>> - should be example.com, I believe.  (draft v5)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2.
> >>>>>>>>>>>>>>>>>> Certainly addresses my
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> hesitations from v2.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> skylar
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav
> >>>>>>>>>>>>>>>>>>
> >> wrote:
> >>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss
> >>>>>>>>>>>>>>>>>>>  mailing list)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-
> >>>>>>>>>>>>>>>>>>>
> >> mac-
> >>
> >>>> tok
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> en
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> While this document has moved to the Apps-
> Discuss
> >>>>>>>>>>>>>>>>>>> mailing list for the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> time being, I wanted to give a quick update to those who
> >>>>>>>>>>>>>>> have been following this draft which originated on this
> list.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The major changes since -02 are:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association.
> The
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>> draft
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> is now a
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does
> >>>>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less
> >>>>>>>>>>>>>>> than
> >>>>>>>>>>>>>>>
> >> a page.
> >>
> >>>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the
> >>>>>>>>>>>>>>>
> >> OAuth
> >>
> >>>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the
> >>>>>>>>>>>>>>> MAC
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> draft.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>> session cookies.
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The
> new
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>> draft
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> uses the
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> raw request URI unchanged.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to
> >>>>>>>>>>>>>>>>>>>
> >> remove
> >>
> >>>> the
> >>>>
> >>>>
> >>>>>>>>>>>>>>>>>>> need for
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> clock sync.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing
> random
> >>>>>>>>>>>>>>>>>>> text to be
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> included in the request and MAC.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source
> >>>>>>>>>>>>>>>>>>> of the credentials as
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> an additional protection.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Peter M. Wolanin, Ph.D.      : Momentum Specialist,
> Acquia.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> Inc.
> >>>>
> >>>>
> >>>>>>>>>>>>>>> peter.wolanin@acquia.com : 978-296-5247
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>> http://www.drupalgardens.com"
> >>>>
> >>>>
> >> _______________________________________________
> >>
> >>>>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> _______________________________________________
> >>>>>>>>>>>>> OAuth mailing list
> >>>>>>>>>>>>> OAuth@ietf.org
> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>> _______________________________________________
> >>>>>> OAuth mailing list
> >>>>>> OAuth@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>>

From kris.selden@gmail.com  Tue May 31 23:46: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 915DBE06B3 for ; Tue, 31 May 2011 23:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.109
X-Spam-Level: 
X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490,  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 pAY-sLF0gLr4 for ; Tue, 31 May 2011 23:46:00 -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 94C2CE06CD for ; Tue, 31 May 2011 23:45:59 -0700 (PDT)
Received: by pzk5 with SMTP id 5so2649702pzk.31 for ; Tue, 31 May 2011 23:45:59 -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=cAOkPHN6q/rJyIev0mjkTIooovCWduCEDPwi6j74ojo=; b=i7LwbM9FWIvnuwFjPJ4BUss9PQQrhOk2+Cfs+FruAryzDAi08LhjYKDSgo4YUutzjn 2tYmnEV60XPAbamGsrLBvZnnXJhyO+Q3h63MHc0dlDSQnhdtcdlPAOgFGLD81TIetzNU 4o8ntSZ8EnvZb5aOTvYGhn9luUvbnWej11Iic=
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=kFmpAnAls+lSbCgDD/PW731tVK5zO6eVsrfES1nFnx/JTsZAYCQA/c/jzaLMQZ2Iir y/vtk/Onk2LX248Afa0UYxtBLRH5SDSFbUddzFCWdaDJUAHF+8D34nEuFqSBd7qw9RT1 7OuLbymN689hVrqxfyizSzmehDBtYV4vho/Ew=
Received: by 10.68.38.230 with SMTP id j6mr2949517pbk.17.1306910758654; Tue, 31 May 2011 23:45:58 -0700 (PDT)
Received: from [172.16.2.2] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id m9sm781175pbd.23.2011.05.31.23.45.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 23:45:57 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-35-38558535
From: Kris Selden 
In-Reply-To: 
Date: Tue, 31 May 2011 23:45:56 -0700
Message-Id: <5058C21C-7C12-47CE-A984-E9EB40CEA952@gmail.com>
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>   
To: Doug Tangren 
X-Mailer: Apple Mail (2.1082)
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 06:46:01 -0000

--Apple-Mail-35-38558535
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I would suspect that many users are overwhelmed when authorizing many =
fine grained scopes and don't fully understand the risks.  Many popular =
sites ask for offline access straight 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 Foursquare does), which sets a Javascript =
accessible non secure cookie on your domain which now means that if =
Foursquare makes a non secure http request to foursquare.com a non =
expiring bearer token will go out in plaintext.  Foursquare is https =
only but many sites that use the JS SDK aren't.

The biggest difference between a refresh token and a non-expiring access =
token is that the refresh token needs to be verified by the =
authorization 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/12238549/ScalableOAuth#RationaleforRenewable=
AccessTokensSessions) which was a predecessor to OAuth WRAP and OAuth 2:

Rationale for Renewable Access Tokens (Sessions)

Many Service Providers have the concept of a Session credential with a =
finite lifetime. Consumers authenticate with the Service Provider's =
Authentication Service to obtain a Session credential to access the =
Service Provider's protected resources. When the Session credential =
expires, the consumer is able to obtain a new Session credential by =
re-authenticating with the Authentication service. The primary benefit =
to this architecture is that Session 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 Session (aka Refresh Secret)

Service Providers often run their Authentication Service separately from =
other protected resources. The Authentication Service is usually =
strictly monitored and controlled, while other Protected Resources may =
be running relatively new and unproven code.

In the event that a Protected Resource is compromised (the SP gets =
hacked), it is desirable to prevent the intruder from being able to =
continue to compromise the system after the vulnerability has been =
fixed. Issuing credentials with a finite lifetime limits the duration =
that the intruder can continue to use compromised credentials. Issuing a =
credential to a Consumer 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 secret is the end user's expectation to stay =
"logged in." =20


On May 31, 2011, at 7:12 PM, Doug Tangren wrote:
>=20
> "offline_access permission."
>=20
> If I read that right, that says the user has to opt into 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 hacking around them.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail-35-38558535
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

foursquare.com a non =
expiring bearer token will go out in plaintext.  Foursquare is =
https only but many sites that use the JS SDK =
aren't.

    The biggest difference between a =
refresh token and a non-expiring access token is that the refresh token =
needs to be verified by the authorization 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/12238549/Scalabl=
eOAuth#RationaleforRenewableAccessTokensSessions) which was =
a predecessor to OAuth WRAP and OAuth =
2:

    Rationale for Renewable Access =
Tokens (Sessions)

    Many Service Providers have the concept of a =
Session credential with a finite lifetime. Consumers authenticate with =
the Service Provider's Authentication Service to obtain a Session =
credential to access the Service Provider's protected resources. =
When the Session credential expires, the consumer is able to obtain a =
new Session credential by re-authenticating with the Authentication =
service. The primary benefit to this architecture is that Session =
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 Session =
(aka Refresh Secret)

    Service Providers often run their =
Authentication Service separately from other protected resources. The =
Authentication Service is usually strictly monitored and controlled, =
while other Protected Resources may be running relatively new and =
unproven code.

    In the event that a Protected Resource is =
compromised (the SP gets hacked), it is desirable to prevent the =
intruder from being able to continue to compromise the system after the =
vulnerability has been fixed. Issuing credentials with a finite =
lifetime limits the duration that the intruder can continue to use =
compromised credentials. Issuing a credential to a Consumer 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.

    ------

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


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

    "
    



    OAuth@ietf.org
    https://www.ietf.org/=
mailman/listinfo/oauth

    =

--Apple-Mail-35-38558535--

From kris.selden@gmail.com  Tue May 31 23:48: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 333CDE06CD for ; Tue, 31 May 2011 23:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level: 
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, 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 U7HLO8COCMvU for ; Tue, 31 May 2011 23:48:08 -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 3073CE0797 for ; Tue, 31 May 2011 23:47:20 -0700 (PDT)
Received: by pwi5 with SMTP id 5so2687703pwi.31 for ; Tue, 31 May 2011 23:47:20 -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=eVQUHcU3cjtHI1YXoNXSuppDFHQaF9/IdasE25fZ8yU=; b=ZwCeTHlA9y+8zlJyB53gJ5UQvqBjKXLnpp74IvPfVInXY1tTwAUWyj29xLREbpXhWH SLtbBEuojQTCkfQjXaTX4HUh4NNw8qCNuaLKS3FjvGvLmi4OHN55RTKVOptb881pZLxg BU7B8BKdYuV7ZeXM5HK40yobLiIEpI58/HQ4E=
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=KVSB9SVy/E8BrqrVXG7eccYHwvHWkqgVNJBLgfhDEKNGur49WO/9ENVD4sl5Kli3cY qrb1GI+bdfHri5d4NCoz5RyThsrwWNu/ljwk3FfNmfkAA6s4G86Ah39Ftj1rsfCEItgk tYhh28V1tetPbC1KcA4R+ECXTsyuO13R2Wm0U=
Received: by 10.68.14.4 with SMTP id l4mr2665058pbc.236.1306910839902; Tue, 31 May 2011 23:47:19 -0700 (PDT)
Received: from [172.16.2.2] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id x1sm775672pbb.82.2011.05.31.23.47.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 23:47:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Kris Selden 
In-Reply-To: 
Date: Tue, 31 May 2011 23:47:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D3B9285-476D-4EA8-ADB5-F3A0FD71815C@gmail.com>
References: <623547103-1306301420-cardhu_decombobulator_blackberry.rim.net-1420910677-@b2.c11.bise7.blackberry>    
To: Brian Eaton 
X-Mailer: Apple Mail (2.1082)
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 06:48:09 -0000

Yes, it is important to remember that when you make allowances for one =
flow you affect other flows, I understand that.  I understand that if in =
the implicit flow you return a refresh token, you then allow other flows =
to use authorization server endpoint to refresh the token without a =
client secret.

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.

Like the client secret though, the refresh token is only exchanged with =
the authorization server and only over https.

I think the fact that the refresh token is only exchanged with the =
authorization server and not the resource servers, still makes it useful =
to apps that can't be shipped with a client secret.  I'm not a fan of =
the implicit flow and JS clients but would like to be able to use the =
other flows with native apps that can't be authenticated (like an iPhone =
app).  So it would be nice if client authentication was not required to =
refresh a token.

On May 31, 2011, at 11:05 PM, Brian Eaton wrote:

> On Tue, May 31, 2011 at 10:39 PM, Kris Selden  =
wrote:
>> Why can't you just revoke the refresh token for a client when you =
change the client secret?
>>=20
>> Is it not easier to revoke a token than it is to rotate the client =
secret (which is usually configured or embedded in the client whereas =
the token is issued)?
>=20
> As I noted in my original e-mail on this thread, I was talking
> specifically about the web server flow.
>=20
> This is one area where the security considerations for installed
> applications are different than for web servers.


From beaton@google.com  Tue May 31 23:56: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 1D70CE0700 for ; Tue, 31 May 2011 23:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.477
X-Spam-Level: 
X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 ZDrBChJ7-eF8 for ; Tue, 31 May 2011 23:56:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 14011E06EF for ; Tue, 31 May 2011 23:56:54 -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 p516usaC031588 for ; Tue, 31 May 2011 23:56:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306911414; bh=UD4UL7nYmSKw2ocWPkFR1Veck4A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=m8qWmch34HLXpcCgU0gIYQRhPcibKulPJw4l+NwEJM1KJuVGG27Lj2yhLCGhbfoJ1 zNZgdnWayQyVO+NU35mkA==
Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by hpaq5.eem.corp.google.com with ESMTP id p516upK3016280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 23:56:52 -0700
Received: by pxi13 with SMTP id 13so2264691pxi.25 for ; Tue, 31 May 2011 23:56:51 -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=5MwJNFkQOK4chR6YAWTrdPzXkY83rSQPCtxOFuexV1U=; b=l8zNdBJbdp7ZOO/74AQF1buNpL72SGZHnMEpuWUR84zuEeWOnSF5bEFNEYj7dRNkX1 fTtd2Q4b7Mjd/gPbv04Q==
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=pwEPrdSjfzDVPohHYeNQMEbyTKNqFXxhCIvnOJ5DPNEvrV/RStsl7Ws7OvUFcJAW0T TRfZDDoUgdg3LKNbCuEQ==
MIME-Version: 1.0
Received: by 10.142.221.1 with SMTP id t1mr1160995wfg.437.1306911410950; Tue, 31 May 2011 23:56:50 -0700 (PDT)
Received: by 10.142.14.2 with HTTP; Tue, 31 May 2011 23:56:50 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 31 May 2011 23:56:50 -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 06:56:56 -0000

On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
 wrote:
> It=92s not entirely necessary; I=92m just having a tough time figuring ou=
t any
> practical difference between the implicit grant flow, and the webserver f=
low
> with no credentials. =A0=A0In general I agree with your points, but I thi=
nk 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
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.)

- 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.

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

> In terms of your example, wouldn=92t basic XSRF protection in the state p=
aram 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