From Internet-Drafts@ietf.org Wed Feb 2 15:45:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC2D3A6CA1; Wed, 2 Feb 2011 15:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2brJyT+2GgC; Wed, 2 Feb 2011 15:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EF43A6C91; Wed, 2 Feb 2011 15:45:02 -0800 (PST) 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.12 Message-ID: <20110202234502.25081.7321.idtracker@localhost> Date: Wed, 02 Feb 2011 15:45:02 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:45: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 : SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 Author(s) : B. Campbell, C. Mortimore Filename : draft-ietf-oauth-saml2-bearer-02.txt Pages : 13 Date : 2011-02-02 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-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 implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-saml2-bearer-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-02153755.I-D@ietf.org> --NextPart-- From bcampbell@pingidentity.com Wed Feb 2 15:49:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1163A6C41 for ; Wed, 2 Feb 2011 15:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym7XPEDcw3f4 for ; Wed, 2 Feb 2011 15:49:54 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with ESMTP id 81A423A6CF5 for ; Wed, 2 Feb 2011 15:49:50 -0800 (PST) Received: from source ([209.85.161.52]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTUnuZoi+oZmOUsbAnG2e0d3aqCoh6OHO@postini.com; Wed, 02 Feb 2011 15:53:11 PST Received: by mail-fx0-f52.google.com with SMTP id 5so572444fxm.25 for ; Wed, 02 Feb 2011 15:53:10 -0800 (PST) Received: by 10.223.123.142 with SMTP id p14mr9230078far.56.1296690790607; Wed, 02 Feb 2011 15:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Wed, 2 Feb 2011 15:52:40 -0800 (PST) In-Reply-To: <20110202234502.25081.7321.idtracker@localhost> References: <20110202234502.25081.7321.idtracker@localhost> From: Brian Campbell Date: Wed, 2 Feb 2011 16:52:40 -0700 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-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:49:54 -0000 The changes in -02 are listed here for easy viewing: draft-ietf-oauth-saml2-bearer-02 - Added scope parameter with text copied from draft-ietf-oauth-v2-12 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't really inherited by this spec anymore) - Change definition of the assertion parameter to be more generally applicable per the suggestion near the end of http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html - Editorial changes based on feedback ---------- Forwarded message ---------- From: Date: Wed, Feb 2, 2011 at 4:45 PM Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-02.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org 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. =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 : B. Campbell, C. Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-02.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-02 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-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 implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Feb 2 16:59:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8363A65A6 for ; Wed, 2 Feb 2011 16:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.917 X-Spam-Level: X-Spam-Status: No, score=-103.917 tagged_above=-999 required=5 tests=[AWL=-0.940, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS3fwAK9tk+e for ; Wed, 2 Feb 2011 16:59:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 88CB63A65A5 for ; Wed, 2 Feb 2011 16:59:01 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p1312KBR027216 for ; Wed, 2 Feb 2011 17:02:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296694941; bh=WtztSX46CpbM3DG347pAezuLXbE=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=dG7YQbwVyFHi+CLDDGYlh1UKkkQ1eZT4j9heFxo736TEooESbUWF4mF2uTZwLFPVM t7+8z9Wlg7BYMdYPSYrjA== Received: from gwb10 (gwb10.prod.google.com [10.200.2.10]) by kpbe13.cbf.corp.google.com with ESMTP id p1311sb5008748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Feb 2011 17:02:19 -0800 Received: by gwb10 with SMTP id 10so302583gwb.26 for ; Wed, 02 Feb 2011 17:02:19 -0800 (PST) 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=MsWahp+EjOwZjW/JOy4CmaUNpo4kivAc9DhIxJvn01Q=; b=Zh7LX+AViU+O6q21LCFqePWOyyp8SFMyhkpFVUyf9q9CWv0uMMy7oIz8NVY3tYpy9w CHx838VhTO5D5y0G+7Eg== 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=HVz8BTTGvijhfU7CRlXAHnPPoBJ78ZVm8B5w6irGpNA4z6Hb13G2dWcmNDY4IDXAQD ubZbTDN81mbAIsWHijMA== Received: by 10.100.127.1 with SMTP id z1mr6441024anc.180.1296694938720; Wed, 02 Feb 2011 17:02:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 2 Feb 2011 17:01:58 -0800 (PST) From: Marius Scurtescu Date: Wed, 2 Feb 2011 17:01:58 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Token Revocation (was: Re-Chartering: What Items to work on?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:59:04 -0000 Following up on the Token Revocation extension proposed at: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ I am suggesting three changes to this extension: 1. Either drop client authentication or make it optional. If clients want to revoke tokens, more power to them. If it is a malicious client, why would the authorization server deny revoking tokens? 2. Can we drop the "token_type" parameter, as suggested before? 3. "authorization server MUST also invalidate all access tokens issued for that refresh token." can we change this MUST to a SHOULD? In case of success, why is the server supposed to return 204 instead of 200? Just worried that this will confuse clients. Thanks, Marius On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu wrote: > On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt > wrote: >> Am 12.01.2011 22:19, schrieb Richer, Justin P.: >>> >>> Yes, let the server do the work. In practice, it's going to be looking up >>> the token based on the token value anyway (for bearer tokens, at least). All >>> the client really cares about is asking to "revoke this token that I am >>> sending you". If the client credentials and token are correct and >>> verifiable, then the revoke should go through. >> >> What do others think? > > I agree with Justin's suggestion, let the server figure the token > type. The server should be able to do that anyhow. > > >>> A client wanting to revoke both a request token and an access token will >>> have to make several calls to this, unless you want to put in a way to put >>> multiple token values in. I don't recommend that though, as it seems to me >>> an optimization for a problem nobody has yet. >> >> the token_type does not control whether the server deletes all access tokens >> associated with a refresh token. >> >> This depends on the authorization servers policy. > > There are cases when the server cannot revoke the access tokens > associated with a refresh token (static access tokens for example). > That being said, I think the server SHOULD revoke all access tokens if > possible. > > > Marius > From hannes.tschofenig@gmx.net Thu Feb 3 00:03:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F56D3A6894 for ; Thu, 3 Feb 2011 00:03:56 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoSf3OABrbQt for ; Thu, 3 Feb 2011 00:03:55 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 0BF8C3A688B for ; Thu, 3 Feb 2011 00:03:54 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 08:07:15 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp011) with SMTP; 03 Feb 2011 09:07:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+g35IQ7gmgX29IAi0FnJOuNoC39MypcArCweZa6y +rK4nx3CoThAVv Message-ID: <4D4A623B.9030105@gmx.net> Date: Thu, 03 Feb 2011 10:07:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth version -12 specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:03:56 -0000 Hey all, the work on version -12 of the OAuth specification has generated a lot of discussion. -12 certainly contains a number of changes; some editorial but also normative changes. I went through the mailing list to see what the level of support we have for various design decisions. I need a bit of feedback. To make it easier to capture your response I have placed each discussion item in a separate mail. Ciao Hannes From hannes.tschofenig@gmx.net Thu Feb 3 00:08:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3963A6893 for ; Thu, 3 Feb 2011 00:08:05 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9kIcVwofrmW for ; Thu, 3 Feb 2011 00:08:04 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 29BC73A688B for ; Thu, 3 Feb 2011 00:08:03 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 08:11:24 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp059) with SMTP; 03 Feb 2011 09:11:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sfbMu+5XsWRoCCVMY8ggyEMX8Ij4xPkGGyiCtwy haaCEqXq5qnzpz Message-ID: <4D4A632A.6070600@gmx.net> Date: Thu, 03 Feb 2011 10:11:22 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:08:05 -0000 Hi all, Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme functionality from the specification in his mail from last month: http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html The discussion got off topic pretty quickly with the discussion about OAuth usage for SASL. I couldn't see a strong objection but rather clarifying discussions. Please correct me if I misread your feedback on this issue. So, my current impression is that there is no objection and we confirm the design decision to remove the 'OAuth2' HTTP Authentication Scheme from draft-ietf-oauth-v2. Deadline for feedback: Feb, 10th 2011 Ciao Hannes From hannes.tschofenig@gmx.net Thu Feb 3 00:10:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FAC53A688B for ; Thu, 3 Feb 2011 00:10:53 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGkvIyhXkmv9 for ; Thu, 3 Feb 2011 00:10:51 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id E7C493A689D for ; Thu, 3 Feb 2011 00:10:46 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 08:14:07 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp024) with SMTP; 03 Feb 2011 09:14:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/7nflCOr37KfvzTAUNP1h7gj0h+2dwgQt/kQvPAk U6Ui7r28wMLny6 Message-ID: <4D4A63D7.3000900@gmx.net> Date: Thu, 03 Feb 2011 10:14:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Hum about 'Removal: Client Assertion Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:10:53 -0000 Hi all, Eran suggested to remove the Client Assertion functionality from the draft-ietf-oauth-v2 specification in his mail from last month: http://www.ietf.org/mail-archive/web/oauth/current/msg05027.html This lead to a heated discussion. Going through the discussions I got the following impression: "+" means in favor of removing the Client Assertion credential functionality from the draft-ietf-oauth-v2 specification and "-" means against it. "*" indicates some constraints. +Eran *Phil (was talking about a stronger version of the client assertion credentials) +David *Francisco (also has a stronger version in mind) -Mike *Marius (Marius has plans to use client assertions in two profiles. So, I assume he wants to have the functionality but I do not know whether he cares about where it is document; in the main spec or in a separate document.) Please correct me if I have forgotten someone or misinterpreted someone's statement. The feedback from the group as I have seen it was a bit difficult to interpret (particularly from Phil, Francisco, and Marius). So, a clarification would be good. Feedback indicated that there is interesting in deploying the Client Assertion credential functionality. That's good. My reading of Section 3.2 of OAuth version -11 is that this functionality is NOT mandatory to implement. So, for me the question therefore is where to describe this functionality. Here are my questions: 1a) Do you insist in having it documented in draft-ietf-oauth-v2? PLEASE NOTE: Having functionality in a separate document does not mean that it will take longer to complete nor that it is less important. It is purely a document management question! 1b) If your answer to question (1) is "NO" then here is another question for you: Would you be willing to co-author a document on this functionality? 2) Do you think that the text in Section 3.2 of version -11 is not sufficient for interoperability, incomplete from a security point of view, or lacking some other functionality? Without going through the arguments again I would like to get a sense from the group. Deadline for response: Feb, 10th 2011 Ciao Hannes From hannes.tschofenig@gmx.net Thu Feb 3 00:13:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FC03A689A for ; Thu, 3 Feb 2011 00:13:00 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2ONTsDcEvIX for ; Thu, 3 Feb 2011 00:12:58 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 600143A688B for ; Thu, 3 Feb 2011 00:12:57 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 08:16:19 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp059) with SMTP; 03 Feb 2011 09:16:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/R/ghnjgrRasmguoWgW+Efw1I7KEJAH4nWGp0knk He073FSD17iir5 Message-ID: <4D4A645A.4060901@gmx.net> Date: Thu, 03 Feb 2011 10:16:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:13:00 -0000 Hi all, Eran suggested to remove the HTTP Basic Authentication functionality from the specification in his mail from last month: http://www.ietf.org/mail-archive/web/oauth/current/msg05028.html Essentially, there are two ways to accomplish the same functionality, namely (1) Request parameters and (2) HTTP Basic authentication. Eran's initial discussion trigger very quickly evolved a discussion about the removal of 'credential body parameters': http://www.ietf.org/mail-archive/web/oauth/current/msg05035.html This was, however, not supported by Justin, Eran, and Marius. The main question for me is: "What is mandatory to implement?" Regarding this question I went through the discussions on the mailing list and I got the following impression: "+" means in favor of removing HTTP Basic Authentication and "-" means against it. "~" indicates that the person is OK with removing it under certain conditions. +Eran +Justin ~Tony (OK with having it optional but does not want to remove it from draft-ietf-oauth-v2) ~Igor (OK with having it optional but does not want to remove it from draft-ietf-oauth-v2) +Marius Please correct me if I have forgotten someone. My reading of the feedback from the response on the list is that we have a decision to make HTTP Basic authentication optional to implement (and therefore the request parameters mandatory to implement). A secondary question is: "Should the **optional** HTTP Basic Authentication functionality be included in the draft-ietf-oauth-v2 specification?" Here are my two questions: 1) Do you insist on having the HTTP Basic authentication documented in draft-ietf-oauth-v2? PLEASE NOTE: Having functionality in a separate document does not mean that it will take longer to complete nor that it is less important. It is purely a document management question! 2) If your answer to question (1) is "NO" then: Would you be willing to co-author a document on this functionality? Since the response so far does not give me a rough consensus I would like to get your feedback. Deadline for response: Feb, 10th 2011 Ciao Hannes From eran@hueniverse.com Thu Feb 3 00:31:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F523A6897 for ; Thu, 3 Feb 2011 00:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbERRCb2fEIZ for ; Thu, 3 Feb 2011 00:31:01 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4BC123A68AD for ; Thu, 3 Feb 2011 00:31:01 -0800 (PST) Received: (qmail 1049 invoked from network); 3 Feb 2011 08:34:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 08:34:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Feb 2011 01:34:21 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 3 Feb 2011 01:34:14 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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_90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:31:07 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After a long bac= k-and-forth, I think it is time to present a few options and have people ex= press their preferences.

 

These are the options mentioned so far and their= +/-:

 

1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)<= /o:p>

 

Eac= h token type gets its own name (which does not include the word ‘oaut= h’ in it), as well as a matching HTTP authentication scheme if a new = one is being defined.

 <= /p>

Benefits:

&= nbsp;

- works cleanly with the HTTP authentic= ation framework by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth au= thorization flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving any a pref= erred treatment.

- built-in discovery us= ing 401 challenge header for which schemes are supported (with their respec= tive information).

 

=

Downsides:

&nb= sp;

- potential creation of many new HTTP aut= hentication schemes which has been stable for a long time.

 

2. Single OAut= h2 scheme with sub-schemes

 

Define a single authentication scheme for all = token types with some attribute used to detect which scheme is actually bei= ng used.

 

Benefits:

 =

- single scheme, reuse of the 1.0 pattern.

 

Downs= ides:

 

- requires a new registry for authentication header parameters.

- schemes are not easily reusable outside O= Auth.

- existing frameworks usually swit= ch on scheme name, not on sub scheme, which will cause difficulty in some d= eployments.

- potential to produce a ver= y complicated scheme once many sub schemes are added.

- requires its own discovery method for which schemes are sup= ported.

 

3. Name prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the pro= tocol a bit easier to newbies since it will look all inclusive (authorizati= on and authentication).

 

Downsides:

 

- makes reuse outside OAuth awkward = without any technical benefit.

&nbs= p;

4. OAuth2 for bearer, MAC for mac

 

Name t= he bearer token ‘OAuth2’ and everything else gets a different n= ame (with or without OAuth in it).

=  

Benefits:

 

- Matches current draft.

 

Downsides:

 

- Elevates bearer token to the preferred token type, instead = of promoting comparison of the various token types available.

- Creates a very odd usage where the authorization se= rver issues an access token of type ‘OAuth2’ which is non-descr= iptive and very confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorizatio= n in an authentication flow, continuing the confusion about what OAuth is (= an authorization protocol).

 <= /o:p>

---

&= nbsp;

Please reply with your preference by 2/= 10. As always, please provide feedback on the options and analysis.

 

EHL

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Feb 3 00:36:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F5D3A68A4 for ; Thu, 3 Feb 2011 00:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTNrcQpl0lT1 for ; Thu, 3 Feb 2011 00:36:36 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 818863A68A3 for ; Thu, 3 Feb 2011 00:36:36 -0800 (PST) Received: (qmail 6489 invoked from network); 3 Feb 2011 08:39:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 08:39:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Feb 2011 01:39:55 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , "oauth@ietf.org" Date: Thu, 3 Feb 2011 01:39:48 -0700 Thread-Topic: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' Thread-Index: AcvDeqYC5RA4U+1xSP6q8KpLWBltXQAAwR3g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4A645A.4060901@gmx.net> In-Reply-To: <4D4A645A.4060901@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 Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 08:36:37 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:16 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for > Client Credentials' >=20 > Hi all, >=20 > Eran suggested to remove the HTTP Basic Authentication functionality > from the specification in his mail from last month: > http://www.ietf.org/mail-archive/web/oauth/current/msg05028.html >=20 > Essentially, there are two ways to accomplish the same functionality, > namely (1) Request parameters and (2) HTTP Basic authentication. >=20 > Eran's initial discussion trigger very quickly evolved a discussion > about the removal of 'credential body parameters': > http://www.ietf.org/mail-archive/web/oauth/current/msg05035.html > This was, however, not supported by Justin, Eran, and Marius. >=20 > The main question for me is: "What is mandatory to implement?" Nothing. The authorization server can support whatever client authenticatio= n methods it deems appropriate. *IF* client password credentials are suppor= ted, then the spec offers one way to provide them using parameters. The re= ason why this is not that important is that there is no real interop as it = currently stands because the process of obtaining these client credentials = is out of scope. EHL =20 > Regarding this question I went through the discussions on the mailing > list and I got the following impression: > "+" means in favor of removing HTTP Basic Authentication and > "-" means against it. > "~" indicates that the person is OK with removing it under certain > conditions. >=20 > +Eran > +Justin > ~Tony (OK with having it optional but does not want to remove it from > draft-ietf-oauth-v2) > ~Igor (OK with having it optional but does not want to remove it from > draft-ietf-oauth-v2) > +Marius >=20 > Please correct me if I have forgotten someone. >=20 > My reading of the feedback from the response on the list is that we have > a decision to make HTTP Basic authentication optional to implement (and > therefore the request parameters mandatory to implement). >=20 > A secondary question is: "Should the **optional** HTTP Basic > Authentication functionality be included in the draft-ietf-oauth-v2 > specification?" >=20 > Here are my two questions: >=20 > 1) Do you insist on having the HTTP Basic authentication documented in > draft-ietf-oauth-v2? >=20 > PLEASE NOTE: Having functionality in a separate document does not mean > that it will take longer to complete nor that it is less important. It > is purely a document management question! >=20 > 2) If your answer to question (1) is "NO" then: > Would you be willing to co-author a document on this functionality? >=20 > Since the response so far does not give me a rough consensus I would > like to get your feedback. >=20 > Deadline for response: Feb, 10th 2011 >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Thu Feb 3 02:49:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16D13A68C6 for ; Thu, 3 Feb 2011 02:49:01 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPw6vF7tI3eg for ; Thu, 3 Feb 2011 02:49:01 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9FDD73A68F0 for ; Thu, 3 Feb 2011 02:49:00 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 10:52:21 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp049) with SMTP; 03 Feb 2011 11:52:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18QxQJJyB0QYUO66pdvuD9aOuzvseuMOF0opRYaBg eDHZIGr4CC26x0 Message-ID: <4D4A88D0.9050409@gmx.net> Date: Thu, 03 Feb 2011 12:52:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] JSON Cryptographic Syntax and Processing: BOF Status and Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 10:49:02 -0000 Hi all, as mentioned earlier I have requested a BOF about the JSON signature topic and the IESG discussed the various BOF proposals this Tuesday. FYI, here are all the BOF proposals: http://trac.tools.ietf.org/bof/trac/ The BOF was not approved because the IESG felt we need more time for preparation. That's not a problem. We will discuss the topic in the OAuth working group meeting, and the security area director, Sean Turner, will create a separate mailing list to involve a larger audience. So, you might ask yourself what is the big issue here. Well. In some sense, the main question that seems to be there is why aren't we using CMS to protect JSON payloads (instead of developing our own signature mechanisms). I believe that this is a fair question to ask why existing and deployed functionality hasn't been used. To some extend this question relates to the overall question of what cryptographic functionality is available with browsers, what are the usage scenarios (e.g. does JavaScript need to be used to compute a signature over the JSON token, what functionality can reside in a browser, etc.). These types of topics will be raised and we should discuss them on the mailing list, once it is created (which should happen today according to Sean). Ciao Hannes From hannes.tschofenig@nsn.com Thu Feb 3 04:59:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278643A695C for ; Thu, 3 Feb 2011 04:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.662 X-Spam-Level: X-Spam-Status: No, score=-104.662 tagged_above=-999 required=5 tests=[AWL=1.937, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKVk4FgPYNr9 for ; Thu, 3 Feb 2011 04:59:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 275393A68F8 for ; Thu, 3 Feb 2011 04:59:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p13D2srl018854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Feb 2011 14:02:54 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p13D2nCO024625; Thu, 3 Feb 2011 14:02:54 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 14:02:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 15:02:44 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4503BE3204@FIESEXC015.nsn-intra.net> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' thread-index: AcvDeqYC5RA4U+1xSP6q8KpLWBltXQAAwR3gAAkWXoA= References: <4D4A645A.4060901@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Eran Hammer-Lahav" , "Hannes Tschofenig" , X-OriginalArrivalTime: 03 Feb 2011 13:02:51.0385 (UTC) FILETIME=[A9F70E90:01CBC3A2] Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 12:59:37 -0000 > > The main question for me is: "What is mandatory to implement?" >=20 > Nothing. The authorization server can support whatever client=20 > authentication methods it deems appropriate. *IF* client=20 > password credentials are supported, then the spec offers one=20 > way to provide them using parameters. The reason why this is=20 > not that important is that there is no real interop as it=20 > currently stands because the process of obtaining these=20 > client credentials is out of scope. In order to deploy Oauth one has to consider a number of components. Today, many of them require proprietary mechanisms and steps executed out-of-band.=20 My hope, however, is that we (as part of this standardization work) improve interoperability and thereby reduce the number of proprietary components.=20 This topic seems to be one where standardization could indeed be helpful.=20 Wouldn't you agree?=20 Ciao Hannes From eran@hueniverse.com Thu Feb 3 06:57:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E937B3A6980 for ; Thu, 3 Feb 2011 06:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdmdZIgegEcj for ; Thu, 3 Feb 2011 06:57:14 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0ADBE3A69A0 for ; Thu, 3 Feb 2011 06:57:14 -0800 (PST) Received: (qmail 15945 invoked from network); 3 Feb 2011 15:00:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 15:00:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Feb 2011 08:00:30 -0700 From: Eran Hammer-Lahav To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Hannes Tschofenig , "oauth@ietf.org" Date: Thu, 3 Feb 2011 08:00:22 -0700 Thread-Topic: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' Thread-Index: AcvDeqYC5RA4U+1xSP6q8KpLWBltXQAAwR3gAAkWXoAABDxsUA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3324@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4A645A.4060901@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4503BE3204@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4503BE3204@FIESEXC015.nsn-intra.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: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:57:15 -0000 Yes. I think automatic registration and other mechanisms for discovery and = obtaining credentials are going to be extremely useful. We're just not ther= e yet. EHL > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, February 03, 2011 5:03 AM > To: Eran Hammer-Lahav; Hannes Tschofenig; oauth@ietf.org > Subject: RE: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication > for Client Credentials' >=20 > > > The main question for me is: "What is mandatory to implement?" > > > > Nothing. The authorization server can support whatever client > > authentication methods it deems appropriate. *IF* client password > > credentials are supported, then the spec offers one way to provide > > them using parameters. The reason why this is not that important is > > that there is no real interop as it currently stands because the > > process of obtaining these client credentials is out of scope. >=20 > In order to deploy Oauth one has to consider a number of components. > Today, many of them require proprietary mechanisms and steps executed > out-of-band. >=20 > My hope, however, is that we (as part of this standardization work) impro= ve > interoperability and thereby reduce the number of proprietary components. >=20 > This topic seems to be one where standardization could indeed be helpful. >=20 > Wouldn't you agree? >=20 > Ciao > Hannes >=20 From tonynad@microsoft.com Thu Feb 3 07:16:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAD53A6969 for ; Thu, 3 Feb 2011 07:16:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miST76gwhENE for ; Thu, 3 Feb 2011 07:16:01 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 71DAF3A6962 for ; Thu, 3 Feb 2011 07:16:01 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Feb 2011 07:19:24 -0800 Received: from TX2EHSOBE004.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 3 Feb 2011 07:19:23 -0800 Received: from mail98-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.8; Thu, 3 Feb 2011 15:19:22 +0000 Received: from mail98-tx2 (localhost.localdomain [127.0.0.1]) by mail98-tx2-R.bigfish.com (Postfix) with ESMTP id DB62C14D04B4 for ; Thu, 3 Feb 2011 15:19:22 +0000 (UTC) X-SpamScore: -43 X-BigFish: PS-43(zz542N14ffO9371PzzdafM1202h1082kzz8275dh1033ILz31h2a8h668h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail98-tx2 (localhost.localdomain [127.0.0.1]) by mail98-tx2 (MessageSwitch) id 1296746362718899_15459; Thu, 3 Feb 2011 15:19:22 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.245]) by mail98-tx2.bigfish.com (Postfix) with ESMTP id A1D46163005A; Thu, 3 Feb 2011 15:19:22 +0000 (UTC) Received: from CH1PRD0302HT003.namprd03.prod.outlook.com (207.46.198.24) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 3 Feb 2011 15:19:21 +0000 Received: from CH1PRD0302MB103.namprd03.prod.outlook.com ([169.254.6.122]) by CH1PRD0302HT003.namprd03.prod.outlook.com ([10.28.28.161]) with mapi id 14.01.0225.023; Thu, 3 Feb 2011 15:19:20 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Thread-Index: AQHLw3oc0qVAQUm0UESqQ1k/84396ZPv4/Rw Date: Thu, 3 Feb 2011 15:19:19 +0000 Message-ID: References: <4D4A632A.6070600@gmx.net> In-Reply-To: <4D4A632A.6070600@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.111.76.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$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: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:16:02 -0000 There have been several of us that have objected and several of that have i= mplemented this feature, it's late in the cycle to remove, so I raise the o= bjection. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, February 03, 2011 12:11 AM To: oauth@ietf.org Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Hi all, Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme functional= ity from the specification in his mail from last month: http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html The discussion got off topic pretty quickly with the discussion about OAuth= usage for SASL. I couldn't see a strong objection but rather clarifying di= scussions. Please correct me if I misread your feedback on this issue. So, my current impression is that there is no objection and we confirm the = design decision to remove the 'OAuth2' HTTP Authentication Scheme from draf= t-ietf-oauth-v2. Deadline for feedback: Feb, 10th 2011 Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Thu Feb 3 07:27:28 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8BD3A6994 for ; Thu, 3 Feb 2011 07:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niOqQdD9hAgb for ; Thu, 3 Feb 2011 07:27:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id F0D283A6984 for ; Thu, 3 Feb 2011 07:27:26 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 15:30:48 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp034) with SMTP; 03 Feb 2011 16:30:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/i1glWJ3bi7sWda4kPfQ8HnJDZVq9rnQTULpK1qQ cFTXjX3Or5rvvm Message-ID: <4D4ACA27.4000308@gmx.net> Date: Thu, 03 Feb 2011 17:30:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Anthony Nadalin References: <4D4A632A.6070600@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:27:28 -0000 Hey Tony, thanks for the feedback. I might have missed the objection. Could you be more specific about who did not want this functionality to be removed? Ciao Hannes On 2/3/2011 5:19 PM, Anthony Nadalin wrote: > There have been several of us that have objected and several of that have implemented this feature, it's late in the cycle to remove, so I raise the objection. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:11 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' > > Hi all, > > Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme functionality from the specification in his mail from last month: > http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html > > The discussion got off topic pretty quickly with the discussion about OAuth usage for SASL. I couldn't see a strong objection but rather clarifying discussions. > > Please correct me if I misread your feedback on this issue. > > So, my current impression is that there is no objection and we confirm the design decision to remove the 'OAuth2' HTTP Authentication Scheme from draft-ietf-oauth-v2. > > Deadline for feedback: Feb, 10th 2011 > > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > From hannes.tschofenig@gmx.net Thu Feb 3 07:37:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD923A69CA for ; Thu, 3 Feb 2011 07:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP7BgIMUWwrO for ; Thu, 3 Feb 2011 07:37:16 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6C1EC3A69DA for ; Thu, 3 Feb 2011 07:37:16 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 15:40:38 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp029) with SMTP; 03 Feb 2011 16:40:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+r0JRGTV+rELZlneANerPaQZ5+tMKJ5MpDBzfrwM +obJbvc+fkxwIF Message-ID: <4D4ACC75.9030209@gmx.net> Date: Thu, 03 Feb 2011 17:40:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4D4A645A.4060901@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4503BE3204@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3324@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3324@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:37:17 -0000 On 2/3/2011 5:00 PM, Eran Hammer-Lahav wrote: > Yes. I think automatic registration and other mechanisms for discovery and obtaining credentials are going to be extremely useful. We're just not there yet. This issue does not only need to be related to automatic registration. With respect to standardizing certain functionality you can decide that a) a certain feature (call it an interface) is out-of-scope (it may be standardized later) You describe them as out-of-scope. Done. b) you want to describe it at a level that ensures interoperability. Since OAuth is more a framework than just a single protocol (or a small number of protocol extensions) you do not need to even envision standardization of every part of it. When you go for (b) then you better pick one way to offer a certain feature unless there is a very good reason to have more than one. Such reason may exist in case of cryptographic algorithms (which may get broken over time), etc. So, do I get the impression that you are essentially saying that - you would rather go for (a) and postpone the standardization of the entire client authentication, - you want to go for (b) but you do not want to have something in the base specification, or - you would go for (b) but you just want to restrict the options down to a smaller set? Ciao Hannes From Michael.Jones@microsoft.com Thu Feb 3 08:02:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60263A67F7 for ; Thu, 3 Feb 2011 08:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Msm2f-5zvsHr for ; Thu, 3 Feb 2011 08:02:47 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 205BE3A69A1 for ; Thu, 3 Feb 2011 08:02:46 -0800 (PST) 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; Thu, 3 Feb 2011 08:06:09 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 08:06:08 -0800 From: Mike Jones To: Hannes Tschofenig , Anthony Nadalin Thread-Topic: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Thread-Index: AQHLw7d8RYfIUgq/Y0SknDklqqt/IpPv8JGQ Date: Thu, 3 Feb 2011 16:06:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394324721274@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4D4A632A.6070600@gmx.net> <4D4ACA27.4000308@gmx.net> In-Reply-To: <4D4ACA27.4000308@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394324721274TK5EX14MBXC201r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:02:53 -0000 --_000_4E1F6AAD24975D4BA5B168042967394324721274TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's one objection, per my note sent on January 18th: 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, February 03, 2011 7:31 AM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me' Hey Tony, thanks for the feedback. I might have missed the objection. Could you be mo= re specific about who did not want this functionality to be removed? Ciao Hannes On 2/3/2011 5:19 PM, Anthony Nadalin wrote: > There have been several of us that have objected and several of that have= implemented this feature, it's late in the cycle to remove, so I raise the= objection. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:11 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme= ' > > Hi all, > > Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme function= ality from the specification in his mail from last month: > http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html > > The discussion got off topic pretty quickly with the discussion about OAu= th usage for SASL. I couldn't see a strong objection but rather clarifying = discussions. > > Please correct me if I misread your feedback on this issue. > > So, my current impression is that there is no objection and we confirm th= e design decision to remove the 'OAuth2' HTTP Authentication Scheme from dr= aft-ietf-oauth-v2. > > Deadline for feedback: Feb, 10th 2011 > > Ciao > Hannes > _______________________________________________ > 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 --_000_4E1F6AAD24975D4BA5B168042967394324721274TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s one objection, per my note sent on J= anuary 18th:

 

'OAuth2' HTTP Authentication Scheme:  Si= mply put, dropping this seems like a huge step away from interoperability.&= nbsp; As one data point, Microsoft implements this in our WIF OAuth2 protec= ted resource code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP imple= mentations need this functionality to migrate to OAuth2.   For al= l these reasons, we support retaining this functionality in OAuth2.

 

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

 

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig
Sent: Thursday, February 03, 2011 7:31 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me'

 

Hey Tony,

 

thanks for the feedback. I might have missed the = objection. Could you be more specific about who did not want this functiona= lity to be removed?

 

Ciao

Hannes

 

On 2/3/2011 5:19 PM, Anthony Nadalin wrote:<= /o:p>

> There have been several of us that have obje= cted and several of that have implemented this feature, it's late in the cy= cle to remove, so I raise the objection.

> 

> -----Original Message-----

> From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf

> Of Hannes Tschofenig

> Sent: Thursday, February 03, 2011 12:11 AM

> To: oauth@ietf.org

> Subject: [OAUTH-WG] Hum about 'Removal: OAut= h2 HTTP Authentication Scheme'

> 

> Hi all,

> 

> Eran suggested to remove the 'OAuth2' HTTP A= uthentication Scheme functionality from the specification in his mail from = last month:

> http://www.ietf.org/m= ail-archive/web/oauth/current/msg05026.html

> 

> The discussion got off topic pretty quickly = with the discussion about OAuth usage for SASL. I couldn't see a strong obj= ection but rather clarifying discussions.

> 

> Please correct me if I misread your feedback= on this issue.

> 

> So, my current impression is that there is n= o objection and we confirm the design decision to remove the 'OAuth2' HTTP = Authentication Scheme from draft-ietf-oauth-v2.

> 

> Deadline for feedback: Feb, 10th 2011

> 

> Ciao

> Hannes

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/oauth

> 

> 

> 

> 

> 

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org=

https://www.ie= tf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B168042967394324721274TK5EX14MBXC201r_-- From hannes.tschofenig@gmx.net Thu Feb 3 08:16:11 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F133A69DA for ; Thu, 3 Feb 2011 08:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+yjsNUNT82q for ; Thu, 3 Feb 2011 08:16:10 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 4C6363A69B4 for ; Thu, 3 Feb 2011 08:16:10 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 16:19:32 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp007) with SMTP; 03 Feb 2011 17:19:32 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Jw44mg9kJi0g5zcI2UghCs8/q9kgFEaWdkisEBq 3ZjSif9jCea8m6 Message-ID: <4D4AD58E.9090407@gmx.net> Date: Thu, 03 Feb 2011 18:19:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:16:11 -0000 Hi all, while we are hopefully coming to an end with the main specification (and the two other WG items) I need to put text for re-chartering together. The entire process typically takes a little while because * I need your feedback (hence this mail) of what you guys want to work on * I have to draft a charter text (and the group needs to be happy with it) * the IESG (who receives the charter text) also needs to agree with it * finally the documents need to be submitted as working group items and progressed in the group. While a few of you have responded already to an earlier query (see http://www.ietf.org/mail-archive/web/oauth/current/msg04352.html) there wasn't enough feedback. Again, here are the documents that have been put forward. When you express interest for a specific item please also provide a bit of additional information. For example, it would be good to know whether you are willing to do reviews, whether you even have time to co-author the specification, whether you want to implement or deploy a specific mechanism, etc. It is quite simply: if there is no interest in the work (other than from the authors) then it does not make sense to turn it into a working group item. If there is nobody who wants to review or edit the document then we cannot pick it up either. Also note that these document are only used as a *starting point* and they are very likely going to change as we work on them. Feel free to express your thoughts about the content as well. Would be nice to know whether you think that the document needs to be, for example, enhanced in a specific direction. Long introduction - here are the documents: A) Simple Web Discovery (SWD) http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt B) HTTP Authentication: MAC Authentication http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ C) Token Revocation http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01 D) OAuth 2.0 Device Profile http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 E) OAuth 2.0 User Experience Extension http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 F) Request by Reference ver.1.0 for OAuth 2.0 http://tools.ietf.org/html/draft-sakimura-oauth-requrl G) OAuth Dynamic Client Registration Protocol http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 H) OAuth Use Cases http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases I) OAuth Client Instance Extension http://datatracker.ietf.org/doc/draft-richer-oauth-instance/ J) XML Encoding for OAuth 2 http://datatracker.ietf.org/doc/draft-richer-oauth-xml/ K) OAuth 2.0 support for the Kerberos V5 Authentication Protocol http://datatracker.ietf.org/doc/draft-hardjono-oauth-kerberos Please let me know if I have forgotten something. I also hope that Torsten is able to submit a security document soon! Ciao Hannes PS: You may notice that I haven't placed http://tools.ietf.org/html/draft-jones-json-web-token-01 on the list yet since I believe we will get push-back from the IESG on that item at the moment. From Michael.Jones@microsoft.com Thu Feb 3 08:16:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F363A6A0D for ; Thu, 3 Feb 2011 08:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6-MRK5S49tt for ; Thu, 3 Feb 2011 08:16:14 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id ECB6A3A6A11 for ; Thu, 3 Feb 2011 08:16:13 -0800 (PST) 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; Thu, 3 Feb 2011 08:19:36 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 08:19:36 -0800 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwAQKdLw Date: Thu, 3 Feb 2011 16:19:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943247212F8TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:16:20 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943247212F8TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This seems like an overly complex characterization - especially because you= 're including hypothetical choices such as schemes and sub-schemes that don= 't provide substantial benefits over the straightforward schemes we have no= w and would complicate implementations and people's understanding of the sp= ec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I wo= uld personally vote no to introducing any further any breaking changes. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_4E1F6AAD24975D4BA5B1680429673943247212F8TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This seems like an ove= rly complex characterization – especially because you’re includ= ing hypothetical choices such as schemes and sub-schemes that don’t p= rovide substantial benefits over the straightforward schemes we have now and would complicate implementations and people’s unders= tanding of the spec, and that don’t have substantial support within t= he working group.

 

Given that we’re= trying to bring the specs to working group last call, I would personally v= ote no to introducing any further any breaking changes.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/1= 0)

 

After a long back-and-forth, I think it is time to p= resent a few options and have people express their preferences.<= /p>

 

These are the options mentioned so far and their = 3;/-:

 

1. Descriptive, non-OAuth-specific scheme names (Bea= rer, MAC)

 

Each token type gets its own name (which does not in= clude the word ‘oauth’ in it), as well as a matching HTTP authe= ntication scheme if a new one is being defined.

 

Benefits:

 

- works cleanly with the HTTP authentication framewo= rk by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorizatio= n flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving a= ny a preferred treatment.

- built-in discovery using 401 challenge header for = which schemes are supported (with their respective information).=

 

Downsides:

 

- potential creation of many new HTTP authentication= schemes which has been stable for a long time.

 

2. Single OAuth2 scheme with sub-schemes<= /p>

 

Define a single authentication scheme for all token = types with some attribute used to detect which scheme is actually being use= d.

 

Benefits:

 

- single scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- requires a new registry for authentication header = parameters.

- schemes are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme name,= not on sub scheme, which will cause difficulty in some deployments.

- potential to produce a very complicated scheme onc= e many sub schemes are added.

- requires its own discovery method for which scheme= s are supported.

 

3. Name prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the protocol a bit easier to newbies since i= t will look all inclusive (authorization and authentication).

 

Downsides:

 

- makes reuse outside OAuth awkward without any tech= nical benefit.

 

4. OAuth2 for bearer, MAC for mac

 

Name the bearer token ‘OAuth2’ and every= thing else gets a different name (with or without OAuth in it).<= /p>

 

Benefits:

 

- Matches current draft.

 

Downsides:

 

- Elevates bearer token to the preferred token type,= instead of promoting comparison of the various token types available.=

- Creates a very odd usage where the authorization s= erver issues an access token of type ‘OAuth2’ which is non-desc= riptive and very confusing (since there are other token types).<= /p>

- Uses the name OAuth2 which stands for authorizatio= n in an authentication flow, continuing the confusion about what OAuth is (= an authorization protocol).

 

---

 

Please reply with your preference by 2/10. As always= , please provide feedback on the options and analysis.

 

EHL

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943247212F8TK5EX14MBXC201r_-- From wmills@yahoo-inc.com Thu Feb 3 08:16:35 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB083A6A1B for ; Thu, 3 Feb 2011 08:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.372 X-Spam-Level: X-Spam-Status: No, score=-17.372 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzB9qmRZN-+x for ; Thu, 3 Feb 2011 08:16:29 -0800 (PST) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id A552C3A6A11 for ; Thu, 3 Feb 2011 08:16:29 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p13GJOSr005264 for ; Thu, 3 Feb 2011 08:19:24 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Thu, 3 Feb 2011 08:19:23 -0800 From: William Mills To: "oauth@ietf.org" Date: Thu, 3 Feb 2011 08:19:19 -0800 Thread-Topic: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Thread-Index: AQHLw7d8RYfIUgq/Y0SknDklqqt/IpPv8JGQgAAD4HA= Message-ID: References: <4D4A632A.6070600@gmx.net> <4D4ACA27.4000308@gmx.net> <4E1F6AAD24975D4BA5B168042967394324721274@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394324721274@TK5EX14MBXC201.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_FFDFD7371D517847AD71FBB08F9A31563849221635SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:16:35 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563849221635SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps it can be left in for compatibility purposes but declared to be dep= recated for new implementations? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Thursday, February 03, 2011 8:06 AM To: Hannes Tschofenig; Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me' Here's one objection, per my note sent on January 18th: 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, February 03, 2011 7:31 AM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me' Hey Tony, thanks for the feedback. I might have missed the objection. Could you be mo= re specific about who did not want this functionality to be removed? Ciao Hannes On 2/3/2011 5:19 PM, Anthony Nadalin wrote: > There have been several of us that have objected and several of that have= implemented this feature, it's late in the cycle to remove, so I raise the= objection. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:11 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme= ' > > Hi all, > > Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme function= ality from the specification in his mail from last month: > http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html > > The discussion got off topic pretty quickly with the discussion about OAu= th usage for SASL. I couldn't see a strong objection but rather clarifying = discussions. > > Please correct me if I misread your feedback on this issue. > > So, my current impression is that there is no objection and we confirm th= e design decision to remove the 'OAuth2' HTTP Authentication Scheme from dr= aft-ietf-oauth-v2. > > Deadline for feedback: Feb, 10th 2011 > > Ciao > Hannes > _______________________________________________ > 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 --_000_FFDFD7371D517847AD71FBB08F9A31563849221635SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps it can be left i= n for compatibility purposes but declared to be deprecated for new implementation= s?

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Thursday, February 03, 2011 8:06 AM
To: Hannes Tschofenig; Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authenticati= on Scheme'

 

Here’s one objection, per my note sent on Jan= uary 18th:

 

'OAuth2' HTTP Authentication Scheme:  Simp= ly put, dropping this seems like a huge step away from interoperability. = As one data point, Microsoft implements this in our WIF OAuth2 protected resou= rce code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP implementations need this functionality= to migrate to OAuth2.   For all these reasons, we support retaining = this functionality in OAuth2.

 

        &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike

 

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 03, 2011 7:31 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me'

 

Hey Tony,

 

thanks for the feedback. I might have missed the objection. Could you be more specific about who did not want this functiona= lity to be removed?

 

Ciao

Hannes

 

On 2/3/2011 5:19 PM, Anthony Nadalin wrote:

> There have been several of us that have object= ed and several of that have implemented this feature, it's late in the cycle to remove, so I raise the objection.

> 

> -----Original Message-----

> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf

> Of Hannes Tschofenig

> Sent: Thursday, February 03, 2011 12:11 AM

> To: oauth@ietf.org

> Subject: [OAUTH-WG] Hum about 'Removal: OAuth2= HTTP Authentication Scheme'

> 

> Hi all,

> 

> Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme functionality from the specification in his mail from last month:

> <= span style=3D'color:windowtext;text-decoration:none'>http://www.ietf.org/mail-ar= chive/web/oauth/current/msg05026.html

> 

> The discussion got off topic pretty quickly wi= th the discussion about OAuth usage for SASL. I couldn't see a strong objection bu= t rather clarifying discussions.

> 

> Please correct me if I misread your feedback o= n this issue.

> 

> So, my current impression is that there is no objection and we confirm the design decision to remove the 'OAuth2' HTTP Authentication Scheme from draft-ietf-oauth-v2.

> 

> Deadline for feedback: Feb, 10th 2011

> 

> Ciao

> Hannes

> ______________________________________________= _

> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailma= n/listinfo/oauth

> 

> 

> 

> 

> 

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailma= n/listinfo/oauth

 

--_000_FFDFD7371D517847AD71FBB08F9A31563849221635SP2EX07VS06ds_-- From wmills@yahoo-inc.com Thu Feb 3 08:39:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541D73A6A19 for ; Thu, 3 Feb 2011 08:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.368 X-Spam-Level: X-Spam-Status: No, score=-17.368 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIfMyowOKrft for ; Thu, 3 Feb 2011 08:39:17 -0800 (PST) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 2DEA13A6985 for ; Thu, 3 Feb 2011 08:39:17 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p13GgG77013356 for ; Thu, 3 Feb 2011 08:42:16 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Thu, 3 Feb 2011 08:42:16 -0800 From: William Mills To: OAuth WG Date: Thu, 3 Feb 2011 08:42:11 -0800 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwARLS/A Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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_FFDFD7371D517847AD71FBB08F9A31563849221643SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:39:23 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563849221643SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm coming around to #1, I'll put my vote there. I do agree that we have= usage out there of the OAuth2 scheme and we need not to break that, how do= we solve that? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_FFDFD7371D517847AD71FBB08F9A31563849221643SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m coming around = to #1, I’ll put my vote there.    I do agree that we have usage out ther= e of the OAuth2 scheme and we need not to break that, how do we solve that?

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/1= 0)

 

After a long back-and-forth, I think it is time to pre= sent a few options and have people express their preferences.

 

These are the options mentioned so far and their +/-:<= o:p>

 

1. Descriptive, non-OAuth-specific scheme names (Beare= r, MAC)

 

Each token type gets its own name (which does not incl= ude the word ‘oauth’ in it), as well as a matching HTTP authenticat= ion scheme if a new one is being defined.

 

Benefits:

 

- works cleanly with the HTTP authentication framework= by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorization = flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving any= a preferred treatment.

- built-in discovery using 401 challenge header for wh= ich schemes are supported (with their respective information).

 

Downsides:

 

- potential creation of many new HTTP authentication s= chemes which has been stable for a long time.

 

2. Single OAuth2 scheme with sub-schemes

 

Define a single authentication scheme for all token ty= pes with some attribute used to detect which scheme is actually being used.

 

Benefits:

 

- single scheme, reuse of the 1.0 pattern.<= /p>

 

Downsides:

 

- requires a new registry for authentication header parameters.

- schemes are not easily reusable outside OAuth.<= /o:p>

- existing frameworks usually switch on scheme name, n= ot on sub scheme, which will cause difficulty in some deployments.

- potential to produce a very complicated scheme once = many sub schemes are added.

- requires its own discovery method for which schemes = are supported.

 

3. Name prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the protocol a bit easier to newbies since it = will look all inclusive (authorization and authentication).

 

Downsides:

 

- makes reuse outside OAuth awkward without any techni= cal benefit.

 

4. OAuth2 for bearer, MAC for mac

 

Name the bearer token ‘OAuth2’ and everyth= ing else gets a different name (with or without OAuth in it).

 

Benefits:

 

- Matches current draft.

 

Downsides:

 

- Elevates bearer token to the preferred token type, i= nstead of promoting comparison of the various token types available.

- Creates a very odd usage where the authorization ser= ver issues an access token of type ‘OAuth2’ which is non-descriptiv= e and very confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorization = in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol).

 

---

 

Please reply with your preference by 2/10. As always, = please provide feedback on the options and analysis.

 

EHL

 

 

--_000_FFDFD7371D517847AD71FBB08F9A31563849221643SP2EX07VS06ds_-- From eran@hueniverse.com Thu Feb 3 08:45:27 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A573A69DC for ; Thu, 3 Feb 2011 08:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhnwAQA807-F for ; Thu, 3 Feb 2011 08:45:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5A4B43A69D7 for ; Thu, 3 Feb 2011 08:45:26 -0800 (PST) Received: (qmail 877 invoked from network); 3 Feb 2011 16:48:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 16:48:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Feb 2011 09:48:44 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig Date: Thu, 3 Feb 2011 09:48:36 -0700 Thread-Topic: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' Thread-Index: AcvDuLsmDnTFaXS1RuWfCe9mi7r8eQACFfMg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3378@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4A645A.4060901@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB32BA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4503BE3204@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3324@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D4ACC75.9030209@gmx.net> In-Reply-To: <4D4ACC75.9030209@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: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:45:27 -0000 This is more about pragmatism than proper standards process. A large number of providers today use client password credentials. This is = the common practice in almost every non-enterprise use case (which was the = original driver behind OAuth and is still the lion share of the work and de= ployment). Since this is such an important use case (based on 3 years of ac= tual deployment), it should be specified in the protocol. This gives a simp= le and immediate solution to most providers. However, client password credentials are clearly limited in their security = attributes. It would not be wise to mandate supporting them as they are sim= ply too weak for some cases. In addition, some use cases do not require any= client authentication. The entire client authentication part of the protoc= ol is very much deployment specific at this point in our experience. So the compromise I have been promoting is to only define the most common *= practice* of sending client credentials using parameters (which is industry= -wide and the most well-established among OAuth adopters). Everything else = can and should be defined elsewhere. This tactic allows for longer debate a= nd deployment experience to provide well-thought and well-specified alterna= tive means for client authentication. Note that HTTP Basic authentication was not completely removed, but was sim= ply demoted from normative language to an example of how client password cr= edentials MAY be sent instead of the query parameters. It is a compromise I= believe allows deployment of Basic auth today without creating any burden = when unwanted. So I'm going for a modified (a). EHL > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, February 03, 2011 7:41 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication > for Client Credentials' >=20 > On 2/3/2011 5:00 PM, Eran Hammer-Lahav wrote: > > Yes. I think automatic registration and other mechanisms for discovery = and > obtaining credentials are going to be extremely useful. We're just not th= ere > yet. >=20 > This issue does not only need to be related to automatic registration. >=20 > With respect to standardizing certain functionality you can decide that >=20 > a) a certain feature (call it an interface) is out-of-scope (it may be > standardized later) >=20 > You describe them as out-of-scope. Done. >=20 > b) you want to describe it at a level that ensures interoperability. >=20 > Since OAuth is more a framework than just a single protocol (or a small > number of protocol extensions) you do not need to even envision > standardization of every part of it. >=20 > When you go for (b) then you better pick one way to offer a certain featu= re > unless there is a very good reason to have more than one. Such reason may > exist in case of cryptographic algorithms (which may get broken over time= ), > etc. >=20 > So, do I get the impression that you are essentially saying that > - you would rather go for (a) and postpone the standardization of the ent= ire > client authentication, > - you want to go for (b) but you do not want to have something in the bas= e > specification, or > - you would go for (b) but you just want to restrict the options down to = a > smaller set? >=20 > Ciao > Hannes >=20 From eran@hueniverse.com Thu Feb 3 09:01:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6193A69B3 for ; Thu, 3 Feb 2011 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLMyjJxtp33r for ; Thu, 3 Feb 2011 09:01:13 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F1B153A687D for ; Thu, 3 Feb 2011 09:01:11 -0800 (PST) Received: (qmail 8074 invoked from network); 3 Feb 2011 17:04:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 17:04:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Feb 2011 10:04:14 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , Anthony Nadalin Date: Thu, 3 Feb 2011 10:04:06 -0700 Thread-Topic: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' Thread-Index: AQHLw7d8RYfIUgq/Y0SknDklqqt/IpPv8JGQgAAMrsA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3388@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4A632A.6070600@gmx.net> <4D4ACA27.4000308@gmx.net> <4E1F6AAD24975D4BA5B168042967394324721274@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394324721274@TK5EX14MBXC201.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_90C41DD21FB7C64BB94121FBBC2E723445A8FB3388P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:01:20 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3388P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem with your entire statement below is that it doesn't explain how= all those important goals listed are actually accomplished by this header = as currently defined. Asking again... - Can you please explain how this header helps interoperability? - How does a client use this header to access a protected resource it knows= nothing about? - Will these clients fail if the header was not returned and why? - If the Bearer token scheme name changed from OAuth2, would you still be l= ooking to retain the OAuth2 scheme in addition to another Bearer (WWW-Authe= nticate) scheme? - How do existing WRAP implementations use this header to migrate? My reason for dropping it is based on the fact that the client already know= s a protected resource supports OAuth, as well as all the required informat= ion needed to successfully obtain an access token (and authenticate). I hav= e not seen a client implementation making an unauthenticated request and th= en trying again based on the WWW-Authenticate: OAuth2 challenge. The main r= eason is that being informed that a protected resource support OAuth2 provi= des no help in actually getting a suitable access token (or client credenti= als for that matter). If the OAuth2 scheme is a forward looking framework, it is premature standa= rdization of something we clearly do not understand yet or have consensus o= n. If it is the challenge half of the bearer token proposal (as it currentl= y seem to be), it should be defined there (once we resolve the scheme name = issue). But it is unclear to me what you are proposing this header to repre= sent. And last question: - If a protected resource supports only MAC type tokens, what does a 401 re= sponse look like? Does it include an OAuth2 challenge, a MAC challenge, bot= h, or none? These are the core *technical* questions that MUST be answered if we are to= retain this header definition. This is not about process, stability, exist= ing deployment, or any other non-technical arguments. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Thursday, February 03, 2011 8:06 AM To: Hannes Tschofenig; Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me' Here's one objection, per my note sent on January 18th: 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, February 03, 2011 7:31 AM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Sche= me' Hey Tony, thanks for the feedback. I might have missed the objection. Could you be mo= re specific about who did not want this functionality to be removed? Ciao Hannes On 2/3/2011 5:19 PM, Anthony Nadalin wrote: > There have been several of us that have objected and several of that have= implemented this feature, it's late in the cycle to remove, so I raise the= objection. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:11 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme= ' > > Hi all, > > Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme function= ality from the specification in his mail from last month: > http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html > > The discussion got off topic pretty quickly with the discussion about OAu= th usage for SASL. I couldn't see a strong objection but rather clarifying = discussions. > > Please correct me if I misread your feedback on this issue. > > So, my current impression is that there is no objection and we confirm th= e design decision to remove the 'OAuth2' HTTP Authentication Scheme from dr= aft-ietf-oauth-v2. > > Deadline for feedback: Feb, 10th 2011 > > Ciao > Hannes > _______________________________________________ > 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 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3388P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The problem with your entire statement below is that it doesn= ’t explain how all those important goals listed are actually accompli= shed by this header as currently defined. Asking again…

 

- Can you pl= ease explain how this header helps interoperability?

<= p class=3DMsoNormal>- How does a client use t= his header to access a protected resource it knows nothing about?

- Will these= clients fail if the header was not returned and why?

=

- If the Bearer token sc= heme name changed from OAuth2, would you still be looking to retain the OAu= th2 scheme in addition to another Bearer (WWW-Authenticate) scheme?

- How do e= xisting WRAP implementations use this header to migrate?<= /p>

 

My reason for dro= pping it is based on the fact that the client already knows a protected res= ource supports OAuth, as well as all the required information needed to suc= cessfully obtain an access token (and authenticate). I have not seen a clie= nt implementation making an unauthenticated request and then trying again b= ased on the WWW-Authenticate: OAuth2 challenge. The main reason is that bei= ng informed that a protected resource support OAuth2 provides no help in ac= tually getting a suitable access token (or client credentials for that matt= er).

 

If the OAuth2 scheme is a forward looking framework, it is premature = standardization of something we clearly do not understand yet or have conse= nsus on. If it is the challenge half of the bearer token proposal (as it cu= rrently seem to be), it should be defined there (once we resolve the scheme= name issue). But it is unclear to me what you are proposing this header to= represent.

 

And last question:

<= span style=3D'color:#1F497D'> 

- If a protected resource supports only MA= C type tokens, what does a 401 response look like? Does it include an OAuth= 2 challenge, a MAC challenge, both, or none?

 

These are the core *techn= ical* questions that MUST be answered if we are to retain this header d= efinition. This is not about process, stability, existing deployment, or an= y other non-technical arguments.

=  

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, Fe= bruary 03, 2011 8:06 AM
To: Hannes Tschofenig; Anthony NadalinCc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Hum about 'Rem= oval: OAuth2 HTTP Authentication Scheme'

<= p class=3DMsoNormal> 

Here’= ;s one objection, per my note sent on January 18th:

 

= 'OAuth2' HTTP Authentication Scheme:  Simply put, dropping this se= ems like a huge step away from interoperability.  As one data point, M= icrosoft implements this in our WIF OAuth2 protected resource code.  A= ll up, clients need a way to authenticate to the protected resource.  = Also, existing WRAP implementations need this functionality to migrate to O= Auth2.   For all these reasons, we support retaining this functio= nality in OAuth2.

 

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

 

-----Original Message-----
From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sen= t: Thursday, February 03, 2011 7:31 AM
To: Anthony Nadalin
Cc: oauth@= ietf.org
Subject: Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authent= ication Scheme'

 

=

Hey Tony,

 

thanks for the feedback. I might = have missed the objection. Could you be more specific about who did not wan= t this functionality to be removed?

<= o:p> 

Ciao

Hannes

 <= /p>

On 2/3/2011 5:19 PM, Anthony Nadalin wrote:=

> There have been several of us that h= ave objected and several of that have implemented this feature, it's late i= n the cycle to remove, so I raise the objection.

> 

> -----Orig= inal Message-----

> From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf

> Of Hannes Tschofenig

> Sent: Thursday, February 03, 2011 12:11 AM

> To: oauth@ietf.org

> Subject: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentica= tion Scheme'

> 

> Hi all,

> 

> Eran suggested to re= move the 'OAuth2' HTTP Authentication Scheme functionality from the specifi= cation in his mail from last month:

&= gt; http://www.ietf= .org/mail-archive/web/oauth/current/msg05026.html

=

> 

&g= t; The discussion got off topic pretty quickly with the discussion about OA= uth usage for SASL. I couldn't see a strong objection but rather clarifying= discussions.

> 

> Please correct me if I misread your feedback= on this issue.

> =

> So, my current impression is that there is= no objection and we confirm the design decision to remove the 'OAuth2' HTT= P Authentication Scheme from draft-ietf-oauth-v2.

> 

> Deadline= for feedback: Feb, 10th 2011

> 

> Ciao

> Hannes

> ____= ___________________________________________

> OAuth mailing list

> <= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org

> https://www.ietf.org/mailman/lis= tinfo/oauth

> = ;

> 

> 

> 

> 

 

________________________= _______________________

OAuth mailing= list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3388P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Feb 3 09:10:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59A13A69D7 for ; Thu, 3 Feb 2011 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uOA-KwTPBW6 for ; Thu, 3 Feb 2011 09:10:20 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3B3533A687D for ; Thu, 3 Feb 2011 09:10:20 -0800 (PST) Received: (qmail 8275 invoked from network); 3 Feb 2011 17:13:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 17:13:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Feb 2011 10:13:39 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Thu, 3 Feb 2011 10:13:31 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwAQKdLwAAHe/CA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.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_90C41DD21FB7C64BB94121FBBC2E723445A8FB3392P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:10:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3392P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All these suggestions were posted to the list by members (Marius, William, = James, Justin). Nothing here is new. If you disagree with my analysis of an= y of the points, please raise your *technical* concerns. Trying to use proc= ess arguments is simply not going to fly. Pick an option, provide a new option (with full analysis), or don't vote. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, February 03, 2011 8:20 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) This seems like an overly complex characterization - especially because you= 're including hypothetical choices such as schemes and sub-schemes that don= 't provide substantial benefits over the straightforward schemes we have no= w and would complicate implementations and people's understanding of the sp= ec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I wo= uld personally vote no to introducing any further any breaking changes. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3392P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All these suggestions were posted to the list by members (Mar= ius, William, James, Justin). Nothing here is new. If you disagree with my = analysis of any of the points, please raise your *technical* concern= s. Trying to use process arguments is simply not going to fly.

 

Pick an opt= ion, provide a new option (with full analysis), or don’t vote.

&nbs= p;

EHL

 

=  

From: M= ike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, F= ebruary 03, 2011 8:20 AM
To: Eran Hammer-Lahav; OAuth WG
Su= bject: RE: Bearer token type and scheme name (deadline: 2/10)

 

This seems like an overly comple= x characterization – especially because you’re including hypoth= etical choices such as schemes and sub-schemes that don’t provide sub= stantial benefits over the straightforward schemes we have now and would co= mplicate implementations and people’s understanding of the spec, and = that don’t have substantial support within the working group.

 = ;

Given = that we’re trying to bring the specs to working group last call, I wo= uld personally vote no to introducing any further any breaking changes.

&= nbsp;

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         -- Mike

 =

From: oauth-bounces@ietf.org [m= ailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
S= ent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
= Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)<= o:p>

 

=

After a long back-and-forth, I think it is time to pre= sent a few options and have people express their preferences.

 

These are t= he options mentioned so far and their +/-:

 

1. Descriptive, non-OAuth-spec= ific scheme names (Bearer, MAC)

&nb= sp;

Each token type gets its own name (which = does not include the word ‘oauth’ in it), as well as a matching= HTTP authentication scheme if a new one is being defined.

 

Benefits:=

 

- = works cleanly with the HTTP authentication framework by simply defining new= methods or reusing existing ones.

- sch= emes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth = 1.0 use cases).

- all schemes are presen= ted equally without giving any a preferred treatment.

- built-in discovery using 401 challenge header for which sch= emes are supported (with their respective information).

 

Downsides:

 

- po= tential creation of many new HTTP authentication schemes which has been sta= ble for a long time.

 

2. Single OAuth2 scheme with sub-schemes<= /p>

 

Define a = single authentication scheme for all token types with some attribute used t= o detect which scheme is actually being used.

 

Benefits:

 

- single scheme= , reuse of the 1.0 pattern.

 <= /o:p>

Downsides:

 

- requires a new registry for au= thentication header parameters.

- scheme= s are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme name, not on sub scheme, wh= ich will cause difficulty in some deployments.

- potential to produce a very complicated scheme once many sub schem= es are added.

- requires its own discove= ry method for which schemes are supported.

 

3. Name prefix (e.g. oauth2_be= arer)

 

Benefits:

 

<= p class=3DMsoNormal>- makes the protocol a bit easier to newbies since it w= ill look all inclusive (authorization and authentication).

 

Downsides:

 

-= makes reuse outside OAuth awkward without any technical benefit.

 

4. OAut= h2 for bearer, MAC for mac

 

Name the bearer token ‘OAuth2’ and= everything else gets a different name (with or without OAuth in it).<= /o:p>

 

Ben= efits:

 

- Matches current draft.

&= nbsp;

Downsides:

 

- Elevates bearer token to= the preferred token type, instead of promoting comparison of the various t= oken types available.

- Creates a very o= dd usage where the authorization server issues an access token of type R= 16;OAuth2’ which is non-descriptive and very confusing (since there a= re other token types).

- Uses the name O= Auth2 which stands for authorization in an authentication flow, continuing = the confusion about what OAuth is (an authorization protocol).

 

---

 

Plea= se reply with your preference by 2/10. As always, please provide feedback o= n the options and analysis.

 <= /o:p>

EHL

&= nbsp;

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3392P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Thu Feb 3 09:16:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A103A6A2C for ; Thu, 3 Feb 2011 09:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIOV2iCo3Qqb for ; Thu, 3 Feb 2011 09:16:12 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A53DB3A6A2A for ; Thu, 3 Feb 2011 09:16:12 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Feb 2011 09:19:35 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Thu, 3 Feb 2011 09:19:35 -0800 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwAQKdLwAAHe/CAAAF5sEA== Date: Thu, 3 Feb 2011 17:19:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943247214A2TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:16:20 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943247214A2TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I realize that spec stability doesn't matter to you, but that doesn't mean = that it's not important to others, including those actually using the specs= . Call that a "process" argument if you want, but that doesn't make it any= less pertinent - the "technical" argument is that breaking changes break i= mplementations. I already did vote below -- for option 4. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, February 03, 2011 9:14 AM To: Mike Jones; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) All these suggestions were posted to the list by members (Marius, William, = James, Justin). Nothing here is new. If you disagree with my analysis of an= y of the points, please raise your *technical* concerns. Trying to use proc= ess arguments is simply not going to fly. Pick an option, provide a new option (with full analysis), or don't vote. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, February 03, 2011 8:20 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) This seems like an overly complex characterization - especially because you= 're including hypothetical choices such as schemes and sub-schemes that don= 't provide substantial benefits over the straightforward schemes we have no= w and would complicate implementations and people's understanding of the sp= ec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I wo= uld personally vote no to introducing any further any breaking changes. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_4E1F6AAD24975D4BA5B1680429673943247214A2TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I realize that spec st= ability doesn’t matter to you, but that doesn’t mean that it= 217;s not important to others, including those actually using the specs.&nb= sp; Call that a “process” argument if you want, but that doesn&= #8217;t make it any less pertinent – the “technical” argument is= that breaking changes break implementations.

 

I already did vote bel= ow -- for option 4.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, February 03, 2011 9:14 AM
To: Mike Jones; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)=

 

All these suggestions = were posted to the list by members (Marius, William, James, Justin). Nothin= g here is new. If you disagree with my analysis of any of the points, pleas= e raise your *technical* concerns. Trying to use process arguments is simply not going to fly.

 

Pick an option, provid= e a new option (with full analysis), or don’t vote.=

 

EHL<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, February 03, 2011 8:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)=

 

This seems like an ove= rly complex characterization – especially because you’re includ= ing hypothetical choices such as schemes and sub-schemes that don’t p= rovide substantial benefits over the straightforward schemes we have now and would complicate implementations and people’s unders= tanding of the spec, and that don’t have substantial support within t= he working group.

 

Given that we’re= trying to bring the specs to working group last call, I would personally v= ote no to introducing any further any breaking changes.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/1= 0)

 

After a long back-and-forth, I think it is time to p= resent a few options and have people express their preferences.<= /p>

 

These are the options mentioned so far and their = 3;/-:

 

1. Descriptive, non-OAuth-specific scheme names (Bea= rer, MAC)

 

Each token type gets its own name (which does not in= clude the word ‘oauth’ in it), as well as a matching HTTP authe= ntication scheme if a new one is being defined.

 

Benefits:

 

- works cleanly with the HTTP authentication framewo= rk by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorizatio= n flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving a= ny a preferred treatment.

- built-in discovery using 401 challenge header for = which schemes are supported (with their respective information).=

 

Downsides:

 

- potential creation of many new HTTP authentication= schemes which has been stable for a long time.

 

2. Single OAuth2 scheme with sub-schemes<= /p>

 

Define a single authentication scheme for all token = types with some attribute used to detect which scheme is actually being use= d.

 

Benefits:

 

- single scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- requires a new registry for authentication header = parameters.

- schemes are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme name,= not on sub scheme, which will cause difficulty in some deployments.

- potential to produce a very complicated scheme onc= e many sub schemes are added.

- requires its own discovery method for which scheme= s are supported.

 

3. Name prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the protocol a bit easier to newbies since i= t will look all inclusive (authorization and authentication).

 

Downsides:

 

- makes reuse outside OAuth awkward without any tech= nical benefit.

 

4. OAuth2 for bearer, MAC for mac

 

Name the bearer token ‘OAuth2’ and every= thing else gets a different name (with or without OAuth in it).<= /p>

 

Benefits:

 

- Matches current draft.

 

Downsides:

 

- Elevates bearer token to the preferred token type,= instead of promoting comparison of the various token types available.=

- Creates a very odd usage where the authorization s= erver issues an access token of type ‘OAuth2’ which is non-desc= riptive and very confusing (since there are other token types).<= /p>

- Uses the name OAuth2 which stands for authorizatio= n in an authentication flow, continuing the confusion about what OAuth is (= an authorization protocol).

 

---

 

Please reply with your preference by 2/10. As always= , please provide feedback on the options and analysis.

 

EHL

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943247214A2TK5EX14MBXC201r_-- From eran@hueniverse.com Thu Feb 3 09:18:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A263A69EC for ; Thu, 3 Feb 2011 09:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lfdWOwl4Nlj for ; Thu, 3 Feb 2011 09:18:22 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1EC533A6A28 for ; Thu, 3 Feb 2011 09:18:21 -0800 (PST) Received: (qmail 30828 invoked from network); 3 Feb 2011 17:21:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 17:21:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Feb 2011 10:20:14 -0700 From: Eran Hammer-Lahav To: William Mills , OAuth WG Date: Thu, 3 Feb 2011 10:20:06 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwARLS/AAAEuVQA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3394@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3394P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:18:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3394P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Bill, It would be useful to know where it is deployed and how it is being used. If an existing deployment already uses the header to authenticate (via Auth= orization request header field), the resource server should continue to acc= ept such request alongside the new name until it can get all clients to mig= rate. This is trivial to support. The usage with the WWW-Authenticate header is being debated on another thre= ad. That's everywhere OAuth2 is used. This is no different from the work Facebook has done to support parameter n= ames we changed during the process to a live (and heavily used) production = system. Probably the largest OAuth 2.0 deployment to date. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Thursday, February 03, 2011 8:42 AM To: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) I'm coming around to #1, I'll put my vote there. I do agree that we have= usage out there of the OAuth2 scheme and we need not to break that, how do= we solve that? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3394P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Bill,

 

It would be useful to know where it is deployed= and how it is being used.

 

If an existing deployment already uses the head= er to authenticate (via Authorization request header field), the resource s= erver should continue to accept such request alongside the new name until i= t can get all clients to migrate. This is trivial to support.

 

The usage wi= th the WWW-Authenticate header is being debated on another thread.

 =

That= 217;s everywhere OAuth2 is used.

=  

This is no different from the work Facebo= ok has done to support parameter names we changed during the process to a l= ive (and heavily used) production system. Probably the largest OAuth 2.0 de= ployment to date.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <= b>On Behalf Of William Mills
Sent: Thursday, February 03, 201= 1 8:42 AM
To: OAuth WG
Subject: Re: [OAUTH-WG] Bearer t= oken type and scheme name (deadline: 2/10)

 

I’m coming around to #1, I’ll put my vote th= ere.    I do agree that we have usage out there of the OAuth= 2 scheme and we need not to break that, how do we solve that?

 

From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav=
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth W= G
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline= : 2/10)

 

After a long back-and-forth, I think it is tim= e to present a few options and have people express their preferences.<= /o:p>

 

The= se are the options mentioned so far and their +/-:

 

1. Descriptive, non-= OAuth-specific scheme names (Bearer, MAC)

 

Each token type gets its own na= me (which does not include the word ‘oauth’ in it), as well as = a matching HTTP authentication scheme if a new one is being defined.

 

Bene= fits:

 

- works cleanly with the HTTP authentication framework by simply de= fining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorization flow (e.g. 2-leg= ged OAuth 1.0 use cases).

- all schemes = are presented equally without giving any a preferred treatment.<= /p>

- built-in discovery using 401 challenge header for= which schemes are supported (with their respective information).

 

Downsid= es:

 

- potential creation of many new HTTP authentication schemes which ha= s been stable for a long time.

&nbs= p;

2. Single OAuth2 scheme with sub-schemes

 

Define a single authentication scheme for all token types with some attrib= ute used to detect which scheme is actually being used.

 

Benefits:

 

- sin= gle scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- requires a new reg= istry for authentication header parameters.

- schemes are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme name, not on su= b scheme, which will cause difficulty in some deployments.

- potential to produce a very complicated scheme once ma= ny sub schemes are added.

- requires its= own discovery method for which schemes are supported.

 

3. Name prefix (e.= g. oauth2_bearer)

 

<= p class=3DMsoNormal>Benefits:

 = ;

- makes the protocol a bit easier to newbie= s since it will look all inclusive (authorization and authentication).=

 

Do= wnsides:

 

- makes reuse outside OAuth awkward without any technical bene= fit.

 

4. OAuth2 for bearer, MAC for mac

 

Name the bearer token ‘OAu= th2’ and everything else gets a different name (with or without OAuth= in it).

 

Benefits:

 =

- Matches current draft.

 

Downsides:

 

- Elevates= bearer token to the preferred token type, instead of promoting comparison = of the various token types available.

- = Creates a very odd usage where the authorization server issues an access to= ken of type ‘OAuth2’ which is non-descriptive and very confusin= g (since there are other token types).

-= Uses the name OAuth2 which stands for authorization in an authentication f= low, continuing the confusion about what OAuth is (an authorization protoco= l).

 

---

 

Please reply with your preference by 2/10. As always, please p= rovide feedback on the options and analysis.

 

EHL

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3394P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Feb 3 09:20:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BA33A69EC for ; Thu, 3 Feb 2011 09:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRMsO36BIx4l for ; Thu, 3 Feb 2011 09:20:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 931283A6A2B for ; Thu, 3 Feb 2011 09:20:26 -0800 (PST) Received: (qmail 9375 invoked from network); 3 Feb 2011 17:23:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 17:23:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Feb 2011 10:23:28 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 3 Feb 2011 10:23:21 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwASlH8Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3395@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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_90C41DD21FB7C64BB94121FBBC2E723445A8FB3395P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:20:34 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3395P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #1 I suggest simply using 'Bearer' as the scheme name. It is descriptive and p= rovide reusability in other protocols with similar needs. I know this is be= ing dismissed but bearer tokens are not unique to OAuth and it would be hel= pful to allow other protocols to use a well-defined scheme, especially with= regard to the extensive security review this scheme is getting. Calling the two current scheme and types 'Mac' and 'Bearer' is clean, simpl= y, descriptive, and forward looking. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3395P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#1

 

I suggest simply using ‘Bearer’ as the schem= e name. It is descriptive and provide reusability in other protocols with s= imilar needs. I know this is being dismissed but bearer tokens are not uniq= ue to OAuth and it would be helpful to allow other protocols to use a well-= defined scheme, especially with regard to the extensive security review thi= s scheme is getting.

 

Calling the two current scheme and types ‘Mac&= #8217; and ‘Bearer’ is clean, simply, descriptive, and forward = looking.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf Of Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:= 34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token typ= e and scheme name (deadline: 2/10)

 

After a long back-a= nd-forth, I think it is time to present a few options and have people expre= ss their preferences.

 <= /p>

These are the options mentioned so far and their +/= -:

 

1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)

 

Each t= oken type gets its own name (which does not include the word ‘oauth&#= 8217; in it), as well as a matching HTTP authentication scheme if a new one= is being defined.

 

=

Benefits:

&nbs= p;

- works cleanly with the HTTP authenticati= on framework by simply defining new methods or reusing existing ones.<= /o:p>

- schemes can be used outside the OAuth autho= rization flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving any a prefe= rred treatment.

- built-in discovery usi= ng 401 challenge header for which schemes are supported (with their respect= ive information).

 

<= p class=3DMsoNormal>Downsides:

&nbs= p;

- potential creation of many new HTTP auth= entication schemes which has been stable for a long time.

 

2. Single OAuth= 2 scheme with sub-schemes

 

Define a single authentication scheme for all t= oken types with some attribute used to detect which scheme is actually bein= g used.

 

Benefits:

 

- single scheme, reuse of the 1.0 pattern.=

 

Downside= s:

 

- requires a new registry for authentication header parameters.

- schemes are not easily reusable outside OAut= h.

- existing frameworks usually switch = on scheme name, not on sub scheme, which will cause difficulty in some depl= oyments.

- potential to produce a very c= omplicated scheme once many sub schemes are added.

- requires its own discovery method for which schemes are supp= orted.

 

3. Name prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the prot= ocol a bit easier to newbies since it will look all inclusive (authorizatio= n and authentication).

 =

Downsides:

 

- makes reuse outside OAuth awkward w= ithout any technical benefit.

 = ;

4. OAuth2 for bearer, MAC for mac

 

Name th= e bearer token ‘OAuth2’ and everything else gets a different na= me (with or without OAuth in it).

&= nbsp;

Benefits:

 

- Matches current draft.

 

= Downsides:

 

- Elevates bearer token to the preferred token type, instead o= f promoting comparison of the various token types available.

=

- Creates a very odd usage where the authorization ser= ver issues an access token of type ‘OAuth2’ which is non-descri= ptive and very confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorization= in an authentication flow, continuing the confusion about what OAuth is (a= n authorization protocol).

 

---

&n= bsp;

Please reply with your preference by 2/1= 0. As always, please provide feedback on the options and analysis.

 

EHL

 

=  

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB3395P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Feb 3 09:27:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9D13A6A3C for ; Thu, 3 Feb 2011 09:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwpM0MWjXcZj for ; Thu, 3 Feb 2011 09:27:13 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1F7BE3A6A37 for ; Thu, 3 Feb 2011 09:27:13 -0800 (PST) Received: (qmail 1553 invoked from network); 3 Feb 2011 17:30:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 17:30:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Feb 2011 10:30:31 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Thu, 3 Feb 2011 10:30:24 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwAQKdLwAAHe/CAAAF5sEAAASqug Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB339C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.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_90C41DD21FB7C64BB94121FBBC2E723445A8FB339CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:27:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB339CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stability comes second to proper definition and building a forward looking = framework. The OAuth2 scheme is the least implemented part of the specifica= tion, and using a different name (i.e. changing 6 characters in an opaque s= tring) a trivial change to support on the server. >From your reply I take it you fully agree with my analysis of the various o= ptions. And I'm actually implementing the specification thank-you-very-much. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, February 03, 2011 9:20 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) I realize that spec stability doesn't matter to you, but that doesn't mean = that it's not important to others, including those actually using the specs= . Call that a "process" argument if you want, but that doesn't make it any= less pertinent - the "technical" argument is that breaking changes break i= mplementations. I already did vote below -- for option 4. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, February 03, 2011 9:14 AM To: Mike Jones; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) All these suggestions were posted to the list by members (Marius, William, = James, Justin). Nothing here is new. If you disagree with my analysis of an= y of the points, please raise your *technical* concerns. Trying to use proc= ess arguments is simply not going to fly. Pick an option, provide a new option (with full analysis), or don't vote. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, February 03, 2011 8:20 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Bearer token type and scheme name (deadline: 2/10) This seems like an overly complex characterization - especially because you= 're including hypothetical choices such as schemes and sub-schemes that don= 't provide substantial benefits over the straightforward schemes we have no= w and would complicate implementations and people's understanding of the sp= ec, and that don't have substantial support within the working group. Given that we're trying to bring the specs to working group last call, I wo= uld personally vote no to introducing any further any breaking changes. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB339CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stability comes second to proper definition and building a fo= rward looking framework. The OAuth2 scheme is the least implemented part of= the specification, and using a different name (i.e. changing 6 characters = in an opaque string) a trivial change to support on the server.<= /span>

 

From your = reply I take it you fully agree with my analysis of the various options.

=  

A= nd I’m actually implementing the specification thank-you-very-much.

 

= EHL

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, = February 03, 2011 9:20 AM
To: Eran Hammer-Lahav; OAuth WG
S= ubject: RE: Bearer token type and scheme name (deadline: 2/10)

 

I realize that spec stability do= esn’t matter to you, but that doesn’t mean that it’s not = important to others, including those actually using the specs.  Call t= hat a “process” argument if you want, but that doesn’t ma= ke it any less pertinent – the “technical” argument is th= at breaking changes break implementations.

 

I already did vote below -- for= option 4.

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, F= ebruary 03, 2011 9:14 AM
To: Mike Jones; OAuth WG
Subject:<= /b> RE: Bearer token type and scheme name (deadline: 2/10)

 

All these suggestions were posted to the= list by members (Marius, William, James, Justin). Nothing here is new. If = you disagree with my analysis of any of the points, please raise your *t= echnical* concerns. Trying to use process arguments is simply not going= to fly.

 

Pick an option, provide a new option (with full analysis), or don= ’t vote.

 

EHL

 

 

<= p class=3DMsoNormal>From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, February 03, 2011 8:20 AM
To: Eran Hammer= -Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (= deadline: 2/10)

=  

This see= ms like an overly complex characterization – especially because you&#= 8217;re including hypothetical choices such as schemes and sub-schemes that= don’t provide substantial benefits over the straightforward schemes = we have now and would complicate implementations and people’s underst= anding of the spec, and that don’t have substantial support within th= e working group.

 

Given that we’re trying to bring the specs to work= ing group last call, I would personally vote no to introducing any further = any breaking changes.

 

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

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
<= b>To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and sche= me name (deadline: 2/10)

 

After a long back-and-forth, = I think it is time to present a few options and have people express their p= references.

 

These are the options mentioned so far and their +/-:

 

1. De= scriptive, non-OAuth-specific scheme names (Bearer, MAC)

 

Each token type = gets its own name (which does not include the word ‘oauth’ in i= t), as well as a matching HTTP authentication scheme if a new one is being = defined.

 

Benefits:

 =

- works cleanly with the HTTP authentication frame= work by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorization= flow (e.g. 2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving any a preferred treat= ment.

- built-in discovery using 401 cha= llenge header for which schemes are supported (with their respective inform= ation).

 

Downsides:

 

- potential creation of many new HTTP authentication= schemes which has been stable for a long time.

 

2. Single OAuth2 scheme w= ith sub-schemes

 

Define a single authentication scheme for all token types= with some attribute used to detect which scheme is actually being used.

 

= Benefits:

 

- single scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- re= quires a new registry for authentication header parameters.

<= p class=3DMsoNormal>- schemes are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme= name, not on sub scheme, which will cause difficulty in some deployments.<= o:p>

- potential to produce a very complicate= d scheme once many sub schemes are added.

- requires its own discovery method for which schemes are supported.=

 

3.= Name prefix (e.g. oauth2_bearer)

&= nbsp;

Benefits:

 

- makes the protocol a bit = easier to newbies since it will look all inclusive (authorization and authe= ntication).

 

Downsides:

 

- makes reuse outside OAuth awkward without any = technical benefit.

 

=

4. OAuth2 for bearer, MAC for mac

 

Name the bearer to= ken ‘OAuth2’ and everything else gets a different name (with or= without OAuth in it).

 =

Benefits:

=  

- Matches current draft.

 

Downsides:<= o:p>

 

- Elevates bearer token to the preferred token type, instead of promoting= comparison of the various token types available.

- Creates a very odd usage where the authorization server issues = an access token of type ‘OAuth2’ which is non-descriptive and v= ery confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorization in an au= thentication flow, continuing the confusion about what OAuth is (an authori= zation protocol).

 

<= p class=3DMsoNormal>---

 

Please reply with your preference by 2/10. As alw= ays, please provide feedback on the options and analysis.

 

EHL<= /p>

 

&nbs= p;

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB339CP3PW5EX1MB01E_-- From peaceable_whale@hotmail.com Thu Feb 3 09:36:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24D13A6A3C for ; Thu, 3 Feb 2011 09:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlPPq4ZoYIsS for ; Thu, 3 Feb 2011 09:36:50 -0800 (PST) Received: from col0-omc1-s16.col0.hotmail.com (col0-omc1-s16.col0.hotmail.com [65.55.34.26]) by core3.amsl.com (Postfix) with ESMTP id B94C93A6A37 for ; Thu, 3 Feb 2011 09:36:50 -0800 (PST) Received: from COL122-DS11 ([65.55.34.9]) by col0-omc1-s16.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 09:40:13 -0800 X-Originating-IP: [14.136.19.151] X-Originating-Email: [peaceable_whale@hotmail.com] Message-ID: From: "Franklin Tse" To: "Mike Jones" References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET><4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com><90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Fri, 4 Feb 2011 01:40:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-OriginalArrivalTime: 03 Feb 2011 17:40:13.0363 (UTC) FILETIME=[695B6030:01CBC3C9] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:36:51 -0000 SGVsbG8gTWlrZSwNCg0KR2l2ZW4gdGhlIHNwZWMgaXMgc3RpbGwgYSBkcmFmdCBhbmQgbW9zdCBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCBpbiBwcm9kdWN0aW9uIHN0YWdlLCBpdCBz ZWVtcyB0aGF0IGNoYW5naW5nIHRoZSBuYW1lIG9mIHRoZSBiZWFyZXIgc2NoZW1lIGZyb20gT0F1 dGgyIHRvIEJlYXJlciBpcyBub3QgZ29pbmcgdG8gaGF2ZSBhIGJpZyBpbXBhY3QuDQoNCldpdGgg YSBzbWFsbCBjaGFuZ2UsIHdlIGFyZSBnb2luZyB0byBoYXZlIGEgY2xlYXJlciBhbmQgbW9yZSBk ZXNjcmlwdGl2ZSBzY2hlbWUgbmFtZSwgYW5kIG1vc3QgaW1wb3J0YW50bHksIGl0IHByZXNlcnZl cyB0aGUgZmFpcm5lc3MgdG8gb3RoZXIgY3VycmVudCAoYW5kIGZ1dHVyZSkgc2NoZW1lcyBieSBu b3QgcHJvbW90aW5nIGEgc3BlY2lmaWMgc2NoZW1lLg0KDQpSZWdhcmRzLA0KRnJhbmtsaW4NCiAg DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJv bTogIk1pa2UgSm9uZXMiIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpEYXRlOiBGcmlk YXksIDA0IEZlYnJ1YXJ5LCAyMDExIDAxOjE5DQpUbzogIkVyYW4gSGFtbWVyLUxhaGF2IiA8ZXJh bkBodWVuaXZlcnNlLmNvbT47ICJPQXV0aCBXRyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQmVhcmVyIHRva2VuIHR5cGUgYW5kIHNjaGVtZSBuYW1lIChkZWFkbGlu ZTogMi8xMCkNCg0KPiBJIHJlYWxpemUgdGhhdCBzcGVjIHN0YWJpbGl0eSBkb2Vzbid0IG1hdHRl ciB0byB5b3UsIGJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB0aGF0IGl0J3Mgbm90IGltcG9ydGFudCB0 byBvdGhlcnMsIGluY2x1ZGluZyB0aG9zZSBhY3R1YWxseSB1c2luZyB0aGUgc3BlY3MuICBDYWxs IHRoYXQgYSAicHJvY2VzcyIgYXJndW1lbnQgaWYgeW91IHdhbnQsIGJ1dCB0aGF0IGRvZXNuJ3Qg bWFrZSBpdCBhbnkgbGVzcyBwZXJ0aW5lbnQgLSB0aGUgInRlY2huaWNhbCIgYXJndW1lbnQgaXMg dGhhdCBicmVha2luZyBjaGFuZ2VzIGJyZWFrIGltcGxlbWVudGF0aW9ucy4NCj4gDQo+IEkgYWxy ZWFkeSBkaWQgdm90ZSBiZWxvdyAtLSBmb3Igb3B0aW9uIDQuDQo+IA0KPiBGcm9tOiBFcmFuIEhh bW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5 LCBGZWJydWFyeSAwMywgMjAxMSA5OjE0IEFNDQo+IFRvOiBNaWtlIEpvbmVzOyBPQXV0aCBXRw0K PiBTdWJqZWN0OiBSRTogQmVhcmVyIHRva2VuIHR5cGUgYW5kIHNjaGVtZSBuYW1lIChkZWFkbGlu ZTogMi8xMCkNCj4gDQo+IEFsbCB0aGVzZSBzdWdnZXN0aW9ucyB3ZXJlIHBvc3RlZCB0byB0aGUg bGlzdCBieSBtZW1iZXJzIChNYXJpdXMsIFdpbGxpYW0sIEphbWVzLCBKdXN0aW4pLiBOb3RoaW5n IGhlcmUgaXMgbmV3LiBJZiB5b3UgZGlzYWdyZWUgd2l0aCBteSBhbmFseXNpcyBvZiBhbnkgb2Yg dGhlIHBvaW50cywgcGxlYXNlIHJhaXNlIHlvdXIgKnRlY2huaWNhbCogY29uY2VybnMuIFRyeWlu ZyB0byB1c2UgcHJvY2VzcyBhcmd1bWVudHMgaXMgc2ltcGx5IG5vdCBnb2luZyB0byBmbHkuDQo+ IA0KPiBQaWNrIGFuIG9wdGlvbiwgcHJvdmlkZSBhIG5ldyBvcHRpb24gKHdpdGggZnVsbCBhbmFs eXNpcyksIG9yIGRvbid0IHZvdGUuDQo+IA0KPiBFSEwNCj4gDQo+IA0KPiBGcm9tOiBNaWtlIEpv bmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXQ0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMDMsIDIwMTEgODoyMCBBTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXY7IE9B dXRoIFdHDQo+IFN1YmplY3Q6IFJFOiBCZWFyZXIgdG9rZW4gdHlwZSBhbmQgc2NoZW1lIG5hbWUg KGRlYWRsaW5lOiAyLzEwKQ0KPiANCj4gVGhpcyBzZWVtcyBsaWtlIGFuIG92ZXJseSBjb21wbGV4 IGNoYXJhY3Rlcml6YXRpb24gLSBlc3BlY2lhbGx5IGJlY2F1c2UgeW91J3JlIGluY2x1ZGluZyBo eXBvdGhldGljYWwgY2hvaWNlcyBzdWNoIGFzIHNjaGVtZXMgYW5kIHN1Yi1zY2hlbWVzIHRoYXQg ZG9uJ3QgcHJvdmlkZSBzdWJzdGFudGlhbCBiZW5lZml0cyBvdmVyIHRoZSBzdHJhaWdodGZvcndh cmQgc2NoZW1lcyB3ZSBoYXZlIG5vdyBhbmQgd291bGQgY29tcGxpY2F0ZSBpbXBsZW1lbnRhdGlv bnMgYW5kIHBlb3BsZSdzIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNwZWMsIGFuZCB0aGF0IGRvbid0 IGhhdmUgc3Vic3RhbnRpYWwgc3VwcG9ydCB3aXRoaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQo+IA0K PiBHaXZlbiB0aGF0IHdlJ3JlIHRyeWluZyB0byBicmluZyB0aGUgc3BlY3MgdG8gd29ya2luZyBn cm91cCBsYXN0IGNhbGwsIEkgd291bGQgcGVyc29uYWxseSB2b3RlIG5vIHRvIGludHJvZHVjaW5n IGFueSBmdXJ0aGVyIGFueSBicmVha2luZyBjaGFuZ2VzLg0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+IA0K PiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQo+IFNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAwMywgMjAxMSAxMjozNCBBTQ0KPiBUbzogT0F1dGggV0cNCj4gU3ViamVjdDogW09B VVRILVdHXSBCZWFyZXIgdG9rZW4gdHlwZSBhbmQgc2NoZW1lIG5hbWUgKGRlYWRsaW5lOiAyLzEw KQ0KPiANCj4gQWZ0ZXIgYSBsb25nIGJhY2stYW5kLWZvcnRoLCBJIHRoaW5rIGl0IGlzIHRpbWUg dG8gcHJlc2VudCBhIGZldyBvcHRpb25zIGFuZCBoYXZlIHBlb3BsZSBleHByZXNzIHRoZWlyIHBy ZWZlcmVuY2VzLg0KPiANCj4gVGhlc2UgYXJlIHRoZSBvcHRpb25zIG1lbnRpb25lZCBzbyBmYXIg YW5kIHRoZWlyICsvLToNCj4gDQo+IDEuIERlc2NyaXB0aXZlLCBub24tT0F1dGgtc3BlY2lmaWMg c2NoZW1lIG5hbWVzIChCZWFyZXIsIE1BQykNCj4gDQo+IEVhY2ggdG9rZW4gdHlwZSBnZXRzIGl0 cyBvd24gbmFtZSAod2hpY2ggZG9lcyBub3QgaW5jbHVkZSB0aGUgd29yZCAnb2F1dGgnIGluIGl0 KSwgYXMgd2VsbCBhcyBhIG1hdGNoaW5nIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIGlmIGEg bmV3IG9uZSBpcyBiZWluZyBkZWZpbmVkLg0KPiANCj4gQmVuZWZpdHM6DQo+IA0KPiAtIHdvcmtz IGNsZWFubHkgd2l0aCB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsgYnkgc2ltcGx5 IGRlZmluaW5nIG5ldyBtZXRob2RzIG9yIHJldXNpbmcgZXhpc3Rpbmcgb25lcy4NCj4gLSBzY2hl bWVzIGNhbiBiZSB1c2VkIG91dHNpZGUgdGhlIE9BdXRoIGF1dGhvcml6YXRpb24gZmxvdyAoZS5n LiAyLWxlZ2dlZCBPQXV0aCAxLjAgdXNlIGNhc2VzKS4NCj4gLSBhbGwgc2NoZW1lcyBhcmUgcHJl c2VudGVkIGVxdWFsbHkgd2l0aG91dCBnaXZpbmcgYW55IGEgcHJlZmVycmVkIHRyZWF0bWVudC4N Cj4gLSBidWlsdC1pbiBkaXNjb3ZlcnkgdXNpbmcgNDAxIGNoYWxsZW5nZSBoZWFkZXIgZm9yIHdo aWNoIHNjaGVtZXMgYXJlIHN1cHBvcnRlZCAod2l0aCB0aGVpciByZXNwZWN0aXZlIGluZm9ybWF0 aW9uKS4NCj4gDQo+IERvd25zaWRlczoNCj4gDQo+IC0gcG90ZW50aWFsIGNyZWF0aW9uIG9mIG1h bnkgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyB3aGljaCBoYXMgYmVlbiBzdGFibGUg Zm9yIGEgbG9uZyB0aW1lLg0KPiANCj4gMi4gU2luZ2xlIE9BdXRoMiBzY2hlbWUgd2l0aCBzdWIt c2NoZW1lcw0KPiANCj4gRGVmaW5lIGEgc2luZ2xlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBmb3Ig YWxsIHRva2VuIHR5cGVzIHdpdGggc29tZSBhdHRyaWJ1dGUgdXNlZCB0byBkZXRlY3Qgd2hpY2gg c2NoZW1lIGlzIGFjdHVhbGx5IGJlaW5nIHVzZWQuDQo+IA0KPiBCZW5lZml0czoNCj4gDQo+IC0g c2luZ2xlIHNjaGVtZSwgcmV1c2Ugb2YgdGhlIDEuMCBwYXR0ZXJuLg0KPiANCj4gRG93bnNpZGVz Og0KPiANCj4gLSByZXF1aXJlcyBhIG5ldyByZWdpc3RyeSBmb3IgYXV0aGVudGljYXRpb24gaGVh ZGVyIHBhcmFtZXRlcnMuDQo+IC0gc2NoZW1lcyBhcmUgbm90IGVhc2lseSByZXVzYWJsZSBvdXRz aWRlIE9BdXRoLg0KPiAtIGV4aXN0aW5nIGZyYW1ld29ya3MgdXN1YWxseSBzd2l0Y2ggb24gc2No ZW1lIG5hbWUsIG5vdCBvbiBzdWIgc2NoZW1lLCB3aGljaCB3aWxsIGNhdXNlIGRpZmZpY3VsdHkg aW4gc29tZSBkZXBsb3ltZW50cy4NCj4gLSBwb3RlbnRpYWwgdG8gcHJvZHVjZSBhIHZlcnkgY29t cGxpY2F0ZWQgc2NoZW1lIG9uY2UgbWFueSBzdWIgc2NoZW1lcyBhcmUgYWRkZWQuDQo+IC0gcmVx dWlyZXMgaXRzIG93biBkaXNjb3ZlcnkgbWV0aG9kIGZvciB3aGljaCBzY2hlbWVzIGFyZSBzdXBw b3J0ZWQuDQo+IA0KPiAzLiBOYW1lIHByZWZpeCAoZS5nLiBvYXV0aDJfYmVhcmVyKQ0KPiANCj4g QmVuZWZpdHM6DQo+IA0KPiAtIG1ha2VzIHRoZSBwcm90b2NvbCBhIGJpdCBlYXNpZXIgdG8gbmV3 YmllcyBzaW5jZSBpdCB3aWxsIGxvb2sgYWxsIGluY2x1c2l2ZSAoYXV0aG9yaXphdGlvbiBhbmQg YXV0aGVudGljYXRpb24pLg0KPiANCj4gRG93bnNpZGVzOg0KPiANCj4gLSBtYWtlcyByZXVzZSBv dXRzaWRlIE9BdXRoIGF3a3dhcmQgd2l0aG91dCBhbnkgdGVjaG5pY2FsIGJlbmVmaXQuDQo+IA0K PiA0LiBPQXV0aDIgZm9yIGJlYXJlciwgTUFDIGZvciBtYWMNCj4gDQo+IE5hbWUgdGhlIGJlYXJl ciB0b2tlbiAnT0F1dGgyJyBhbmQgZXZlcnl0aGluZyBlbHNlIGdldHMgYSBkaWZmZXJlbnQgbmFt ZSAod2l0aCBvciB3aXRob3V0IE9BdXRoIGluIGl0KS4NCj4gDQo+IEJlbmVmaXRzOg0KPiANCj4g LSBNYXRjaGVzIGN1cnJlbnQgZHJhZnQuDQo+IA0KPiBEb3duc2lkZXM6DQo+IA0KPiAtIEVsZXZh dGVzIGJlYXJlciB0b2tlbiB0byB0aGUgcHJlZmVycmVkIHRva2VuIHR5cGUsIGluc3RlYWQgb2Yg cHJvbW90aW5nIGNvbXBhcmlzb24gb2YgdGhlIHZhcmlvdXMgdG9rZW4gdHlwZXMgYXZhaWxhYmxl Lg0KPiAtIENyZWF0ZXMgYSB2ZXJ5IG9kZCB1c2FnZSB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBvZiB0eXBlICdPQXV0aDInIHdoaWNoIGlzIG5v bi1kZXNjcmlwdGl2ZSBhbmQgdmVyeSBjb25mdXNpbmcgKHNpbmNlIHRoZXJlIGFyZSBvdGhlciB0 b2tlbiB0eXBlcykuDQo+IC0gVXNlcyB0aGUgbmFtZSBPQXV0aDIgd2hpY2ggc3RhbmRzIGZvciBh dXRob3JpemF0aW9uIGluIGFuIGF1dGhlbnRpY2F0aW9uIGZsb3csIGNvbnRpbnVpbmcgdGhlIGNv bmZ1c2lvbiBhYm91dCB3aGF0IE9BdXRoIGlzIChhbiBhdXRob3JpemF0aW9uIHByb3RvY29sKS4N Cj4gDQo+IC0tLQ0KPiANCj4gUGxlYXNlIHJlcGx5IHdpdGggeW91ciBwcmVmZXJlbmNlIGJ5IDIv MTAuIEFzIGFsd2F5cywgcGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgb24gdGhlIG9wdGlvbnMgYW5k IGFuYWx5c2lzLg0KPiANCj4gRUhMDQo+IA0KPiANCj4NCg0KDQoNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCj4g From recordond@gmail.com Thu Feb 3 09:38:10 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDCC3A6A37 for ; Thu, 3 Feb 2011 09:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WeFA50G0Ekp for ; Thu, 3 Feb 2011 09:38:10 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AEB293A6A22 for ; Thu, 3 Feb 2011 09:38:09 -0800 (PST) Received: by vws7 with SMTP id 7so879190vws.31 for ; Thu, 03 Feb 2011 09:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=rWBscMWsz0/oqfcCz4Cl8MUnAT8A5EYLNL/fvfsr6Ig=; b=YPdkmRa5mJGkbmdiDsT9l/3t9yizyYiEMutPDnUymMaDan0tl3SlJ21jrziNa6Oi1n Qk0zSujmYsIYqHs7BrTzIBRLLVEqsmvW57iQq4O0zcZkh/8fee7UZR619XbdVK0z8COh 8e2Q+68L3ml7KT2MzaU0IlrSKD7s8Dm8OZwHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=T30KhV/rEkO9dwWqZlCRCS+1sv0twPAeTUlmrnX8Sj2oEZPyD6aLBVqZzpdWSLprK9 clP1FI2hUI2Hygsrm0HefcrL8XyfJF0pcnPUULsLo12flS/mzvacBY0EZOzklfQks3WQ mo+Ffz8is2b4wK/HUf9irZ0hpiSgPpkX9QM+s= MIME-Version: 1.0 Received: by 10.220.200.69 with SMTP id ev5mr2885912vcb.45.1296754892225; Thu, 03 Feb 2011 09:41:32 -0800 (PST) Received: by 10.220.187.197 with HTTP; Thu, 3 Feb 2011 09:41:32 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Feb 2011 09:41:32 -0800 Message-ID: From: David Recordon To: William Mills , OAuth WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:38:11 -0000 Also #1. While I feel for existing implementations of "OAuth2" by itself, it's not the best name for this specific piece of functionality and Facebook too has a final migration server side to make for other features in the spec which weren't finalized when we implemented them. On Thu, Feb 3, 2011 at 8:42 AM, William Mills wrote: > I=92m coming around to #1, I=92ll put my vote there.=A0=A0=A0 I do agree = that we have > usage out there of the OAuth2 scheme and we need not to break that, how d= o > we solve that? > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Thursday, February 03, 2011 12:34 AM > To: OAuth WG > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) > > > > After a long back-and-forth, I think it is time to present a few options = and > have people express their preferences. > > > > These are the options mentioned so far and their +/-: > > > > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > > > > Each token type gets its own name (which does not include the word =91oau= th=92 > in it), as well as a matching HTTP authentication scheme if a new one is > being defined. > > > > Benefits: > > > > - works cleanly with the HTTP authentication framework by simply defining > new methods or reusing existing ones. > > - schemes can be used outside the OAuth authorization flow (e.g. 2-legged > OAuth 1.0 use cases). > > - all schemes are presented equally without giving any a preferred > treatment. > > - built-in discovery using 401 challenge header for which schemes are > supported (with their respective information). > > > > Downsides: > > > > - potential creation of many new HTTP authentication schemes which has be= en > stable for a long time. > > > > 2. Single OAuth2 scheme with sub-schemes > > > > Define a single authentication scheme for all token types with some > attribute used to detect which scheme is actually being used. > > > > Benefits: > > > > - single scheme, reuse of the 1.0 pattern. > > > > Downsides: > > > > - requires a new registry for authentication header parameters. > > - schemes are not easily reusable outside OAuth. > > - existing frameworks usually switch on scheme name, not on sub scheme, > which will cause difficulty in some deployments. > > - potential to produce a very complicated scheme once many sub schemes ar= e > added. > > - requires its own discovery method for which schemes are supported. > > > > 3. Name prefix (e.g. oauth2_bearer) > > > > Benefits: > > > > - makes the protocol a bit easier to newbies since it will look all > inclusive (authorization and authentication). > > > > Downsides: > > > > - makes reuse outside OAuth awkward without any technical benefit. > > > > 4. OAuth2 for bearer, MAC for mac > > > > Name the bearer token =91OAuth2=92 and everything else gets a different n= ame > (with or without OAuth in it). > > > > Benefits: > > > > - Matches current draft. > > > > Downsides: > > > > - Elevates bearer token to the preferred token type, instead of promoting > comparison of the various token types available. > > - Creates a very odd usage where the authorization server issues an acces= s > token of type =91OAuth2=92 which is non-descriptive and very confusing (s= ince > there are other token types). > > - Uses the name OAuth2 which stands for authorization in an authenticatio= n > flow, continuing the confusion about what OAuth is (an authorization > protocol). > > > > --- > > > > Please reply with your preference by 2/10. As always, please provide > feedback on the options and analysis. > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From stpeter@stpeter.im Thu Feb 3 10:07:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1DF3A6A46 for ; Thu, 3 Feb 2011 10:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXMVci3ZEuzZ for ; Thu, 3 Feb 2011 10:07:13 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 04B593A6932 for ; Thu, 3 Feb 2011 10:07:13 -0800 (PST) Received: from squire.local (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 28098400F6 for ; Thu, 3 Feb 2011 11:27:32 -0700 (MST) Message-ID: <4D4AEF98.4060101@stpeter.im> Date: Thu, 03 Feb 2011 19:10:32 +0100 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="------------ms070403070607030209020009" Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:07:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070403070607030209020009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With my individual contributor hat on, I too prefer #1 -- it's just a lot cleaner to my mind. On 2/3/11 6:41 PM, David Recordon wrote: > Also #1. While I feel for existing implementations of "OAuth2" by > itself, it's not the best name for this specific piece of > functionality and Facebook too has a final migration server side to > make for other features in the spec which weren't finalized when we > implemented them. >=20 >=20 > On Thu, Feb 3, 2011 at 8:42 AM, William Mills wr= ote: >> I=E2=80=99m coming around to #1, I=E2=80=99ll put my vote there. I = do agree that we have >> usage out there of the OAuth2 scheme and we need not to break that, ho= w do >> we solve that? >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of >> Eran Hammer-Lahav >> Sent: Thursday, February 03, 2011 12:34 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)= >> >> >> >> After a long back-and-forth, I think it is time to present a few optio= ns and >> have people express their preferences. >> >> >> >> These are the options mentioned so far and their +/-: >> >> >> >> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >> >> >> >> Each token type gets its own name (which does not include the word =E2= =80=98oauth=E2=80=99 >> in it), as well as a matching HTTP authentication scheme if a new one = is >> being defined. >> >> >> >> Benefits: >> >> >> >> - works cleanly with the HTTP authentication framework by simply defin= ing >> new methods or reusing existing ones. >> >> - schemes can be used outside the OAuth authorization flow (e.g. 2-leg= ged >> OAuth 1.0 use cases). >> >> - all schemes are presented equally without giving any a preferred >> treatment. >> >> - built-in discovery using 401 challenge header for which schemes are >> supported (with their respective information). >> >> >> >> Downsides: >> >> >> >> - potential creation of many new HTTP authentication schemes which has= been >> stable for a long time. >> >> >> >> 2. Single OAuth2 scheme with sub-schemes >> >> >> >> Define a single authentication scheme for all token types with some >> attribute used to detect which scheme is actually being used. >> >> >> >> Benefits: >> >> >> >> - single scheme, reuse of the 1.0 pattern. >> >> >> >> Downsides: >> >> >> >> - requires a new registry for authentication header parameters. >> >> - schemes are not easily reusable outside OAuth. >> >> - existing frameworks usually switch on scheme name, not on sub scheme= , >> which will cause difficulty in some deployments. >> >> - potential to produce a very complicated scheme once many sub schemes= are >> added. >> >> - requires its own discovery method for which schemes are supported. >> >> >> >> 3. Name prefix (e.g. oauth2_bearer) >> >> >> >> Benefits: >> >> >> >> - makes the protocol a bit easier to newbies since it will look all >> inclusive (authorization and authentication). >> >> >> >> Downsides: >> >> >> >> - makes reuse outside OAuth awkward without any technical benefit. >> >> >> >> 4. OAuth2 for bearer, MAC for mac >> >> >> >> Name the bearer token =E2=80=98OAuth2=E2=80=99 and everything else get= s a different name >> (with or without OAuth in it). >> >> >> >> Benefits: >> >> >> >> - Matches current draft. >> >> >> >> Downsides: >> >> >> >> - Elevates bearer token to the preferred token type, instead of promot= ing >> comparison of the various token types available. >> >> - Creates a very odd usage where the authorization server issues an ac= cess >> token of type =E2=80=98OAuth2=E2=80=99 which is non-descriptive and ve= ry confusing (since >> there are other token types). >> >> - Uses the name OAuth2 which stands for authorization in an authentica= tion >> flow, continuing the confusion about what OAuth is (an authorization >> protocol). >> >> >> >> --- >> >> >> >> Please reply with your preference by 2/10. As always, please provide >> feedback on the options and analysis. >> >> >> >> EHL >> --------------ms070403070607030209020009 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIw MzE4MTAzMlowIwYJKoZIhvcNAQkEMRYEFM7XZCXF4v2BzidHQ5uaPuNkuVaMMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBG9KNqAMjKmGjMCd/6iaT4DYRdnmKa2JHoFi45NBEZkr+H2WkqU4jKFR8a xVyc0HWreF5FI9D/URGXO/SStDS1bCN3xDsVpcexg4zRlamrAHVNyD6YG32EgZzAbhXomsa9 Wr808kdVJOItk1jj8LYQO+kz9AqOapZ4h0CNbBKQG/zIZF5urE4lLZ6qNG2CxmaqZiHv/IEt n+AWTH7LXKNFtbaSgPd8CsO+u1PAz2GJkP58xoN35lBXxynVbAoiwXMUWOFKc+rC3koo4q+j XhqLZ1m17HVgV7kwwkFgk3pjJIhmBg8kBdBKUdLPU0pr6oySC3gMlGyS/XlMKomI2SMyAAAA AAAA --------------ms070403070607030209020009-- From phil.hunt@oracle.com Thu Feb 3 10:10:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD40B3A69F3 for ; Thu, 3 Feb 2011 10:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqmm6VGlDYQP for ; Thu, 3 Feb 2011 10:10:18 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 04F533A6932 for ; Thu, 3 Feb 2011 10:10:17 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p13IDcCm031405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Feb 2011 18:13:40 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p13HmJtG003485 for ; Thu, 3 Feb 2011 18:13:36 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 977710281296756770; Thu, 03 Feb 2011 10:12:50 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 10:12:49 -0800 From: Phil Hunt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2-621986719 Date: Thu, 3 Feb 2011 10:12:46 -0800 In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> To: OAuth WG References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-Id: X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D4AF052.0047:SCFMA4539814,ss=1,fgs=0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:10:19 -0000 --Apple-Mail-2-621986719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OPTION 1. Phil phil.hunt@oracle.com On 2011-02-03, at 9:19 AM, Mike Jones wrote: > I realize that spec stability doesn=92t matter to you, but that = doesn=92t mean that it=92s not important to others, including those = actually using the specs. Call that a =93process=94 argument if you = want, but that doesn=92t make it any less pertinent =96 the =93technical=94= argument is that breaking changes break implementations. > =20 > I already did vote below -- for option 4. > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Thursday, February 03, 2011 9:14 AM > To: Mike Jones; OAuth WG > Subject: RE: Bearer token type and scheme name (deadline: 2/10) > =20 > All these suggestions were posted to the list by members (Marius, = William, James, Justin). Nothing here is new. If you disagree with my = analysis of any of the points, please raise your *technical* concerns. = Trying to use process arguments is simply not going to fly. > =20 > Pick an option, provide a new option (with full analysis), or don=92t = vote. > =20 > EHL > =20 > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Thursday, February 03, 2011 8:20 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: Bearer token type and scheme name (deadline: 2/10) > =20 > This seems like an overly complex characterization =96 especially = because you=92re including hypothetical choices such as schemes and = sub-schemes that don=92t provide substantial benefits over the = straightforward schemes we have now and would complicate implementations = and people=92s understanding of the spec, and that don=92t have = substantial support within the working group. > =20 > Given that we=92re trying to bring the specs to working group last = call, I would personally vote no to introducing any further any breaking = changes. > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Thursday, February 03, 2011 12:34 AM > To: OAuth WG > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) > =20 > After a long back-and-forth, I think it is time to present a few = options and have people express their preferences. > =20 > These are the options mentioned so far and their +/-: > =20 > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > =20 > Each token type gets its own name (which does not include the word = =91oauth=92 in it), as well as a matching HTTP authentication scheme if = a new one is being defined. > =20 > Benefits: > =20 > - works cleanly with the HTTP authentication framework by simply = defining new methods or reusing existing ones. > - schemes can be used outside the OAuth authorization flow (e.g. = 2-legged OAuth 1.0 use cases). > - all schemes are presented equally without giving any a preferred = treatment. > - built-in discovery using 401 challenge header for which schemes are = supported (with their respective information). > =20 > Downsides: > =20 > - potential creation of many new HTTP authentication schemes which has = been stable for a long time. > =20 > 2. Single OAuth2 scheme with sub-schemes > =20 > Define a single authentication scheme for all token types with some = attribute used to detect which scheme is actually being used. > =20 > Benefits: > =20 > - single scheme, reuse of the 1.0 pattern. > =20 > Downsides: > =20 > - requires a new registry for authentication header parameters. > - schemes are not easily reusable outside OAuth. > - existing frameworks usually switch on scheme name, not on sub = scheme, which will cause difficulty in some deployments. > - potential to produce a very complicated scheme once many sub schemes = are added. > - requires its own discovery method for which schemes are supported. > =20 > 3. Name prefix (e.g. oauth2_bearer) > =20 > Benefits: > =20 > - makes the protocol a bit easier to newbies since it will look all = inclusive (authorization and authentication). > =20 > Downsides: > =20 > - makes reuse outside OAuth awkward without any technical benefit. > =20 > 4. OAuth2 for bearer, MAC for mac > =20 > Name the bearer token =91OAuth2=92 and everything else gets a = different name (with or without OAuth in it). > =20 > Benefits: > =20 > - Matches current draft. > =20 > Downsides: > =20 > - Elevates bearer token to the preferred token type, instead of = promoting comparison of the various token types available. > - Creates a very odd usage where the authorization server issues an = access token of type =91OAuth2=92 which is non-descriptive and very = confusing (since there are other token types). > - Uses the name OAuth2 which stands for authorization in an = authentication flow, continuing the confusion about what OAuth is (an = authorization protocol). > =20 > --- > =20 > Please reply with your preference by 2/10. As always, please provide = feedback on the options and analysis. > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-621986719 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Phil

On 2011-02-03, at 9:19 AM, Mike Jones wrote:

I realize that spec stability doesn=92t matter to you, but = that doesn=92t mean that it=92s not important to others, including those = actually using the specs.  Call that a =93process=94 argument if = you want, but that doesn=92t make it any less pertinent =96 the = =93technical=94 argument is that breaking changes break = implementations.
 
I already did vote below -- for option = 4.
 
From: Eran Hammer-Lahav = [mailto:eran@hueniverse.com] 
Sent: Thursday, February 03, 2011 = 9:14 AM
To: Mike Jones; OAuth = WG
Subject: RE: Bearer token type and = scheme name (deadline: 2/10)
All these suggestions were posted to the list by members = (Marius, William, James, Justin). Nothing here is new. If you disagree = with my analysis of any of the points, please raise your = *technical* concerns. Trying to use process arguments is simply = not going to fly.
 
Pick an option, provide a new option (with full analysis), = or don=92t vote.
 
EHL
 
 
From: Mike Jones = [mailto:Michael.Jones@microsoft.com] 
Sent: Thursday, February 03, 2011 = 8:20 AM
To: Eran Hammer-Lahav; OAuth = WG
Subject: RE: Bearer token type and = scheme name (deadline: 2/10)
This seems like an overly complex characterization =96 especially = because you=92re including hypothetical choices such as schemes and = sub-schemes that don=92t provide substantial benefits over the = straightforward schemes we have now and would complicate implementations = and people=92s understanding of the spec, and that don=92t have = substantial support within the working = group.
 
Given that we=92re trying to bring the specs to working group = last call, I would personally vote no to introducing any further any = breaking changes.
 
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Eran = Hammer-Lahav
Sent: Thursday, February 03, 2011 = 12:34 AM
To: OAuth = WG
Subject: [OAUTH-WG] Bearer token = type and scheme name (deadline: = 2/10)
 
These are the options mentioned so = far and their +/-:
 
 
Each token type = gets its own name (which does not include the word =91oauth=92 in it), = as well as a matching HTTP authentication scheme if a new one is being = defined.
 
 
- = works cleanly with the HTTP authentication framework by simply defining = new methods or reusing existing ones.
- = schemes can be used outside the OAuth authorization flow (e.g. 2-legged = OAuth 1.0 use cases).
- all schemes are presented = equally without giving any a preferred treatment.
- = built-in discovery using 401 challenge header for which schemes are = supported (with their respective information).
Downsides:
- potential creation of many new = HTTP authentication schemes which has been stable for a long = time.
 
2. Single OAuth2 = scheme with sub-schemes
 
 
 
- = single scheme, reuse of the 1.0 pattern.
Downsides:
- requires a new registry for = authentication header parameters.
- = schemes are not easily reusable outside OAuth.
- = existing frameworks usually switch on scheme name, not on sub scheme, = which will cause difficulty in some deployments.
- = potential to produce a very complicated scheme once many sub schemes are = added.
- requires its own discovery method for which = schemes are supported.
 
Benefits:
- makes the protocol a bit easier to = newbies since it will look all inclusive (authorization and = authentication).
 
 
- = makes reuse outside OAuth awkward without any technical = benefit.
 
Name the bearer token =91OAuth2=92 = and everything else gets a different name (with or without OAuth in = it).
 
 
- = Matches current draft.
 
 
- = Elevates bearer token to the preferred token type, instead of promoting = comparison of the various token types available.
- = Creates a very odd usage where the authorization server issues an access = token of type =91OAuth2=92 which is non-descriptive and very confusing = (since there are other token types).
- = Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization = protocol).
 
 
Please reply with = your preference by 2/10. As always, please provide feedback on the = options and analysis.
 
 
> itself, it's not the best name for this specific piece of >> functionality and Facebook too has a final migration server side to >> make for other features in the spec which weren't finalized when we >> implemented them. >>=20 >>=20 >> On Thu, Feb 3, 2011 at 8:42 AM, William Mills = wrote: >>> I=92m coming around to #1, I=92ll put my vote there. I do agree = that we have >>> usage out there of the OAuth2 scheme and we need not to break that, = how do >>> we solve that? >>>=20 >>>=20 >>>=20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of >>> Eran Hammer-Lahav >>> Sent: Thursday, February 03, 2011 12:34 AM >>> To: OAuth WG >>> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) >>>=20 >>>=20 >>>=20 >>> After a long back-and-forth, I think it is time to present a few = options and >>> have people express their preferences. >>>=20 >>>=20 >>>=20 >>> These are the options mentioned so far and their +/-: >>>=20 >>>=20 >>>=20 >>> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >>>=20 >>>=20 >>>=20 >>> Each token type gets its own name (which does not include the word = =91oauth=92 >>> in it), as well as a matching HTTP authentication scheme if a new = one is >>> being defined. >>>=20 >>>=20 >>>=20 >>> Benefits: >>>=20 >>>=20 >>>=20 >>> - works cleanly with the HTTP authentication framework by simply = defining >>> new methods or reusing existing ones. >>>=20 >>> - schemes can be used outside the OAuth authorization flow (e.g. = 2-legged >>> OAuth 1.0 use cases). >>>=20 >>> - all schemes are presented equally without giving any a preferred >>> treatment. >>>=20 >>> - built-in discovery using 401 challenge header for which schemes = are >>> supported (with their respective information). >>>=20 >>>=20 >>>=20 >>> Downsides: >>>=20 >>>=20 >>>=20 >>> - potential creation of many new HTTP authentication schemes which = has been >>> stable for a long time. >>>=20 >>>=20 >>>=20 >>> 2. Single OAuth2 scheme with sub-schemes >>>=20 >>>=20 >>>=20 >>> Define a single authentication scheme for all token types with some >>> attribute used to detect which scheme is actually being used. >>>=20 >>>=20 >>>=20 >>> Benefits: >>>=20 >>>=20 >>>=20 >>> - single scheme, reuse of the 1.0 pattern. >>>=20 >>>=20 >>>=20 >>> Downsides: >>>=20 >>>=20 >>>=20 >>> - requires a new registry for authentication header parameters. >>>=20 >>> - schemes are not easily reusable outside OAuth. >>>=20 >>> - existing frameworks usually switch on scheme name, not on sub = scheme, >>> which will cause difficulty in some deployments. >>>=20 >>> - potential to produce a very complicated scheme once many sub = schemes are >>> added. >>>=20 >>> - requires its own discovery method for which schemes are supported. >>>=20 >>>=20 >>>=20 >>> 3. Name prefix (e.g. oauth2_bearer) >>>=20 >>>=20 >>>=20 >>> Benefits: >>>=20 >>>=20 >>>=20 >>> - makes the protocol a bit easier to newbies since it will look all >>> inclusive (authorization and authentication). >>>=20 >>>=20 >>>=20 >>> Downsides: >>>=20 >>>=20 >>>=20 >>> - makes reuse outside OAuth awkward without any technical benefit. >>>=20 >>>=20 >>>=20 >>> 4. OAuth2 for bearer, MAC for mac >>>=20 >>>=20 >>>=20 >>> Name the bearer token =91OAuth2=92 and everything else gets a = different name >>> (with or without OAuth in it). >>>=20 >>>=20 >>>=20 >>> Benefits: >>>=20 >>>=20 >>>=20 >>> - Matches current draft. >>>=20 >>>=20 >>>=20 >>> Downsides: >>>=20 >>>=20 >>>=20 >>> - Elevates bearer token to the preferred token type, instead of = promoting >>> comparison of the various token types available. >>>=20 >>> - Creates a very odd usage where the authorization server issues an = access >>> token of type =91OAuth2=92 which is non-descriptive and very = confusing (since >>> there are other token types). >>>=20 >>> - Uses the name OAuth2 which stands for authorization in an = authentication >>> flow, continuing the confusion about what OAuth is (an authorization >>> protocol). >>>=20 >>>=20 >>>=20 >>> --- >>>=20 >>>=20 >>>=20 >>> Please reply with your preference by 2/10. As always, please provide >>> feedback on the options and analysis. >>>=20 >>>=20 >>>=20 >>> EHL >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Thu Feb 3 10:14:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BEE3A6A20 for ; Thu, 3 Feb 2011 10:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyEDVS-81kYY for ; Thu, 3 Feb 2011 10:14:36 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by core3.amsl.com (Postfix) with SMTP id 0EB3B3A69F3 for ; Thu, 3 Feb 2011 10:14:35 -0800 (PST) Received: from source ([74.125.82.178]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKTUrxVj4IdWha56NUgbYfPwYNunRJBsjs@postini.com; Thu, 03 Feb 2011 10:17:59 PST Received: by wyb42 with SMTP id 42so1507581wyb.23 for ; Thu, 03 Feb 2011 10:17:57 -0800 (PST) Received: by 10.227.164.70 with SMTP id d6mr11139130wby.167.1296757076449; Thu, 03 Feb 2011 10:17:56 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id x1sm318183wbh.14.2011.02.03.10.17.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 10:17:55 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1082) From: Skylar Woodward In-Reply-To: Date: Thu, 3 Feb 2011 19:17:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33F40F5E-02CD-4D44-B06C-59D41789019F@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: OAuth WG X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:14:37 -0000 While I'm mostly indifferent between #1 and #3, I cast my vote for #1 = for the sake of garnering consensus. Also, it seems important to some that the current specs be usable = outside of OAuth. While I'm not convinced there are sufficient other use = cases being examined to deliver the extra-OAuth value, I see no need = limit these ambitions by choice of scheme name. I'm also assuming that if the larger HTTP or IETF community would have = issue with how Auth scheme names are allocated (short vs. long, general = vs. specific) there would be some regulatory measure in place to address = that. As to the issue of backwards compatibility that William raises, my = earlier proposal is in line with what Eran just proposed. Moreover, the value of a working group would seem to be that the = community can work to consensus for the best possible design without = (and particularly so) the burden of supporting pre-standard systems. On Feb 3, 2011, at 6:41 PM, David Recordon wrote: > Also #1. While I feel for existing implementations of "OAuth2" by > itself, it's not the best name for this specific piece of > functionality and Facebook too has a final migration server side to > make for other features in the spec which weren't finalized when we > implemented them. >=20 >=20 > On Thu, Feb 3, 2011 at 8:42 AM, William Mills = wrote: >> I=92m coming around to #1, I=92ll put my vote there. I do agree = that we have >> usage out there of the OAuth2 scheme and we need not to break that, = how do >> we solve that? >>=20 >>=20 >>=20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of >> Eran Hammer-Lahav >> Sent: Thursday, February 03, 2011 12:34 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) >>=20 >>=20 >>=20 >> After a long back-and-forth, I think it is time to present a few = options and >> have people express their preferences. >>=20 >>=20 >>=20 >> These are the options mentioned so far and their +/-: >>=20 >>=20 >>=20 >> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >>=20 >>=20 >>=20 >> Each token type gets its own name (which does not include the word = =91oauth=92 >> in it), as well as a matching HTTP authentication scheme if a new one = is >> being defined. >>=20 >>=20 >>=20 >> Benefits: >>=20 >>=20 >>=20 >> - works cleanly with the HTTP authentication framework by simply = defining >> new methods or reusing existing ones. >>=20 >> - schemes can be used outside the OAuth authorization flow (e.g. = 2-legged >> OAuth 1.0 use cases). >>=20 >> - all schemes are presented equally without giving any a preferred >> treatment. >>=20 >> - built-in discovery using 401 challenge header for which schemes are >> supported (with their respective information). >>=20 >>=20 >>=20 >> Downsides: >>=20 >>=20 >>=20 >> - potential creation of many new HTTP authentication schemes which = has been >> stable for a long time. >>=20 >>=20 >>=20 >> 2. Single OAuth2 scheme with sub-schemes >>=20 >>=20 >>=20 >> Define a single authentication scheme for all token types with some >> attribute used to detect which scheme is actually being used. >>=20 >>=20 >>=20 >> Benefits: >>=20 >>=20 >>=20 >> - single scheme, reuse of the 1.0 pattern. >>=20 >>=20 >>=20 >> Downsides: >>=20 >>=20 >>=20 >> - requires a new registry for authentication header parameters. >>=20 >> - schemes are not easily reusable outside OAuth. >>=20 >> - existing frameworks usually switch on scheme name, not on sub = scheme, >> which will cause difficulty in some deployments. >>=20 >> - potential to produce a very complicated scheme once many sub = schemes are >> added. >>=20 >> - requires its own discovery method for which schemes are supported. >>=20 >>=20 >>=20 >> 3. Name prefix (e.g. oauth2_bearer) >>=20 >>=20 >>=20 >> Benefits: >>=20 >>=20 >>=20 >> - makes the protocol a bit easier to newbies since it will look all >> inclusive (authorization and authentication). >>=20 >>=20 >>=20 >> Downsides: >>=20 >>=20 >>=20 >> - makes reuse outside OAuth awkward without any technical benefit. >>=20 >>=20 >>=20 >> 4. OAuth2 for bearer, MAC for mac >>=20 >>=20 >>=20 >> Name the bearer token =91OAuth2=92 and everything else gets a = different name >> (with or without OAuth in it). >>=20 >>=20 >>=20 >> Benefits: >>=20 >>=20 >>=20 >> - Matches current draft. >>=20 >>=20 >>=20 >> Downsides: >>=20 >>=20 >>=20 >> - Elevates bearer token to the preferred token type, instead of = promoting >> comparison of the various token types available. >>=20 >> - Creates a very odd usage where the authorization server issues an = access >> token of type =91OAuth2=92 which is non-descriptive and very = confusing (since >> there are other token types). >>=20 >> - Uses the name OAuth2 which stands for authorization in an = authentication >> flow, continuing the confusion about what OAuth is (an authorization >> protocol). >>=20 >>=20 >>=20 >> --- >>=20 >>=20 >>=20 >> Please reply with your preference by 2/10. As always, please provide >> feedback on the options and analysis. >>=20 >>=20 >>=20 >> EHL >>=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 From wmills@yahoo-inc.com Thu Feb 3 10:18:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181873A67B8 for ; Thu, 3 Feb 2011 10:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.531 X-Spam-Level: X-Spam-Status: No, score=-17.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ1N4LgwBWLC for ; Thu, 3 Feb 2011 10:18:13 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 223ED3A67CC for ; Thu, 3 Feb 2011 10:18:12 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p13IL24q082072; Thu, 3 Feb 2011 10:21:02 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Thu, 3 Feb 2011 10:21:02 -0800 From: William Mills To: Phil Hunt , Mike Jones Date: Thu, 3 Feb 2011 10:21:00 -0800 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDzpEJGcut8jBoRSmUAvho8NmK0wAAHkzA Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D4AEF98.4060101@stpeter.im> <72132254-CC56-4507-9993-8D856103CDC0@oracle.com> In-Reply-To: <72132254-CC56-4507-9993-8D856103CDC0@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@ietf.org" Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:18:14 -0000 +1 for reserving the legacy behavior as well. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, February 03, 2011 10:15 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-03, at 10:10 AM, Peter Saint-Andre wrote: >=20 > > With my individual contributor hat on, I too prefer #1 -- it's just a > > lot cleaner to my mind. > > > > On 2/3/11 6:41 PM, David Recordon wrote: > >> Also #1. While I feel for existing implementations of "OAuth2" by > >> itself, it's not the best name for this specific piece of > >> functionality and Facebook too has a final migration server side to > >> make for other features in the spec which weren't finalized when we > >> implemented them. > >> > >> > >> On Thu, Feb 3, 2011 at 8:42 AM, William Mills > wrote: > >>> I'm coming around to #1, I'll put my vote there. I do agree that > we have > >>> usage out there of the OAuth2 scheme and we need not to break that, > how do > >>> we solve that? > >>> > >>> > >>> > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of > >>> Eran Hammer-Lahav > >>> Sent: Thursday, February 03, 2011 12:34 AM > >>> To: OAuth WG > >>> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > >>> > >>> > >>> > >>> After a long back-and-forth, I think it is time to present a few > options and > >>> have people express their preferences. > >>> > >>> > >>> > >>> These are the options mentioned so far and their +/-: > >>> > >>> > >>> > >>> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > >>> > >>> > >>> > >>> Each token type gets its own name (which does not include the word > 'oauth' > >>> in it), as well as a matching HTTP authentication scheme if a new > one is > >>> being defined. > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - works cleanly with the HTTP authentication framework by simply > defining > >>> new methods or reusing existing ones. > >>> > >>> - schemes can be used outside the OAuth authorization flow (e.g. 2- > legged > >>> OAuth 1.0 use cases). > >>> > >>> - all schemes are presented equally without giving any a preferred > >>> treatment. > >>> > >>> - built-in discovery using 401 challenge header for which schemes > are > >>> supported (with their respective information). > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - potential creation of many new HTTP authentication schemes which > has been > >>> stable for a long time. > >>> > >>> > >>> > >>> 2. Single OAuth2 scheme with sub-schemes > >>> > >>> > >>> > >>> Define a single authentication scheme for all token types with some > >>> attribute used to detect which scheme is actually being used. > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - single scheme, reuse of the 1.0 pattern. > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - requires a new registry for authentication header parameters. > >>> > >>> - schemes are not easily reusable outside OAuth. > >>> > >>> - existing frameworks usually switch on scheme name, not on sub > scheme, > >>> which will cause difficulty in some deployments. > >>> > >>> - potential to produce a very complicated scheme once many sub > schemes are > >>> added. > >>> > >>> - requires its own discovery method for which schemes are > supported. > >>> > >>> > >>> > >>> 3. Name prefix (e.g. oauth2_bearer) > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - makes the protocol a bit easier to newbies since it will look all > >>> inclusive (authorization and authentication). > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - makes reuse outside OAuth awkward without any technical benefit. > >>> > >>> > >>> > >>> 4. OAuth2 for bearer, MAC for mac > >>> > >>> > >>> > >>> Name the bearer token 'OAuth2' and everything else gets a different > name > >>> (with or without OAuth in it). > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - Matches current draft. > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - Elevates bearer token to the preferred token type, instead of > promoting > >>> comparison of the various token types available. > >>> > >>> - Creates a very odd usage where the authorization server issues an > access > >>> token of type 'OAuth2' which is non-descriptive and very confusing > (since > >>> there are other token types). > >>> > >>> - Uses the name OAuth2 which stands for authorization in an > authentication > >>> flow, continuing the confusion about what OAuth is (an > authorization > >>> protocol). > >>> > >>> > >>> > >>> --- > >>> > >>> > >>> > >>> Please reply with your preference by 2/10. As always, please > provide > >>> feedback on the options and analysis. > >>> > >>> > >>> > >>> 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 From michael.d.adams@gmail.com Thu Feb 3 10:27:07 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334D13A6767 for ; Thu, 3 Feb 2011 10:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry034sjM3syW for ; Thu, 3 Feb 2011 10:27:06 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2747D3A6452 for ; Thu, 3 Feb 2011 10:27:05 -0800 (PST) Received: by fxm9 with SMTP id 9so1580343fxm.31 for ; Thu, 03 Feb 2011 10:30:28 -0800 (PST) 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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fR39MGp+28xOP/UvHZNEDD4G40oSCgUqRTSzTCYxV/8=; b=tTTxjyRpFiLBGvAGdN+/3ie0z4BW+LI0O46knXlQzjRiSe4ZXZS4Lz6c/9ysYp9fcm CCZIyvdkEAxBitzPBaShx0a70DXsVUya5kW6DCzOE3pPeoMxmZ+k9gCj3EMmf76j/ef2 jBlRuZbFXbrWuC1g8Um7ztiycJzrhQcvHf8Ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=NU+G2mIjcediPJKhcc215q6bFGvVDxrgnVhjq8PZL2HG7jlyu3lDx5I/iQNmuV5w2b ttse97Li8lsHhuGMYFRNPdaCzBT3d7IvQZ7rgzeWMofR1rgZaKX8zp9RyWutQCwav14p x5HKeX8Cx94l1QekL0yBkcL5uRCA4L2oYkBL8= Received: by 10.223.123.142 with SMTP id p14mr10266219far.56.1296757828526; Thu, 03 Feb 2011 10:30:28 -0800 (PST) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.223.74.202 with HTTP; Thu, 3 Feb 2011 10:30:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Michael D Adams Date: Thu, 3 Feb 2011 10:30:00 -0800 X-Google-Sender-Auth: 3uecRc6d8WhqPTq2yfqAvirx8oI Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:27:07 -0000 On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav wrote: > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) I vote #1. In addition to the pros/cons Eran mentioned, it seems the simplest and cleanest so will cause the least confusion. William and others brought up backward compatibily, but, supposing #1 "wins", I don't see a need to support "legacy" #4 in the spec. I feel it can be addressed by implementors without loss of full compliance. Phil's note about reserving OAUTH2 as a scheme name makes more sense to me than supporting it. I do not disagree with any of Eran's analysis, though #4, which I am voting against, has a couple of the same benefits as #1: - works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones. - built-in discovery using 401 challenge header for which schemes are supported (with their respective information). Mike Adams From igor.faynberg@alcatel-lucent.com Thu Feb 3 10:28:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155FB3A676A for ; Thu, 3 Feb 2011 10:28:53 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB-odm-xLfuD for ; Thu, 3 Feb 2011 10:28:52 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id CDD413A6452 for ; Thu, 3 Feb 2011 10:28:51 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p13IWESZ027030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 12:32:14 -0600 (CST) 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 p13IWDv9011674; Thu, 3 Feb 2011 12:32:13 -0600 (CST) Message-ID: <4D4AF4AD.5070704@alcatel-lucent.com> Date: Thu, 03 Feb 2011 13:32:13 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: William Mills References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D4AEF98.4060101@stpeter.im> <72132254-CC56-4507-9993-8D856103CDC0@oracle.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.35 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 03 Feb 2011 18:28:53 -0000 (How pleasant it is to agree with everyone!) +1 Igor William Mills wrote: > +1 for reserving the legacy behavior as well. > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Phil Hunt >> Sent: Thursday, February 03, 2011 10:15 AM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >> >> BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour. >> >> Phil >> phil.hunt@oracle.com >> >> >> >> >> On 2011-02-03, at 10:10 AM, Peter Saint-Andre wrote: >> >> >>> With my individual contributor hat on, I too prefer #1 -- it's just a >>> lot cleaner to my mind. >>> >>> On 2/3/11 6:41 PM, David Recordon wrote: >>> >>>> Also #1. While I feel for existing implementations of "OAuth2" by >>>> itself, it's not the best name for this specific piece of >>>> functionality and Facebook too has a final migration server side to >>>> make for other features in the spec which weren't finalized when we >>>> implemented them. >>>> >>>> >>>> On Thu, Feb 3, 2011 at 8:42 AM, William Mills >>>> >> wrote: >> >>>>> I'm coming around to #1, I'll put my vote there. I do agree that >>>>> >> we have >> >>>>> usage out there of the OAuth2 scheme and we need not to break that, >>>>> >> how do >> >>>>> we solve that? >>>>> >>>>> >>>>> >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> >> Behalf Of >> >>>>> Eran Hammer-Lahav >>>>> Sent: Thursday, February 03, 2011 12:34 AM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: >>>>> >> 2/10) >> >>>>> >>>>> After a long back-and-forth, I think it is time to present a few >>>>> >> options and >> >>>>> have people express their preferences. >>>>> >>>>> >>>>> >>>>> These are the options mentioned so far and their +/-: >>>>> >>>>> >>>>> >>>>> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >>>>> >>>>> >>>>> >>>>> Each token type gets its own name (which does not include the word >>>>> >> 'oauth' >> >>>>> in it), as well as a matching HTTP authentication scheme if a new >>>>> >> one is >> >>>>> being defined. >>>>> >>>>> >>>>> >>>>> Benefits: >>>>> >>>>> >>>>> >>>>> - works cleanly with the HTTP authentication framework by simply >>>>> >> defining >> >>>>> new methods or reusing existing ones. >>>>> >>>>> - schemes can be used outside the OAuth authorization flow (e.g. 2- >>>>> >> legged >> >>>>> OAuth 1.0 use cases). >>>>> >>>>> - all schemes are presented equally without giving any a preferred >>>>> treatment. >>>>> >>>>> - built-in discovery using 401 challenge header for which schemes >>>>> >> are >> >>>>> supported (with their respective information). >>>>> >>>>> >>>>> >>>>> Downsides: >>>>> >>>>> >>>>> >>>>> - potential creation of many new HTTP authentication schemes which >>>>> >> has been >> >>>>> stable for a long time. >>>>> >>>>> >>>>> >>>>> 2. Single OAuth2 scheme with sub-schemes >>>>> >>>>> >>>>> >>>>> Define a single authentication scheme for all token types with some >>>>> attribute used to detect which scheme is actually being used. >>>>> >>>>> >>>>> >>>>> Benefits: >>>>> >>>>> >>>>> >>>>> - single scheme, reuse of the 1.0 pattern. >>>>> >>>>> >>>>> >>>>> Downsides: >>>>> >>>>> >>>>> >>>>> - requires a new registry for authentication header parameters. >>>>> >>>>> - schemes are not easily reusable outside OAuth. >>>>> >>>>> - existing frameworks usually switch on scheme name, not on sub >>>>> >> scheme, >> >>>>> which will cause difficulty in some deployments. >>>>> >>>>> - potential to produce a very complicated scheme once many sub >>>>> >> schemes are >> >>>>> added. >>>>> >>>>> - requires its own discovery method for which schemes are >>>>> >> supported. >> >>>>> >>>>> 3. Name prefix (e.g. oauth2_bearer) >>>>> >>>>> >>>>> >>>>> Benefits: >>>>> >>>>> >>>>> >>>>> - makes the protocol a bit easier to newbies since it will look all >>>>> inclusive (authorization and authentication). >>>>> >>>>> >>>>> >>>>> Downsides: >>>>> >>>>> >>>>> >>>>> - makes reuse outside OAuth awkward without any technical benefit. >>>>> >>>>> >>>>> >>>>> 4. OAuth2 for bearer, MAC for mac >>>>> >>>>> >>>>> >>>>> Name the bearer token 'OAuth2' and everything else gets a different >>>>> >> name >> >>>>> (with or without OAuth in it). >>>>> >>>>> >>>>> >>>>> Benefits: >>>>> >>>>> >>>>> >>>>> - Matches current draft. >>>>> >>>>> >>>>> >>>>> Downsides: >>>>> >>>>> >>>>> >>>>> - Elevates bearer token to the preferred token type, instead of >>>>> >> promoting >> >>>>> comparison of the various token types available. >>>>> >>>>> - Creates a very odd usage where the authorization server issues an >>>>> >> access >> >>>>> token of type 'OAuth2' which is non-descriptive and very confusing >>>>> >> (since >> >>>>> there are other token types). >>>>> >>>>> - Uses the name OAuth2 which stands for authorization in an >>>>> >> authentication >> >>>>> flow, continuing the confusion about what OAuth is (an >>>>> >> authorization >> >>>>> protocol). >>>>> >>>>> >>>>> >>>>> --- >>>>> >>>>> >>>>> >>>>> Please reply with your preference by 2/10. As always, please >>>>> >> provide >> >>>>> feedback on the options and analysis. >>>>> >>>>> >>>>> >>>>> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Thu Feb 3 10:32:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE59C3A6A60 for ; Thu, 3 Feb 2011 10:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.834 X-Spam-Level: X-Spam-Status: No, score=-105.834 tagged_above=-999 required=5 tests=[AWL=0.143, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjZw3dacKms9 for ; Thu, 3 Feb 2011 10:32:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AFB813A6A5F for ; Thu, 3 Feb 2011 10:32:30 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p13IZrCc030595 for ; Thu, 3 Feb 2011 10:35:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296758153; bh=DBl4RdlEuTGvjanbtrIlYsxBv8s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=s+s9OA3YkqZk7xCJcL2xxxkpGPT5mWW9EqQx1oEIwI6CzZH4nBoxu3mR8YWBGeVri DM4w0exDyjfE/bFxkkRPA== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by wpaz24.hot.corp.google.com with ESMTP id p13IZqs0003265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 3 Feb 2011 10:35:52 -0800 Received: by yxl31 with SMTP id 31so658284yxl.14 for ; Thu, 03 Feb 2011 10:35:52 -0800 (PST) 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=p+0k60yctCUCuky8PYWA7ywa9BiooI+v3XKzqIAxJx4=; b=gmEgZGTM+EAGz5XMtekCMGNtDF7q3CqyzXvwZU1ZdjQor2b6sPxX8nGvZLmtM+eryD gCvvaE+f7J17F7DGkByA== 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=iz1F1R3LZ83gNjNysb8lAP93YEPZRAjb25mjhWCCS9SGS7llOBjk2+xzNKx+sD+uU7 YjV+NA2SB1M+QVEbwhEQ== Received: by 10.100.227.17 with SMTP id z17mr6924442ang.214.1296758152075; Thu, 03 Feb 2011 10:35:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Thu, 3 Feb 2011 10:35:31 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 3 Feb 2011 10:35:31 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:32:31 -0000 On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav wrote: > 2. Single OAuth2 scheme with sub-schemes > > Define a single authentication scheme for all token types with some > attribute used to detect which scheme is actually being used. > > Benefits: > > - single scheme, reuse of the 1.0 pattern. > > Downsides: > > - requires a new registry for authentication header parameters. How is this different from option 1? Wouldn't that need some registry? > - schemes are not easily reusable outside OAuth. Sure. But I really don't see this group trying to create generic authentication schemes. > - existing frameworks usually switch on scheme name, not on sub scheme, > which will cause difficulty in some deployments. I can see this as a potential problem. But considering that there wasn't much objection to use "OAuth" as a scheme name before (total overlap with OAuth 1, and the suggested solution was to look for the signature parameter) I don't see how this is suddenly an issue. Do we have a concrete problem here or this is just theoretical? > - potential to produce a very complicated scheme once many sub schemes are > added. Why? I would argue that this option actually produces more uniform schemes because it forces all of them to be name/value pairs. Beyond token_type everything is scheme specific. I really don't see what is very complicate here. > - requires its own discovery method for which schemes are supported. Why is this a downside only for this option? Marius From eran@hueniverse.com Thu Feb 3 11:36:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7593A6A4C for ; Thu, 3 Feb 2011 11:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piObQzZphuIR for ; Thu, 3 Feb 2011 11:36:00 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9DF4F3A67B0 for ; Thu, 3 Feb 2011 11:36:00 -0800 (PST) Received: (qmail 20961 invoked from network); 3 Feb 2011 19:39:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Feb 2011 19:39:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Feb 2011 12:39:15 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Thu, 3 Feb 2011 12:39:07 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvD0TLrHEo3bywlTR6UI25xgf3CBQAB8Dmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 19:36:01 -0000 Hey Marius, > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, February 03, 2011 10:36 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > wrote: >=20 > > 2. Single OAuth2 scheme with sub-schemes > > > > Define a single authentication scheme for all token types with some > > attribute used to detect which scheme is actually being used. > > > > Benefits: > > > > - single scheme, reuse of the 1.0 pattern. > > > > Downsides: > > > > - requires a new registry for authentication header parameters. >=20 > How is this different from option 1? Wouldn't that need some registry? #1 relies on the existing practice of creating HTTP scheme names (no curren= t registry but httpbis might be creating one), as well as the -12 token typ= e registry. Using a sub-scheme means you also need a registry for the heade= r attributes that each token type will need (unless you just don't care abo= ut using the same attribute name for different needs). > > - schemes are not easily reusable outside OAuth. >=20 > Sure. But I really don't see this group trying to create generic authenti= cation > schemes. MAC is exactly that. =20 > > - existing frameworks usually switch on scheme name, not on sub > > scheme, which will cause difficulty in some deployments. >=20 > I can see this as a potential problem. But considering that there wasn't = much > objection to use "OAuth" as a scheme name before (total overlap with > OAuth 1, and the suggested solution was to look for the signature > parameter) I don't see how this is suddenly an issue. There was pretty strong objection to reusing OAuth. > Do we have a concrete problem here or this is just theoretical? This came up during the review of draft-hammer-http-token-auth [1]. There w= as a long thread about it where people posted actual framework issues. =20 > > - potential to produce a very complicated scheme once many sub schemes > > are added. >=20 > Why? I would argue that this option actually produces more uniform > schemes because it forces all of them to be name/value pairs. Beyond > token_type everything is scheme specific. I really don't see what is very > complicate here. It is still a single scheme with many different sub-schemes, each with diff= erent key-value pairs that may have conflicting meaning. The way I look at = it is that if I try to fully implement this mega scheme (which means all it= s sub-schemes), it will likely be a complicated task. On the other hand, if= you split it across scheme name, we already have a well-established system= in place to pick and choose HTTP authentication schemes. =20 > > - requires its own discovery method for which schemes are supported. >=20 > Why is this a downside only for this option? Because the other options get this for free by using the WWW-Authenticate h= eader (since each scheme has a unique name). You can list multiple headers = in the 401 response. Should I record your vote for #2? EHL [1] http://tools.ietf.org/html/draft-hammer-http-token-auth-01 From phil.hunt@oracle.com Thu Feb 3 12:23:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219343A6AE2 for ; Thu, 3 Feb 2011 12:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG5R8kC-uw1u for ; Thu, 3 Feb 2011 12:23:37 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 228153A6AE1 for ; Thu, 3 Feb 2011 12:23:37 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p13KQtJw004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Feb 2011 20:26:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p13Jp0rK007123 for ; Thu, 3 Feb 2011 20:26:54 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 978077131296764811; Thu, 03 Feb 2011 12:26:51 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 12:26:51 -0800 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 12:26:47 -0800 Message-Id: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D4B0F8F.013B:SCFMA4539814,ss=1,fgs=0 Subject: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 20:23:38 -0000 In 5.1 (draft 12), if a refresh_token is returned with an access_token, = what does expires_in refer to? Strict reading of the spec says it refers = to the access_token, but isn't lifetime of the refresh token as = important? Should there be a similar "refresh_expires_in"? Apologies if this was discussed before. Phil phil.hunt@oracle.com From wmills@yahoo-inc.com Thu Feb 3 12:40:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE84F3A6AEC for ; Thu, 3 Feb 2011 12:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.367 X-Spam-Level: X-Spam-Status: No, score=-17.367 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5Z2amH+PAPk for ; Thu, 3 Feb 2011 12:40:34 -0800 (PST) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 210373A6405 for ; Thu, 3 Feb 2011 12:40:34 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p13Khblt000785; Thu, 3 Feb 2011 12:43:37 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Thu, 3 Feb 2011 12:43:36 -0800 From: William Mills To: Phil Hunt , OAuth WG Date: Thu, 3 Feb 2011 12:43:35 -0800 Thread-Topic: [OAUTH-WG] Refresh Token and Expires_in Thread-Index: AcvD4Mfmc0XVpLqfQNW0UjQ/4MPw6wAAiMRQ Message-ID: References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> In-Reply-To: <813E07E4-C925-4550-A3D1-580A6A871036@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 Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 20:40:34 -0000 The general use case for refresh tokens is that they don't have a lifetime,= although they can be invalidated by various things. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, February 03, 2011 12:27 PM > To: OAuth WG > Subject: [OAUTH-WG] Refresh Token and Expires_in >=20 > In 5.1 (draft 12), if a refresh_token is returned with an access_token, > what does expires_in refer to? Strict reading of the spec says it > refers to the access_token, but isn't lifetime of the refresh token as > important? Should there be a similar "refresh_expires_in"? >=20 > Apologies if this was discussed before. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jhart@photobucket.com Thu Feb 3 12:43:39 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C153A6AF4 for ; Thu, 3 Feb 2011 12:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2XDEpgJtpJU for ; Thu, 3 Feb 2011 12:43:38 -0800 (PST) Received: from exhub003-1.exch003intermedia.net (exhub003-1.exch003intermedia.net [207.5.74.28]) by core3.amsl.com (Postfix) with ESMTP id 33CB13A6405 for ; Thu, 3 Feb 2011 12:43:38 -0800 (PST) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by exhub003-1.exch003intermedia.net ([207.5.74.28]) with mapi; Thu, 3 Feb 2011 12:47:01 -0800 From: Justin Hart To: Eran Hammer-Lahav Date: Thu, 3 Feb 2011 12:47:00 -0800 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvD44GhTbIi8isnSX6wR5aBHTkwsw== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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_EFB76CD3E1EA4DDC853E8F71E0933945photobucketcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 20:43:39 -0000 --_000_EFB76CD3E1EA4DDC853E8F71E0933945photobucketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable #1, which is nice to support the OAuth2 scheme as previously discussed (Hun= t, etc) as a legacy type (can be specified in a migration spec). ---- -- Justin Hart -- jhart@photobucket.com On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote: After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word =91oauth= =92 in it), as well as a matching HTTP authentication scheme if a new one i= s being defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token =91OAuth2=92 and everything else gets a different nam= e (with or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type =91OAuth2=92 which is non-descriptive and very confusing (sin= ce there are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_EFB76CD3E1EA4DDC853E8F71E0933945photobucketcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable #1, which is nice to support the OAuth2 scheme as previously discussed (Hu= nt, etc) as a legacy type (can be specified in a migration spec).
----
-- Justin Hart



=


On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote:
After a long back-and-forth, I think it is time to present a few option= s and have people express their preferences.
 <= /div>
These are the options mentioned so far and their +/-:
&nb= sp;
1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
 
Each token type gets its own name (which does = not include the word =91oauth=92 in it), as well as a matching HTTP authent= ication scheme if a new one is being defined.
 =
 
- works cleanly with the HTTP au= thentication framework by simply defining new methods or reusing existing o= nes.
- schemes can be used outside the OAuth authorization flow= (e.g. 2-legged OAuth 1.0 use cases).
- all schemes are present= ed equally without giving any a preferred treatment.
- built-in= discovery using 401 challenge header for which schemes are supported (with= their respective information).
 
Downsides:
 
- potential creation of many new HTTP authent= ication schemes which has been stable for a long time.
&nb= sp;
2. Single OAuth2 scheme with sub-schemes
 =
Define a single authentication scheme for all token types with some= attribute used to detect which scheme is actually being used.
=  
Benefits:
 
- single schem= e, reuse of the 1.0 pattern.
 
Downsides:
 
- requires a new registry for authentication he= ader parameters.
- schemes are not easily reusable outside OAut= h.
- existing frameworks usually switch on scheme name, not on = sub scheme, which will cause difficulty in some deployments.
- = potential to produce a very complicated scheme once many sub schemes are ad= ded.
- requires its own discovery method for which schemes are = supported.
 
3. Name prefix (e.g. oauth2_beare= r)
 
Benefits:
 
= - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication).
 
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Downs= ides:
 
- makes reuse outside OAuth awkward wi= thout any technical benefit.
 
4. OAuth2 for = bearer, MAC for mac
 
Name the bearer token = =91OAuth2=92 and everything else gets a different name (with or without OAu= th in it).
 
Benefits:
 =
- Matches current draft.
 
Downsides:<= o:p>
 
- Elevates bearer token to the preferred tok= en type, instead of promoting comparison of the various token types availab= le.
- Creates a very odd usage where the authorization server i= ssues an access token of type =91OAuth2=92 which is non-descriptive and ver= y confusing (since there are other token types).
- Uses the nam= e OAuth2 which stands for authorization in an authentication flow, continui= ng the confusion about what OAuth is (an authorization protocol).
---
 
Please reply with = your preference by 2/10. As always, please provide feedback on the options = and analysis.
 
EHL
 
 
<ATT00001..txt>
<= /span>

= --_000_EFB76CD3E1EA4DDC853E8F71E0933945photobucketcom_-- From phil.hunt@oracle.com Thu Feb 3 13:36:59 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7852F3A69F7 for ; Thu, 3 Feb 2011 13:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVkPTRPULxiz for ; Thu, 3 Feb 2011 13:36:58 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6FB1E3A69EE for ; Thu, 3 Feb 2011 13:36:58 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p13LeIOc013680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Feb 2011 21:40:20 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p13LeEN0010645; Thu, 3 Feb 2011 21:40:15 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 1021503711296769119; Thu, 03 Feb 2011 13:38:39 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 13:38:38 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Thu, 3 Feb 2011 13:38:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9FE8761E-2EE4-4593-B983-2C76C7407C58@oracle.com> References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> To: William Mills X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D4B20C1.00EB:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:36:59 -0000 Thanks. This makes sense. I'm wondering if there should be some = explanative text under "refresh_token". Yet, it doesn't make all that = much sense to define why something isn't there. Never-the-less, it just = seem like an awkward omission after reading it. I do note, that section 6 (Refreshing an Access Token) does not indicate = any standard error responses. This seems to be covered by section 5. The second last paragraph in 6 states: "If valid, the authorization = server issues an access token response as described in Section 5".=20 Maybe that should read:=20 "The authorization server issues a response as described in Section 5". = So in this case, invalid_grant error would be generated. Regards, Phil phil.hunt@oracle.com On 2011-02-03, at 12:43 PM, William Mills wrote: > The general use case for refresh tokens is that they don't have a = lifetime, although they can be invalidated by various things. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Phil Hunt >> Sent: Thursday, February 03, 2011 12:27 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Refresh Token and Expires_in >>=20 >> In 5.1 (draft 12), if a refresh_token is returned with an = access_token, >> what does expires_in refer to? Strict reading of the spec says it >> refers to the access_token, but isn't lifetime of the refresh token = as >> important? Should there be a similar "refresh_expires_in"? >>=20 >> Apologies if this was discussed before. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Thu Feb 3 15:18:16 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F1B3A688A for ; Thu, 3 Feb 2011 15:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnbw11yZZzql for ; Thu, 3 Feb 2011 15:18:15 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by core3.amsl.com (Postfix) with ESMTP id 3F0863A687A for ; Thu, 3 Feb 2011 15:18:14 -0800 (PST) Received: from source ([209.85.161.49]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTUs4gdkgz5P/rIQDgvw2ObTFE+OgI9Ew@postini.com; Thu, 03 Feb 2011 15:21:39 PST Received: by mail-fx0-f49.google.com with SMTP id 19so1745121fxm.8 for ; Thu, 03 Feb 2011 15:21:37 -0800 (PST) Received: by 10.223.93.139 with SMTP id v11mr10527898fam.132.1296775297692; Thu, 03 Feb 2011 15:21:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Thu, 3 Feb 2011 15:21:06 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Thu, 3 Feb 2011 16:21:06 -0700 Message-ID: To: oauth Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:18:16 -0000 Also #1 On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart wrote: > #1, which is nice to support the OAuth2 scheme as previously discussed > (Hunt, etc) as a legacy type (can be specified in a migration spec). > ---- > -- Justin Hart > -- jhart@photobucket.com > > > > > > On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote: > > After a long back-and-forth, I think it is time to present a few options = and > have people express their preferences. > > These are the options mentioned so far and their +/-: > > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > > Each token type gets its own name (which does not include the word =91oau= th=92 > in it), as well as a matching HTTP authentication scheme if a new one is > being defined. > > Benefits: > > - works cleanly with the HTTP authentication framework by simply defining > new methods or reusing existing ones. > - schemes can be used outside the OAuth authorization flow (e.g. 2-legged > OAuth 1.0 use cases). > - all schemes are presented equally without giving any a preferred > treatment. > - built-in discovery using 401 challenge header for which schemes are > supported (with their respective information). > > Downsides: > > - potential creation of many new HTTP authentication schemes which has be= en > stable for a long time. > > 2. Single OAuth2 scheme with sub-schemes > > Define a single authentication scheme for all token types with some > attribute used to detect which scheme is actually being used. > > Benefits: > > - single scheme, reuse of the 1.0 pattern. > > Downsides: > > - requires a new registry for authentication header parameters. > - schemes are not easily reusable outside OAuth. > - existing frameworks usually switch on scheme name, not on sub scheme, > which will cause difficulty in some deployments. > - potential to produce a very complicated scheme once many sub schemes ar= e > added. > - requires its own discovery method for which schemes are supported. > > 3. Name prefix (e.g. oauth2_bearer) > > Benefits: > > - makes the protocol a bit easier to newbies since it will look all > inclusive (authorization and authentication). > > Downsides: > > - makes reuse outside OAuth awkward without any technical benefit. > > 4. OAuth2 for bearer, MAC for mac > > Name the bearer token =91OAuth2=92 and everything else gets a different n= ame > (with or without OAuth in it). > > Benefits: > > - Matches current draft. > > Downsides: > > - Elevates bearer token to the preferred token type, instead of promoting > comparison of the various token types available. > - Creates a very odd usage where the authorization server issues an acces= s > token of type =91OAuth2=92 which is non-descriptive and very confusing (s= ince > there are other token types). > - Uses the name OAuth2 which stands for authorization in an authenticatio= n > flow, continuing the confusion about what OAuth is (an authorization > protocol). > > --- > > Please reply with your preference by 2/10. As always, please provide > feedback on the options and analysis. > > EHL > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From lshepard@fb.com Thu Feb 3 16:13:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410073A6B57 for ; Thu, 3 Feb 2011 16:13:46 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbUJTa45IfUU for ; Thu, 3 Feb 2011 16:13:45 -0800 (PST) Received: from mx-out.facebook.com (outmail009.snc4.facebook.com [66.220.144.141]) by core3.amsl.com (Postfix) with ESMTP id DE8D53A6B50 for ; Thu, 3 Feb 2011 16:13:43 -0800 (PST) Received: from [192.168.18.212] ([192.168.18.212:55210] helo=mail.thefacebook.com) by mta013.snc4.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(37388)) with ESMTP id 45/3F-28233-D754B4D4; Thu, 03 Feb 2011 16:17:01 -0800 Received: from SC-MBX02-5.TheFacebook.com ([fe80::9dc2:cfe6:2745:44cc]) by sc-hub04.TheFacebook.com ([192.168.18.212]) with mapi id 14.01.0218.012; Thu, 3 Feb 2011 16:17:00 -0800 From: Luke Shepard To: Brian Campbell Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwAqjFcAAAVhwwAAAfVsgA== Date: Fri, 4 Feb 2011 00:17:00 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.18.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:13:46 -0000 +1 #1 On Feb 3, 2011, at 3:21 PM, Brian Campbell wrote: > Also #1 >=20 > On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart wrote= : >> #1, which is nice to support the OAuth2 scheme as previously discussed >> (Hunt, etc) as a legacy type (can be specified in a migration spec). >> ---- >> -- Justin Hart >> -- jhart@photobucket.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote: >>=20 >> After a long back-and-forth, I think it is time to present a few options= and >> have people express their preferences. >>=20 >> These are the options mentioned so far and their +/-: >>=20 >> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >>=20 >> Each token type gets its own name (which does not include the word =91oa= uth=92 >> in it), as well as a matching HTTP authentication scheme if a new one is >> being defined. >>=20 >> Benefits: >>=20 >> - works cleanly with the HTTP authentication framework by simply definin= g >> new methods or reusing existing ones. >> - schemes can be used outside the OAuth authorization flow (e.g. 2-legge= d >> OAuth 1.0 use cases). >> - all schemes are presented equally without giving any a preferred >> treatment. >> - built-in discovery using 401 challenge header for which schemes are >> supported (with their respective information). >>=20 >> Downsides: >>=20 >> - potential creation of many new HTTP authentication schemes which has b= een >> stable for a long time. >>=20 >> 2. Single OAuth2 scheme with sub-schemes >>=20 >> Define a single authentication scheme for all token types with some >> attribute used to detect which scheme is actually being used. >>=20 >> Benefits: >>=20 >> - single scheme, reuse of the 1.0 pattern. >>=20 >> Downsides: >>=20 >> - requires a new registry for authentication header parameters. >> - schemes are not easily reusable outside OAuth. >> - existing frameworks usually switch on scheme name, not on sub scheme, >> which will cause difficulty in some deployments. >> - potential to produce a very complicated scheme once many sub schemes a= re >> added. >> - requires its own discovery method for which schemes are supported. >>=20 >> 3. Name prefix (e.g. oauth2_bearer) >>=20 >> Benefits: >>=20 >> - makes the protocol a bit easier to newbies since it will look all >> inclusive (authorization and authentication). >>=20 >> Downsides: >>=20 >> - makes reuse outside OAuth awkward without any technical benefit. >>=20 >> 4. OAuth2 for bearer, MAC for mac >>=20 >> Name the bearer token =91OAuth2=92 and everything else gets a different = name >> (with or without OAuth in it). >>=20 >> Benefits: >>=20 >> - Matches current draft. >>=20 >> Downsides: >>=20 >> - Elevates bearer token to the preferred token type, instead of promotin= g >> comparison of the various token types available. >> - Creates a very odd usage where the authorization server issues an acce= ss >> token of type =91OAuth2=92 which is non-descriptive and very confusing (= since >> there are other token types). >> - Uses the name OAuth2 which stands for authorization in an authenticati= on >> flow, continuing the confusion about what OAuth is (an authorization >> protocol). >>=20 >> --- >>=20 >> Please reply with your preference by 2/10. As always, please provide >> feedback on the options and analysis. >>=20 >> EHL >>=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 From matake@gmail.com Thu Feb 3 16:16:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFC53A6B57 for ; Thu, 3 Feb 2011 16:16:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1p+bJTbVAAU for ; Thu, 3 Feb 2011 16:16:40 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EA9283A6A05 for ; Thu, 3 Feb 2011 16:16:39 -0800 (PST) Received: by gxk27 with SMTP id 27so801693gxk.31 for ; Thu, 03 Feb 2011 16:20:03 -0800 (PST) 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=pDxKVDbRgYZ3gPCEl4qbVcHXar4GClApnkpojDAv9KE=; b=GE+VF0T/ZZQ2vo5+m2ahJg39Vu3lrN8FDVvH0tiOQNBwGLF3eyCc49DFV/PlP0TEYN TrKlOm1vExRtPtCApuHQQeoVasXFCocoaWJCY8QgTDZfm3J95nL6lWMYa1n2L4HwHHkH awk4yS3rKQmq+B6vwugQ/Y/Jykw1ub/RZlixU= 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=l7E5pysQ1TuaAsJllNR/RsSRW7L04zwLnv2hgy5ZUGSjstt2faesHU4ZeYsF1Z6JNr syzUNus46IkkWQhaVRf713oCyRkUVbPhgqT+N/uXNbjsPYVI5yFFXLf1WDsmxKppFneR 6bphjPu5j2iJnAZovu/2+j/RmM9BtZwi+QOfQ= Received: by 10.101.68.18 with SMTP id v18mr7179229ank.41.1296778801474; Thu, 03 Feb 2011 16:20:01 -0800 (PST) Received: from [10.0.1.3] (w180029.dynamic.ppp.asahi-net.or.jp [121.1.180.29]) by mx.google.com with ESMTPS id c28sm147667ana.1.2011.02.03.16.19.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 16:20:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "matake@gmail" In-Reply-To: Date: Fri, 4 Feb 2011 09:19:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:16:41 -0000 Mixi, one of the biggest Japanese social network service, supports = OAuth2 with refresh_token. The lifetime of refresh_token is 6 hours ~ 3 months depends on user's = decision on authorization. In that case, how can Mixi tell the lifetime of refresh_token? Currently they just documented it in their API document. On 2011/02/04, at 5:43, William Mills wrote: > The general use case for refresh tokens is that they don't have a = lifetime, although they can be invalidated by various things. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Phil Hunt >> Sent: Thursday, February 03, 2011 12:27 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Refresh Token and Expires_in >>=20 >> In 5.1 (draft 12), if a refresh_token is returned with an = access_token, >> what does expires_in refer to? Strict reading of the spec says it >> refers to the access_token, but isn't lifetime of the refresh token = as >> important? Should there be a similar "refresh_expires_in"? >>=20 >> Apologies if this was discussed before. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Thu Feb 3 16:31:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476673A6801 for ; Thu, 3 Feb 2011 16:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgGGiuO2qzsR for ; Thu, 3 Feb 2011 16:31:51 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2B0893A6944 for ; Thu, 3 Feb 2011 16:31:51 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p140ZBlX017651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 00:35:12 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p140Z9W3012376; Fri, 4 Feb 2011 00:35:09 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 1021999581296779703; Thu, 03 Feb 2011 16:35:03 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 16:35:02 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> Date: Thu, 3 Feb 2011 16:35:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> To: "matake@gmail" X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D4B49BF.002F:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:31:53 -0000 I think this is a matter of frequency. Since an access token might = expire frequently (e.g. in seconds rather than days or months), it is = worth having the client calculate to see if a token has expired (by = returning expires_in). It has the effect of saving the client/server a = failed request/response round trip that might occur fairly frequently. In the case of the refresh_token, since it expires in 3 to 6 months, as = in your example, it doesn't cost much to try the token and get an = invalid_grant error in response forcing the client to re-authorize the = grant. Still, I think the OAuth specification might be improved with some = clarifying text (in section 1.4?). Phil phil.hunt@oracle.com On 2011-02-03, at 4:19 PM, matake@gmail wrote: > Mixi, one of the biggest Japanese social network service, supports = OAuth2 with refresh_token. > The lifetime of refresh_token is 6 hours ~ 3 months depends on user's = decision on authorization. >=20 > In that case, how can Mixi tell the lifetime of refresh_token? > Currently they just documented it in their API document. >=20 > On 2011/02/04, at 5:43, William Mills wrote: >=20 >> The general use case for refresh tokens is that they don't have a = lifetime, although they can be invalidated by various things. >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>> Of Phil Hunt >>> Sent: Thursday, February 03, 2011 12:27 PM >>> To: OAuth WG >>> Subject: [OAUTH-WG] Refresh Token and Expires_in >>>=20 >>> In 5.1 (draft 12), if a refresh_token is returned with an = access_token, >>> what does expires_in refer to? Strict reading of the spec says it >>> refers to the access_token, but isn't lifetime of the refresh token = as >>> important? Should there be a similar "refresh_expires_in"? >>>=20 >>> Apologies if this was discussed before. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From matake@gmail.com Thu Feb 3 16:39:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4563A694C for ; Thu, 3 Feb 2011 16:39:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpIeI2Ytbj6k for ; Thu, 3 Feb 2011 16:39:35 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 224383A6944 for ; Thu, 3 Feb 2011 16:39:35 -0800 (PST) Received: by yie19 with SMTP id 19so814378yie.31 for ; Thu, 03 Feb 2011 16:42:58 -0800 (PST) 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=QYnFxXBmNYdSa3UFKu94RuoKSpB3Wntv33V6k4ydFqs=; b=ATul75VnOcjugDSP9b8RdjOrIjEoGHqhsxUe7dofFo2xPc10OALWsiELwAVhEoTu15 mXZ8p/UlP4XH1XVp+flDHYOICV0xr2gUdZ3ApFumjsUDqLMWa4jK1SFaBT/Hs/Akj5X/ aNAmaqqUzJ7asFG2IpVk3l3GGMSdHuMBvAb4U= 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=nKPhO6Nq4yf4oEA9rQIlTPVQc8U6OtoFxLruvh7OPKfNnDTexVB/7T+K8Nekro+oj2 fN+Oo2PHLaAIHJPnZQHqGTgW573/QREpdaGy/wTjS1e8HrIfg7uqB8ijCrhRed9QXjir g/FujiaAp2LYVTnyQmdmheJJTdDhtAwDKSHf8= Received: by 10.150.200.20 with SMTP id x20mr10951314ybf.56.1296780173367; Thu, 03 Feb 2011 16:42:53 -0800 (PST) Received: from [10.0.1.3] (w180029.dynamic.ppp.asahi-net.or.jp [121.1.180.29]) by mx.google.com with ESMTPS id k1sm696742ybj.0.2011.02.03.16.42.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 16:42:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "matake@gmail" In-Reply-To: Date: Fri, 4 Feb 2011 09:42:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <39564003-867F-4762-8592-BAC3BF725166@gmail.com> References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> To: Phil Hunt X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:39:36 -0000 > since it expires in 3 to 6 months No, 6 hours or 3 months. 3 months when user approved long-time access, 6 hours when not. (Mixi has a checkbox on authorization page for that, so an client can = have both kind of refresh_tokens) The only way to know the refresh_token lifetime is try to refresh after = 6+ hours in this case. On 2011/02/04, at 9:35, Phil Hunt wrote: > I think this is a matter of frequency. Since an access token might = expire frequently (e.g. in seconds rather than days or months), it is = worth having the client calculate to see if a token has expired (by = returning expires_in). It has the effect of saving the client/server a = failed request/response round trip that might occur fairly frequently. >=20 > In the case of the refresh_token, since it expires in 3 to 6 months, = as in your example, it doesn't cost much to try the token and get an = invalid_grant error in response forcing the client to re-authorize the = grant. >=20 > Still, I think the OAuth specification might be improved with some = clarifying text (in section 1.4?). >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-03, at 4:19 PM, matake@gmail wrote: >=20 >> Mixi, one of the biggest Japanese social network service, supports = OAuth2 with refresh_token. >> The lifetime of refresh_token is 6 hours ~ 3 months depends on user's = decision on authorization. >>=20 >> In that case, how can Mixi tell the lifetime of refresh_token? >> Currently they just documented it in their API document. >>=20 >> On 2011/02/04, at 5:43, William Mills wrote: >>=20 >>> The general use case for refresh tokens is that they don't have a = lifetime, although they can be invalidated by various things. >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>> Of Phil Hunt >>>> Sent: Thursday, February 03, 2011 12:27 PM >>>> To: OAuth WG >>>> Subject: [OAUTH-WG] Refresh Token and Expires_in >>>>=20 >>>> In 5.1 (draft 12), if a refresh_token is returned with an = access_token, >>>> what does expires_in refer to? Strict reading of the spec says it >>>> refers to the access_token, but isn't lifetime of the refresh token = as >>>> important? Should there be a similar "refresh_expires_in"? >>>>=20 >>>> Apologies if this was discussed before. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From phil.hunt@oracle.com Thu Feb 3 16:42:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84593A6944 for ; Thu, 3 Feb 2011 16:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFneGsd0QZ1r for ; Thu, 3 Feb 2011 16:42:03 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AC52C3A635F for ; Thu, 3 Feb 2011 16:42:03 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p140jNqx002502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 00:45:25 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p140jMnI032314; Fri, 4 Feb 2011 00:45:22 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 978600981296780261; Thu, 03 Feb 2011 16:44:21 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 16:44:20 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <39564003-867F-4762-8592-BAC3BF725166@gmail.com> Date: Thu, 3 Feb 2011 16:44:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7256C2-9C95-4E05-8BF4-9E06F65229C4@oracle.com> References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> <39564003-867F-4762-8592-BAC3BF725166@gmail.com> To: "matake@gmail" X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D4B4C23.0054:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:42:04 -0000 Correct. So the request would fail and you then re-authorize. You get a = wasted request/response. But it doesn't cost as much as for an expired = access_token. Phil phil.hunt@oracle.com On 2011-02-03, at 4:42 PM, matake@gmail wrote: >> since it expires in 3 to 6 months >=20 > No, 6 hours or 3 months. > 3 months when user approved long-time access, 6 hours when not. > (Mixi has a checkbox on authorization page for that, so an client can = have both kind of refresh_tokens) >=20 > The only way to know the refresh_token lifetime is try to refresh = after 6+ hours in this case. >=20 > On 2011/02/04, at 9:35, Phil Hunt wrote: >=20 >> I think this is a matter of frequency. Since an access token might = expire frequently (e.g. in seconds rather than days or months), it is = worth having the client calculate to see if a token has expired (by = returning expires_in). It has the effect of saving the client/server a = failed request/response round trip that might occur fairly frequently. >>=20 >> In the case of the refresh_token, since it expires in 3 to 6 months, = as in your example, it doesn't cost much to try the token and get an = invalid_grant error in response forcing the client to re-authorize the = grant. >>=20 >> Still, I think the OAuth specification might be improved with some = clarifying text (in section 1.4?). >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-02-03, at 4:19 PM, matake@gmail wrote: >>=20 >>> Mixi, one of the biggest Japanese social network service, supports = OAuth2 with refresh_token. >>> The lifetime of refresh_token is 6 hours ~ 3 months depends on = user's decision on authorization. >>>=20 >>> In that case, how can Mixi tell the lifetime of refresh_token? >>> Currently they just documented it in their API document. >>>=20 >>> On 2011/02/04, at 5:43, William Mills wrote: >>>=20 >>>> The general use case for refresh tokens is that they don't have a = lifetime, although they can be invalidated by various things. >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>>> Of Phil Hunt >>>>> Sent: Thursday, February 03, 2011 12:27 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Refresh Token and Expires_in >>>>>=20 >>>>> In 5.1 (draft 12), if a refresh_token is returned with an = access_token, >>>>> what does expires_in refer to? Strict reading of the spec says it >>>>> refers to the access_token, but isn't lifetime of the refresh = token as >>>>> important? Should there be a similar "refresh_expires_in"? >>>>>=20 >>>>> Apologies if this was discussed before. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 From eran@hueniverse.com Thu Feb 3 16:42:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873D83A6B09 for ; Thu, 3 Feb 2011 16:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-A6pCUWK1hW for ; Thu, 3 Feb 2011 16:42:25 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7D4C63A6ADE for ; Thu, 3 Feb 2011 16:42:25 -0800 (PST) Received: (qmail 15047 invoked from network); 4 Feb 2011 00:45:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Feb 2011 00:45:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Feb 2011 17:45:35 -0700 From: Eran Hammer-Lahav To: "matake@gmail" , Phil Hunt Date: Thu, 3 Feb 2011 17:45:27 -0700 Thread-Topic: [OAUTH-WG] Refresh Token and Expires_in Thread-Index: AcvEBHs4zXtoMamQREmJekjrwYGbFgAAERYQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB34DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> <39564003-867F-4762-8592-BAC3BF725166@gmail.com> In-Reply-To: <39564003-867F-4762-8592-BAC3BF725166@gmail.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] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:42:26 -0000 Seems a bit odd to issue a refresh token for 6 hours. Why not just issue an= access token for 6 hours without any refresh token. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of matake@gmail > Sent: Thursday, February 03, 2011 4:43 PM > To: Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Refresh Token and Expires_in >=20 > > since it expires in 3 to 6 months >=20 > No, 6 hours or 3 months. > 3 months when user approved long-time access, 6 hours when not. > (Mixi has a checkbox on authorization page for that, so an client can hav= e > both kind of refresh_tokens) >=20 > The only way to know the refresh_token lifetime is try to refresh after 6= + > hours in this case. >=20 > On 2011/02/04, at 9:35, Phil Hunt wrote: >=20 > > I think this is a matter of frequency. Since an access token might expi= re > frequently (e.g. in seconds rather than days or months), it is worth havi= ng > the client calculate to see if a token has expired (by returning expires_= in). It > has the effect of saving the client/server a failed request/response roun= d > trip that might occur fairly frequently. > > > > In the case of the refresh_token, since it expires in 3 to 6 months, as= in > your example, it doesn't cost much to try the token and get an invalid_gr= ant > error in response forcing the client to re-authorize the grant. > > > > Still, I think the OAuth specification might be improved with some clar= ifying > text (in section 1.4?). > > > > Phil > > phil.hunt@oracle.com > > > > > > > > > > On 2011-02-03, at 4:19 PM, matake@gmail wrote: > > > >> Mixi, one of the biggest Japanese social network service, supports > OAuth2 with refresh_token. > >> The lifetime of refresh_token is 6 hours ~ 3 months depends on user's > decision on authorization. > >> > >> In that case, how can Mixi tell the lifetime of refresh_token? > >> Currently they just documented it in their API document. > >> > >> On 2011/02/04, at 5:43, William Mills wrote: > >> > >>> The general use case for refresh tokens is that they don't have a > lifetime, although they can be invalidated by various things. > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Phil Hunt > >>>> Sent: Thursday, February 03, 2011 12:27 PM > >>>> To: OAuth WG > >>>> Subject: [OAUTH-WG] Refresh Token and Expires_in > >>>> > >>>> In 5.1 (draft 12), if a refresh_token is returned with an > >>>> access_token, what does expires_in refer to? Strict reading of the > >>>> spec says it refers to the access_token, but isn't lifetime of the > >>>> refresh token as important? Should there be a similar > "refresh_expires_in"? > >>>> > >>>> Apologies if this was discussed before. > >>>> > >>>> Phil > >>>> phil.hunt@oracle.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 > >> > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From matake@gmail.com Thu Feb 3 17:44:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FD63A6947 for ; Thu, 3 Feb 2011 17:44:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNTajZlFILu6 for ; Thu, 3 Feb 2011 17:44:12 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id ADF293A68E7 for ; Thu, 3 Feb 2011 17:44:12 -0800 (PST) Received: by yie19 with SMTP id 19so832708yie.31 for ; Thu, 03 Feb 2011 17:47:36 -0800 (PST) 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=ZDaqg09pjtSuupqdLRdbV3j18VUtBxS+dOTMaORB/I0=; b=vUQ69plx++H9JfRsJPuOhg1u7gpVQAV6UIsX4Q+VEJvA6QVL33eDkYVPWY7dGlinqa kCYWTnjmCoqpTI1EN9+PPxAlgqueTjBP6tFMZjn6zHM3zUs5UjkBLBF2POVp1/B/x+LJ vKmMwubHIKnQu8218uLLrHLuKIBZxCz4xm5O0= 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=F+6nMnbKx+p1eu+MrkJX18dNm4C6ZnMCKI6JyTokCccOLf04eh3V4kiI2iTxeVSHjq JfM+bi4dPhWvtwNz8+JXTmCK7kZZkhbIiHEDOncAyyKsSyBn9SImjSL+aiphuoUcJCFL 2Z5wXTkVYJx9mpzexE5KQx8QHjgTbO8Qbd5Ug= Received: by 10.90.93.2 with SMTP id q2mr8091149agb.39.1296784055845; Thu, 03 Feb 2011 17:47:35 -0800 (PST) Received: from dell_38.cerego.co.jp (firebox.cerego.co.jp [61.121.210.70]) by mx.google.com with ESMTPS id b11sm225928ana.18.2011.02.03.17.47.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 17:47:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: nov matake In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB34DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Feb 2011 10:47:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <813E07E4-C925-4550-A3D1-580A6A871036@oracle.com> <154D47B6-D128-49D5-8A13-47E7714C0B35@gmail.com> <39564003-867F-4762-8592-BAC3BF725166@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB34DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Token and Expires_in X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 01:44:14 -0000 Yeah, your way is much better, especially for client developers. All mixi access_tokens expire in 15 mins, I'm not sure the details of = their security policy though. And there are no way to know the lifetime of refresh_token when client = get an access_token. On 2011/02/04, at 9:45, Eran Hammer-Lahav wrote: > Seems a bit odd to issue a refresh token for 6 hours. Why not just = issue an access token for 6 hours without any refresh token. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of matake@gmail >> Sent: Thursday, February 03, 2011 4:43 PM >> To: Phil Hunt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Refresh Token and Expires_in >>=20 >>> since it expires in 3 to 6 months >>=20 >> No, 6 hours or 3 months. >> 3 months when user approved long-time access, 6 hours when not. >> (Mixi has a checkbox on authorization page for that, so an client can = have >> both kind of refresh_tokens) >>=20 >> The only way to know the refresh_token lifetime is try to refresh = after 6+ >> hours in this case. >>=20 >> On 2011/02/04, at 9:35, Phil Hunt wrote: >>=20 >>> I think this is a matter of frequency. Since an access token might = expire >> frequently (e.g. in seconds rather than days or months), it is worth = having >> the client calculate to see if a token has expired (by returning = expires_in). It >> has the effect of saving the client/server a failed request/response = round >> trip that might occur fairly frequently. >>>=20 >>> In the case of the refresh_token, since it expires in 3 to 6 months, = as in >> your example, it doesn't cost much to try the token and get an = invalid_grant >> error in response forcing the client to re-authorize the grant. >>>=20 >>> Still, I think the OAuth specification might be improved with some = clarifying >> text (in section 1.4?). >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-02-03, at 4:19 PM, matake@gmail wrote: >>>=20 >>>> Mixi, one of the biggest Japanese social network service, supports >> OAuth2 with refresh_token. >>>> The lifetime of refresh_token is 6 hours ~ 3 months depends on = user's >> decision on authorization. >>>>=20 >>>> In that case, how can Mixi tell the lifetime of refresh_token? >>>> Currently they just documented it in their API document. >>>>=20 >>>> On 2011/02/04, at 5:43, William Mills wrote: >>>>=20 >>>>> The general use case for refresh tokens is that they don't have a >> lifetime, although they can be invalidated by various things. >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Phil Hunt >>>>>> Sent: Thursday, February 03, 2011 12:27 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] Refresh Token and Expires_in >>>>>>=20 >>>>>> In 5.1 (draft 12), if a refresh_token is returned with an >>>>>> access_token, what does expires_in refer to? Strict reading of = the >>>>>> spec says it refers to the access_token, but isn't lifetime of = the >>>>>> refresh token as important? Should there be a similar >> "refresh_expires_in"? >>>>>>=20 >>>>>> Apologies if this was discussed before. >>>>>>=20 >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Feb 3 20:20:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95273A6B0D for ; Thu, 3 Feb 2011 20:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd+zaSMKmQtS for ; Thu, 3 Feb 2011 20:20:42 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id A7D7F3A6A31 for ; Thu, 3 Feb 2011 20:20:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,424,1291554000"; d="scan'208,217";a="25790128" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 04 Feb 2011 15:24:04 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="18519142" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 04 Feb 2011 15:24:03 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 4 Feb 2011 15:24:03 +1100 From: "Manger, James H" To: OAuth WG Date: Fri, 4 Feb 2011 15:24:02 +1100 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwApdWcA Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127D45802AWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 04:20:46 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127D45802AWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for #1 #2 is awful; #3 is unnecessary; #4 "OAuth2" just has less meaning than, say= , "Bearer". #1 offers the cleanest separation between "using-a-token to authenticated a= request" and "a delegation flow to authorize a client" which is likely to = be helpful for lots of people now and in the future trying to get their hea= ds around this complex space. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, 3 February 2011 7:34 PM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 2. Single OAuth2 scheme with sub-schemes ... 3. Name prefix (e.g. oauth2_bearer) ... 4. OAuth2 for bearer, MAC for mac ... --_000_255B9BB34FB7D647A506DC292726F6E1127D45802AWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for #1

 

#2 is awful; #3 is unn= ecessary; #4 “OAuth2” just has less meaning than, say, “B= earer”.

#1 offers the cleanest= separation between “using-a-token to authenticated a request” = and “a delegation flow to authorize a client” which is likely t= o be helpful for lots of people now and in the future trying to get their heads around this complex space.

 

--

James Manger

 

From: oauth-bounces@ietf.= org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, 3 February 2011 7:34 PM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/1= 0)

 

After a long back-and-forth, I = think it is time to present a few options and have people express their pre= ferences.

 

These are the options mentioned= so far and their +/-:

 

1. Descriptive, non-OAuth-speci= fic scheme names (Bearer, MAC)

…=

2. Single OAuth2 scheme with su= b-schemes

…=

3. Name prefix (e.g. oauth2_bea= rer)

…=

4. OAuth2 for bearer, MAC for m= ac

…=

--_000_255B9BB34FB7D647A506DC292726F6E1127D45802AWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Thu Feb 3 20:35:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1643A69FE for ; Thu, 3 Feb 2011 20:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=0.020, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TsJZBfaAFoi for ; Thu, 3 Feb 2011 20:35:34 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 986053A67D6 for ; Thu, 3 Feb 2011 20:35:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,424,1291554000"; d="scan'208";a="27365050" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 04 Feb 2011 15:38:56 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="18672033" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccni.tcif.telstra.com.au with ESMTP; 04 Feb 2011 15:38:56 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 4 Feb 2011 15:38:55 +1100 From: "Manger, James H" To: Hannes Tschofenig , "oauth@ietf.org" Date: Fri, 4 Feb 2011 15:38:54 +1100 Thread-Topic: [OAUTH-WG] New Working Group Items? Thread-Index: AcvDvinbHi952u8nQX60t/AmMf+8iAAZjRSQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D4580AA@WSMSG3153V.srv.dir.telstra.com> References: <4D4AD58E.9090407@gmx.net> In-Reply-To: <4D4AD58E.9090407@gmx.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 04:35:34 -0000 Hannes, I would like one more item in the list: * OAuth2 discovery from the response to any HTTP request, probably via a WW= W-Authenticate response header. I am keen to contribute, and perhaps co-aut= hor such a spec. > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ I'm happy to review. > E) OAuth 2.0 User Experience Extension > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 I'm happy to support. -- James Manger From James.H.Manger@team.telstra.com Thu Feb 3 21:19:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1583A6853 for ; Thu, 3 Feb 2011 21:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.019, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nCb7QxORzoU for ; Thu, 3 Feb 2011 21:19:37 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 31EF53A6AAF for ; Thu, 3 Feb 2011 21:19:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,424,1291554000"; d="p7s'?scan'208";a="24159688" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 04 Feb 2011 16:22:58 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="18439861" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 04 Feb 2011 16:22:56 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 4 Feb 2011 16:22:55 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 4 Feb 2011 16:22:54 +1100 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/A= Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01CBC487.C6B5E6B0" MIME-Version: 1.0 Subject: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 05:19:38 -0000 ------=_NextPart_000_0014_01CBC487.C6B5E6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments on draft-hammer-oauth-v2-mac-token-02 This draft is a good improvement. (continuing numbering from my previous comments) 11. The "access token" field would be better labelled "id". The MAC scheme only needs this field to identify the MAC secret. The MAC scheme itself doesn't need to care whether this id also represents a scope, duration, assertion etc. Though it may slightly complicated the use of the MAC scheme with OAuth2, I would seriously consider supporting two identifiers: * An authentication id -- to identify the key used to verify the MAC; and * An authorization id -- to identify the scope/account/permissions/duration... that the client want to act under. The SASL framework has these two concepts [RFC4422 Simple Authentication and Security Layer (SASL)]. Any modern SASL authentication mechanism will be expected to support both ids. The authorization id is a good match for an OAuth2 token or other sort of assertion. The OAuth2-to-MAC binding could define a 'keyid' parameter to accompany the 'secret'. The 'keyid' value would map to the authentication id field in the MAC scheme, and the 'access_token' would map to the authorization id field. 12. Which bytes does the body hash apply to? Is it the "message-body" or "payload body" (in HTTPbis parlance)? I assume any Transfer-Encoding (eg chunked) is removed before calculating the body hash, but any Content-Encoding (eg gzip) is not removed. The spec should explicitly state this. [c.f. wording as for the "Content-MD5" header in draft-ietf-httpbis-p3-payload-12, section 6.8] 13. The MAC algorithm should be explicitly indicated in the request, instead of being implied by the access-token/id. I suggest including an "algorithm" parameter in the "Authorization" request header. I also suggest including an "algorithms" parameter in the "WWW-Authenticate" response header that is a (comma-separated?) list of MAC algorithms that the server supports. 14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-256) are used to calculate the body hash when using the hmac-sha-1 (and hmac-sha-256) algorithm. 15. 3.3.2 (and 3.3.3) shouldn't mention the OAuth-specific "authorization server" (when defining their "key" field). 16. OAuth2 can provide a "secret" as a Unicode string. MAC algorithms such as HMAC use a key that is a byte array. Section 2 of the MAC spec says 'secret' can only include printable ASCII chars (except " and /). This is not quite right. The MAC scheme should expect 'secret' to be a byte array (ie not limit its chars). A 'secret' string from an OAuth2 response should be UTF-8 encoded to produce the byte array the MAC scheme uses. 17. This MAC scheme should be compared to the SCRAM SASL mechanism [RFC 5802]. SCRAM is the latest-and-greatest authentication mechanism based on a shared secret (without using the brilliant, but patent-troubled, zero-knowledge proof techniques). It has quite a few features that MAC is missing: two ids (auth & authz); credentials at the server are not sufficient to impersonate the client (not a "password-equivalent"); mutual authentication; channel binding (to an underlying TLS secure tunnel). I don't think MAC can achieve all these properties. The MAC scheme almost certainly wants to avoid multiple exchanges at the HTTP layer. I expect the wider IETF community to judge MAC by comparing it negatively to SCRAM unless the document is quite clear about its constraints (eg sign an HTTP request without any interactivity with the server; suitable for shared secret keys, but not for shared passwords...). -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H Sent: Tuesday, 11 January 2011 5:05 PM To: OAuth WG Subject: [OAUTH-WG] MAC: comments on draft-hammer-oauth-v2-mac-token-00 Comments on draft-hammer-oauth-v2-mac-token-00 1. The connection of this MAC scheme to OAuth is secondary. The primary function of the MAC scheme is to secure the authenticity of parts of an HTTP request using a shared secret. Section 2 "Issuing MAC-Type Access Tokens" would be better at the end, ideally as an Annex, along with most of the OAuth talk from the introduction (and title). 2. Include a \n after the final query string parameter. It makes the format simply lines of text, instead of making the last line special (and only special if there are query params). It is awkward to manually edit sample files, debug files etc without a final newline character. Adding a final \n would just make it more consistent. 3. The Authorization header example in 1.1 uses single quotes around values. It should use double quotes. The ABNF in 3.1 for timestamp, for instance, explicitly uses <">. 4. The quoted-string production only supports a subset of ASCII. Better add a sentence stating that the 'token' is assumed to only use this subset so no escaping is defined. May be worth adding that only double-quote and backslash need escaping in quoted-string, but neither of those are allowed in any of this specs parameters so no escaping in quoted-string values shall occur. 5. Don't list the new line characters as separate numbered items in section 3.2.1 "Normalized Request String". Better to say it is a line-based format. Each line ends with a single new line character (U+000A). Then list the 7 lines (as points 1 to 7), followed by point 8 saying there is 1 extra line for each query string parameter. 6. I18N. Is the Normalised Request String UTF-8, or does it happen to be just ASCII? Host, path, and query strings can contain non-ASCII characters -- but I guess that the ASCII-only escaping used to create an HTTP Host header and URI are assumed to have occurred before this spec uses these values. Would be worth an explicit statement, and definitely an example. 7. I suggest swapping steps 2 (sort) & 3 (combine escaped name and value) in section 3.2.1.1. "Parameters Normalization". The current 2-layer sort is not ideal (sort on %-escaped name, then on %-escaped value if the names are equal). It needs a special comparator function etc, instead of using a programming language's standard sort-a-list-of-strings function. It is tempting to concatenate %-escaped name=value pairs and sort those -- but it doesn't always give the same result. Eg a1=X and a11=Y should sort in that order according to the spec, but "1" < "=" in an ASCII string comparison of the pairs. A programmer probably has a map/dictionary/assoc-array of unescaped names to values. The normalisation rules require a separate map of escaped names to escaped values plus a custom comparator that considers names and values. A nicer alternative would be to construct escaped name=value pairs then sort that list (not map). It would be worth adding another parameter to the example (eg a22=A) to illustrate this (regardless of whether or not the steps are swapped). 8. HMAC operates on bytes, not strings. The 'text' and 'key' HMAC inputs (in 3.2.2 and 3.2.3) should be specified as the UTF-8-encoding of the Normalized Request String and access token shared secret respectively. Might be able to say ASCII-encoding, but only if we are sure that an OAuth token response (which might be a UTF-8 JSON blob) can never return non-ASCII chars in a 'secret' field. 9. The 'secret' parameter is registered twice (7.1 & 7.2). I guess one of these should be registering the 'algorithm' parameter instead. 10. I would like a "WWW-Authenticate: MAC algorithm=..." response header defined. It would provide a nice illustration of how a complete HTTP auth scheme is mapped to OAuth2. That is, how the scheme name "MAC" and parameters from the "WWW-Authenticate: MAC ..." response header can be mapped to fields in an OAuth2 token response (where they are accompanied by an actual secret key). -- James Manger ------=_NextPart_000_0014_01CBC487.C6B5E6B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIc2jCCBqMw ggSLoAMCAQICEClsBJZEfCC2SncEyz0UzYEwDQYJKoZIhvcNAQEFBQAwGjEYMBYGA1UEAxMPVGVs c3RyYSBSb290IENBMB4XDTA5MTExNjA0NTkxM1oXDTM0MTExNjA1MDYxMVowGjEYMBYGA1UEAxMP VGVsc3RyYSBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA3r3Fb5E/8GUk cHwd9/kRB14EH1trG6C7NrwmF7isLj3j8fbELwkg0Lm0qzVuYziwqC3sbB4BcpY1YU9UZfB8J7cO Efbk1GkVkSwNnpKyUHsxAWAelb0eOord3bB21M2UeUyWkGQhoU3+ZxyaAALKDm1QZQx7Tw8wdkIQ mc1mJ4cJg/I9dTk1J5ybG4ZWs4/87PnLe0A5KRD841YWeKO1oLrV6Zvj65Aa6gpme0AdLVEDStM/ 4jNtso6jf63ixizKzazfbt5lJJZizGHelymCF2BGjps0+6eMsteMmfQ84OXG82V00pFy6kwGjH6+ Y081OXTo6Gq/sR+6d4RDFIltIYGyYKKBzsEGw2MJqxqyXat9UV/50xspN26BZlB5zHFNdKI9eBKC sv6EpgklYSfv9vgNBBnwavHmGvmw12i0NUd9WlS3YybQzxnWE49Q05jIxt+ZgV4Rg6oiCRb7rktN d8qwRUb0LcSfcYOqGGffuckNQzKGNGySrkznOrC33BsVEmGMgXGqtZk4L7Sfq5NL1y7wCJUKw8qI Ox/ijs0SSfc9VDwqZmhEM9NV8sGUsvmTeH1D8G06zjmE6loXUyIQXZLohQQ96TQyjKuA3lvtCbJt yHFbgyi8wVJG+Ze3+Ywo+JB10rlR7FF6XEniihJEIYAHkSsGRqOASUzBA7p2Ip8CAwEAAaOCAeMw ggHfMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1UdDgQWBBSXNqRMMI9eSlUu k+RwLu+s1mV3iDAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwDQYJKoZIhvcNAQEFBQADggIBAHZuKnwg4R4Fk32A fxTzTHtDboZI1ZW3Yv7nSdqfZlnfF8bEAD6FSEoMJ0w6jProxVXSZwia5Fkhf4jt6M949PP+G5Cl V89x3z8pECqJhbVcZbE9p1hJXPy72IwILRblSnTnPh9CTLV0gTOkmX6SmrDMG3GSV3djTt8cf88o JTcbRe0vJgFwf5sPlMEplrK3tK0pIjomzcoGLfP9Zv+wvVLvGvu5TVxWiFIQrdtuUjzL3/2VxFb4 M5kLQaQCaxTOxcB/8epSyaInbLI1YsyhRtPyzCAT0pbTTPKR3eNgMF7YlzakASa5LbiTkWIayS8h s+MjkqIF9CX1PwOBphQgJa3yPm4bIfNBGH4520knrb5r/D/cTDtjarXh4v/ExJphEqbU6m44C4Wq Cp7jV3v6Xm91QaQbCF/e4H4RD9PTr/c+MILhmhEq879n6iF6276oe2kWZE0yXy8eiK5Ung0F2tJX PfQidNaI9NTMHViQoacVY9ah/juHnEIrnEozrYuMLqC+39i9BXAIQ4Qq7GJ132xr5o8/xb2iQ1IZ wD27yb7Or1gzcKjKvJj/pkCeDgC7fQVlxtvfDBjiKuAoWs7PXGTtGzfiObrnEmhmR0DnWSehA5ld o3/fyiGuyN53nU+ewQY4AyE8jBzPxq6YmVjWM0FAdyJLHyX+YBvYjs2VAX2cMIIG6jCCBNKgAwIB AgIKYQWDvgAAAAAABTANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9UZWxzdHJhIFJvb3QgQ0Ew HhcNMDkxMTI1MDEyNDI3WhcNMTkxMTI1MDEzNDI3WjBDMSQwIgYDVQQKExtUZWxzdHJhIENvcnBv cmF0aW9uIExpbWl0ZWQxGzAZBgNVBAMTElRlbHN0cmEgUG9saWN5IENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK3IBZQGtMLEw5e8k3SJcSRf/BnMWwguu1Ltka6XK/nmcmjTOPl/ qqpkC2uBZUFZAflrWJdmh5MTamCWNMsRSmtiWwSJQsFTPWstSRELqkuM0+lXIlTTU4dTFM3cp/pE l4ly+xBUd6ndQQeB/MOsTsbdkhALj/oMZzSSVLJw3cngrS4pG9TjV8zKMIkZQBeIURBgqh1yd6nX n1FNctjyDH1ybxftcuhK3hEEbPrAHJQB9YN317l7ISYqg99jec/3mVf0C1fOuzefKHGINXo8M2lL H3P4O28fSmaLyJK3p6IStoRmtrHwIkc9WHnDe0e9aieQx+PPosll61EtyJiaRX0CAwEAAaOCAwcw ggMDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFJT5/udCeR3rxZ9HUpfHV7X4nD4oMAsG A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUlzakTDCPXkpVLpPkcC7vrNZld4gwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwUm9vdCUyMENBLmNybDCBlQYI KwYBBQUHAQEEgYgwgYUwSQYIKwYBBQUHMAKGPWh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVsc3Ry YS5jb20uYXUvVGVsc3RyYSUyMFJvb3QlMjBDQS5jcnQwOAYIKwYBBQUHMAGGLGh0dHA6Ly90ZWxz dHJhLW9jc3AucGtpLnRlbHN0cmEuY29tLmF1L29jc3AvMA0GCSqGSIb3DQEBBQUAA4ICAQDIYtRV XKCxl7sydCNMtC6BCJXmw7pgGswnfIDNCOF/XKTNA+5xY1+VchlRI1iWb4q15YToT6EEKXJPdWdv pO+atxyMMUScQCmZM5mW1PpbMGzXRrTL3LbDhDRaLWYD15+Wt2rgNU++iiIVA363TdgCllY3ync7 GzknJGdTl+0BEen2d4juqf0GWURu/KICxyt0YOYgoDe1O3mYbJJ4RjOOFc3lTkGPgwagtJNP22yq CcJ776pzvaa6qMTMEqzAgM5X6o6Yhp8zXHOU0M0x4/pJGb8PswKhzFi7F1TWKf0zmoKlpvAUV39U P0F8oPyMYjYPDYyBsRiaZ7iRUH1u01bPQ8XXt1jmDemXxO9w4d//Kp1qark3rcUZLi6FC4QPg0Rp S9rLWAPBDHqqFKi6mAU2W8nGWj3yY6/FI2dBPSGsxY0W2KUiEbEvgN534SPgZxJd1QT2x2CEUy1x x98EBpBZCkNQN1pMo3k3CaMn14ychHd3Y544+8UD0IYWaGzbrWiEBlcHca0yg7+F0Wu3Jln4DRM+ G0MlsB9Nq5J4YvgtX3ao0V7q+nA6oEV0TX3nPl1K99b6Xou4lILRg+/siOSIwsf+xTlaiLMntO2+ evRHTSJTPwR2H1LQQIuVatkBnTx3Yh28zMP1ge+hNLU66RHEez2mE+LktzmpQdysO8UGEzCCB0Qw ggYsoAMCAQICCicgTlUAAAAAAXkwDQYJKoZIhvcNAQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2Nv bTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzARBgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJ k/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJhIFVzZXIgSXNzdWluZyBDQTEwHhcNMTAwODIz MDE0MDM4WhcNMTEwODIzMDE0MDM4WjASMRAwDgYDVQQDEwdjNzk5ODc4MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyYk0amYR4rSpU7VIfUpitrwxSHUV8uqzWzL7a/EqvsUIEwSAIj+A UfTFuvla72Np6qcnIcbosMpdC4OrCVNtN0rTrxsBGXTie8ED3Bg3SvHntM9qBo5vgnibBmICd2pN 3CGVKega3Y6l5AEdc9ZzBJCvpgl6b0q49Sne9QY/lVLKQYHcxLOZj5l9xFWzsLkY6KSEi/M8Wolz UDjyFN8QPgxe8CHeKwmBOEkd/W+n0JWGf96yR9SFaCIy/3O9S6Wotu5ZE2kZHz9nppfYp8O0wIS2 IMqhbJL1jZg4NpcYsRpp7EefqXadeqeq2bCIhK82SmI4LmTrMoYfYBfTF8G/4QIDAQABo4IEMDCC BCwwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSP6v7Q6Lp5k8/olxFNK7ONKJcdkTA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiE1I4igu3fU4X1gxiCxrxchYe7LX6HyKV0hceteQIBZAIBBDAfBgNV HSMEGDAWgBSzErFXrmmp60LIrAigOp3IfvE23DCCATwGA1UdHwSCATMwggEvMIIBK6CCASegggEj hoHWbGRhcDovLy9DTj1UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEsQ049V1NDQVMwMTAx LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBD QTEuY3JsMIIBcQYIKwYBBQUHAQEEggFjMIIBXzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPVRl bHN0cmElMjBVc2VyJTIwSXNzdWluZyUyMENBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxz dHJhLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTBUBggrBgEFBQcwAoZIaHR0cDovL3RlbHN0cmEtcGtpLnBraS50ZWxzdHJhLmNvbS5h dS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzATBgNVHSUEDDAKBggrBgEFBQcD BDBdBgNVHSAEVjBUMFIGDCsGAQQBiEAEGwEBATBCMEAGCCsGAQUFBwIBFjRodHRwOi8vdGVsc3Ry YS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRmMBsGCSsGAQQBgjcVCgQOMAww CgYIKwYBBQUHAwQwWAYDVR0RBFEwT6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIu dGVsc3RyYS5jb22BH0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEF BQADggEBAAOidxye9ItR/UmzA6cuskZAxk5mPXP095W06xsU8RTJQBjRPj5IO7bqNNvs4V0e0ps1 QzcS17JCLPR9EnU3gT0YEdvr+ZeDi02HoMSfownaVjPDScpAVm16xi99EGJLlS1Tlx1IXRPMFb3S 1Qm+A9nb6yMAt1ob14tbgEh42rneimOlFVY6r8DW4wPrbRasargZdfe3SUaBAZZy3oIOzyfiT+Vj fvnw00OFQvrPbsUUJwN1zqjmItU2KTZIpkKH4nfkQfHbRuZphD5FVxFvJLaCKz8EakrwwkOfFF4r RDJ1JVL0Fc27H4oWTrcYIwUcI6pIZXXAjrispvomSUNAG7wwggf5MIIG4aADAgECAgoWWLv+AAAA AAAFMA0GCSqGSIb3DQEBBQUAMEMxJDAiBgNVBAoTG1RlbHN0cmEgQ29ycG9yYXRpb24gTGltaXRl ZDEbMBkGA1UEAxMSVGVsc3RyYSBQb2xpY3kgQ0ExMB4XDTA5MTEyOTA4MzI0NVoXDTE0MTEyOTA4 NDI0NVowfDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzAR BgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJk/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJh IFVzZXIgSXNzdWluZyBDQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCevv2YM8z1 batCiS4O8l8YKJZNgA6wCcNatQ0E3OK1ZKLijCumkWAbGkRGHvIsZGkvU9XV4SEVzaVmdC+w83S+ wDNwj+8RtR3yjTOZ/ttiXO1/zWbXq8pS+RYalOp2NS6bIs7J6bvN5nSzYJESNEkSwv57ZxDutL12 gw2tC411FYTWqaL10rAOA3Hn5wSyr51WdrkjxNZqmmhSGvOITi+8UAeIe6rzarh/YemYJp1sA2p0 ZIg1VhBg8vvY6dONG1h/atFDjECJtroqYbvtJpQWeXQK8hSR/JlLeAYqt/J8GKQv+8mkycQUn0Xt D5gbjF60i81culOIsXttS4xIe1tzAgMBAAGjggS0MIIEsDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBSzErFXrmmp60LIrAigOp3IfvE23DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMC AQAwggGJBgNVHSAEggGAMIIBfDCCAXgGDCsGAQQBiEAEGwEBATCCAWYwggEgBggrBgEFBQcCAjCC ARIeggEOAEYAbwByACAAYQAgAGMAbwBwAHkAIABvAGYAIAB0AGgAZQAgAFQAZQBsAHMAdAByAGEA IABQAEsASQAgAEMAUABTACwAIABjAGwAaQBjAGsAIABNAG8AcgBlACAASQBuAGYAbwAuACAARgBv AHIAIABDAFAAUwAgAHEAdQBlAHIAaQBlAHMAIABjAG8AbgB0AGEAYwB0ACAAdABoAGUAIABHAG8A dgBlAHIAbgBhAG4AYwBlACAAQwBvAHUAbgBjAGkAbAAsACAARQBtAGEAaQBsADoAIABUAGUAbABz AHQAcgBhAC4AUABHAEMAQAB0AGUAYQBtAC4AdABlAGwAcwB0AHIAYQAuAGMAbwBtMEAGCCsGAQUF BwIBFjRodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRm MBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJT5/udCeR3rxZ9HUpfHV7X4 nD4oMIIBLAYDVR0fBIIBIzCCAR8wggEboIIBF6CCAROGgc5sZGFwOi8vL0NOPVRlbHN0cmElMjBQ b2xpY3klMjBDQTEsQ049d3NjYXAwMTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEs REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludIZAaHR0cDovL3RlbHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxz dHJhJTIwUG9saWN5JTIwQ0ExLmNybDCCAWEGCCsGAQUFBwEBBIIBUzCCAU8wgcQGCCsGAQUFBzAC hoG3bGRhcDovLy9DTj1UZWxzdHJhJTIwUG9saWN5JTIwQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGly LERDPXRlbHN0cmEsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MEwGCCsGAQUFBzAChkBodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0 cmEuY29tLmF1L1RlbHN0cmElMjBQb2xpY3klMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzANBgkqhkiG9w0BAQUFAAOCAQEA KLKdzu8ZWRTUOdOZJ02fEONNrwAHAUMMwFh5pD/2CPhY6e29qU+4zih5R30GUcj+2LVohlOHyWVq vvQJyJTxH+YTf3xrldjV69lL3lLCMfsuGX2LteGfwLsN45hUOnm1RWlvf0Gaug4GdLZeXjVLyfgU MF/BhesXEUGWB68Q5N8FxUVVgrmXRYYWyGQHGGHXWn/UCOreGjawPr7GC0HgndgkwHxjhTqgCmzo Sl0TIwWxFu6gO0eleF+3S85IFb3dwmctj+ZZm0tm3i5+59RVytuycvvAArwZT4Dc3nLD78fnjpXs c9oXwjRWF3x98fn2ycF56Ys+d3592133GLCMljGCAjgwggI0AgEBMIGKMHwxEzARBgoJkiaJk/Is ZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgd0ZWxzdHJhMRMwEQYKCZImiZPyLGQBGRYDZGlyMRQw EgYKCZImiZPyLGQBGRYEY29yZTEhMB8GA1UEAxMYVGVsc3RyYSBVc2VyIElzc3VpbmcgQ0ExAgon IE5VAAAAAAF5MAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwMjA0MDUyMjU0WjAjBgkqhkiG9w0BCQQxFgQUpE7qaZ0csjDh17x2fbDEyy5r 3IQwJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASC AQACyKVJ6ltFYYycyIxs72sgaT61CdzRvWlrzJfbqZ2i02emfLVawyBZn5YqxqBVXeDOXmUabRei f8H58Bf72sQ2bR1b6DbrPKd4LWLtp33R0WWoFBGBRJJll+1Npm6r1/up0DYGzUw5B2tZjn+BG6nh id2o739CxpdkbrQIC7qVm/aNzD1P/9udCy9UJw5yd/QaBCFMzF0rmtc2wEeXrvVQWSLJSJsOx8oR Ryf5M/Pt7lEqheCHj/+Eq4LyJvS7mrzfqQiwGpiZ5vT0OWbduGeen55+budboGQ0Mf6D7ZvPjNnG hDbLTIpK2a0vD8u/GdVI4U1doIVEjDRKOvH6yyubAAAAAAAA ------=_NextPart_000_0014_01CBC487.C6B5E6B0-- From eran@hueniverse.com Thu Feb 3 21:58:49 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFEE3A69EC for ; Thu, 3 Feb 2011 21:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObMxoTvrXFdJ for ; Thu, 3 Feb 2011 21:58:48 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5B0C93A6778 for ; Thu, 3 Feb 2011 21:58:48 -0800 (PST) Received: (qmail 19035 invoked from network); 4 Feb 2011 06:02:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2011 06:02:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Feb 2011 23:02:10 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Thu, 3 Feb 2011 23:02:00 -0700 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/ABAMSawA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 05:58:49 -0000 Thanks James. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, February 03, 2011 9:23 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2- > mac-token-02 >=20 > Comments on draft-hammer-oauth-v2-mac-token-02 > >=20 > This draft is a good improvement. >=20 > (continuing numbering from my previous comments) >=20 > 11. The "access token" field would be better labelled "id". The MAC schem= e > only needs this field to identify the MAC secret. The MAC scheme itself > doesn't need to care whether this id also represents a scope, duration, > assertion etc. >=20 > Though it may slightly complicated the use of the MAC scheme with OAuth2, > I would seriously consider supporting two identifiers: > * An authentication id -- to identify the key used to verify the MAC; and > * An authorization id -- to identify the > scope/account/permissions/duration... > that the client want to act under. > The SASL framework has these two concepts > [RFC4422 Simple Authentication and Security Layer (SASL)]. > Any modern SASL authentication mechanism will be expected to support > both ids. > The authorization id is a good match for an OAuth2 token or other sort of > assertion. > The OAuth2-to-MAC binding could define a 'keyid' parameter to accompany > the 'secret'. > The 'keyid' value would map to the authentication id field in the MAC > scheme, and the 'access_token' would map to the authorization id field. I don't see the value of this, but I do see how it complicates both the spe= cification and its usage with OAuth. The token can be constructed using the= se two identifiers if needed, outside its use with OAuth, but my instinctiv= e reaction is that if you need something that much more specific, you will = be better off using something else. > 12. Which bytes does the body hash apply to? Is it the "message-body" or > "payload body" (in HTTPbis parlance)? I assume any Transfer-Encoding (eg > chunked) is removed before calculating the body hash, but any Content- > Encoding (eg gzip) is not removed. The spec should explicitly state this.= [c.f. > wording as for the "Content-MD5" header in draft-ietf-httpbis-p3-payload- > 12, section 6.8] I'll make this clear. =20 > 13. The MAC algorithm should be explicitly indicated in the request, inst= ead > of being implied by the access-token/id. I suggest including an "algorith= m" > parameter in the "Authorization" request header. I also suggest including= an > "algorithms" parameter in the "WWW-Authenticate" response header that is > a > (comma-separated?) list of MAC algorithms that the server supports. Why? The client does not get a choice which algorithm to use. There is no n= egotiation here. > 14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-256= ) are > used to calculate the body hash when using the hmac-sha-1 (and hmac-sha- > 256) algorithm. Why isn't 3.2 enough? That's where body hash is discussed. > 15. 3.3.2 (and 3.3.3) shouldn't mention the OAuth-specific "authorization > server" (when defining their "key" field). Ok. > 16. OAuth2 can provide a "secret" as a Unicode string. MAC algorithms suc= h > as HMAC use a key that is a byte array. Section 2 of the MAC spec says > 'secret' > can only include printable ASCII chars (except " and /). This is not quit= e right. > The MAC scheme should expect 'secret' to be a byte array (ie not limit it= s > chars). A 'secret' string from an OAuth2 response should be UTF-8 encoded > to produce the byte array the MAC scheme uses. What about when the secret is returned in the HTTP fragment? What is the va= lue of making this use UTF-8. > 17. This MAC scheme should be compared to the SCRAM SASL mechanism > [RFC 5802]. > SCRAM is the latest-and-greatest authentication mechanism based on a > shared secret (without using the brilliant, but patent-troubled, zero- > knowledge proof techniques). > It has quite a few features that MAC is missing: two ids (auth & authz); > credentials at the server are not sufficient to impersonate the client (n= ot a > "password-equivalent"); mutual authentication; channel binding (to an > underlying TLS secure tunnel). > I don't think MAC can achieve all these properties. The MAC scheme almost > certainly wants to avoid multiple exchanges at the HTTP layer. I expect t= he > wider IETF community to judge MAC by comparing it negatively to SCRAM > unless the document is quite clear about its constraints (eg sign an HTTP > request without any interactivity with the server; suitable for shared se= cret > keys, but not for shared passwords...). I'll make this comparison clear in the introduction. EHL >=20 > -- > James Manger >=20 >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Tuesday, 11 January 2011 5:05 PM > To: OAuth WG > Subject: [OAUTH-WG] MAC: comments on draft-hammer-oauth-v2-mac- > token-00 >=20 > Comments on draft-hammer-oauth-v2-mac-token-00 > >=20 > 1. The connection of this MAC scheme to OAuth is secondary. The primary > function of the MAC scheme is to secure the authenticity of parts of an H= TTP > request using a shared secret. Section 2 "Issuing MAC-Type Access Tokens" > would be better at the end, ideally as an Annex, along with most of the > OAuth talk from the introduction (and title). >=20 > 2. Include a \n after the final query string parameter. > It makes the format simply lines of text, instead of making the last line= special > (and only special if there are query params). It is awkward to manually e= dit > sample files, debug files etc without a final newline character. > Adding a final \n would just make it more consistent. >=20 > 3. The Authorization header example in 1.1 uses single quotes around valu= es. > It should use double quotes. The ABNF in 3.1 for timestamp, for instance, > explicitly uses <">. >=20 > 4. The quoted-string production only supports a subset of ASCII. Better a= dd a > sentence stating that the 'token' is assumed to only use this subset so n= o > escaping is defined. May be worth adding that only double-quote and > backslash need escaping in quoted-string, but neither of those are allowe= d in > any of this specs parameters so no escaping in quoted-string values shall > occur. >=20 > 5. Don't list the new line characters as separate numbered items in secti= on > 3.2.1 "Normalized Request String". Better to say it is a line-based forma= t. > Each line ends with a single new line character (U+000A). Then list the 7= lines > (as points 1 to 7), followed by point 8 saying there is 1 extra line for = each > query string parameter. >=20 > 6. I18N. Is the Normalised Request String UTF-8, or does it happen to be = just > ASCII? Host, path, and query strings can contain non-ASCII characters -- = but I > guess that the ASCII-only escaping used to create an HTTP Host header and > URI are assumed to have occurred before this spec uses these values. Woul= d > be worth an explicit statement, and definitely an example. >=20 > 7. I suggest swapping steps 2 (sort) & 3 (combine escaped name and value)= in > section 3.2.1.1. "Parameters Normalization". > The current 2-layer sort is not ideal (sort on %-escaped name, then on %- > escaped value if the names are equal). It needs a special comparator func= tion > etc, instead of using a programming language's standard sort-a-list-of-st= rings > function. It is tempting to concatenate %-escaped name=3Dvalue pairs and = sort > those -- but it doesn't always give the same result. > Eg a1=3DX and a11=3DY should sort in that order according to the spec, bu= t "1" < > "=3D" in an ASCII string comparison of the pairs. > A programmer probably has a map/dictionary/assoc-array of unescaped > names to values. The normalisation rules require a separate map of escape= d > names to escaped values plus a custom comparator that considers names > and values. > A nicer alternative would be to construct escaped name=3Dvalue pairs then > sort that list (not map). > It would be worth adding another parameter to the example (eg a22=3DA) to > illustrate this (regardless of whether or not the steps are swapped). >=20 > 8. HMAC operates on bytes, not strings. The 'text' and 'key' HMAC inputs = (in > 3.2.2 and 3.2.3) should be specified as the UTF-8-encoding of the Normali= zed > Request String and access token shared secret respectively. Might be able= to > say ASCII-encoding, but only if we are sure that an OAuth token response > (which might be a UTF-8 JSON blob) can never return non-ASCII chars in a > 'secret' field. >=20 > 9. The 'secret' parameter is registered twice (7.1 & 7.2). I guess one of= these > should be registering the 'algorithm' parameter instead. >=20 > 10. I would like a "WWW-Authenticate: MAC algorithm=3D..." response heade= r > defined. It would provide a nice illustration of how a complete HTTP auth > scheme is mapped to OAuth2. That is, how the scheme name "MAC" and > parameters from the "WWW-Authenticate: MAC ..." response header can be > mapped to fields in an OAuth2 token response (where they are accompanied > by an actual secret key). >=20 > -- > James Manger From James.H.Manger@team.telstra.com Thu Feb 3 22:29:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19443A687B for ; Thu, 3 Feb 2011 22:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=0.018, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYYKFJJ2JJ6L for ; Thu, 3 Feb 2011 22:29:21 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 953E93A6784 for ; Thu, 3 Feb 2011 22:29:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,424,1291554000"; d="scan'208";a="23995516" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 04 Feb 2011 17:32:43 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6245"; a="18959555" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 04 Feb 2011 17:32:43 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 4 Feb 2011 17:32:42 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Fri, 4 Feb 2011 17:32:41 +1100 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/ABAMSawAAAVoow Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D458345@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 06:29:23 -0000 >> 14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-25= 6) are >> used to calculate the body hash when using the hmac-sha-1 (and hmac-sha- >> 256) algorithm. > Why isn't 3.2 enough? That's where body hash is discussed. 3.2 says the "body hash algorithm is determined by the access token algorit= hm" so it makes sense to state the former where you define the latter (in 3= .3.2 & 3.3.3). If someone ever wants to specify another algorithm the obvious thing to do = is start with the text in 3.3.2 "hmac-sha-1" and modify it for the new algo= rithm -- but that would miss the extra detail that an algorithm spec needs = (indicating a body hash alg). Anyway, this is a basically a minor editorial issue. -- James Manger From eran@hueniverse.com Thu Feb 3 22:29:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84B63A6784 for ; Thu, 3 Feb 2011 22:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WxVo6Iox7ij for ; Thu, 3 Feb 2011 22:29:22 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 170753A6877 for ; Thu, 3 Feb 2011 22:29:21 -0800 (PST) Received: (qmail 31958 invoked from network); 4 Feb 2011 06:32:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Feb 2011 06:32:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Feb 2011 23:32:44 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , "oauth@ietf.org" Date: Thu, 3 Feb 2011 23:32:35 -0700 Thread-Topic: [OAUTH-WG] New Working Group Items? Thread-Index: AcvDvi2jQeKl1EycSGiLAU6ABng9vwAczEnw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3514@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4AD58E.9090407@gmx.net> In-Reply-To: <4D4AD58E.9090407@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 Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 06:29:26 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 8:19 AM > A) Simple Web Discovery (SWD) > http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt This has no business in this working group. It is not even the appropriate = venue for discussions (the application area list is much more suitable). In= addition, it is directly competing with other efforts without any attempt = to address them. > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ I am not sure I want this to become a WG item, given the WG's apparent inte= rest in engineering a solution that involves repeating HTTP bits in a signa= ture specific payload. I am only interested in making this an official WG i= tem if it is clearly scoped to work with a single HTTP request (i.e. no Dig= est like round trips), and without any duplication of request bits (HTTP me= thod, request URI, etc.). This does not preclude such proposals, but that's= a completely separate item. =20 MAC is already implemented in an open source library and in a product that = will ship in the next few month. > C) Token Revocation > http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01 Will review. > D) OAuth 2.0 Device Profile > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Will review. > E) OAuth 2.0 User Experience Extension > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 Will review and happy to help with editorial. > G) OAuth Dynamic Client Registration Protocol > http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 No objections but this feel premature. I would like to see some working imp= lementations of this in shipped products.=20 > H) OAuth Use Cases > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases I am not sure if this is worth the effort if it requires WG resources, but = if the author is willing to keep working on it, I support its publication. EHL From pjwalker@gmail.com Thu Feb 3 23:03:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D13F3A6B5F for ; Thu, 3 Feb 2011 23:03:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzLS4Wy37ECz for ; Thu, 3 Feb 2011 23:03:49 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 35B223A6B1F for ; Thu, 3 Feb 2011 23:03:48 -0800 (PST) Received: by pzk5 with SMTP id 5so426610pzk.31 for ; Thu, 03 Feb 2011 23:07:13 -0800 (PST) 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=VNbzzZ2WLHsAuQxMgL1AcZAzAPKTDTcG9HoVWz8h/mQ=; b=OvOcli0mhNEzgj0xbyL/TBlir8ey4KHBglEbCm8SjHkYkNki9gJRGFXuhEfqGJngpU 16wjid6cgkHAWmy2xziuADoPt+ce4owfir5LJilcvFLTLA5pupAUfmm7kvlVhskk9Hf0 vgslwmqP2dFfM163BcjSu9XVcRI09ChN7mqQE= 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=t534FnYXovFPbEmNhbbzpVrMkXfCHJt6wqT3TnWhgvEi19scj5EVlpxJ+ABlJ7/gB9 VsQsqiLiRHzI8GDhBB+GWNlTG2tQci0k9pzvPMwPPLyTx77mf62U6te6WBLta/KsXlw4 QBlDyJUMRomiPgI+pkIo727Ye0Eav2+e4QoTk= Received: by 10.142.163.19 with SMTP id l19mr5076793wfe.202.1296803233215; Thu, 03 Feb 2011 23:07:13 -0800 (PST) Received: from [192.168.1.103] (ip70-181-133-26.sd.sd.cox.net [70.181.133.26]) by mx.google.com with ESMTPS id w22sm537938wfd.19.2011.02.03.23.07.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 23:07:12 -0800 (PST) From: Paul Walker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 23:07:10 -0800 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] token_type parameter value X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 07:03:55 -0000 In no place in the OAuth 2.0 Bearer Token Specification does it actually = say what the token_type parameter value should be in the access token = response. The only way anyone is able to pick this up is gleaning it = from the example in the OAuth 2.0 specification itself. And the only = way a reader can do that is by assuming the different font used in the = html version for "bearer" means that that is the value to be used for = the token_type parameter.= From beaton@google.com Thu Feb 3 23:54:33 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A8D3A6888 for ; Thu, 3 Feb 2011 23:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.477 X-Spam-Level: X-Spam-Status: No, score=-105.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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aaHG0k6X3sq for ; Thu, 3 Feb 2011 23:54:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 82E5C3A6882 for ; Thu, 3 Feb 2011 23:54:31 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p147vs34010756 for ; Thu, 3 Feb 2011 23:57:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296806275; bh=zm6SgY5zZle3s1bOiwznNkFUygE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=W/F2gpVA6YpYQP2bgtSqISA/6fQFhwdh66aFa5tuHFNrlG4fwQBAMks500Kov9EsX diO/jaquXmE1qrDkWwOXw== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by hpaq3.eem.corp.google.com with ESMTP id p147vpFO021004 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 3 Feb 2011 23:57:53 -0800 Received: by pwj3 with SMTP id 3so406050pwj.33 for ; Thu, 03 Feb 2011 23:57:51 -0800 (PST) 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=XUGSP7a56tjvu9Mam1STcrKRicmFyKKnIlnUuvP2ARw=; b=cZlDjFXtygtJlcRrHjjNsS6cwKCmhlhQ4abI72SD9NR7JrNMrFSSxdoBvluEdcsyET PQCb6swlztsbJ+8xnngw== 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=URgvuFakN7cDG9R2BN6bMgXEiidma2T2gWWBp7wV7s/pjn8uXBu+7L7BwArqTDYkrz QWLu0/m5OJ8hK4CgmxXQ== MIME-Version: 1.0 Received: by 10.142.246.20 with SMTP id t20mr2474810wfh.340.1296806271180; Thu, 03 Feb 2011 23:57:51 -0800 (PST) Received: by 10.142.213.7 with HTTP; Thu, 3 Feb 2011 23:57:51 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 3 Feb 2011 23:57:51 -0800 Message-ID: From: Brian Eaton To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 07:54:33 -0000 How do we reconcile "Bearer" with "Negotiate", "NTLM", "Basic", and "GoogleLogin"? All of those examples are widely deployed and use bearer tokens in Authorization headers. Should all of those switch to using the "Bearer" scheme as well? Tokens issued via OAuth will require specific validation logic, for exactly the same reasons that all of the above examples have specific, different validation logic. The normal way code that needs to deal with multiple authentication types gets written is to look at the scheme name, and then switch out library support based on the scheme. Something like "Bearer" seems overly generic. Why do we think we are qualified to claim "Bearer" for our own? On Thu, Feb 3, 2011 at 8:24 PM, Manger, James H wrote: > +1 for #1 > > > > #2 is awful; #3 is unnecessary; #4 =93OAuth2=94 just has less meaning tha= n, say, > =93Bearer=94. > > #1 offers the cleanest separation between =93using-a-token to authenticat= ed a > request=94 and =93a delegation flow to authorize a client=94 which is lik= ely to be > helpful for lots of people now and in the future trying to get their head= s > around this complex space. > > > > -- > > James Manger > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Thursday, 3 February 2011 7:34 PM > To: OAuth WG > > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) > > > > After a long back-and-forth, I think it is time to present a few options = and > have people express their preferences. > > > > These are the options mentioned so far and their +/-: > > > > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > > =85 > > 2. Single OAuth2 scheme with sub-schemes > > =85 > > 3. Name prefix (e.g. oauth2_bearer) > > =85 > > 4. OAuth2 for bearer, MAC for mac > > =85 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Fri Feb 4 00:07:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351223A6889 for ; Fri, 4 Feb 2011 00:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Use9e5ss1Rxu for ; Fri, 4 Feb 2011 00:07:05 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5EF383A6936 for ; Fri, 4 Feb 2011 00:07:05 -0800 (PST) Received: (qmail 1270 invoked from network); 4 Feb 2011 08:10:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2011 08:10:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Feb 2011 01:07:11 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "Manger, James H" Date: Fri, 4 Feb 2011 01:07:03 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEQT5e4do/uEFiSzyp3fAtLVTCMwAAIocQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:07:06 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, February 03, 2011 11:58 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > How do we reconcile "Bearer" with "Negotiate", "NTLM", "Basic", and > "GoogleLogin"? All of those examples are widely deployed and use bearer > tokens in Authorization headers. Should all of those switch to using the > "Bearer" scheme as well? Basic and Digest use the same credentials, only in different ways. =20 > Something like "Bearer" seems overly generic. Why do we think we are > qualified to claim "Bearer" for our own? We can use any name we want as long as it is not taken, and is not misleadi= ng. 'Bearer' passes this test. This is not a sexy namespace like link relat= ions or HTML tags where everyone wants to claim a name. You define a scheme= and name it. =20 EHL > On Thu, Feb 3, 2011 at 8:24 PM, Manger, James H > wrote: > > +1 for #1 > > > > > > > > #2 is awful; #3 is unnecessary; #4 "OAuth2" just has less meaning > > than, say, "Bearer". > > > > #1 offers the cleanest separation between "using-a-token to > > authenticated a request" and "a delegation flow to authorize a client" > > which is likely to be helpful for lots of people now and in the future > > trying to get their heads around this complex space. > > > > > > > > -- > > > > James Manger > > > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, 3 February 2011 7:34 PM > > To: OAuth WG > > > > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > > > > > > > After a long back-and-forth, I think it is time to present a few > > options and have people express their preferences. > > > > > > > > These are the options mentioned so far and their +/-: > > > > > > > > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > > > > ... > > > > 2. Single OAuth2 scheme with sub-schemes > > > > ... > > > > 3. Name prefix (e.g. oauth2_bearer) > > > > ... > > > > 4. OAuth2 for bearer, MAC for mac > > > > ... > > > > _______________________________________________ > > 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 balfanz@google.com Fri Feb 4 08:28:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995C03A69BF for ; Fri, 4 Feb 2011 08:28:21 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUY0Zcldg2df for ; Fri, 4 Feb 2011 08:28:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E314C3A695F for ; Fri, 4 Feb 2011 08:28:19 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p14GVhJJ025685 for ; Fri, 4 Feb 2011 08:31:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296837104; bh=I2kG96Dc+RdkX90TdZpD+NbMrbQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FEIaFXkK0gzrbqCLzaKWMlTC/4FfVIJY2KmZBdJG6xrA+QkdXUUk7mFtSDEs0nRx2 9i5OB3D99vzGKKn5uCHaw== Received: from iyj18 (iyj18.prod.google.com [10.241.51.82]) by wpaz9.hot.corp.google.com with ESMTP id p14GVfNS024704 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Feb 2011 08:31:42 -0800 Received: by iyj18 with SMTP id 18so2419044iyj.12 for ; Fri, 04 Feb 2011 08:31:41 -0800 (PST) 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=9LItzDy5XGs8p1/+7ElqvLe7G1XxGfP1qkkXB64gxLY=; b=pkfWUFsCeRZ8gQuidbhqeU6Cegb2725XcY6b58SlITcI2pajgbY2f2g0yyvcyfkQ7+ 8DrX4TvNB8AtlYPH+Fzg== 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=YuLGksrUzoKw//Ms1tltkar4TFb2CDby+TcuomEPyv5C0DP9mYKj2CyCOTdAWjeCcQ vplOD03bwGQREJBprQDA== MIME-Version: 1.0 Received: by 10.231.192.73 with SMTP id dp9mr13231528ibb.20.1296837100841; Fri, 04 Feb 2011 08:31:40 -0800 (PST) Received: by 10.231.12.73 with HTTP; Fri, 4 Feb 2011 08:31:40 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Feb 2011 08:31:40 -0800 Message-ID: From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016367d6740ba2d00049b776af7 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:28:21 -0000 --0016367d6740ba2d00049b776af7 Content-Type: text/plain; charset=ISO-8859-1 FWIW, I agree with Brian - it should say OAuth somewhere, because it's an OAuth token. My vote would be for OAuth2 for bearer tokens, and OAuth2Signed for MAC tokens, for all the backward-compatibility issues with oauth_bearer, etc. Dirk. On Fri, Feb 4, 2011 at 12:07 AM, Eran Hammer-Lahav wrote: > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Eaton > > Sent: Thursday, February 03, 2011 11:58 PM > > To: Manger, James H > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > > 2/10) > > > > How do we reconcile "Bearer" with "Negotiate", "NTLM", "Basic", and > > "GoogleLogin"? All of those examples are widely deployed and use bearer > > tokens in Authorization headers. Should all of those switch to using the > > "Bearer" scheme as well? > > Basic and Digest use the same credentials, only in different ways. > > > Something like "Bearer" seems overly generic. Why do we think we are > > qualified to claim "Bearer" for our own? > > We can use any name we want as long as it is not taken, and is not > misleading. 'Bearer' passes this test. This is not a sexy namespace like > link relations or HTML tags where everyone wants to claim a name. You define > a scheme and name it. > > EHL > > > On Thu, Feb 3, 2011 at 8:24 PM, Manger, James H > > wrote: > > > +1 for #1 > > > > > > > > > > > > #2 is awful; #3 is unnecessary; #4 "OAuth2" just has less meaning > > > than, say, "Bearer". > > > > > > #1 offers the cleanest separation between "using-a-token to > > > authenticated a request" and "a delegation flow to authorize a client" > > > which is likely to be helpful for lots of people now and in the future > > > trying to get their heads around this complex space. > > > > > > > > > > > > -- > > > > > > James Manger > > > > > > > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > > Of Eran Hammer-Lahav > > > Sent: Thursday, 3 February 2011 7:34 PM > > > To: OAuth WG > > > > > > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: > > 2/10) > > > > > > > > > > > > After a long back-and-forth, I think it is time to present a few > > > options and have people express their preferences. > > > > > > > > > > > > These are the options mentioned so far and their +/-: > > > > > > > > > > > > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > > > > > > ... > > > > > > 2. Single OAuth2 scheme with sub-schemes > > > > > > ... > > > > > > 3. Name prefix (e.g. oauth2_bearer) > > > > > > ... > > > > > > 4. OAuth2 for bearer, MAC for mac > > > > > > ... > > > > > > _______________________________________________ > > > 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 > --0016367d6740ba2d00049b776af7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW, I agree with Brian - it should say OAuth somewhere, because it's = an OAuth token. My vote would be for OAuth2 for bearer tokens, and OAuth2Si= gned for MAC tokens, for all the backward-compatibility issues with oauth_b= earer, etc.

Dirk.

On Fri, Feb 4, 2011 = at 12:07 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Brian Eaton
> Sent: Thursday, February 03, 2011 11:58 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Bearer token type and = scheme name (deadline:
> 2/10)
>
> How do we reconcile "Bearer" with &q= uot;Negotiate", "NTLM", "Basic", and
> "GoogleLogin"? =A0All of those examples are widely deployed = and use bearer
> tokens in Authorization headers. =A0Should all of those switch to usin= g the
> "Bearer" scheme as well?

Basic and Digest use the same credentials, only in different ways.

> Something like "Bearer" seems overly generic. =A0Why do we t= hink we are
> qualified to claim "Bearer" for our own?

We can use any name we want as long as it is not taken, and is not mi= sleading. 'Bearer' passes this test. This is not a sexy namespace l= ike link relations or HTML tags where everyone wants to claim a name. You d= efine a scheme and name it.

EHL

> On Thu, Feb 3, 2011 at 8:24 PM, Manger, James H
> <James.H.Manger@= team.telstra.com> wrote:
> > +1 for #1
> >
> >
> >
> > #2 is awful; #3 is unnecessary; #4 "OAuth2" just has le= ss meaning
> > than, say, "Bearer".
> >
> > #1 offers the cleanest separation between "using-a-token to<= br> > > authenticated a request" and "a delegation flow to auth= orize a client"
> > which is likely to be helpful for lots of people now and in the f= uture
> > trying to get their heads around this complex space.
> >
> >
> >
> > --
> >
> > James Manger
> >
> >
> >
> > From: oauth-bounces@iet= f.org [mailto:oauth-bounces@i= etf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Thursday, 3 February 2011 7:34 PM
> > To: OAuth WG
> >
> > Subject: [OAUTH-WG] Bearer token type and scheme name (deadline:<= br> > 2/10)
> >
> >
> >
> > After a long back-and-forth, I think it is time to present a few<= br> > > options and have people express their preferences.
> >
> >
> >
> > These are the options mentioned so far and their +/-:
> >
> >
> >
> > 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
> >
> > ...
> >
> > 2. Single OAuth2 scheme with sub-schemes
> >
> > ...
> >
> > 3. Name prefix (e.g. oauth2_bearer)
> >
> > ...
> >
> > 4. OAuth2 for bearer, MAC for mac
> >
> > ...
> >
> > _______________________________________________
> > 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016367d6740ba2d00049b776af7-- From mscurtescu@google.com Fri Feb 4 09:36:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492403A69FA for ; Fri, 4 Feb 2011 09:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.88 X-Spam-Level: X-Spam-Status: No, score=-103.88 tagged_above=-999 required=5 tests=[AWL=-0.903, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0cb5CEduaof for ; Fri, 4 Feb 2011 09:36:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CF2AD3A68C5 for ; Fri, 4 Feb 2011 09:36:17 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p14Hdgx3003288 for ; Fri, 4 Feb 2011 09:39:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296841182; bh=GPc5bcokW7YkJG+q5YHIulfOf/k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ivc/V/aF0bE9KUNFheTA4CBJLG9eIP6l33CMP4fdALUGBRlXnCiqugiGO+PoVqm3O oZzv4VbrKsnWrbbVGAg3g== Received: from yib17 (yib17.prod.google.com [10.243.65.81]) by wpaz29.hot.corp.google.com with ESMTP id p14Hde3Q018411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Feb 2011 09:39:41 -0800 Received: by yib17 with SMTP id 17so1117896yib.21 for ; Fri, 04 Feb 2011 09:39:40 -0800 (PST) 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=4VSYhvt/a9oz3+zTeybh5dHTxTZ1keL5zCf3PxhFcos=; b=bdSo2pEwJ8k/julRPh6aSv9UgUMwOmMuRiNV8XV2ygWvQgBvvtgv0muCwqMJw1ALZU LFIxe7uhi3KCfhDq+Whg== 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=P4G/XNDI4OnwCQc0/bQVCSitYFuEUQ9mewLePCBzcF4atsagV3YlyHK1VQ7vfZVq0v nEqEwK0KDQe7aknZ3FOA== Received: by 10.100.227.17 with SMTP id z17mr7670963ang.214.1296841180736; Fri, 04 Feb 2011 09:39:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Fri, 4 Feb 2011 09:39:20 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 4 Feb 2011 09:39:20 -0800 Message-ID: To: Eran Hammer-Lahav 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 type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:36:19 -0000 On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav wr= ote: > Hey Marius, > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, February 03, 2011 10:36 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >> >> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >> wrote: >> >> > 2. Single OAuth2 scheme with sub-schemes >> > >> > Define a single authentication scheme for all token types with some >> > attribute used to detect which scheme is actually being used. >> > >> > Benefits: >> > >> > - single scheme, reuse of the 1.0 pattern. >> > >> > Downsides: >> > >> > - requires a new registry for authentication header parameters. >> >> How is this different from option 1? Wouldn't that need some registry? > > #1 relies on the existing practice of creating HTTP scheme names (no curr= ent registry but httpbis might be creating one), as well as the -12 token t= ype registry. Using a sub-scheme means you also need a registry for the hea= der attributes that each token type will need (unless you just don't care a= bout using the same attribute name for different needs). Sure, there is no registry for schemes yet, but we would still need some coordination. The fact that a sub-scheme needs a registry that we control is a benefit not a downside IMO. >> > - schemes are not easily reusable outside OAuth. >> >> Sure. But I really don't see this group trying to create generic authent= ication >> schemes. > > MAC is exactly that. May or may not be. My point is that this group is not focused on creating generic authentication schemes. Are you aware of any other protocols that might use MAC or BEARER? Are we willing to put in the effort to create generic schemes? Is it our charter? >> > - existing frameworks usually switch on scheme name, not on sub >> > scheme, which will cause difficulty in some deployments. >> >> I can see this as a potential problem. But considering that there wasn't= much >> objection to use "OAuth" as a scheme name before (total overlap with >> OAuth 1, and the suggested solution was to look for the signature >> parameter) I don't see how this is suddenly an issue. > > There was pretty strong objection to reusing OAuth. Yes, because there was no sub-scheme nor version (and the grammar was totally broken). Even so, lots of implementations went ahead and did it. Were there any scheme switching issues we are aware of? >> Do we have a concrete problem here or this is just theoretical? > > This came up during the review of draft-hammer-http-token-auth [1]. There= was a long thread about it where people posted actual framework issues. > >> > - potential to produce a very complicated scheme once many sub schemes >> > are added. >> >> Why? I would argue that this option actually produces more uniform >> schemes because it forces all of them to be name/value pairs. Beyond >> token_type everything is scheme specific. I really don't see what is ver= y >> complicate here. > > It is still a single scheme with many different sub-schemes, each with di= fferent key-value pairs that may have conflicting meaning. The way I look a= t it is that if I try to fully implement this mega scheme (which means all = its sub-schemes), it will likely be a complicated task. On the other hand, = if you split it across scheme name, we already have a well-established syst= em in place to pick and choose HTTP authentication schemes. No one has to implement a mega scheme. All schemes must use name/value pairs and that's where the common part stops. >> > - requires its own discovery method for which schemes are supported. >> >> Why is this a downside only for this option? > > Because the other options get this for free by using the WWW-Authenticate= header (since each scheme has a unique name). You can list multiple header= s in the 401 response. I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate work for sub-schemes as well? > Should I record your vote for #2? #2 or #3 Thanks, Marius From phil.hunt@oracle.com Fri Feb 4 09:38:57 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA083A69FA for ; Fri, 4 Feb 2011 09:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK1N+YDZ6DKA for ; Fri, 4 Feb 2011 09:38:51 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 877233A69E3 for ; Fri, 4 Feb 2011 09:38:51 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p14Hg80L025072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 17:42:10 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p14F1fUf002663; Fri, 4 Feb 2011 17:42:06 GMT Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 1024633671296841323; Fri, 04 Feb 2011 09:42:03 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Feb 2011 09:42:02 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 4 Feb 2011 09:42:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D4C3A6F.002A:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:38:57 -0000 OAuth should be able to support other token schemes. =20 Or conversely you don't have to have OAuth to use MAC, JWT, or whatever. Phil phil.hunt@oracle.com On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav = wrote: >> Hey Marius, >>=20 >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Thursday, February 03, 2011 10:36 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>> 2/10) >>>=20 >>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>> wrote: >>>=20 >>>> 2. Single OAuth2 scheme with sub-schemes >>>>=20 >>>> Define a single authentication scheme for all token types with some >>>> attribute used to detect which scheme is actually being used. >>>>=20 >>>> Benefits: >>>>=20 >>>> - single scheme, reuse of the 1.0 pattern. >>>>=20 >>>> Downsides: >>>>=20 >>>> - requires a new registry for authentication header parameters. >>>=20 >>> How is this different from option 1? Wouldn't that need some = registry? >>=20 >> #1 relies on the existing practice of creating HTTP scheme names (no = current registry but httpbis might be creating one), as well as the -12 = token type registry. Using a sub-scheme means you also need a registry = for the header attributes that each token type will need (unless you = just don't care about using the same attribute name for different = needs). >=20 > Sure, there is no registry for schemes yet, but we would still need > some coordination. The fact that a sub-scheme needs a registry that we > control is a benefit not a downside IMO. >=20 >=20 >>>> - schemes are not easily reusable outside OAuth. >>>=20 >>> Sure. But I really don't see this group trying to create generic = authentication >>> schemes. >>=20 >> MAC is exactly that. >=20 > May or may not be. My point is that this group is not focused on > creating generic authentication schemes. Are you aware of any other > protocols that might use MAC or BEARER? Are we willing to put in the > effort to create generic schemes? Is it our charter? >=20 >=20 >>>> - existing frameworks usually switch on scheme name, not on sub >>>> scheme, which will cause difficulty in some deployments. >>>=20 >>> I can see this as a potential problem. But considering that there = wasn't much >>> objection to use "OAuth" as a scheme name before (total overlap with >>> OAuth 1, and the suggested solution was to look for the signature >>> parameter) I don't see how this is suddenly an issue. >>=20 >> There was pretty strong objection to reusing OAuth. >=20 > Yes, because there was no sub-scheme nor version (and the grammar was > totally broken). Even so, lots of implementations went ahead and did > it. Were there any scheme switching issues we are aware of? >=20 >=20 >>> Do we have a concrete problem here or this is just theoretical? >>=20 >> This came up during the review of draft-hammer-http-token-auth [1]. = There was a long thread about it where people posted actual framework = issues. >>=20 >>>> - potential to produce a very complicated scheme once many sub = schemes >>>> are added. >>>=20 >>> Why? I would argue that this option actually produces more uniform >>> schemes because it forces all of them to be name/value pairs. Beyond >>> token_type everything is scheme specific. I really don't see what is = very >>> complicate here. >>=20 >> It is still a single scheme with many different sub-schemes, each = with different key-value pairs that may have conflicting meaning. The = way I look at it is that if I try to fully implement this mega scheme = (which means all its sub-schemes), it will likely be a complicated task. = On the other hand, if you split it across scheme name, we already have a = well-established system in place to pick and choose HTTP authentication = schemes. >=20 > No one has to implement a mega scheme. All schemes must use name/value > pairs and that's where the common part stops. >=20 >=20 >>>> - requires its own discovery method for which schemes are = supported. >>>=20 >>> Why is this a downside only for this option? >>=20 >> Because the other options get this for free by using the = WWW-Authenticate header (since each scheme has a unique name). You can = list multiple headers in the 401 response. >=20 > I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > work for sub-schemes as well? >=20 >=20 >> Should I record your vote for #2? >=20 > #2 or #3 >=20 >=20 > Thanks, > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From minoo.hamilton@workday.com Fri Feb 4 10:18:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269DD3A69B3 for ; Fri, 4 Feb 2011 10:18:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrXJVjv+ARoA for ; Fri, 4 Feb 2011 10:18:07 -0800 (PST) Received: from server515.appriver.com (server515h.exghost.com [72.32.253.71]) by core3.amsl.com (Postfix) with ESMTP id D9B9C3A694A for ; Fri, 4 Feb 2011 10:18:06 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2011 12:21:15 PM X-Policy: GLOBAL - workday.com X-Policy: GLOBAL - workday.com X-Primary: minoo.hamilton@workday.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @workday.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.6 X-Note-Reverse-DNS: X-Note-WHTLIST: minoo.hamilton@workday.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G195 G196 G197 G198 G202 G203 G214 G302 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [72.32.49.6] (HELO FE2.exchange.rackspace.com) by server515.appriver.com (CommuniGate Pro SMTP 5.3.5) with ESMTP id 260658852; Fri, 04 Feb 2011 12:21:15 -0600 Received: from 34093-C13-EVS1.exchange.rackspace.com ([192.168.1.237]) by FE2.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 12:21:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC498.4C364666" Date: Fri, 4 Feb 2011 12:24:14 -0600 Message-ID: <4195724F51EFC54FBEFD25223C9761D40308D9ED@34093-C13-EVS1.exchange.rackspace.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwBGtGgw References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Minoo Hamilton" To: "Eran Hammer-Lahav" , "OAuth WG" X-OriginalArrivalTime: 04 Feb 2011 18:21:10.0467 (UTC) FILETIME=[4C517130:01CBC498] Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:18:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC498.4C364666 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I vote for #1. I really do not like the downsides of #4 (promoting bearer to preferred token type). =20 Minoo =20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) =20 After a long back-and-forth, I think it is time to present a few options and have people express their preferences. =20 These are the options mentioned so far and their +/-: =20 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) =20 Each token type gets its own name (which does not include the word 'oauth' in it), as well as a matching HTTP authentication scheme if a new one is being defined. =20 Benefits: =20 - works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatment. - built-in discovery using 401 challenge header for which schemes are supported (with their respective information). =20 Downsides: =20 - potential creation of many new HTTP authentication schemes which has been stable for a long time. =20 2. Single OAuth2 scheme with sub-schemes =20 Define a single authentication scheme for all token types with some attribute used to detect which scheme is actually being used. =20 Benefits: =20 - single scheme, reuse of the 1.0 pattern. =20 Downsides: =20 - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, which will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are added. - requires its own discovery method for which schemes are supported. =20 3. Name prefix (e.g. oauth2_bearer) =20 Benefits: =20 - makes the protocol a bit easier to newbies since it will look all inclusive (authorization and authentication). =20 Downsides: =20 - makes reuse outside OAuth awkward without any technical benefit. =20 4. OAuth2 for bearer, MAC for mac =20 Name the bearer token 'OAuth2' and everything else gets a different name (with or without OAuth in it). =20 Benefits: =20 - Matches current draft. =20 Downsides: =20 - Elevates bearer token to the preferred token type, instead of promoting comparison of the various token types available. - Creates a very odd usage where the authorization server issues an access token of type 'OAuth2' which is non-descriptive and very confusing (since there are other token types). - Uses the name OAuth2 which stands for authorization in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol). =20 --- =20 Please reply with your preference by 2/10. As always, please provide feedback on the options and analysis. =20 EHL =20 =20 ------_=_NextPart_001_01CBC498.4C364666 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I vote for #1.  I really do not like the = downsides of #4 (promoting bearer to preferred token = type).

 

Minoo

 

From:= = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 = AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token = type and scheme name (deadline: = 2/10)

 

After a long = back-and-forth, I think it is time to present a few options and have = people express their preferences.

 

These are = the options mentioned so far and their +/-:

 

1. = Descriptive, non-OAuth-specific scheme names (Bearer, = MAC)

 

Each token type gets its own name (which does not = include the word ‘oauth’ in it), as well as a matching HTTP = authentication scheme if a new one is being defined.

 

Benefits:

 

- works = cleanly with the HTTP authentication framework by simply defining new = methods or reusing existing ones.

- = schemes can be used outside the OAuth authorization flow (e.g. 2-legged = OAuth 1.0 use cases).

- all schemes = are presented equally without giving any a preferred = treatment.

- built-in discovery using = 401 challenge header for which schemes are supported (with their = respective information).

 

Downsides:

 

- potential = creation of many new HTTP authentication schemes which has been stable = for a long time.

 

2. Single = OAuth2 scheme with sub-schemes

 

Define a = single authentication scheme for all token types with some attribute = used to detect which scheme is actually being used.

 

Benefits:

 

- single = scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- requires a = new registry for authentication header parameters.

- schemes are not easily reusable outside = OAuth.

- existing frameworks usually = switch on scheme name, not on sub scheme, which will cause difficulty in = some deployments.

- potential to = produce a very complicated scheme once many sub schemes are = added.

- requires its own discovery = method for which schemes are supported.

 

3. Name = prefix (e.g. oauth2_bearer)

 

Benefits:

 

- makes the = protocol a bit easier to newbies since it will look all inclusive = (authorization and authentication).

 

Downsides:

 

- makes = reuse outside OAuth awkward without any technical = benefit.

 

4. OAuth2 for bearer, MAC for mac

 

Name the = bearer token ‘OAuth2’ and everything else gets a different = name (with or without OAuth in it).

 

Benefits:

 

- Matches = current draft.

 

Downsides:

 

- Elevates = bearer token to the preferred token type, instead of promoting = comparison of the various token types available.

- Creates a very odd usage where the authorization = server issues an access token of type ‘OAuth2’ which is = non-descriptive and very confusing (since there are other token = types).

- Uses the name OAuth2 which = stands for authorization in an authentication flow, continuing the = confusion about what OAuth is (an authorization = protocol).

 

---

 

Please reply = with your preference by 2/10. As always, please provide feedback on the = options and analysis.

 

EHL

 

 

------_=_NextPart_001_01CBC498.4C364666-- From mkent@proofpoint.com Fri Feb 4 10:33:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0453A65A6 for ; Fri, 4 Feb 2011 10:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6S8JhO19ODS for ; Fri, 4 Feb 2011 10:33:33 -0800 (PST) Received: from mx2.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) by core3.amsl.com (Postfix) with ESMTP id 9AAFD3A6A3C for ; Fri, 4 Feb 2011 10:33:33 -0800 (PST) Received: from CUP-POSTAL1.corp.proofpoint.com (cup-sv11.corp.proofpoint.com [10.20.7.111]) by admin1009 (8.14.3/8.14.3) with ESMTP id p140rMCl017642 for ; Thu, 3 Feb 2011 16:53:22 -0800 Received: from 208.86.202.10 ([208.86.202.10]) by CUP-POSTAL1.corp.proofpoint.com ([10.20.7.22]) via Exchange Front-End Server owa.proofpoint.com ([10.20.7.23]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2011 00:53:22 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Feb 2011 16:53:21 -0800 From: Mark Kent To: Message-ID: Thread-Topic: Stored association for Access Token Request Thread-Index: AcvEBesyA22Ln7XyKUuKEMzpWyd6bg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3379596801_17793253" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-02-04_01:2011-02-03, 2011-02-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1102030205 Subject: [OAUTH-WG] Stored association for Access Token Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:33:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3379596801_17793253 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Section 4.1.3 (v12) says: The authorization server MUST: o Validate the client credentials and ensure they match the authorization code. o Verify that the authorization code and redirection URI are valid and match its stored association. The =B3stored association=B2 does not appear to be referenced elsewhere in the document, and it=B9s not clear to me what association is intended, or when it should be established. A cursory search of the archives of this list has no= t provided a conclusive explanation; my apologies if I=B9ve missed something. Thanks, Mark. --B_3379596801_17793253 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Stored association for Access Token Request Section 4.1.3 (v12) says:

  The authorization server MUST:

   o  Validate the client credentials and ensure they m= atch the
      authorization code.
   o  Verify that the authorization code and redirectio= n URI are valid
      and match its stored association.

The “stored association” does not appear to be referenced elsew= here in the document, and it’s not clear to me what association is int= ended, or when it should be established. A cursory search of the archives of= this list has not provided a conclusive explanation; my apologies if I̵= 7;ve missed something.

Thanks,
Mark. --B_3379596801_17793253-- From wmills@yahoo-inc.com Fri Feb 4 11:26:47 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D9A3A69CF for ; Fri, 4 Feb 2011 11:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.53 X-Spam-Level: X-Spam-Status: No, score=-17.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsDFxHN7zDY7 for ; Fri, 4 Feb 2011 11:26:46 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id C5CA13A68FC for ; Fri, 4 Feb 2011 11:26:46 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p14JTqYs048014; Fri, 4 Feb 2011 11:29:52 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Fri, 4 Feb 2011 11:29:52 -0800 From: William Mills To: Phil Hunt , Marius Scurtescu Date: Fri, 4 Feb 2011 11:29:49 -0800 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEkw2ZqwaFJyjYTByRkbD3GS5V9QADr6yw Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> In-Reply-To: <500DC355-E308-4BDA-817F-FC5CCED45172@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] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:26:47 -0000 The only challenge is to know what scheme to use and what the nuances are o= f how to present the credential. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Friday, February 04, 2011 9:42 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > OAuth should be able to support other token schemes. >=20 > Or conversely you don't have to have OAuth to use MAC, JWT, or > whatever. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >=20 > > On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > wrote: > >> Hey Marius, > >> > >>> -----Original Message----- > >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>> Sent: Thursday, February 03, 2011 10:36 AM > >>> To: Eran Hammer-Lahav > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > (deadline: > >>> 2/10) > >>> > >>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > >>> wrote: > >>> > >>>> 2. Single OAuth2 scheme with sub-schemes > >>>> > >>>> Define a single authentication scheme for all token types with > some > >>>> attribute used to detect which scheme is actually being used. > >>>> > >>>> Benefits: > >>>> > >>>> - single scheme, reuse of the 1.0 pattern. > >>>> > >>>> Downsides: > >>>> > >>>> - requires a new registry for authentication header parameters. > >>> > >>> How is this different from option 1? Wouldn't that need some > registry? > >> > >> #1 relies on the existing practice of creating HTTP scheme names (no > current registry but httpbis might be creating one), as well as the -12 > token type registry. Using a sub-scheme means you also need a registry > for the header attributes that each token type will need (unless you > just don't care about using the same attribute name for different > needs). > > > > Sure, there is no registry for schemes yet, but we would still need > > some coordination. The fact that a sub-scheme needs a registry that > we > > control is a benefit not a downside IMO. > > > > > >>>> - schemes are not easily reusable outside OAuth. > >>> > >>> Sure. But I really don't see this group trying to create generic > authentication > >>> schemes. > >> > >> MAC is exactly that. > > > > May or may not be. My point is that this group is not focused on > > creating generic authentication schemes. Are you aware of any other > > protocols that might use MAC or BEARER? Are we willing to put in the > > effort to create generic schemes? Is it our charter? > > > > > >>>> - existing frameworks usually switch on scheme name, not on sub > >>>> scheme, which will cause difficulty in some deployments. > >>> > >>> I can see this as a potential problem. But considering that there > wasn't much > >>> objection to use "OAuth" as a scheme name before (total overlap > with > >>> OAuth 1, and the suggested solution was to look for the signature > >>> parameter) I don't see how this is suddenly an issue. > >> > >> There was pretty strong objection to reusing OAuth. > > > > Yes, because there was no sub-scheme nor version (and the grammar was > > totally broken). Even so, lots of implementations went ahead and did > > it. Were there any scheme switching issues we are aware of? > > > > > >>> Do we have a concrete problem here or this is just theoretical? > >> > >> This came up during the review of draft-hammer-http-token-auth [1]. > There was a long thread about it where people posted actual framework > issues. > >> > >>>> - potential to produce a very complicated scheme once many sub > schemes > >>>> are added. > >>> > >>> Why? I would argue that this option actually produces more uniform > >>> schemes because it forces all of them to be name/value pairs. > Beyond > >>> token_type everything is scheme specific. I really don't see what > is very > >>> complicate here. > >> > >> It is still a single scheme with many different sub-schemes, each > with different key-value pairs that may have conflicting meaning. The > way I look at it is that if I try to fully implement this mega scheme > (which means all its sub-schemes), it will likely be a complicated > task. On the other hand, if you split it across scheme name, we already > have a well-established system in place to pick and choose HTTP > authentication schemes. > > > > No one has to implement a mega scheme. All schemes must use > name/value > > pairs and that's where the common part stops. > > > > > >>>> - requires its own discovery method for which schemes are > supported. > >>> > >>> Why is this a downside only for this option? > >> > >> Because the other options get this for free by using the WWW- > Authenticate header (since each scheme has a unique name). You can list > multiple headers in the 401 response. > > > > I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > > work for sub-schemes as well? > > > > > >> Should I record your vote for #2? > > > > #2 or #3 > > > > > > Thanks, > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Fri Feb 4 11:35:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C003A69D5 for ; Fri, 4 Feb 2011 11:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpmChgJNY-fq for ; Fri, 4 Feb 2011 11:35:01 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E77DC3A69CF for ; Fri, 4 Feb 2011 11:35:00 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p14JcJT8002418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 19:38:21 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p14FAhJi008667; Fri, 4 Feb 2011 19:38:18 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 980906371296848237; Fri, 04 Feb 2011 11:37:17 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Feb 2011 11:37:17 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 4 Feb 2011 11:37:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> To: William Mills X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D4C55AB.005B:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:35:04 -0000 Yes. This should be defined in each token type specification. Phil phil.hunt@oracle.com On 2011-02-04, at 11:29 AM, William Mills wrote: > The only challenge is to know what scheme to use and what the nuances = are of how to present the credential. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Phil Hunt >> Sent: Friday, February 04, 2011 9:42 AM >> To: Marius Scurtescu >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >>=20 >> OAuth should be able to support other token schemes. >>=20 >> Or conversely you don't have to have OAuth to use MAC, JWT, or >> whatever. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >>=20 >>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav >> wrote: >>>> Hey Marius, >>>>=20 >>>>> -----Original Message----- >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>> Sent: Thursday, February 03, 2011 10:36 AM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >> (deadline: >>>>> 2/10) >>>>>=20 >>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>>>> wrote: >>>>>=20 >>>>>> 2. Single OAuth2 scheme with sub-schemes >>>>>>=20 >>>>>> Define a single authentication scheme for all token types with >> some >>>>>> attribute used to detect which scheme is actually being used. >>>>>>=20 >>>>>> Benefits: >>>>>>=20 >>>>>> - single scheme, reuse of the 1.0 pattern. >>>>>>=20 >>>>>> Downsides: >>>>>>=20 >>>>>> - requires a new registry for authentication header parameters. >>>>>=20 >>>>> How is this different from option 1? Wouldn't that need some >> registry? >>>>=20 >>>> #1 relies on the existing practice of creating HTTP scheme names = (no >> current registry but httpbis might be creating one), as well as the = -12 >> token type registry. Using a sub-scheme means you also need a = registry >> for the header attributes that each token type will need (unless you >> just don't care about using the same attribute name for different >> needs). >>>=20 >>> Sure, there is no registry for schemes yet, but we would still need >>> some coordination. The fact that a sub-scheme needs a registry that >> we >>> control is a benefit not a downside IMO. >>>=20 >>>=20 >>>>>> - schemes are not easily reusable outside OAuth. >>>>>=20 >>>>> Sure. But I really don't see this group trying to create generic >> authentication >>>>> schemes. >>>>=20 >>>> MAC is exactly that. >>>=20 >>> May or may not be. My point is that this group is not focused on >>> creating generic authentication schemes. Are you aware of any other >>> protocols that might use MAC or BEARER? Are we willing to put in the >>> effort to create generic schemes? Is it our charter? >>>=20 >>>=20 >>>>>> - existing frameworks usually switch on scheme name, not on sub >>>>>> scheme, which will cause difficulty in some deployments. >>>>>=20 >>>>> I can see this as a potential problem. But considering that there >> wasn't much >>>>> objection to use "OAuth" as a scheme name before (total overlap >> with >>>>> OAuth 1, and the suggested solution was to look for the signature >>>>> parameter) I don't see how this is suddenly an issue. >>>>=20 >>>> There was pretty strong objection to reusing OAuth. >>>=20 >>> Yes, because there was no sub-scheme nor version (and the grammar = was >>> totally broken). Even so, lots of implementations went ahead and did >>> it. Were there any scheme switching issues we are aware of? >>>=20 >>>=20 >>>>> Do we have a concrete problem here or this is just theoretical? >>>>=20 >>>> This came up during the review of draft-hammer-http-token-auth [1]. >> There was a long thread about it where people posted actual framework >> issues. >>>>=20 >>>>>> - potential to produce a very complicated scheme once many sub >> schemes >>>>>> are added. >>>>>=20 >>>>> Why? I would argue that this option actually produces more uniform >>>>> schemes because it forces all of them to be name/value pairs. >> Beyond >>>>> token_type everything is scheme specific. I really don't see what >> is very >>>>> complicate here. >>>>=20 >>>> It is still a single scheme with many different sub-schemes, each >> with different key-value pairs that may have conflicting meaning. The >> way I look at it is that if I try to fully implement this mega scheme >> (which means all its sub-schemes), it will likely be a complicated >> task. On the other hand, if you split it across scheme name, we = already >> have a well-established system in place to pick and choose HTTP >> authentication schemes. >>>=20 >>> No one has to implement a mega scheme. All schemes must use >> name/value >>> pairs and that's where the common part stops. >>>=20 >>>=20 >>>>>> - requires its own discovery method for which schemes are >> supported. >>>>>=20 >>>>> Why is this a downside only for this option? >>>>=20 >>>> Because the other options get this for free by using the WWW- >> Authenticate header (since each scheme has a unique name). You can = list >> multiple headers in the 401 response. >>>=20 >>> I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate >>> work for sub-schemes as well? >>>=20 >>>=20 >>>> Should I record your vote for #2? >>>=20 >>> #2 or #3 >>>=20 >>>=20 >>> Thanks, >>> Marius >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Fri Feb 4 11:41:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CE13A69D5 for ; Fri, 4 Feb 2011 11:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.532 X-Spam-Level: X-Spam-Status: No, score=-17.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxtuZ9zbK0aW for ; Fri, 4 Feb 2011 11:41:31 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 4CBC53A69CF for ; Fri, 4 Feb 2011 11:41:31 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p14JidMr030680; Fri, 4 Feb 2011 11:44:39 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Fri, 4 Feb 2011 11:44:39 -0800 From: William Mills To: Phil Hunt Date: Fri, 4 Feb 2011 11:44:38 -0800 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEoywLXfc25Ax9Sly4oGKQ9ROMHwAABVpw Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> In-Reply-To: <97468434-860E-4E65-BBF2-A61088C9FB02@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] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:41:32 -0000 I was thinking more about how the client knows what to use. The ubiquitous= "service documentation" may come in to play here. Some form of serv ice d= iscovery/webfinger thing could also be used. > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Friday, February 04, 2011 11:37 AM > To: William Mills > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > Yes. This should be defined in each token type specification. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-04, at 11:29 AM, William Mills wrote: >=20 > > The only challenge is to know what scheme to use and what the nuances > are of how to present the credential. > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of Phil Hunt > >> Sent: Friday, February 04, 2011 9:42 AM > >> To: Marius Scurtescu > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > >> 2/10) > >> > >> OAuth should be able to support other token schemes. > >> > >> Or conversely you don't have to have OAuth to use MAC, JWT, or > >> whatever. > >> > >> Phil > >> phil.hunt@oracle.com > >> > >> > >> > >> > >> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > >> > >>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > >> wrote: > >>>> Hey Marius, > >>>> > >>>>> -----Original Message----- > >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>>> Sent: Thursday, February 03, 2011 10:36 AM > >>>>> To: Eran Hammer-Lahav > >>>>> Cc: OAuth WG > >>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > >> (deadline: > >>>>> 2/10) > >>>>> > >>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > >>>>> wrote: > >>>>> > >>>>>> 2. Single OAuth2 scheme with sub-schemes > >>>>>> > >>>>>> Define a single authentication scheme for all token types with > >> some > >>>>>> attribute used to detect which scheme is actually being used. > >>>>>> > >>>>>> Benefits: > >>>>>> > >>>>>> - single scheme, reuse of the 1.0 pattern. > >>>>>> > >>>>>> Downsides: > >>>>>> > >>>>>> - requires a new registry for authentication header parameters. > >>>>> > >>>>> How is this different from option 1? Wouldn't that need some > >> registry? > >>>> > >>>> #1 relies on the existing practice of creating HTTP scheme names > (no > >> current registry but httpbis might be creating one), as well as the > -12 > >> token type registry. Using a sub-scheme means you also need a > registry > >> for the header attributes that each token type will need (unless you > >> just don't care about using the same attribute name for different > >> needs). > >>> > >>> Sure, there is no registry for schemes yet, but we would still need > >>> some coordination. The fact that a sub-scheme needs a registry that > >> we > >>> control is a benefit not a downside IMO. > >>> > >>> > >>>>>> - schemes are not easily reusable outside OAuth. > >>>>> > >>>>> Sure. But I really don't see this group trying to create generic > >> authentication > >>>>> schemes. > >>>> > >>>> MAC is exactly that. > >>> > >>> May or may not be. My point is that this group is not focused on > >>> creating generic authentication schemes. Are you aware of any other > >>> protocols that might use MAC or BEARER? Are we willing to put in > the > >>> effort to create generic schemes? Is it our charter? > >>> > >>> > >>>>>> - existing frameworks usually switch on scheme name, not on sub > >>>>>> scheme, which will cause difficulty in some deployments. > >>>>> > >>>>> I can see this as a potential problem. But considering that there > >> wasn't much > >>>>> objection to use "OAuth" as a scheme name before (total overlap > >> with > >>>>> OAuth 1, and the suggested solution was to look for the signature > >>>>> parameter) I don't see how this is suddenly an issue. > >>>> > >>>> There was pretty strong objection to reusing OAuth. > >>> > >>> Yes, because there was no sub-scheme nor version (and the grammar > was > >>> totally broken). Even so, lots of implementations went ahead and > did > >>> it. Were there any scheme switching issues we are aware of? > >>> > >>> > >>>>> Do we have a concrete problem here or this is just theoretical? > >>>> > >>>> This came up during the review of draft-hammer-http-token-auth > [1]. > >> There was a long thread about it where people posted actual > framework > >> issues. > >>>> > >>>>>> - potential to produce a very complicated scheme once many sub > >> schemes > >>>>>> are added. > >>>>> > >>>>> Why? I would argue that this option actually produces more > uniform > >>>>> schemes because it forces all of them to be name/value pairs. > >> Beyond > >>>>> token_type everything is scheme specific. I really don't see what > >> is very > >>>>> complicate here. > >>>> > >>>> It is still a single scheme with many different sub-schemes, each > >> with different key-value pairs that may have conflicting meaning. > The > >> way I look at it is that if I try to fully implement this mega > scheme > >> (which means all its sub-schemes), it will likely be a complicated > >> task. On the other hand, if you split it across scheme name, we > already > >> have a well-established system in place to pick and choose HTTP > >> authentication schemes. > >>> > >>> No one has to implement a mega scheme. All schemes must use > >> name/value > >>> pairs and that's where the common part stops. > >>> > >>> > >>>>>> - requires its own discovery method for which schemes are > >> supported. > >>>>> > >>>>> Why is this a downside only for this option? > >>>> > >>>> Because the other options get this for free by using the WWW- > >> Authenticate header (since each scheme has a unique name). You can > list > >> multiple headers in the 401 response. > >>> > >>> I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > >>> work for sub-schemes as well? > >>> > >>> > >>>> Should I record your vote for #2? > >>> > >>> #2 or #3 > >>> > >>> > >>> Thanks, > >>> 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 phil.hunt@oracle.com Fri Feb 4 13:10:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267EA3A69A9 for ; Fri, 4 Feb 2011 13:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzRBzt5Bps18 for ; Fri, 4 Feb 2011 13:10:49 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C01633A694A for ; Fri, 4 Feb 2011 13:10:48 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p14LE8td006749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 21:14:10 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p14JKnvm017487; Fri, 4 Feb 2011 21:14:08 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 981142171296854029; Fri, 04 Feb 2011 13:13:49 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Feb 2011 13:13:48 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 4 Feb 2011 13:13:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> To: William Mills X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D4C6C20.00EF:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:10:52 -0000 I agree, that is still to be defined. There seems to be some push back = on discovery, but this is likely warranted. If only because web sites = may have both browser clients and app clients. In a previous message, I did suggest the web site return HTTP 401 as = below... >> 401 Unauthorized >> WWW-Authenticate: Basic realm=3D"tokenSvc" >> WWW-Authenticate: Digest realm=3D"tokenSvc" >> WWW-Authenticate: Form url=3D"/clientAuthenticate.jsp",realm=3D"tokenSv= c" It could also include other items for "MAC", etc. The only other issue would be determining whether the token is obtained = via an OAuth profile or via some default profile. That could be handled = with something like: WWW-Authenticate: Basic realm=3D"somerealm" WWW-Authenticate: MAC realm=3D"somerealm" WWW-Authenticate: OAuth = token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy" The above would suggest that MAC tokens could be used alone as described = in some specification for "MAC". However, the presence of the OAuth = header indicates that MAC and BEARER tokens can be used in the OAuth = pattern. I think this allows both de-coupling of tokens from OAuth but also = informs clients what tokens can be used with OAuth. There may be other ways to do this. But it does help with the = decoupling. Phil phil.hunt@oracle.com On 2011-02-04, at 11:44 AM, William Mills wrote: > I was thinking more about how the client knows what to use. The = ubiquitous "service documentation" may come in to play here. Some form = of serv ice discovery/webfinger thing could also be used. >=20 >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com] >> Sent: Friday, February 04, 2011 11:37 AM >> To: William Mills >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >>=20 >> Yes. This should be defined in each token type specification. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-02-04, at 11:29 AM, William Mills wrote: >>=20 >>> The only challenge is to know what scheme to use and what the = nuances >> are of how to present the credential. >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >>>> Of Phil Hunt >>>> Sent: Friday, February 04, 2011 9:42 AM >>>> To: Marius Scurtescu >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name = (deadline: >>>> 2/10) >>>>=20 >>>> OAuth should be able to support other token schemes. >>>>=20 >>>> Or conversely you don't have to have OAuth to use MAC, JWT, or >>>> whatever. >>>>=20 >>>> Phil >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >>>>=20 >>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav >>>> wrote: >>>>>> Hey Marius, >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>> Sent: Thursday, February 03, 2011 10:36 AM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG >>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >>>> (deadline: >>>>>>> 2/10) >>>>>>>=20 >>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 2. Single OAuth2 scheme with sub-schemes >>>>>>>>=20 >>>>>>>> Define a single authentication scheme for all token types with >>>> some >>>>>>>> attribute used to detect which scheme is actually being used. >>>>>>>>=20 >>>>>>>> Benefits: >>>>>>>>=20 >>>>>>>> - single scheme, reuse of the 1.0 pattern. >>>>>>>>=20 >>>>>>>> Downsides: >>>>>>>>=20 >>>>>>>> - requires a new registry for authentication header parameters. >>>>>>>=20 >>>>>>> How is this different from option 1? Wouldn't that need some >>>> registry? >>>>>>=20 >>>>>> #1 relies on the existing practice of creating HTTP scheme names >> (no >>>> current registry but httpbis might be creating one), as well as the >> -12 >>>> token type registry. Using a sub-scheme means you also need a >> registry >>>> for the header attributes that each token type will need (unless = you >>>> just don't care about using the same attribute name for different >>>> needs). >>>>>=20 >>>>> Sure, there is no registry for schemes yet, but we would still = need >>>>> some coordination. The fact that a sub-scheme needs a registry = that >>>> we >>>>> control is a benefit not a downside IMO. >>>>>=20 >>>>>=20 >>>>>>>> - schemes are not easily reusable outside OAuth. >>>>>>>=20 >>>>>>> Sure. But I really don't see this group trying to create generic >>>> authentication >>>>>>> schemes. >>>>>>=20 >>>>>> MAC is exactly that. >>>>>=20 >>>>> May or may not be. My point is that this group is not focused on >>>>> creating generic authentication schemes. Are you aware of any = other >>>>> protocols that might use MAC or BEARER? Are we willing to put in >> the >>>>> effort to create generic schemes? Is it our charter? >>>>>=20 >>>>>=20 >>>>>>>> - existing frameworks usually switch on scheme name, not on sub >>>>>>>> scheme, which will cause difficulty in some deployments. >>>>>>>=20 >>>>>>> I can see this as a potential problem. But considering that = there >>>> wasn't much >>>>>>> objection to use "OAuth" as a scheme name before (total overlap >>>> with >>>>>>> OAuth 1, and the suggested solution was to look for the = signature >>>>>>> parameter) I don't see how this is suddenly an issue. >>>>>>=20 >>>>>> There was pretty strong objection to reusing OAuth. >>>>>=20 >>>>> Yes, because there was no sub-scheme nor version (and the grammar >> was >>>>> totally broken). Even so, lots of implementations went ahead and >> did >>>>> it. Were there any scheme switching issues we are aware of? >>>>>=20 >>>>>=20 >>>>>>> Do we have a concrete problem here or this is just theoretical? >>>>>>=20 >>>>>> This came up during the review of draft-hammer-http-token-auth >> [1]. >>>> There was a long thread about it where people posted actual >> framework >>>> issues. >>>>>>=20 >>>>>>>> - potential to produce a very complicated scheme once many sub >>>> schemes >>>>>>>> are added. >>>>>>>=20 >>>>>>> Why? I would argue that this option actually produces more >> uniform >>>>>>> schemes because it forces all of them to be name/value pairs. >>>> Beyond >>>>>>> token_type everything is scheme specific. I really don't see = what >>>> is very >>>>>>> complicate here. >>>>>>=20 >>>>>> It is still a single scheme with many different sub-schemes, each >>>> with different key-value pairs that may have conflicting meaning. >> The >>>> way I look at it is that if I try to fully implement this mega >> scheme >>>> (which means all its sub-schemes), it will likely be a complicated >>>> task. On the other hand, if you split it across scheme name, we >> already >>>> have a well-established system in place to pick and choose HTTP >>>> authentication schemes. >>>>>=20 >>>>> No one has to implement a mega scheme. All schemes must use >>>> name/value >>>>> pairs and that's where the common part stops. >>>>>=20 >>>>>=20 >>>>>>>> - requires its own discovery method for which schemes are >>>> supported. >>>>>>>=20 >>>>>>> Why is this a downside only for this option? >>>>>>=20 >>>>>> Because the other options get this for free by using the WWW- >>>> Authenticate header (since each scheme has a unique name). You can >> list >>>> multiple headers in the 401 response. >>>>>=20 >>>>> I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate >>>>> work for sub-schemes as well? >>>>>=20 >>>>>=20 >>>>>> Should I record your vote for #2? >>>>>=20 >>>>> #2 or #3 >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Marius >>>>> _______________________________________________ >>>>> 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 eran@hueniverse.com Fri Feb 4 13:12:29 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909163A69FA for ; Fri, 4 Feb 2011 13:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR21mBcFckwh for ; Fri, 4 Feb 2011 13:12:28 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8BB273A6A4E for ; Fri, 4 Feb 2011 13:12:28 -0800 (PST) Received: (qmail 5854 invoked from network); 4 Feb 2011 21:15:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Feb 2011 21:15:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Feb 2011 14:15:38 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Fri, 4 Feb 2011 14:15:28 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEkoe5jzLWjhGXT/Cwdk5aRpjG3wAHF0Lw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BF9CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@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] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:12:29 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Friday, February 04, 2011 9:39 AM > >> > - schemes are not easily reusable outside OAuth. > >> > >> Sure. But I really don't see this group trying to create generic > >> authentication schemes. > > > > MAC is exactly that. >=20 > May or may not be. My point is that this group is not focused on creating > generic authentication schemes. Are you aware of any other protocols that > might use MAC or BEARER? Are we willing to put in the effort to create > generic schemes? Is it our charter? We are chartered to produce one such generic HTTP authentication scheme: "The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenario)." My team is using MAC outside of OAuth. Also keep in mind that MAC is not a = working group item or document. It is an individual submission aimed at pro= ducing an HTTP authentication scheme that is useful on its own but with OAu= th binding. =20 > >> > - existing frameworks usually switch on scheme name, not on sub > >> > scheme, which will cause difficulty in some deployments. > >> > >> I can see this as a potential problem. But considering that there > >> wasn't much objection to use "OAuth" as a scheme name before (total > >> overlap with OAuth 1, and the suggested solution was to look for the > >> signature > >> parameter) I don't see how this is suddenly an issue. > > > > There was pretty strong objection to reusing OAuth. >=20 > Yes, because there was no sub-scheme nor version (and the grammar was > totally broken). Even so, lots of implementations went ahead and did it. > Were there any scheme switching issues we are aware of? There was a wide range of reasons. At the end, we are talking about a liter= al string. Code doesn't care what humans make of it. =20 > >> > - requires its own discovery method for which schemes are supported. > >> > >> Why is this a downside only for this option? > > > > Because the other options get this for free by using the WWW- > Authenticate header (since each scheme has a unique name). You can list > multiple headers in the 401 response. >=20 > I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > work for sub-schemes as well? It can. But it is not as trivial. With different schemes, the existing 2617= framework does everything for you. You just include multiple headers. With= sub-schemes, it is awkward to repeat the same scheme multiple times (but p= robably allowed), so you need to define some key=3D"value, value, value" fo= rmat for specifying multiple sub-schemes. And then if each sub-scheme has o= ther parameters, it gets tricky. IOW, you are moving functionality provided to you by HTTP into one you are = making up. What's the point? Where is the value? I think the core differenc= e here is you are more concerned about the HTTP scheme namespace and I am m= ore concerned about inventing new authentication framework facilities. EHL From Internet-Drafts@ietf.org Fri Feb 4 13:30:03 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DDB3A69D4; Fri, 4 Feb 2011 13:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSm-gGiMXlXB; Fri, 4 Feb 2011 13:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEFE3A67F2; Fri, 4 Feb 2011 13:30:01 -0800 (PST) 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.12 Message-ID: <20110204213001.3449.46831.idtracker@localhost> Date: Fri, 04 Feb 2011 13:30:01 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:30: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 : SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 Author(s) : B. Campbell, C. Mortimore Filename : draft-ietf-oauth-saml2-bearer-03.txt Pages : 13 Date : 2011-02-04 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-03.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-saml2-bearer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-04132017.I-D@ietf.org> --NextPart-- From wmills@yahoo-inc.com Fri Feb 4 13:36:39 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4103A68FC for ; Fri, 4 Feb 2011 13:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.535 X-Spam-Level: X-Spam-Status: No, score=-17.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUKRUjNESAqn for ; Fri, 4 Feb 2011 13:36:38 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 2FF283A67F2 for ; Fri, 4 Feb 2011 13:36:38 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p14LdkdH084615; Fri, 4 Feb 2011 13:39:46 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Fri, 4 Feb 2011 13:39:46 -0800 From: William Mills To: Phil Hunt Date: Fri, 4 Feb 2011 13:39:45 -0800 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEsJhsbgKG7JMVSAaodwrcqACUQgAALvHA Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> In-Reply-To: <120D927A-EC25-4ED2-A8DA-887FEACC9143@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] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:36:39 -0000 I was thinking along the lines of simply returning the HTTP Authorization h= eader schemes that are supported. In the OAuth 2 context that would be=20 WWW-Authenticate: 401 error=3D"blah blah blah" auth_types=3D"Bearer MAC B= asic" The client has to be aware of the authentication scheme names.=20 -bill > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Friday, February 04, 2011 1:14 PM > To: William Mills > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > I agree, that is still to be defined. There seems to be some push back > on discovery, but this is likely warranted. If only because web sites > may have both browser clients and app clients. >=20 > In a previous message, I did suggest the web site return HTTP 401 as > below... > >> 401 Unauthorized > >> WWW-Authenticate: Basic realm=3D"tokenSvc" > >> WWW-Authenticate: Digest realm=3D"tokenSvc" > >> WWW-Authenticate: Form > url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" >=20 > It could also include other items for "MAC", etc. >=20 > The only other issue would be determining whether the token is obtained > via an OAuth profile or via some default profile. That could be > handled with something like: >=20 > WWW-Authenticate: Basic realm=3D"somerealm" > WWW-Authenticate: MAC realm=3D"somerealm" > WWW-Authenticate: OAuth > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy" >=20 > The above would suggest that MAC tokens could be used alone as > described in some specification for "MAC". However, the presence of > the OAuth header indicates that MAC and BEARER tokens can be used in > the OAuth pattern. >=20 > I think this allows both de-coupling of tokens from OAuth but also > informs clients what tokens can be used with OAuth. >=20 > There may be other ways to do this. But it does help with the > decoupling. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-04, at 11:44 AM, William Mills wrote: >=20 > > I was thinking more about how the client knows what to use. The > ubiquitous "service documentation" may come in to play here. Some form > of serv ice discovery/webfinger thing could also be used. > > > >> -----Original Message----- > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > >> Sent: Friday, February 04, 2011 11:37 AM > >> To: William Mills > >> Cc: Marius Scurtescu; OAuth WG > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > >> 2/10) > >> > >> Yes. This should be defined in each token type specification. > >> > >> Phil > >> phil.hunt@oracle.com > >> > >> > >> > >> > >> On 2011-02-04, at 11:29 AM, William Mills wrote: > >> > >>> The only challenge is to know what scheme to use and what the > nuances > >> are of how to present the credential. > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf > >>>> Of Phil Hunt > >>>> Sent: Friday, February 04, 2011 9:42 AM > >>>> To: Marius Scurtescu > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > (deadline: > >>>> 2/10) > >>>> > >>>> OAuth should be able to support other token schemes. > >>>> > >>>> Or conversely you don't have to have OAuth to use MAC, JWT, or > >>>> whatever. > >>>> > >>>> Phil > >>>> phil.hunt@oracle.com > >>>> > >>>> > >>>> > >>>> > >>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > >>>> > >>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > >>>> wrote: > >>>>>> Hey Marius, > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>>>>> Sent: Thursday, February 03, 2011 10:36 AM > >>>>>>> To: Eran Hammer-Lahav > >>>>>>> Cc: OAuth WG > >>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > >>>> (deadline: > >>>>>>> 2/10) > >>>>>>> > >>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > >>>>>>> wrote: > >>>>>>> > >>>>>>>> 2. Single OAuth2 scheme with sub-schemes > >>>>>>>> > >>>>>>>> Define a single authentication scheme for all token types with > >>>> some > >>>>>>>> attribute used to detect which scheme is actually being used. > >>>>>>>> > >>>>>>>> Benefits: > >>>>>>>> > >>>>>>>> - single scheme, reuse of the 1.0 pattern. > >>>>>>>> > >>>>>>>> Downsides: > >>>>>>>> > >>>>>>>> - requires a new registry for authentication header > parameters. > >>>>>>> > >>>>>>> How is this different from option 1? Wouldn't that need some > >>>> registry? > >>>>>> > >>>>>> #1 relies on the existing practice of creating HTTP scheme names > >> (no > >>>> current registry but httpbis might be creating one), as well as > the > >> -12 > >>>> token type registry. Using a sub-scheme means you also need a > >> registry > >>>> for the header attributes that each token type will need (unless > you > >>>> just don't care about using the same attribute name for different > >>>> needs). > >>>>> > >>>>> Sure, there is no registry for schemes yet, but we would still > need > >>>>> some coordination. The fact that a sub-scheme needs a registry > that > >>>> we > >>>>> control is a benefit not a downside IMO. > >>>>> > >>>>> > >>>>>>>> - schemes are not easily reusable outside OAuth. > >>>>>>> > >>>>>>> Sure. But I really don't see this group trying to create > generic > >>>> authentication > >>>>>>> schemes. > >>>>>> > >>>>>> MAC is exactly that. > >>>>> > >>>>> May or may not be. My point is that this group is not focused on > >>>>> creating generic authentication schemes. Are you aware of any > other > >>>>> protocols that might use MAC or BEARER? Are we willing to put in > >> the > >>>>> effort to create generic schemes? Is it our charter? > >>>>> > >>>>> > >>>>>>>> - existing frameworks usually switch on scheme name, not on > sub > >>>>>>>> scheme, which will cause difficulty in some deployments. > >>>>>>> > >>>>>>> I can see this as a potential problem. But considering that > there > >>>> wasn't much > >>>>>>> objection to use "OAuth" as a scheme name before (total overlap > >>>> with > >>>>>>> OAuth 1, and the suggested solution was to look for the > signature > >>>>>>> parameter) I don't see how this is suddenly an issue. > >>>>>> > >>>>>> There was pretty strong objection to reusing OAuth. > >>>>> > >>>>> Yes, because there was no sub-scheme nor version (and the grammar > >> was > >>>>> totally broken). Even so, lots of implementations went ahead and > >> did > >>>>> it. Were there any scheme switching issues we are aware of? > >>>>> > >>>>> > >>>>>>> Do we have a concrete problem here or this is just theoretical? > >>>>>> > >>>>>> This came up during the review of draft-hammer-http-token-auth > >> [1]. > >>>> There was a long thread about it where people posted actual > >> framework > >>>> issues. > >>>>>> > >>>>>>>> - potential to produce a very complicated scheme once many sub > >>>> schemes > >>>>>>>> are added. > >>>>>>> > >>>>>>> Why? I would argue that this option actually produces more > >> uniform > >>>>>>> schemes because it forces all of them to be name/value pairs. > >>>> Beyond > >>>>>>> token_type everything is scheme specific. I really don't see > what > >>>> is very > >>>>>>> complicate here. > >>>>>> > >>>>>> It is still a single scheme with many different sub-schemes, > each > >>>> with different key-value pairs that may have conflicting meaning. > >> The > >>>> way I look at it is that if I try to fully implement this mega > >> scheme > >>>> (which means all its sub-schemes), it will likely be a complicated > >>>> task. On the other hand, if you split it across scheme name, we > >> already > >>>> have a well-established system in place to pick and choose HTTP > >>>> authentication schemes. > >>>>> > >>>>> No one has to implement a mega scheme. All schemes must use > >>>> name/value > >>>>> pairs and that's where the common part stops. > >>>>> > >>>>> > >>>>>>>> - requires its own discovery method for which schemes are > >>>> supported. > >>>>>>> > >>>>>>> Why is this a downside only for this option? > >>>>>> > >>>>>> Because the other options get this for free by using the WWW- > >>>> Authenticate header (since each scheme has a unique name). You can > >> list > >>>> multiple headers in the 401 response. > >>>>> > >>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- > Authenticate > >>>>> work for sub-schemes as well? > >>>>> > >>>>> > >>>>>> Should I record your vote for #2? > >>>>> > >>>>> #2 or #3 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> 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 Fri Feb 4 13:42:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2323A67F2 for ; Fri, 4 Feb 2011 13:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEuPX-2MYkcD for ; Fri, 4 Feb 2011 13:42:48 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by core3.amsl.com (Postfix) with ESMTP id 787C53A67B0 for ; Fri, 4 Feb 2011 13:42:47 -0800 (PST) Received: from source ([209.85.161.44]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTUxzoF1pQOzTKiyW6weQeRAb5k4rCDZB@postini.com; Fri, 04 Feb 2011 13:46:13 PST Received: by mail-fx0-f44.google.com with SMTP id 9so3060416fxm.31 for ; Fri, 04 Feb 2011 13:46:08 -0800 (PST) Received: by 10.223.83.194 with SMTP id g2mr7306238fal.75.1296855968702; Fri, 04 Feb 2011 13:46:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Fri, 4 Feb 2011 13:45:38 -0800 (PST) In-Reply-To: <20110204213001.3449.46831.idtracker@localhost> References: <20110204213001.3449.46831.idtracker@localhost> From: Brian Campbell Date: Fri, 4 Feb 2011 14:45:38 -0700 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-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:42:48 -0000 The changes in this draft are only editorial cleanup items. Review and feedback is always welcome, however. ---------- Forwarded message ---------- From: Date: Fri, Feb 4, 2011 at 2:30 PM Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-03.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org 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. =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 : B. Campbell, C. Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-03.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-04 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-03.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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Fri Feb 4 13:51:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438523A69D3 for ; Fri, 4 Feb 2011 13:51:09 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+kNJVsFI5q9 for ; Fri, 4 Feb 2011 13:51:08 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 405D53A69FC for ; Fri, 4 Feb 2011 13:51:08 -0800 (PST) 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 p14LsUPn013655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 15:54:33 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p14LsShs032366 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 15:54:29 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 4 Feb 2011 15:54:29 -0600 From: "Zeltsan, Zachary (Zachary)" To: "oauth@ietf.org" Date: Fri, 4 Feb 2011 15:54:28 -0600 Thread-Topic: New Version Notification for draft-zeltsan-oauth-use-cases-01 Thread-Index: AcvEtSFLi2jA1Qr0Rhuv4GrFWxxSJAAAEALA Message-ID: <5710F82C0E73B04FA559560098BF95B12505F040F0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [OAUTH-WG] FW: New Version Notification for draft-zeltsan-oauth-use-cases-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:51:09 -0000 I posted a new version of the draft on the OAuth use cases today. Your comments are welcome. Zachary -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Friday, February 04, 2011 4:44 PM To: Zeltsan, Zachary (Zachary) Cc: gffletch@aol.com; torsten@lodderstedt.net Subject: New Version Notification for draft-zeltsan-oauth-use-cases-01=20 A new version of I-D, draft-zeltsan-oauth-use-cases-01.txt has been success= fully submitted by Zachary Zeltsan and posted to the IETF repository. Filename: draft-zeltsan-oauth-use-cases Revision: 01 Title: OAuth Use Cases Creation_date: 2011-02-04 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document lists the OAuth use cases. The document's objective is to identify the use cases that will be a base for deriving the OAuth requirements. The provided list is based on the Internet-Drafts of the OAUTH working group and discussions on the group's mailing list. = =20 The IETF Secretariat. From rasmus@lerdorf.com Sat Feb 5 00:29:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8836A3A6892 for ; Sat, 5 Feb 2011 00:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioshHgyvmzBj for ; Sat, 5 Feb 2011 00:29:51 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A41E53A6778 for ; Sat, 5 Feb 2011 00:29:51 -0800 (PST) Received: by iwc10 with SMTP id 10so3221292iwc.31 for ; Sat, 05 Feb 2011 00:33:18 -0800 (PST) Received: by 10.231.36.5 with SMTP id r5mr14295980ibd.134.1296894797692; Sat, 05 Feb 2011 00:33:17 -0800 (PST) Received: from [192.168.200.144] (c-98-234-184-167.hsd1.ca.comcast.net [98.234.184.167]) by mx.google.com with ESMTPS id u9sm1411918ibe.14.2011.02.05.00.33.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 00:33:16 -0800 (PST) Message-ID: <4D4D0B4A.1000008@lerdorf.com> Date: Sat, 05 Feb 2011 00:33:14 -0800 From: Rasmus Lerdorf User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] client_id chicken+egg problem and a typo in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 08:29:52 -0000 In "4.1.2.1. Error Response" it says: If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format: and then in the error section we have: invalid_client The client identifier provided is invalid. Since the redirect URI is tied to a client's identity, we can't have an invalid client identity and a valid redirect URI at the same time. In think the first part of 4.1.2.1 which currently says: If the request fails due to a missing, invalid, or mismatching redirection URI, the authorization server SHOULD inform the resource owner of the error, and MUST NOT redirect the user-agent to the invalid redirection URI. should say: If the request fails due to a missing or invalid client identifier, or due to a missing, invalid or mismatching redirect URI, the authorization server SHOULD inform the resource owner of the error, and MUST NOT redirect the user-agent to the invalid redirection URI. and the invalid_client error code should be removed from the list of errors below. And a minor typo at the end of 4.1.2: "The authorization server should document the size of any value is issues." -Rasmus From wmills@yahoo-inc.com Sat Feb 5 08:38:58 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276133A69B7 for ; Sat, 5 Feb 2011 08:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.369 X-Spam-Level: X-Spam-Status: No, score=-17.369 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1r66v7ROHRl for ; Sat, 5 Feb 2011 08:38:54 -0800 (PST) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 9CC333A6902 for ; Sat, 5 Feb 2011 08:38:54 -0800 (PST) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p15GfhBg008209; Sat, 5 Feb 2011 08:41:43 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Sat, 5 Feb 2011 08:41:43 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Sat, 5 Feb 2011 08:41:41 -0800 Thread-Topic: draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu50HMZE3ElIG/6SjSQTXJNzEiUCwLgpcKA Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@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_FFDFD7371D517847AD71FBB08F9A31563849221B1CSP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 16:38:58 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563849221B1CSP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reading through and looking at your example in 1.1 I think you don't have e= nough lines. Your text specified 9 elements to be signed, but you only hav= e 7 lines in the text to be signed. The way I read the text you should hav= e 9 elements followed by newlines, which can be empty, but the newlines sho= uld be there. -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 21, 2011 5:10 PM To: OAuth WG Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 New version includes the following changes: o Added body-hash support. o Updated OAuth 2.0 reference to -12 and added token type registration = template. o Removed error and error URI attributes (codes were just a duplication= of the HTTP status codes). Feedback would be greatly appreciated. EHL --_000_FFDFD7371D517847AD71FBB08F9A31563849221B1CSP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reading through and look= ing at your example in 1.1 I think you don’t have enough lines.  Your t= ext specified 9 elements to be signed, but you only have 7 lines in the text to be signed.  The way I read the text you should have 9 elements followed b= y newlines, which can be empty, but the newlines should be there.<= /span>

 =

-bill<= /p>

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 21, 2011 5:10 PM
To: OAuth WG
Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

 

http= ://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

 

New version includes the following changes:=

 

   o  Added body-hash support.

   o  Updated OAuth 2.0 reference to -= 12 and added token type registration template.

   o  Removed error and error URI attributes (codes were just a duplication of the HTTP status codes).

 

Feedback would be greatly appreciated.

 

EHL

 

 

--_000_FFDFD7371D517847AD71FBB08F9A31563849221B1CSP2EX07VS06ds_-- From eran@hueniverse.com Sat Feb 5 08:57:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1473A6992 for ; Sat, 5 Feb 2011 08:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ey5n3e1Dc4S for ; Sat, 5 Feb 2011 08:57:34 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5284A3A6907 for ; Sat, 5 Feb 2011 08:57:33 -0800 (PST) Received: (qmail 361 invoked from network); 5 Feb 2011 17:00:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Feb 2011 17:00:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 5 Feb 2011 10:00:20 -0700 From: Eran Hammer-Lahav To: William Mills , OAuth WG Date: Sat, 5 Feb 2011 10:00:09 -0700 Thread-Topic: draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu50HMZE3ElIG/6SjSQTXJNzEiUCwLgpcKAAADDeiA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFA9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFA9CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 16:57:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFA9CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm confused. Can you cut-and-paste the problematic text? From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Saturday, February 05, 2011 8:42 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: draft-hammer-oauth-v2-mac-token-02 Reading through and looking at your example in 1.1 I think you don't have e= nough lines. Your text specified 9 elements to be signed, but you only hav= e 7 lines in the text to be signed. The way I read the text you should hav= e 9 elements followed by newlines, which can be empty, but the newlines sho= uld be there. -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 21, 2011 5:10 PM To: OAuth WG Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 New version includes the following changes: o Added body-hash support. o Updated OAuth 2.0 reference to -12 and added token type registration = template. o Removed error and error URI attributes (codes were just a duplication= of the HTTP status codes). Feedback would be greatly appreciated. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFA9CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m confused. Can you cut-and-paste the problematic tex= t?

=  

From: W= illiam Mills [mailto:wmills@yahoo-inc.com]
Sent: Saturday, Febru= ary 05, 2011 8:42 AM
To: Eran Hammer-Lahav; OAuth WG
Subjec= t: RE: draft-hammer-oauth-v2-mac-token-02

 

Reading through and looking at your example in 1.1 I = think you don’t have enough lines.  Your text specified 9 elemen= ts to be signed, but you only have 7 lines in the text to be signed.  = The way I read the text you should have 9 elements followed by newlines, wh= ich can be empty, but the newlines should be there.

 

-bill

 

From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav<= br>Sent: Friday, January 21, 2011 5:10 PM
To: OAuth WG
= Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

 

http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

 

= New version includes the following changes:

 

   o  = Added body-hash support.

=    o  Updated OAuth 2.0 reference to -12 and added token typ= e registration template.

=    o  Removed error and error URI attributes (codes were jus= t a duplication of the HTTP status codes).

 

= Feedback would be greatly appreciated.

 

EHL<= o:p>

 <= /p>

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFA9CP3PW5EX1MB01E_-- From torsten@lodderstedt.net Sat Feb 5 10:00:16 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F51B3A6969 for ; Sat, 5 Feb 2011 10:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBynaef0fuNQ for ; Sat, 5 Feb 2011 10:00:14 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id B9D903A68C5 for ; Sat, 5 Feb 2011 10:00:13 -0800 (PST) Received: from [79.253.43.94] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PlmTz-0004r4-Kg; Sat, 05 Feb 2011 19:03:39 +0100 Message-ID: <4D4D90F9.1030205@lodderstedt.net> Date: Sat, 05 Feb 2011 19:03:37 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phil Hunt References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247212F8@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3392@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943247214A2@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060603000608030107010701" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 18:00:16 -0000 This is a multi-part message in MIME format. --------------060603000608030107010701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 for option 3, but would be fine with option 1, too Both are quite similar, except 3 keeps the link between the OAuth authorization server API (how to get a token) and the HTTP schemes used to send the tokens to the resource servers. Since OAuth is becoming, in my perception, the synonym for token-based authorization of REST service calls this link might be important. regards, Torsten. Am 03.02.2011 19:12, schrieb Phil Hunt: > OPTION 1. > > Phil > phil.hunt@oracle.com > > > > > On 2011-02-03, at 9:19 AM, Mike Jones wrote: > >> I realize that spec stability doesn’t matter to you, but that doesn’t >> mean that it’s not important to others, including those actually >> using the specs. Call that a “process” argument if you want, but >> that doesn’t make it any less pertinent – the “technical” argument is >> that breaking changes break implementations. >> I already did vote below -- for option 4. >> *From:*Eran Hammer-Lahav [mailto:eran@hueniverse.com] >> *Sent:*Thursday, February 03, 2011 9:14 AM >> *To:*Mike Jones; OAuth WG >> *Subject:*RE: Bearer token type and scheme name (deadline: 2/10) >> All these suggestions were posted to the list by members (Marius, >> William, James, Justin). Nothing here is new. If you disagree with my >> analysis of any of the points, please raise your **technical** >> concerns. Trying to use process arguments is simply not going to fly. >> Pick an option, provide a new option (with full analysis), or don’t vote. >> EHL >> *From:*Mike Jones [mailto:Michael.Jones@microsoft.com] >> *Sent:*Thursday, February 03, 2011 8:20 AM >> *To:*Eran Hammer-Lahav; OAuth WG >> *Subject:*RE: Bearer token type and scheme name (deadline: 2/10) >> This seems like an overly complex characterization – especially >> because you’re including hypothetical choices such as schemes and >> sub-schemes that don’t provide substantial benefits over the >> straightforward schemes we have now and would complicate >> implementations and people’s understanding of the spec, and that >> don’t have substantial support within the working group. >> Given that we’re trying to bring the specs to working group last >> call, I would personally vote no to introducing any further any >> breaking changes. >> -- Mike >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org]*On >> Behalf Of*Eran Hammer-Lahav >> *Sent:*Thursday, February 03, 2011 12:34 AM >> *To:*OAuth WG >> *Subject:*[OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) >> After a long back-and-forth, I think it is time to present a few >> options and have people express their preferences. >> These are the options mentioned so far and their +/-: >> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) >> Each token type gets its own name (which does not include the word >> ‘oauth’ in it), as well as a matching HTTP authentication scheme if a >> new one is being defined. >> Benefits: >> - works cleanly with the HTTP authentication framework by simply >> defining new methods or reusing existing ones. >> - schemes can be used outside the OAuth authorization flow (e.g. >> 2-legged OAuth 1.0 use cases). >> - all schemes are presented equally without giving any a preferred >> treatment. >> - built-in discovery using 401 challenge header for which schemes are >> supported (with their respective information). >> Downsides: >> - potential creation of many new HTTP authentication schemes which >> has been stable for a long time. >> 2. Single OAuth2 scheme with sub-schemes >> Define a single authentication scheme for all token types with some >> attribute used to detect which scheme is actually being used. >> Benefits: >> - single scheme, reuse of the 1.0 pattern. >> Downsides: >> - requires a new registry for authentication header parameters. >> - schemes are not easily reusable outside OAuth. >> - existing frameworks usually switch on scheme name, not on sub >> scheme, which will cause difficulty in some deployments. >> - potential to produce a very complicated scheme once many sub >> schemes are added. >> - requires its own discovery method for which schemes are supported. >> 3. Name prefix (e.g. oauth2_bearer) >> Benefits: >> - makes the protocol a bit easier to newbies since it will look all >> inclusive (authorization and authentication). >> Downsides: >> - makes reuse outside OAuth awkward without any technical benefit. >> 4. OAuth2 for bearer, MAC for mac >> Name the bearer token ‘OAuth2’ and everything else gets a different >> name (with or without OAuth in it). >> Benefits: >> - Matches current draft. >> Downsides: >> - Elevates bearer token to the preferred token type, instead of >> promoting comparison of the various token types available. >> - Creates a very odd usage where the authorization server issues an >> access token of type ‘OAuth2’ which is non-descriptive and very >> confusing (since there are other token types). >> - Uses the name OAuth2 which stands for authorization in an >> authentication flow, continuing the confusion about what OAuth is (an >> authorization protocol). >> --- >> Please reply with your preference by 2/10. As always, please provide >> feedback on the options and analysis. >> 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 --------------060603000608030107010701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1 for option 3, but would be fine with option 1, too

Both are quite similar, except 3 keeps the link between the OAuth authorization server API (how to get a token) and the HTTP schemes used to send the tokens to the resource servers. Since OAuth is becoming, in my perception, the synonym for token-based authorization of REST service calls this link might be important.

regards,
Torsten.
Am 03.02.2011 19:12, schrieb Phil Hunt:
OPTION 1.

Phil

On 2011-02-03, at 9:19 AM, Mike Jones wrote:

I realize that spec stability doesn’t matter to you, but that doesn’t mean that it’s not important to others, including those actually using the specs.  Call that a “process” argument if you want, but that doesn’t make it any less pertinent – the “technical” argument is that breaking changes break implementations.
 
I already did vote below -- for option 4.
 
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Thursday, February 03, 2011 9:14 AM
To: Mike Jones; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)
 
All these suggestions were posted to the list by members (Marius, William, James, Justin). Nothing here is new. If you disagree with my analysis of any of the points, please raise your *technical* concerns. Trying to use process arguments is simply not going to fly.
 
Pick an option, provide a new option (with full analysis), or don’t vote.
 
EHL
 
 
From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Thursday, February 03, 2011 8:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)
This seems like an overly complex characterization – especially because you’re including hypothetical choices such as schemes and sub-schemes that don’t provide substantial benefits over the straightforward schemes we have now and would complicate implementations and people’s understanding of the spec, and that don’t have substantial support within the working group.
 
Given that we’re trying to bring the specs to working group last call, I would personally vote no to introducing any further any breaking changes.
 
                                                            -- Mike
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
 
After a long back-and-forth, I think it is time to present a few options and have people express their preferences.
 
These are the options mentioned so far and their +/-:
 
1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
 
Each token type gets its own name (which does not include the word ‘oauth’ in it), as well as a matching HTTP authentication scheme if a new one is being defined.
 
Benefits:
 
- works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones.
- schemes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth 1.0 use cases).
- all schemes are presented equally without giving any a preferred treatment.
- built-in discovery using 401 challenge header for which schemes are supported (with their respective information).
 
Downsides:
 
- potential creation of many new HTTP authentication schemes which has been stable for a long time.
 
2. Single OAuth2 scheme with sub-schemes
 
Define a single authentication scheme for all token types with some attribute used to detect which scheme is actually being used.
 
Benefits:
 
- single scheme, reuse of the 1.0 pattern.
 
Downsides:
 
- requires a new registry for authentication header parameters.
- schemes are not easily reusable outside OAuth.
- existing frameworks usually switch on scheme name, not on sub scheme, which will cause difficulty in some deployments.
- potential to produce a very complicated scheme once many sub schemes are added.
- requires its own discovery method for which schemes are supported.
 
3. Name prefix (e.g. oauth2_bearer)
 
Benefits:
 
- makes the protocol a bit easier to newbies since it will look all inclusive (authorization and authentication).
 
Downsides:
 
- makes reuse outside OAuth awkward without any technical benefit.
 
4. OAuth2 for bearer, MAC for mac
 
Name the bearer token ‘OAuth2’ and everything else gets a different name (with or without OAuth in it).
 
Benefits:
 
- Matches current draft.
 
Downsides:
 
- Elevates bearer token to the preferred token type, instead of promoting comparison of the various token types available.
- Creates a very odd usage where the authorization server issues an access token of type ‘OAuth2’ which is non-descriptive and very confusing (since there are other token types).
- Uses the name OAuth2 which stands for authorization in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol).
 
---
 
Please reply with your preference by 2/10. As always, please provide feedback on the options and analysis.
 
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
--------------060603000608030107010701-- From torsten@lodderstedt.net Sat Feb 5 10:17:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96E53A6969 for ; Sat, 5 Feb 2011 10:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8hI0h1JQ+Ut for ; Sat, 5 Feb 2011 10:17:44 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) by core3.amsl.com (Postfix) with ESMTP id 0124D3A68E1 for ; Sat, 5 Feb 2011 10:17:43 -0800 (PST) Received: from [79.253.43.94] (helo=[192.168.71.49]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Plmkv-00021X-UR; Sat, 05 Feb 2011 19:21:10 +0100 Message-ID: <4D4D9514.2090604@lodderstedt.net> Date: Sat, 05 Feb 2011 19:21:08 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: William Mills References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 18:17:45 -0000 that's not the way WWW-Authenticate headers are used today. Instead the resource server should return a single WWW-Authenticate header _per_ supported authentication scheme, such as WWW-Authenticate: MAC realm="somerealm" WWW-Authenticate: BEARER realm="somerealm" furthermore, I think interdependencies among WWW-Authenticate headers as suggested by Phil WWW-Authenticate: OAuth token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyy could be rather fragile. I would expect the WWW-Authenticate header to return all the data required to obtain the credentials/tokens, such as WWW-Authenticate: MAC realm="somerealm", tokenUrl="yyyyy&token_secret=yes" WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy" Which raises the question whether the coupling between authentication schemes and the OAuth2 core protocol is stronger than assumed. please als see http://www.ietf.org/mail-archive/web/oauth/current/msg04988.html regards, Torsten. Am 04.02.2011 22:39, schrieb William Mills: > I was thinking along the lines of simply returning the HTTP Authorization header schemes that are supported. In the OAuth 2 context that would be > > WWW-Authenticate: 401 error="blah blah blah" auth_types="Bearer MAC Basic" > > The client has to be aware of the authentication scheme names. > > -bill > >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com] >> Sent: Friday, February 04, 2011 1:14 PM >> To: William Mills >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >> >> I agree, that is still to be defined. There seems to be some push back >> on discovery, but this is likely warranted. If only because web sites >> may have both browser clients and app clients. >> >> In a previous message, I did suggest the web site return HTTP 401 as >> below... >>>> 401 Unauthorized >>>> WWW-Authenticate: Basic realm="tokenSvc" >>>> WWW-Authenticate: Digest realm="tokenSvc" >>>> WWW-Authenticate: Form >> url="/clientAuthenticate.jsp",realm="tokenSvc" >> >> It could also include other items for "MAC", etc. >> >> The only other issue would be determining whether the token is obtained >> via an OAuth profile or via some default profile. That could be >> handled with something like: >> >> WWW-Authenticate: Basic realm="somerealm" >> WWW-Authenticate: MAC realm="somerealm" >> WWW-Authenticate: OAuth >> token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy" >> >> The above would suggest that MAC tokens could be used alone as >> described in some specification for "MAC". However, the presence of >> the OAuth header indicates that MAC and BEARER tokens can be used in >> the OAuth pattern. >> >> I think this allows both de-coupling of tokens from OAuth but also >> informs clients what tokens can be used with OAuth. >> >> There may be other ways to do this. But it does help with the >> decoupling. >> >> Phil >> phil.hunt@oracle.com >> >> >> >> >> On 2011-02-04, at 11:44 AM, William Mills wrote: >> >>> I was thinking more about how the client knows what to use. The >> ubiquitous "service documentation" may come in to play here. Some form >> of serv ice discovery/webfinger thing could also be used. >>>> -----Original Message----- >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] >>>> Sent: Friday, February 04, 2011 11:37 AM >>>> To: William Mills >>>> Cc: Marius Scurtescu; OAuth WG >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>>> 2/10) >>>> >>>> Yes. This should be defined in each token type specification. >>>> >>>> Phil >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> >>>> On 2011-02-04, at 11:29 AM, William Mills wrote: >>>> >>>>> The only challenge is to know what scheme to use and what the >> nuances >>>> are of how to present the credential. >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf >>>>>> Of Phil Hunt >>>>>> Sent: Friday, February 04, 2011 9:42 AM >>>>>> To: Marius Scurtescu >>>>>> Cc: OAuth WG >>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >> (deadline: >>>>>> 2/10) >>>>>> >>>>>> OAuth should be able to support other token schemes. >>>>>> >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, or >>>>>> whatever. >>>>>> >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >>>>>> >>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav >>>>>> wrote: >>>>>>>> Hey Marius, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM >>>>>>>>> To: Eran Hammer-Lahav >>>>>>>>> Cc: OAuth WG >>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >>>>>> (deadline: >>>>>>>>> 2/10) >>>>>>>>> >>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes >>>>>>>>>> >>>>>>>>>> Define a single authentication scheme for all token types with >>>>>> some >>>>>>>>>> attribute used to detect which scheme is actually being used. >>>>>>>>>> >>>>>>>>>> Benefits: >>>>>>>>>> >>>>>>>>>> - single scheme, reuse of the 1.0 pattern. >>>>>>>>>> >>>>>>>>>> Downsides: >>>>>>>>>> >>>>>>>>>> - requires a new registry for authentication header >> parameters. >>>>>>>>> How is this different from option 1? Wouldn't that need some >>>>>> registry? >>>>>>>> #1 relies on the existing practice of creating HTTP scheme names >>>> (no >>>>>> current registry but httpbis might be creating one), as well as >> the >>>> -12 >>>>>> token type registry. Using a sub-scheme means you also need a >>>> registry >>>>>> for the header attributes that each token type will need (unless >> you >>>>>> just don't care about using the same attribute name for different >>>>>> needs). >>>>>>> Sure, there is no registry for schemes yet, but we would still >> need >>>>>>> some coordination. The fact that a sub-scheme needs a registry >> that >>>>>> we >>>>>>> control is a benefit not a downside IMO. >>>>>>> >>>>>>> >>>>>>>>>> - schemes are not easily reusable outside OAuth. >>>>>>>>> Sure. But I really don't see this group trying to create >> generic >>>>>> authentication >>>>>>>>> schemes. >>>>>>>> MAC is exactly that. >>>>>>> May or may not be. My point is that this group is not focused on >>>>>>> creating generic authentication schemes. Are you aware of any >> other >>>>>>> protocols that might use MAC or BEARER? Are we willing to put in >>>> the >>>>>>> effort to create generic schemes? Is it our charter? >>>>>>> >>>>>>> >>>>>>>>>> - existing frameworks usually switch on scheme name, not on >> sub >>>>>>>>>> scheme, which will cause difficulty in some deployments. >>>>>>>>> I can see this as a potential problem. But considering that >> there >>>>>> wasn't much >>>>>>>>> objection to use "OAuth" as a scheme name before (total overlap >>>>>> with >>>>>>>>> OAuth 1, and the suggested solution was to look for the >> signature >>>>>>>>> parameter) I don't see how this is suddenly an issue. >>>>>>>> There was pretty strong objection to reusing OAuth. >>>>>>> Yes, because there was no sub-scheme nor version (and the grammar >>>> was >>>>>>> totally broken). Even so, lots of implementations went ahead and >>>> did >>>>>>> it. Were there any scheme switching issues we are aware of? >>>>>>> >>>>>>> >>>>>>>>> Do we have a concrete problem here or this is just theoretical? >>>>>>>> This came up during the review of draft-hammer-http-token-auth >>>> [1]. >>>>>> There was a long thread about it where people posted actual >>>> framework >>>>>> issues. >>>>>>>>>> - potential to produce a very complicated scheme once many sub >>>>>> schemes >>>>>>>>>> are added. >>>>>>>>> Why? I would argue that this option actually produces more >>>> uniform >>>>>>>>> schemes because it forces all of them to be name/value pairs. >>>>>> Beyond >>>>>>>>> token_type everything is scheme specific. I really don't see >> what >>>>>> is very >>>>>>>>> complicate here. >>>>>>>> It is still a single scheme with many different sub-schemes, >> each >>>>>> with different key-value pairs that may have conflicting meaning. >>>> The >>>>>> way I look at it is that if I try to fully implement this mega >>>> scheme >>>>>> (which means all its sub-schemes), it will likely be a complicated >>>>>> task. On the other hand, if you split it across scheme name, we >>>> already >>>>>> have a well-established system in place to pick and choose HTTP >>>>>> authentication schemes. >>>>>>> No one has to implement a mega scheme. All schemes must use >>>>>> name/value >>>>>>> pairs and that's where the common part stops. >>>>>>> >>>>>>> >>>>>>>>>> - requires its own discovery method for which schemes are >>>>>> supported. >>>>>>>>> Why is this a downside only for this option? >>>>>>>> Because the other options get this for free by using the WWW- >>>>>> Authenticate header (since each scheme has a unique name). You can >>>> list >>>>>> multiple headers in the 401 response. >>>>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- >> Authenticate >>>>>>> work for sub-schemes as well? >>>>>>> >>>>>>> >>>>>>>> Should I record your vote for #2? >>>>>>> #2 or #3 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> 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 phil.hunt@oracle.com Sat Feb 5 10:57:33 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EFC3A68EA for ; Sat, 5 Feb 2011 10:57:33 -0800 (PST) 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.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV2CHVRUY2V8 for ; Sat, 5 Feb 2011 10:57:31 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 36F1A3A68E1 for ; Sat, 5 Feb 2011 10:57:31 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p15J0u4I012677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Feb 2011 19:00:58 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p15IQIJa014122; Sat, 5 Feb 2011 19:00:55 GMT Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 1026609381296932434; Sat, 05 Feb 2011 11:00:34 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 05 Feb 2011 11:00:33 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4D4D9514.2090604@lodderstedt.net> Date: Sat, 5 Feb 2011 11:00:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <22A44118-A11A-4BAD-BFBD-862C9692B354@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D4D9E68.0079:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 18:57:33 -0000 I think you are correct - there should be only one scheme per header. However, there is an issue that a particular token type may be used = outside of OAuth and then it may also be used within OAuth at the same = time. So you do have to list protocols twice. I believe Eran had = mentioned an approach of sub-categorization that could also work... WWW-Authenticate: BEARER ... WWW-Authenticate: OAUTH2_MAC ... WWW-Authenticate: OAUTH2_BEARER ... This may have some advantages. E.g. different parameters for each OAuth = sub category. The big difference would be that this sub-category = approach would end up requiring more registrations. I'm neutral on the approach here, but I think the key is that tokens = need to be usable both inside and outside of OAuth and that servers may = need both at the same time. Phil phil.hunt@oracle.com On 2011-02-05, at 10:21 AM, Torsten Lodderstedt wrote: > that's not the way WWW-Authenticate headers are used today. Instead = the resource server should return a single WWW-Authenticate header _per_ = supported authentication scheme, such as >=20 > WWW-Authenticate: MAC realm=3D"somerealm" > WWW-Authenticate: BEARER realm=3D"somerealm" >=20 > furthermore, I think interdependencies among WWW-Authenticate headers = as suggested by Phil >=20 > WWW-Authenticate: OAuth > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyy >=20 > could be rather fragile. >=20 > I would expect the WWW-Authenticate header to return all the data = required to obtain the credentials/tokens, such as >=20 > WWW-Authenticate: MAC realm=3D"somerealm", = tokenUrl=3D"yyyyy&token_secret=3Dyes" > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" >=20 > Which raises the question whether the coupling between authentication = schemes and the OAuth2 core protocol is stronger than assumed. >=20 > please als see = http://www.ietf.org/mail-archive/web/oauth/current/msg04988.html >=20 > regards, > Torsten. >=20 > Am 04.02.2011 22:39, schrieb William Mills: >=20 >> I was thinking along the lines of simply returning the HTTP = Authorization header schemes that are supported. In the OAuth 2 context = that would be >>=20 >> WWW-Authenticate: 401 error=3D"blah blah blah" = auth_types=3D"Bearer MAC Basic" >>=20 >> The client has to be aware of the authentication scheme names. >>=20 >> -bill >>=20 >>> -----Original Message----- >>> From: Phil Hunt [mailto:phil.hunt@oracle.com] >>> Sent: Friday, February 04, 2011 1:14 PM >>> To: William Mills >>> Cc: Marius Scurtescu; OAuth WG >>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>> 2/10) >>>=20 >>> I agree, that is still to be defined. There seems to be some push = back >>> on discovery, but this is likely warranted. If only because web = sites >>> may have both browser clients and app clients. >>>=20 >>> In a previous message, I did suggest the web site return HTTP 401 as >>> below... >>>>> 401 Unauthorized >>>>> WWW-Authenticate: Basic realm=3D"tokenSvc" >>>>> WWW-Authenticate: Digest realm=3D"tokenSvc" >>>>> WWW-Authenticate: Form >>> url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" >>>=20 >>> It could also include other items for "MAC", etc. >>>=20 >>> The only other issue would be determining whether the token is = obtained >>> via an OAuth profile or via some default profile. That could be >>> handled with something like: >>>=20 >>> WWW-Authenticate: Basic realm=3D"somerealm" >>> WWW-Authenticate: MAC realm=3D"somerealm" >>> WWW-Authenticate: OAuth >>> token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy" >>>=20 >>> The above would suggest that MAC tokens could be used alone as >>> described in some specification for "MAC". However, the presence of >>> the OAuth header indicates that MAC and BEARER tokens can be used in >>> the OAuth pattern. >>>=20 >>> I think this allows both de-coupling of tokens from OAuth but also >>> informs clients what tokens can be used with OAuth. >>>=20 >>> There may be other ways to do this. But it does help with the >>> decoupling. >>>=20 >>> Phil >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-02-04, at 11:44 AM, William Mills wrote: >>>=20 >>>> I was thinking more about how the client knows what to use. The >>> ubiquitous "service documentation" may come in to play here. Some = form >>> of serv ice discovery/webfinger thing could also be used. >>>>> -----Original Message----- >>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] >>>>> Sent: Friday, February 04, 2011 11:37 AM >>>>> To: William Mills >>>>> Cc: Marius Scurtescu; OAuth WG >>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name = (deadline: >>>>> 2/10) >>>>>=20 >>>>> Yes. This should be defined in each token type specification. >>>>>=20 >>>>> Phil >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2011-02-04, at 11:29 AM, William Mills wrote: >>>>>=20 >>>>>> The only challenge is to know what scheme to use and what the >>> nuances >>>>> are of how to present the credential. >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf >>>>>>> Of Phil Hunt >>>>>>> Sent: Friday, February 04, 2011 9:42 AM >>>>>>> To: Marius Scurtescu >>>>>>> Cc: OAuth WG >>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >>> (deadline: >>>>>>> 2/10) >>>>>>>=20 >>>>>>> OAuth should be able to support other token schemes. >>>>>>>=20 >>>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, or >>>>>>> whatever. >>>>>>>=20 >>>>>>> Phil >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >>>>>>>=20 >>>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav >>>>>>> wrote: >>>>>>>>> Hey Marius, >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM >>>>>>>>>> To: Eran Hammer-Lahav >>>>>>>>>> Cc: OAuth WG >>>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >>>>>>> (deadline: >>>>>>>>>> 2/10) >>>>>>>>>>=20 >>>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes >>>>>>>>>>>=20 >>>>>>>>>>> Define a single authentication scheme for all token types = with >>>>>>> some >>>>>>>>>>> attribute used to detect which scheme is actually being = used. >>>>>>>>>>>=20 >>>>>>>>>>> Benefits: >>>>>>>>>>>=20 >>>>>>>>>>> - single scheme, reuse of the 1.0 pattern. >>>>>>>>>>>=20 >>>>>>>>>>> Downsides: >>>>>>>>>>>=20 >>>>>>>>>>> - requires a new registry for authentication header >>> parameters. >>>>>>>>>> How is this different from option 1? Wouldn't that need some >>>>>>> registry? >>>>>>>>> #1 relies on the existing practice of creating HTTP scheme = names >>>>> (no >>>>>>> current registry but httpbis might be creating one), as well as >>> the >>>>> -12 >>>>>>> token type registry. Using a sub-scheme means you also need a >>>>> registry >>>>>>> for the header attributes that each token type will need (unless >>> you >>>>>>> just don't care about using the same attribute name for = different >>>>>>> needs). >>>>>>>> Sure, there is no registry for schemes yet, but we would still >>> need >>>>>>>> some coordination. The fact that a sub-scheme needs a registry >>> that >>>>>>> we >>>>>>>> control is a benefit not a downside IMO. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> - schemes are not easily reusable outside OAuth. >>>>>>>>>> Sure. But I really don't see this group trying to create >>> generic >>>>>>> authentication >>>>>>>>>> schemes. >>>>>>>>> MAC is exactly that. >>>>>>>> May or may not be. My point is that this group is not focused = on >>>>>>>> creating generic authentication schemes. Are you aware of any >>> other >>>>>>>> protocols that might use MAC or BEARER? Are we willing to put = in >>>>> the >>>>>>>> effort to create generic schemes? Is it our charter? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> - existing frameworks usually switch on scheme name, not on >>> sub >>>>>>>>>>> scheme, which will cause difficulty in some deployments. >>>>>>>>>> I can see this as a potential problem. But considering that >>> there >>>>>>> wasn't much >>>>>>>>>> objection to use "OAuth" as a scheme name before (total = overlap >>>>>>> with >>>>>>>>>> OAuth 1, and the suggested solution was to look for the >>> signature >>>>>>>>>> parameter) I don't see how this is suddenly an issue. >>>>>>>>> There was pretty strong objection to reusing OAuth. >>>>>>>> Yes, because there was no sub-scheme nor version (and the = grammar >>>>> was >>>>>>>> totally broken). Even so, lots of implementations went ahead = and >>>>> did >>>>>>>> it. Were there any scheme switching issues we are aware of? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Do we have a concrete problem here or this is just = theoretical? >>>>>>>>> This came up during the review of draft-hammer-http-token-auth >>>>> [1]. >>>>>>> There was a long thread about it where people posted actual >>>>> framework >>>>>>> issues. >>>>>>>>>>> - potential to produce a very complicated scheme once many = sub >>>>>>> schemes >>>>>>>>>>> are added. >>>>>>>>>> Why? I would argue that this option actually produces more >>>>> uniform >>>>>>>>>> schemes because it forces all of them to be name/value pairs. >>>>>>> Beyond >>>>>>>>>> token_type everything is scheme specific. I really don't see >>> what >>>>>>> is very >>>>>>>>>> complicate here. >>>>>>>>> It is still a single scheme with many different sub-schemes, >>> each >>>>>>> with different key-value pairs that may have conflicting = meaning. >>>>> The >>>>>>> way I look at it is that if I try to fully implement this mega >>>>> scheme >>>>>>> (which means all its sub-schemes), it will likely be a = complicated >>>>>>> task. On the other hand, if you split it across scheme name, we >>>>> already >>>>>>> have a well-established system in place to pick and choose HTTP >>>>>>> authentication schemes. >>>>>>>> No one has to implement a mega scheme. All schemes must use >>>>>>> name/value >>>>>>>> pairs and that's where the common part stops. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>>> - requires its own discovery method for which schemes are >>>>>>> supported. >>>>>>>>>> Why is this a downside only for this option? >>>>>>>>> Because the other options get this for free by using the WWW- >>>>>>> Authenticate header (since each scheme has a unique name). You = can >>>>> list >>>>>>> multiple headers in the 401 response. >>>>>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- >>> Authenticate >>>>>>>> work for sub-schemes as well? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Should I record your vote for #2? >>>>>>>> #2 or #3 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Marius >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Sun Feb 6 03:39:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E24E3A6ACF for ; Sun, 6 Feb 2011 03:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k886ugT1OM0 for ; Sun, 6 Feb 2011 03:39:08 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 314763A6AAF for ; Sun, 6 Feb 2011 03:39:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,433,1291554000"; d="scan'208";a="24035501" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Feb 2011 22:39:08 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6248"; a="19024689" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Feb 2011 22:39:08 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Sun, 6 Feb 2011 22:39:07 +1100 From: "Manger, James H" To: Brian Eaton , OAuth WG Date: Sun, 6 Feb 2011 22:39:05 +1100 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEQT3qF4ux/naeRoWOY2lepI5ssABqeP3w Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D51DE32@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 11:39:09 -0000 Brian said: > How do we reconcile "Bearer" with "Negotiate", "NTLM", "Basic", and > "GoogleLogin"? All of those examples are widely deployed and use > bearer tokens in Authorization headers. Should all of those switch to > using the "Bearer" scheme as well? "Basic" & "NTLM" are password schemes; "Negotiate" can be a password or Ker= beros or other scheme (I think); "GoogleLogin" is a password scheme with an= optional CAPTCHA. These aren't bearer token schemes so they should not (and cannot) switch to= the "Bearer" scheme. ... > Something like "Bearer" seems overly generic. > Why do we think we are qualified to claim "Bearer" for our own? By not defining it to be just our own, ie don't make the definition OAuth-s= pecific. -- James Manger From James.H.Manger@team.telstra.com Sun Feb 6 04:26:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B043A68E0 for ; Sun, 6 Feb 2011 04:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vRgnlSJV6GF for ; Sun, 6 Feb 2011 04:26:15 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 6170C3A68D4 for ; Sun, 6 Feb 2011 04:26:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,433,1291554000"; d="scan'208,217";a="24259441" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 06 Feb 2011 23:26:13 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6248"; a="18599985" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 06 Feb 2011 23:26:13 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sun, 6 Feb 2011 23:26:12 +1100 From: "Manger, James H" To: Dirk Balfanz , OAuth WG Date: Sun, 6 Feb 2011 23:26:10 +1100 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvEiQaJj9dtj/DUQ/uTfaLWFqT8iABaTQFA Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127D51DE34WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 12:26:18 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127D51DE34WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dirk said: > FWIW, I agree with Brian - it [the "Bearer" scheme] should say OAuth some= where, because it's an OAuth token. OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, a= nything else. Conversely, any of these tokens can come from a variety of sources: a user-= delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do = with OAuth, a device interaction, manual configuration.... A server receives a bearer token in a request. Dirk, are you saying the contents of the token (at that it is a bearer toke= n) is not enough for the server? Does the server also need to know that it = came from an OAuth flow? If so, I suspect the server actually needs to know= more than that: such as which OAuth flow was used (eg user-delegation, cli= ent-only, assertion, future device flow etc), or from which authorization s= erver it came. I don't think a scheme name saying "OAuth" helps. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127D51DE34WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dirk said:

> FWIW, I agree wi= th Brian - it [the “Bearer” scheme] should say OAuth somewhere,= because it's an OAuth token.

 

OAuth can deliver any= variety of bearer token: SAML, JWT, SWT, opaque id, anything else.

Conversely, any of th= ese tokens can come from a variety of sources: a user-delegation OAuth flow= , a client-only OAuth flow, a flow with nothing to do with OAuth, a device = interaction, manual configuration….

 

A server receives a b= earer token in a request.

Dirk, are you saying = the contents of the token (at that it is a bearer token) is not enough for = the server? Does the server also need to know that it came from an OAuth fl= ow? If so, I suspect the server actually needs to know more than that: such as which OAuth flow was used (eg user-d= elegation, client-only, assertion, future device flow etc), or from which a= uthorization server it came. I don’t think a scheme name saying ̶= 0;OAuth” helps.

 

--<= /p>

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E1127D51DE34WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sun Feb 6 05:07:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC163A6924 for ; Sun, 6 Feb 2011 05:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJWEn3YkEht1 for ; Sun, 6 Feb 2011 05:07:37 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 0BCAB3A68CB for ; Sun, 6 Feb 2011 05:07:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,433,1291554000"; d="scan'208";a="27485193" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 07 Feb 2011 00:07:35 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6248"; a="18715506" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 Feb 2011 00:07:36 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 7 Feb 2011 00:07:35 +1100 From: "Manger, James H" To: Phil Hunt , OAuth WG Date: Mon, 7 Feb 2011 00:07:33 +1100 Thread-Topic: WWW-Auth. OAuth scheme (was RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)) Thread-Index: AcvEsIG7FoMx/j75QcuZC91St9uiRwBSXffw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D51DE35@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> In-Reply-To: <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] WWW-Auth. OAuth scheme (was RE: Bearer token type and scheme name (deadline: 2/10)) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 13:07:38 -0000 Phil Hunt said: > The only other issue would be determining whether the token is obtained v= ia an OAuth profile or > via some default profile. That could be handled w= ith something like: > > WWW-Authenticate: Basic realm=3D"somerealm" > WWW-Authenticate: MAC realm=3D"somerealm" > WWW-Authenticate: OAuth token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",t= okenUrl=3D"yyyyyy" > > The above would suggest that MAC tokens could be used alone as described = in some specification > for "MAC". However, the presence of the OAuth head= er indicates that MAC and BEARER tokens can > be used in the OAuth pattern. > > I think this allows both de-coupling of tokens from OAuth but also inform= s clients what tokens > can be used with OAuth. > > There may be other ways to do this. But it does help with the decoupling. I agree that this is a good approach. A separate WWW-Authenticate header in= dicating that an OAuth delegation flow can be used to get access. I am not = sure that you need to token=3D"MAC;BEARER" at this point -- you can get tha= t detail from the token response. Torsten Lodderstedt said: > I would expect the WWW-Authenticate header to return all the data require= d to obtain the credentials/tokens, such as > > WWW-Authenticate: MAC realm=3D"somerealm", tokenUrl=3D"yyyyy&token_secret= =3Dyes" > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" I don't really like this approach. Existing WWW-Auth headers do NOT "return all the data required to obtain th= e credentials". They assume the client already has the credentials -- perha= ps from a config file, perhaps from prompting a user. I don't think we can add tokenUrl etc to existing (non-OAuth-specific) auth= schemes -- the existing specs and existing implementations just don't supp= ort it. That shouldn't mean those schemes cannot be used for the authentica= tion part of an OAuth authorization flow, though. I would expect a 401 HTTP error response to return all the data required (e= xcept any client credentials (if required)) for the client to make a succes= sful request. Or at least the data required for the next step towards makin= g a successful request (eg an authorization URI). -- James Manger From James.H.Manger@team.telstra.com Sun Feb 6 05:43:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0611F3A68C6 for ; Sun, 6 Feb 2011 05:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdXVBLTexGkt for ; Sun, 6 Feb 2011 05:43:14 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id D97493A6778 for ; Sun, 6 Feb 2011 05:43:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,433,1291554000"; d="scan'208";a="24038851" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 07 Feb 2011 00:43:14 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6248"; a="18716435" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 Feb 2011 00:43:13 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 7 Feb 2011 00:43:13 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Mon, 7 Feb 2011 00:43:12 +1100 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 -- algorithm param Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/ABAMSawAB0Cinw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D51DE36@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 -- algorithm param X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 13:43:15 -0000 Eran, >> 13. The MAC algorithm should be explicitly indicated in the request, ins= tead >> of being implied by the access-token/id. I suggest including an "algorit= hm" >> parameter in the "Authorization" request header. I also suggest includin= g an >> "algorithms" parameter in the "WWW-Authenticate" response header that is >> a (comma-separated?) list of MAC algorithms that the server supports. > Why? The client does not get a choice which algorithm to use. There is no= negotiation here. Pretty much every standardised crypto message indicates the algorithm used = to protect it in the message itself. Why be different? Consider hashing the body. You don't need the secret key to do this, but yo= u do need to know the hash algorithm. With an algorithm parameter, a front-= end web server can use that to confirm the body-hash parameter is correct b= efore passing the message to a middle tier where the secret key is availabl= e to verify the MAC. An algorithm parameter offers some ability to migrate to stronger MAC algor= ithms if, say, (more) weaknesses in SHA-1 are found. Without it you need to= issue new credentials to migrate. If you have a environment of heterogeneous servers (legacy, new, vendor A, = vendor B...) they might support different algorithms, but it would handy if= clients could use a single credential. Secret keys are generally handled separately in software than support for c= rypto algorithms. For instance, you can store a secret key in a Java Key St= ore, but I don't think there is an associated spot to specify a MAC algorit= hm. -- James Manger From James.H.Manger@team.telstra.com Sun Feb 6 06:16:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C8A3A6960 for ; Sun, 6 Feb 2011 06:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOgra-urfaNP for ; Sun, 6 Feb 2011 06:16:13 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 428103A6937 for ; Sun, 6 Feb 2011 06:16:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,433,1291554000"; d="scan'208";a="25900151" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 Feb 2011 01:16:13 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6248"; a="18516146" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 Feb 2011 01:16:13 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Mon, 7 Feb 2011 01:16:12 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Mon, 7 Feb 2011 01:16:11 +1100 Thread-Topic: more comments on draft-hammer-oauth-v2-mac-token-02 -- encoding of secret Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbAA7aFd/ABAMSawAB1A1ug Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D51DE37@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB350E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02 -- encoding of secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 14:16:14 -0000 Eran, >> 16. OAuth2 can provide a "secret" as a Unicode string. MAC algorithms su= ch >> as HMAC use a key that is a byte array. Section 2 of the MAC spec says >> 'secret' >> can only include printable ASCII chars (except " and /). This is not qui= te right. >> The MAC scheme should expect 'secret' to be a byte array (ie not limit i= ts >> chars). A 'secret' string from an OAuth2 response should be UTF-8 encode= d >> to produce the byte array the MAC scheme uses. > What about when the secret is returned in the HTTP fragment? A fragment is part of a URI which is a string. Presumably you: (1) unescape= any %xx sequences in the fragment (assuming UTF-8) to get a string of any = Unicode characters; (2) encode the string to bytes using some character enc= oding; (3) pass the bytes as the secret key to the MAC algorithm. The spec should explicitly the state what the character encoding is at step= (2). > What is the value of making this use UTF-8. It was one reasonable choice -- once I convince you that a string-to-bytes = encoding needs to be explicitly stated. Other options are ASCII or hex or b= ase64url. -- James Manger From balfanz@google.com Sun Feb 6 23:16:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493483A6A11 for ; Sun, 6 Feb 2011 23:16:30 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5bMQkp5Kkbu for ; Sun, 6 Feb 2011 23:16:29 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 24A663A6A28 for ; Sun, 6 Feb 2011 23:16:28 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p177GUDV006095 for ; Sun, 6 Feb 2011 23:16:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297062991; bh=TD8nFW2k1SvCwQR8hXsHhSVHMa4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nBussogbgE5YktufRfh6SDr9fdbxO9HIdnOuN4gp/T2dT7COo/sG6Z5LRm+RYAXb3 fPRg+YNoLU9+dbXvaYr1A== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by kpbe19.cbf.corp.google.com with ESMTP id p177GB4g011560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Feb 2011 23:16:29 -0800 Received: by qyk12 with SMTP id 12so3755938qyk.19 for ; Sun, 06 Feb 2011 23:16:29 -0800 (PST) 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=m4gOTn3L5tcI6yS+7rnUol0zE2HYO2XCm99934bxrbI=; b=kJZ8TQd5/K+sS5D2wygAxnzeKvnxSv/EII8rcezADHAA8PfCOnoFCzUcI3A0jHmj9F n9S1Uc+06LIK38X9sJsA== 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=IrIFgtuuRgGs//ERHY6HjzDmH+kJBZRaeJk90I9tIwzWzZ8Od53TQXdjbJ00NQhexS C4bzcBGjltjVL3Qtonxw== MIME-Version: 1.0 Received: by 10.224.28.70 with SMTP id l6mr6385461qac.302.1297062989107; Sun, 06 Feb 2011 23:16:29 -0800 (PST) Received: by 10.229.77.205 with HTTP; Sun, 6 Feb 2011 23:16:28 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 6 Feb 2011 23:16:28 -0800 Message-ID: From: Dirk Balfanz To: "Manger, James H" Content-Type: multipart/alternative; boundary=0015175ce088b7937e049bac0235 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 07:16:30 -0000 --0015175ce088b7937e049bac0235 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Dirk said: > > > FWIW, I agree with Brian - it [the =93Bearer=94 scheme] should say OAut= h > somewhere, because it's an OAuth token. > > > > OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, > anything else. > > Conversely, any of these tokens can come from a variety of sources: a > user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing= to > do with OAuth, a device interaction, manual configuration=85. > Yes - they're all still all OAuth tokens, though. As opposed to passwords, basic auth tokens, etc., (which are also bearer tokens, but not OAuth tokens). > A server receives a bearer token in a request. > > Dirk, are you saying the contents of the token (at that it is a bearer > token) is not enough for the server? > No - I'm sure the server can look at the token and figure out that it's on OAuth token. All I'm saying is that if it's an OAuth token, we should call it an OAuth token. Dirk. > Does the server also need to know that it came from an OAuth flow? If so,= I > suspect the server actually needs to know more than that: such as which > OAuth flow was used (eg user-delegation, client-only, assertion, future > device flow etc), or from which authorization server it came. I don=92t t= hink > a scheme name saying =93OAuth=94 helps. > > > > -- > > James Manger > > > --0015175ce088b7937e049bac0235 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 6, 2011 at 4:26 AM, Manger, = James H <James.H.Manger@team.telstra.com> wrote:

Dirk said:

> FWIW, I agree with Brian - it [the =93B= earer=94 scheme] should say OAuth somewhere, because it's an OAuth toke= n.

=A0

OAuth can deliver any variety of bearer toke= n: SAML, JWT, SWT, opaque id, anything else.

Conversely, any of these tokens can come fro= m a variety of sources: a user-delegation OAuth flow, a client-only OAuth f= low, a flow with nothing to do with OAuth, a device interaction, manual con= figuration=85.

Yes - they're all still all OAuth tokens,= though. As opposed to passwords, basic auth tokens, etc., (which are also = bearer tokens, but not OAuth tokens).

A server receives a bearer token in a request.

Dirk, are you saying the contents of the tok= en (at that it is a bearer token) is not enough for the server?

=
No - I'm sure the server can look at the = token and figure out that it's on OAuth token. All I'm saying is th= at if it's an OAuth token, we should call it an OAuth token.

Dirk.
=A0

Does the server also need to know that it came from an OAuth = flow? If so, I suspect the server actually needs to know more than that: such as which OAuth flow was used (eg user-d= elegation, client-only, assertion, future device flow etc), or from which a= uthorization server it came. I don=92t think a scheme name saying =93OAuth= =94 helps.

=A0

--

James Manger

=A0


--0015175ce088b7937e049bac0235-- From eran@hueniverse.com Mon Feb 7 00:03:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF803A6B0B for ; Mon, 7 Feb 2011 00:03:06 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5mpmDTt08DG for ; Mon, 7 Feb 2011 00:03:03 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 27C1C3A69A7 for ; Mon, 7 Feb 2011 00:03:02 -0800 (PST) Received: (qmail 24048 invoked from network); 7 Feb 2011 08:03:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2011 08:03:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 01:03:04 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz , "Manger, James H" Date: Mon, 7 Feb 2011 01:02:51 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvGlvVPLUGacYGqROqpzlTz3v7GoAABiG7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFB5AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 08:03:07 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFB5AP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, any token issued via OAuth by an authorization server is an OAuth toke= n by definition. Which makes 'token_type=3Doauth2' an silly and confusing s= tatement, given that any token issued via this method is also an OAuth 2.0 = token... but for some reason only one is labeled oauth2. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz Sent: Sunday, February 06, 2011 11:16 PM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H > wrote: Dirk said: > FWIW, I agree with Brian - it [the "Bearer" scheme] should say OAuth some= where, because it's an OAuth token. OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, a= nything else. Conversely, any of these tokens can come from a variety of sources: a user-= delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do = with OAuth, a device interaction, manual configuration.... Yes - they're all still all OAuth tokens, though. As opposed to passwords, = basic auth tokens, etc., (which are also bearer tokens, but not OAuth token= s). A server receives a bearer token in a request. Dirk, are you saying the contents of the token (at that it is a bearer toke= n) is not enough for the server? No - I'm sure the server can look at the token and figure out that it's on = OAuth token. All I'm saying is that if it's an OAuth token, we should call = it an OAuth token. Dirk. Does the server also need to know that it came from an OAuth flow? If so, I= suspect the server actually needs to know more than that: such as which OA= uth flow was used (eg user-delegation, client-only, assertion, future devic= e flow etc), or from which authorization server it came. I don't think a sc= heme name saying "OAuth" helps. -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFB5AP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, any = token issued via OAuth by an authorization server is an OAuth token by defi= nition. Which makes ‘token_type=3Doauth2’ an silly and confusin= g statement, given that any token issued via this method is also an OAuth 2= .0 token… but for some reason only one is labeled oauth2.<= /span>

 

EHL

 

From:= oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Dir= k Balfanz
Sent: Sunday, February 06, 2011 11:16 PM
To: = Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Be= arer token type and scheme name (deadline: 2/10)

 

 

On= Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:

Dirk said= :

> FWIW, I agree with Brian - it [the “Bearer= 221; scheme] should say OAuth somewhere, because it's an OAuth token.

 

OAuth can deliver any variety of bearer t= oken: SAML, JWT, SWT, opaque id, anything else.

Conversely,= any of these tokens can come from a variety of sources: a user-delegation = OAuth flow, a client-only OAuth flow, a flow with nothing to do with OAuth,= a device interaction, manual configuration….

Yes - they're= all still all OAuth tokens, though. As opposed to passwords, basic auth to= kens, etc., (which are also bearer tokens, but not OAuth tokens).

A server receives a bearer token in a request.

Dirk, are you sayi= ng the contents of the token (at that it is a bearer token) is not enough f= or the server?

=

No - I'm sure the server can look at= the token and figure out that it's on OAuth token. All I'm saying is that = if it's an OAuth token, we should call it an OAuth token.

 

Dirk.

 

Does the server also need to know= that it came from an OAuth flow? If so, I suspect the server actually need= s to know more than that: such as which OAuth flow was used (eg user-delega= tion, client-only, assertion, future device flow etc), or from which author= ization server it came. I don’t think a scheme name saying “OAu= th” helps.

 

--

= James Manger

<= span lang=3DEN-AU> 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFB5AP3PW5EX1MB01E_-- From skylar@kiva.org Mon Feb 7 08:01:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5165B3A6D97 for ; Mon, 7 Feb 2011 08:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOkN6Ot+Vls1 for ; Mon, 7 Feb 2011 08:01:47 -0800 (PST) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by core3.amsl.com (Postfix) with SMTP id CC16C3A6DD5 for ; Mon, 7 Feb 2011 08:01:46 -0800 (PST) Received: from source ([74.125.82.51]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTVAXbtco7X0LPDxfMFSbyxFGcjpIvxbf@postini.com; Mon, 07 Feb 2011 08:01:51 PST Received: by mail-ww0-f51.google.com with SMTP id 15so4783121wwe.20 for ; Mon, 07 Feb 2011 08:01:50 -0800 (PST) Received: by 10.227.132.84 with SMTP id a20mr8698487wbt.56.1297094509895; Mon, 07 Feb 2011 08:01:49 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id y29sm3455874wbd.22.2011.02.07.08.01.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 08:01:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <4D4D0B4A.1000008@lerdorf.com> Date: Mon, 7 Feb 2011 17:01:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4D0B4A.1000008@lerdorf.com> To: Rasmus Lerdorf X-Mailer: Apple Mail (2.1082) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] client_id chicken+egg problem and a typo in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:01:48 -0000 I struggled w/ this conflict as well during implementation since we also = tie the redirection URI to client identity. However, URI preregistration = is not required by the spec (3.1.1, paragraph 3, so, if a provider's = redirect_uri validation is not dependent on client_id (be it a subset of = URIs, or all URIs) then the invalid_client error is possible. In practice, however, invalid_client will likely be an unlikely error. Perhaps the spec could make this more obvious by noting that = invalid_client should not be returned by providers who require = pre-registered redirection URIs. skylar On Feb 5, 2011, at 9:33 AM, Rasmus Lerdorf wrote: > In "4.1.2.1. Error Response" it says: >=20 > If the resource owner denies the access request or if the request > fails for reasons other than a missing or invalid redirection URI, > the authorization server informs the client by adding the following > parameters to the query component of the redirection URI using the > "application/x-www-form-urlencoded" format: >=20 > and then in the error section we have: >=20 > invalid_client > The client identifier provided is invalid. >=20 > Since the redirect URI is tied to a client's identity, we can't have = an > invalid client identity and a valid redirect URI at the same time. >=20 > In think the first part of 4.1.2.1 which currently says: >=20 > If the request fails due to a missing, invalid, or mismatching > redirection URI, the authorization server SHOULD inform the resource > owner of the error, and MUST NOT redirect the user-agent to the > invalid redirection URI. >=20 > should say: >=20 > If the request fails due to a missing or invalid client identifier, > or due to a missing, invalid or mismatching redirect URI, the > authorization server SHOULD inform the resource owner of the error, > and MUST NOT redirect the user-agent to the invalid redirection URI. >=20 > and the invalid_client error code should be removed from the list of > errors below. >=20 > And a minor typo at the end of 4.1.2: >=20 > "The authorization server should document the size of any value is > issues." >=20 > -Rasmus > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon Feb 7 08:36:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD883A6D7D for ; Mon, 7 Feb 2011 08:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf5t-sS85TBD for ; Mon, 7 Feb 2011 08:36:14 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 757A73A6959 for ; Mon, 7 Feb 2011 08:36:05 -0800 (PST) Received: from source ([74.125.82.179]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTVAfeSxSUXaWNWBl6fvZYRwkUA+NArXS@postini.com; Mon, 07 Feb 2011 08:36:10 PST Received: by wyi11 with SMTP id 11so4598712wyi.10 for ; Mon, 07 Feb 2011 08:36:08 -0800 (PST) Received: by 10.227.132.149 with SMTP id b21mr5346465wbt.48.1297096567908; Mon, 07 Feb 2011 08:36:07 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id w25sm3493655wbd.11.2011.02.07.08.36.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 08:36:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 7 Feb 2011 17:36:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA0EEE5-B3A9-4276-9BAC-D48880845DA1@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:36:15 -0000 A couple of editorial notes: 3.2 has a mismatch of parameters between the example and the text (eg, = "using access token j92fsdjf094gjfdi,..." where h480djs93hd8 from 1.1 is = used in the example). The timestamp and nonce are also mismatched, = though bodyhash seems correct. As a result, the signature is invalid for = the example. 3.3.1 gives an example of a request but doesn't provide the secret or a = signature. It's not necessary here, but adding a valid Authentication = header for this line as well as "using.... secret...algorithm" statement = gives implementors more information to validate their work against the = spec. Adding the algorithm for the token/secret would also inform the = method implied (sha1) for the body hash in this example. If these two issues are resolved, the spec gives 3 clear examples (eg, = test case) for implementors to confirm their understanding of the = signature process. It's a valuable side-effect with very little effort = or distraction. skylar On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > =20 > New version includes the following changes: > =20 > o Added body-hash support. > o Updated OAuth 2.0 reference to -12 and added token type = registration template. > o Removed error and error URI attributes (codes were just a = duplication of the HTTP status codes). > =20 > Feedback would be greatly appreciated. > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Mon Feb 7 08:56:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759953A6DD9 for ; Mon, 7 Feb 2011 08:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM6k6IutmmxZ for ; Mon, 7 Feb 2011 08:56:53 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id A08723A6950 for ; Mon, 7 Feb 2011 08:56:52 -0800 (PST) Received: from source ([209.85.161.50]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTVAkWCKX93F75FEK6/slJdpsW2o0kYuc@postini.com; Mon, 07 Feb 2011 08:56:57 PST Received: by mail-fx0-f50.google.com with SMTP id 14so5672442fxm.37 for ; Mon, 07 Feb 2011 08:56:56 -0800 (PST) Received: by 10.223.111.137 with SMTP id s9mr11636924fap.98.1297097816301; Mon, 07 Feb 2011 08:56:56 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id a2sm1288213faw.22.2011.02.07.08.56.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 08:56:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 7 Feb 2011 17:56:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42F6D9E1-05F5-4CD5-97DB-DF3BE0763A04@kiva.org> References: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127D4581D7@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:56:55 -0000 comments below... On Feb 4, 2011, at 6:22 AM, Manger, James H wrote: > Comments on draft-hammer-oauth-v2-mac-token-02 > >=20 > This draft is a good improvement. >=20 > (continuing numbering from my previous comments) >=20 > 11. The "access token" field would be better labelled "id". The MAC = scheme > only needs this field to identify the MAC secret. The MAC scheme = itself > doesn't need to care whether this id also represents a scope, = duration, > assertion etc. >=20 > Though it may slightly complicated the use of the MAC scheme with = OAuth2, > I would seriously consider supporting two identifiers: > * An authentication id -- to identify the key used to verify the MAC; = and > * An authorization id -- to identify the = scope/account/permissions/duration... > that the client want to act under. > The SASL framework has these two concepts > [RFC4422 Simple Authentication and Security Layer (SASL)]. > Any modern SASL authentication mechanism will be expected to support = both ids. > The authorization id is a good match for an OAuth2 token or other sort = of=20 > assertion. > The OAuth2-to-MAC binding could define a 'keyid' parameter to = accompany the=20 > 'secret'. > The 'keyid' value would map to the authentication id field in the MAC = scheme, > and the 'access_token' would map to the authorization id field. While I don't see much need for two IDs (they could be combined in the = token, if necessary, as Eran mentions) I do favor using a term other = than token, merely for the sake of clarity when this is used outside of = OAuth. Consistent naming with other similar conventions (AWS, SASL?, = etc.) seems like a logical decision maker. I had suggested "assertion" = as each token seems to be asserting some identity, permission, etc. = However, "id" is perhaps just as good if only to remove the implication = that this is to be used primarily with OAuth or that the value of = "token" is always a value so-named coming from an OAuth server. >=20 > 13. The MAC algorithm should be explicitly indicated in the request, = instead > of being implied by the access-token/id. I suggest including an = "algorithm" > parameter in the "Authorization" request header. I also suggest = including an > "algorithms" parameter in the "WWW-Authenticate" response header that = is a > (comma-separated?) list of MAC algorithms that the server supports. After seeing James' follow-up on this, I see the value to implementors = and tiered architectures to adding this parameter. On the other-hand, = this could be yet another element forced into "token" (as with = client_id) if it was critical for providers to detect at the header. = This seems to be a tension between minimalism and convention. One argument for not including it is that providers should not be = tempted to validate a token based on the signature method supplied by = the client. That is, if "algorithm" was included, the provider MUST = validate at the lower level that it matches that of the token issued. By = not having it in the header, providers are required to do the look-up. = As Eran said, it's not negotiable. From skylar@kiva.org Mon Feb 7 09:24:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E728D3A6E3A for ; Mon, 7 Feb 2011 09:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExGtZB-+24rc for ; Mon, 7 Feb 2011 09:24:45 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 9652C3A6E2F for ; Mon, 7 Feb 2011 09:24:44 -0800 (PST) Received: from source ([209.85.215.175]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTVAq4G8U5vaBs+jkd9wFRL5TcqJGR9QO@postini.com; Mon, 07 Feb 2011 09:24:49 PST Received: by eya28 with SMTP id 28so2305978eya.34 for ; Mon, 07 Feb 2011 09:24:47 -0800 (PST) Received: by 10.204.56.14 with SMTP id w14mr15976780bkg.27.1297099484614; Mon, 07 Feb 2011 09:24:44 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id a17sm2183660bku.23.2011.02.07.09.24.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 09:24:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 7 Feb 2011 18:24:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav , OAuth WG X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:24:46 -0000 On body-hash... Having completed a trial implementation, it seems redundant, and = potentially problematic, to include the body-hash in the Authentication = header. The danger is that implementors may neglect to recalculate the = hash themselves, reusing the value (even if incorrect) provided by the = client. Why not just require the provider to calculate this and validate = it by comparing the final signature? This way it's clearer for everyone = what the expectations are in validating the signature. I propose either a flag (eg, usebodyhash=3D"1") or an algorithm = (bodyhashalgorithm=3D"sha1"). If this parameter was provided, the = correct hash would be added to the base string for signing. If omitted = (or set false?) then an empty string is used for base string element #4. On including parameters for signing... I'd retract my suggestion that we'd include parameter-hash in the = header. Instead, I would suggest making parameters optional in = calculating the signature using a flag as with bodyhash. Providers could = require including parameters if so desired. Parameters could be included = as currently defined, or with a hash method similar to entity-body = (which I find both simpler and more congruent).=20 Again, the goal in making query parameters optional is to allow = providers to make signature calculation as simple as possible for = clients (so much as it is in line with the security requirements of the = provider) and avoid complexities in implementation such as those that = tripped up OAuth 1. On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > =20 > New version includes the following changes: > =20 > o Added body-hash support. > o Updated OAuth 2.0 reference to -12 and added token type = registration template. > o Removed error and error URI attributes (codes were just a = duplication of the HTTP status codes). > =20 > Feedback would be greatly appreciated. > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Feb 7 09:27:08 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76D73A6E37 for ; Mon, 7 Feb 2011 09:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmzihOXiSkgy for ; Mon, 7 Feb 2011 09:27:07 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CCB343A6E2F for ; Mon, 7 Feb 2011 09:27:07 -0800 (PST) Received: (qmail 28865 invoked from network); 7 Feb 2011 17:27:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2011 17:27:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 7 Feb 2011 10:27:00 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , OAuth WG Date: Mon, 7 Feb 2011 10:26:46 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvG6+zzWEcHzevzR2iwFVcy1BpGKgAACFjg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC42@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> In-Reply-To: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@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 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:27:08 -0000 Yeah... I struggled with that. There is no reason to include the body hash with the= request other than to indicate a body hash is included in the normalized r= equest string. It's just that an attribute like 'bodyhash=3Dtrue' is so ugl= y... I'm still thinking about this. EHL > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Monday, February 07, 2011 9:25 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > On body-hash... >=20 > Having completed a trial implementation, it seems redundant, and > potentially problematic, to include the body-hash in the Authentication > header. The danger is that implementors may neglect to recalculate the ha= sh > themselves, reusing the value (even if incorrect) provided by the client.= Why > not just require the provider to calculate this and validate it by compar= ing the > final signature? This way it's clearer for everyone what the expectations= are > in validating the signature. >=20 > I propose either a flag (eg, usebodyhash=3D"1") or an algorithm > (bodyhashalgorithm=3D"sha1"). If this parameter was provided, the correct > hash would be added to the base string for signing. If omitted (or set fa= lse?) > then an empty string is used for base string element #4. >=20 >=20 > On including parameters for signing... >=20 > I'd retract my suggestion that we'd include parameter-hash in the header. > Instead, I would suggest making parameters optional in calculating the > signature using a flag as with bodyhash. Providers could require includin= g > parameters if so desired. Parameters could be included as currently defin= ed, > or with a hash method similar to entity-body (which I find both simpler a= nd > more congruent). >=20 > Again, the goal in making query parameters optional is to allow providers= to > make signature calculation as simple as possible for clients (so much as = it is in > line with the security requirements of the provider) and avoid complexiti= es in > implementation such as those that tripped up OAuth 1. >=20 >=20 >=20 > On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: >=20 > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > > > > New version includes the following changes: > > > > o Added body-hash support. > > o Updated OAuth 2.0 reference to -12 and added token type registrat= ion > template. > > o Removed error and error URI attributes (codes were just a duplica= tion > of the HTTP status codes). > > > > Feedback would be greatly appreciated. > > > > EHL > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Feb 7 09:31:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208CB3A6E3D for ; Mon, 7 Feb 2011 09:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEwzAwPAG7nw for ; Mon, 7 Feb 2011 09:31:21 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E7EA03A6E24 for ; Mon, 7 Feb 2011 09:31:20 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p17HV7Jp015161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 17:31:10 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17HQHEw021601; Mon, 7 Feb 2011 17:30:43 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 1030075861297096142; Mon, 07 Feb 2011 08:29:02 -0800 Received: from [192.168.1.12] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 08:28:59 -0800 References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: multipart/alternative; boundary=Apple-Mail-2-961357116 Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Mon, 7 Feb 2011 08:28:52 -0800 To: Eran Hammer-Lahav X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D502C57.00AF:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:31:22 -0000 --Apple-Mail-2-961357116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 -1 I don't agree fully here.=20 Phil Sent from my phone.=20 On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote: > Yes, any token issued via OAuth by an authorization server is an OAuth tok= en by definition. Which makes =E2=80=98token_type=3Doauth2=E2=80=99 an silly= and confusing statement, given that any token issued via this method is als= o an OAuth 2.0 token=E2=80=A6 but for some reason only one is labeled oauth2= . >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz > Sent: Sunday, February 06, 2011 11:16 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)= >=20 > =20 >=20 > =20 >=20 > On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H wrote: >=20 > Dirk said: >=20 > > FWIW, I agree with Brian - it [the =E2=80=9CBearer=E2=80=9D scheme] shou= ld say OAuth somewhere, because it's an OAuth token. >=20 > =20 >=20 > OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, a= nything else. >=20 > Conversely, any of these tokens can come from a variety of sources: a user= -delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do w= ith OAuth, a device interaction, manual configuration=E2=80=A6. >=20 > Yes - they're all still all OAuth tokens, though. As opposed to passwords,= basic auth tokens, etc., (which are also bearer tokens, but not OAuth token= s). >=20 > A server receives a bearer token in a request. >=20 > Dirk, are you saying the contents of the token (at that it is a bearer tok= en) is not enough for the server? >=20 > No - I'm sure the server can look at the token and figure out that it's on= OAuth token. All I'm saying is that if it's an OAuth token, we should call i= t an OAuth token. >=20 > =20 >=20 > Dirk. >=20 > =20 >=20 > Does the server also need to know that it came from an OAuth flow? If so, I= suspect the server actually needs to know more than that: such as which OAu= th flow was used (eg user-delegation, client-only, assertion, future device f= low etc), or from which authorization server it came. I don=E2=80=99t think a= scheme name saying =E2=80=9COAuth=E2=80=9D helps. >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-961357116 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
-1

I don't agr= ee fully here. 

Phil

Sent from my phone. = ;

On 2011-02-07, at 0:02, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Yes, any token issu= ed via OAuth by an authorization server is an OAuth token by definition. Whi= ch makes =E2=80=98token_type=3Doauth2=E2=80=99 an silly and confusing statem= ent, given that any token issued via this method is also an OAuth 2.0 token=E2= =80=A6 but for some reason only one is labeled oauth2.

=

 

EHL

<= p class=3D"MsoNormal"> 

=

From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf Of Dirk Balfanz
Sent= : Sunday, February 06, 2011 11:16 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and sc= heme name (deadline: 2/10)

 

 

On Sun, Feb 6, 2011 a= t 4:26 AM, Manger, James H <James.H.Manger@team= .telstra.com> wrote:

Dirk said: =

> FWIW, I agree w= ith Brian - it [the =E2=80=9CBearer=E2=80=9D scheme] should say OAuth somewh= ere, because it's an OAuth token.

 

OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id,= anything else.

Conversely, any of these tokens can come f= rom a variety of sources: a user-delegation OAuth flow, a client-only OAuth f= low, a flow with nothing to do with OAuth, a device interaction, manual conf= iguration=E2=80=A6.

<= /div>

Yes - they're all still all OAuth tokens, t= hough. As opposed to passwords, basic auth tokens, etc., (which are also bea= rer tokens, but not OAuth tokens).

A server rec= eives a bearer token in a request.

Dirk, are you saying the contents of the token (at= that it is a bearer token) is not enough for the server?

No - I'm sure the server can look at the token and figure out that it= 's on OAuth token. All I'm saying is that if it's an OAuth token, we should c= all it an OAuth token.

=  

Dirk.

=

 

Does the server also need to know that it came from an OAuth flow?= If so, I suspect the server actually needs to know more than that: such as w= hich OAuth flow was used (eg user-delegation, client-only, assertion, future= device flow etc), or from which authorization server it came. I don=E2=80=99= t think a scheme name saying =E2=80=9COAuth=E2=80=9D helps.

 

--

James Manger

 =

 

_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-2-961357116-- From eran@hueniverse.com Mon Feb 7 09:55:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2783A6E4C for ; Mon, 7 Feb 2011 09:55:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoPTZSKveI8k for ; Mon, 7 Feb 2011 09:55:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5A0813A6E41 for ; Mon, 7 Feb 2011 09:55:00 -0800 (PST) Received: (qmail 23654 invoked from network); 7 Feb 2011 17:55:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2011 17:55:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 10:55:00 -0700 From: Eran Hammer-Lahav To: Phillip Hunt Date: Mon, 7 Feb 2011 10:54:47 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvG7NlCQlsFJD0bSjOw8GZdGMbbGwAAzgtg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC55P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:55:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC55P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBkb27igJl0IHlvdSBhZ3JlZSB3aXRoPw0KDQpFSEwNCg0KRnJvbTogUGhpbGxpcCBIdW50 IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA3 LCAyMDExIDg6MjkgQU0NClRvOiBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IERpcmsgQmFsZmFuejsg TWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQmVhcmVy IHRva2VuIHR5cGUgYW5kIHNjaGVtZSBuYW1lIChkZWFkbGluZTogMi8xMCkNCg0KLTENCg0KSSBk b24ndCBhZ3JlZSBmdWxseSBoZXJlLg0KDQpQaGlsDQoNClNlbnQgZnJvbSBteSBwaG9uZS4NCg0K T24gMjAxMS0wMi0wNywgYXQgMDowMiwgRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJz ZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNClllcywgYW55IHRva2Vu IGlzc3VlZCB2aWEgT0F1dGggYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgYW4gT0F1dGgg dG9rZW4gYnkgZGVmaW5pdGlvbi4gV2hpY2ggbWFrZXMg4oCYdG9rZW5fdHlwZT1vYXV0aDLigJkg YW4gc2lsbHkgYW5kIGNvbmZ1c2luZyBzdGF0ZW1lbnQsIGdpdmVuIHRoYXQgYW55IHRva2VuIGlz c3VlZCB2aWEgdGhpcyBtZXRob2QgaXMgYWxzbyBhbiBPQXV0aCAyLjAgdG9rZW7igKYgYnV0IGZv ciBzb21lIHJlYXNvbiBvbmx5IG9uZSBpcyBsYWJlbGVkIG9hdXRoMi4NCg0KRUhMDQoNCkZyb206 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpcmsgQmFsZmFueg0K U2VudDogU3VuZGF5LCBGZWJydWFyeSAwNiwgMjAxMSAxMToxNiBQTQ0KVG86IE1hbmdlciwgSmFt ZXMgSA0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBCZWFyZXIgdG9rZW4g dHlwZSBhbmQgc2NoZW1lIG5hbWUgKGRlYWRsaW5lOiAyLzEwKQ0KDQoNCk9uIFN1biwgRmViIDYs IDIwMTEgYXQgNDoyNiBBTSwgTWFuZ2VyLCBKYW1lcyBIIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tPG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6 DQoNCkRpcmsgc2FpZDoNCg0KPiBGV0lXLCBJIGFncmVlIHdpdGggQnJpYW4gLSBpdCBbdGhlIOKA nEJlYXJlcuKAnSBzY2hlbWVdIHNob3VsZCBzYXkgT0F1dGggc29tZXdoZXJlLCBiZWNhdXNlIGl0 J3MgYW4gT0F1dGggdG9rZW4uDQoNCg0KDQpPQXV0aCBjYW4gZGVsaXZlciBhbnkgdmFyaWV0eSBv ZiBiZWFyZXIgdG9rZW46IFNBTUwsIEpXVCwgU1dULCBvcGFxdWUgaWQsIGFueXRoaW5nIGVsc2Uu DQoNCkNvbnZlcnNlbHksIGFueSBvZiB0aGVzZSB0b2tlbnMgY2FuIGNvbWUgZnJvbSBhIHZhcmll dHkgb2Ygc291cmNlczogYSB1c2VyLWRlbGVnYXRpb24gT0F1dGggZmxvdywgYSBjbGllbnQtb25s eSBPQXV0aCBmbG93LCBhIGZsb3cgd2l0aCBub3RoaW5nIHRvIGRvIHdpdGggT0F1dGgsIGEgZGV2 aWNlIGludGVyYWN0aW9uLCBtYW51YWwgY29uZmlndXJhdGlvbuKApi4NClllcyAtIHRoZXkncmUg YWxsIHN0aWxsIGFsbCBPQXV0aCB0b2tlbnMsIHRob3VnaC4gQXMgb3Bwb3NlZCB0byBwYXNzd29y ZHMsIGJhc2ljIGF1dGggdG9rZW5zLCBldGMuLCAod2hpY2ggYXJlIGFsc28gYmVhcmVyIHRva2Vu cywgYnV0IG5vdCBPQXV0aCB0b2tlbnMpLg0KDQpBIHNlcnZlciByZWNlaXZlcyBhIGJlYXJlciB0 b2tlbiBpbiBhIHJlcXVlc3QuDQoNCkRpcmssIGFyZSB5b3Ugc2F5aW5nIHRoZSBjb250ZW50cyBv ZiB0aGUgdG9rZW4gKGF0IHRoYXQgaXQgaXMgYSBiZWFyZXIgdG9rZW4pIGlzIG5vdCBlbm91Z2gg Zm9yIHRoZSBzZXJ2ZXI/DQpObyAtIEknbSBzdXJlIHRoZSBzZXJ2ZXIgY2FuIGxvb2sgYXQgdGhl IHRva2VuIGFuZCBmaWd1cmUgb3V0IHRoYXQgaXQncyBvbiBPQXV0aCB0b2tlbi4gQWxsIEknbSBz YXlpbmcgaXMgdGhhdCBpZiBpdCdzIGFuIE9BdXRoIHRva2VuLCB3ZSBzaG91bGQgY2FsbCBpdCBh biBPQXV0aCB0b2tlbi4NCg0KRGlyay4NCg0KDQpEb2VzIHRoZSBzZXJ2ZXIgYWxzbyBuZWVkIHRv IGtub3cgdGhhdCBpdCBjYW1lIGZyb20gYW4gT0F1dGggZmxvdz8gSWYgc28sIEkgc3VzcGVjdCB0 aGUgc2VydmVyIGFjdHVhbGx5IG5lZWRzIHRvIGtub3cgbW9yZSB0aGFuIHRoYXQ6IHN1Y2ggYXMg d2hpY2ggT0F1dGggZmxvdyB3YXMgdXNlZCAoZWcgdXNlci1kZWxlZ2F0aW9uLCBjbGllbnQtb25s eSwgYXNzZXJ0aW9uLCBmdXR1cmUgZGV2aWNlIGZsb3cgZXRjKSwgb3IgZnJvbSB3aGljaCBhdXRo b3JpemF0aW9uIHNlcnZlciBpdCBjYW1lLiBJIGRvbuKAmXQgdGhpbmsgYSBzY2hlbWUgbmFtZSBz YXlpbmcg4oCcT0F1dGjigJ0gaGVscHMuDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC55P3PW5EX1MB01E_ 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 b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1 ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hhdCBkb27igJl0IHlvdSBhZ3JlZSB3aXRoPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+RUhMPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBQaGlsbGlwIEh1 bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXks IEZlYnJ1YXJ5IDA3LCAyMDExIDg6MjkgQU08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhh djxicj48Yj5DYzo8L2I+IERpcmsgQmFsZmFuejsgTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRzxi cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQmVhcmVyIHRva2VuIHR5cGUgYW5kIHNj aGVtZSBuYW1lIChkZWFkbGluZTogMi8xMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPi0xPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBkb24n dCBhZ3JlZSBmdWxseSBoZXJlLiZuYnNwOzxicj48YnI+UGhpbDxvOnA+PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlNlbnQgZnJvbSBteSBwaG9uZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPjxicj5PbiAyMDExLTAyLTA3LCBhdCAwOjAyLCBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5ZZXMsIGFueSB0b2tlbiBpc3N1ZWQgdmlhIE9B dXRoIGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGFuIE9BdXRoIHRva2VuIGJ5IGRlZmlu aXRpb24uIFdoaWNoIG1ha2VzIOKAmHRva2VuX3R5cGU9b2F1dGgy4oCZIGFuIHNpbGx5IGFuZCBj b25mdXNpbmcgc3RhdGVtZW50LCBnaXZlbiB0aGF0IGFueSB0b2tlbiBpc3N1ZWQgdmlhIHRoaXMg bWV0aG9kIGlzIGFsc28gYW4gT0F1dGggMi4wIHRva2Vu4oCmIGJ1dCBmb3Igc29tZSByZWFzb24g b25seSBvbmUgaXMgbGFiZWxlZCBvYXV0aDIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhMPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5EaXJrIEJhbGZhbno8YnI+PGI+U2Vu dDo8L2I+IFN1bmRheSwgRmVicnVhcnkgMDYsIDIwMTEgMTE6MTYgUE08YnI+PGI+VG86PC9iPiBN YW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gQmVhcmVyIHRva2VuIHR5cGUgYW5kIHNjaGVtZSBuYW1lIChkZWFkbGlu ZTogMi8xMCk8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+Jm5ic3A7PG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5PbiBTdW4sIEZlYiA2LCAyMDExIGF0IDQ6 MjYgQU0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2Vy QHRlYW0udGVsc3RyYS5jb20iPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHA+PHNwYW4gbGFuZz1FTi1BVSBzdHls ZT0nY29sb3I6YmxhY2snPkRpcmsgc2FpZDogPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFu IGxhbmc9RU4tQVUgc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IEZXSVcsIEkgYWdyZWUgd2l0aCBC cmlhbiAtIGl0IFt0aGUg4oCcQmVhcmVy4oCdIHNjaGVtZV0gc2hvdWxkIHNheSBPQXV0aCBzb21l d2hlcmUsIGJlY2F1c2UgaXQncyBhbiBPQXV0aCB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+ PHA+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjpibGFjayc+T0F1dGgg Y2FuIGRlbGl2ZXIgYW55IHZhcmlldHkgb2YgYmVhcmVyIHRva2VuOiBTQU1MLCBKV1QsIFNXVCwg b3BhcXVlIGlkLCBhbnl0aGluZyBlbHNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBs YW5nPUVOLUFVIHN0eWxlPSdjb2xvcjpibGFjayc+Q29udmVyc2VseSwgYW55IG9mIHRoZXNlIHRv a2VucyBjYW4gY29tZSBmcm9tIGEgdmFyaWV0eSBvZiBzb3VyY2VzOiBhIHVzZXItZGVsZWdhdGlv biBPQXV0aCBmbG93LCBhIGNsaWVudC1vbmx5IE9BdXRoIGZsb3csIGEgZmxvdyB3aXRoIG5vdGhp bmcgdG8gZG8gd2l0aCBPQXV0aCwgYSBkZXZpY2UgaW50ZXJhY3Rpb24sIG1hbnVhbCBjb25maWd1 cmF0aW9u4oCmLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPlllcyAtIHRoZXkncmUgYWxsIHN0aWxsIGFsbCBPQXV0aCB0b2tlbnMsIHRo b3VnaC4gQXMgb3Bwb3NlZCB0byBwYXNzd29yZHMsIGJhc2ljIGF1dGggdG9rZW5zLCBldGMuLCAo d2hpY2ggYXJlIGFsc28gYmVhcmVyIHRva2VucywgYnV0IG5vdCBPQXV0aCB0b2tlbnMpLjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PGRpdj48cD48c3BhbiBsYW5nPUVOLUFVPkEgc2VydmVyIHJlY2VpdmVzIGEg YmVhcmVyIHRva2VuIGluIGEgcmVxdWVzdC48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4g bGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6YmxhY2snPkRpcmssIGFyZSB5b3Ugc2F5aW5nIHRoZSBj b250ZW50cyBvZiB0aGUgdG9rZW4gKGF0IHRoYXQgaXQgaXMgYSBiZWFyZXIgdG9rZW4pIGlzIG5v dCBlbm91Z2ggZm9yIHRoZSBzZXJ2ZXI/IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5ObyAtIEknbSBzdXJlIHRo ZSBzZXJ2ZXIgY2FuIGxvb2sgYXQgdGhlIHRva2VuIGFuZCBmaWd1cmUgb3V0IHRoYXQgaXQncyBv biBPQXV0aCB0b2tlbi4gQWxsIEknbSBzYXlpbmcgaXMgdGhhdCBpZiBpdCdzIGFuIE9BdXRoIHRv a2VuLCB3ZSBzaG91bGQgY2FsbCBpdCBhbiBPQXV0aCB0b2tlbi48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+RGlyay48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cD48c3BhbiBs YW5nPUVOLUFVIHN0eWxlPSdjb2xvcjpibGFjayc+RG9lcyB0aGUgc2VydmVyIGFsc28gbmVlZCB0 byBrbm93IHRoYXQgaXQgY2FtZSBmcm9tIGFuIE9BdXRoIGZsb3c/IElmIHNvLCBJIHN1c3BlY3Qg dGhlIHNlcnZlciBhY3R1YWxseSBuZWVkcyB0byBrbm93IG1vcmUgdGhhbiB0aGF0OiBzdWNoIGFz IHdoaWNoIE9BdXRoIGZsb3cgd2FzIHVzZWQgKGVnIHVzZXItZGVsZWdhdGlvbiwgY2xpZW50LW9u bHksIGFzc2VydGlvbiwgZnV0dXJlIGRldmljZSBmbG93IGV0YyksIG9yIGZyb20gd2hpY2ggYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaXQgY2FtZS4gSSBkb27igJl0IHRoaW5rIGEgc2NoZW1lIG5hbWUg c2F5aW5nIOKAnE9BdXRo4oCdIGhlbHBzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBs YW5nPUVOLUFVIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2NvbG9yOmJsYWNrJz4tLTwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjpibGFjayc+SmFtZXMgTWFu Z2VyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g bGFuZz1FTi1BVT4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5Pjwv aHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC55P3PW5EX1MB01E_-- From beaton@google.com Mon Feb 7 10:09:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFE23A6E60 for ; Mon, 7 Feb 2011 10:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZM6dlkmeGD for ; Mon, 7 Feb 2011 10:09:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id D57713A6E56 for ; Mon, 7 Feb 2011 10:09:54 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p17I9vVF028363 for ; Mon, 7 Feb 2011 10:09:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297102198; bh=dZ6Hze7Q0AHquAyrYoYWtHXSa6E=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=Psic7akco52c/5eLFZTNJtquiVjrDw3mxKGtGAkAPLnReK3+dTy7J7xMQM46+xJ17 GKROT9oMiEyNCAR868mIQ== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz29.hot.corp.google.com with ESMTP id p17I9r42006794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Feb 2011 10:09:56 -0800 Received: by pwj9 with SMTP id 9so1159354pwj.35 for ; Mon, 07 Feb 2011 10:09:56 -0800 (PST) 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=r+R37gM1uP3/msak2PTwceoCgOHAFIB6q2T85rXcXjY=; b=kvgRcwvqPsp1u6ytu9UeWDI2QEzLOPbn0xI37Zq7KuHBq5Q2CVaORM1lNuqOTBaQ1c rlNXht4scHGkCaB5nx2A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=FucelbMfK36C/UJKpZ7WetWvTvNYPx/dZVx2jQL+vo/I57Nm5el3M7T7lnav6PRRVN KIi8UcfMeVDivDkDOE9w== MIME-Version: 1.0 Received: by 10.143.156.19 with SMTP id i19mr3429891wfo.304.1297102196516; Mon, 07 Feb 2011 10:09:56 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 7 Feb 2011 10:09:56 -0800 (PST) Date: Mon, 7 Feb 2011 10:09:56 -0800 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] who is working on security considerations? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:09:55 -0000 Has anyone stepped up to start writing security considerations yet? Now that the organization is back to tracking different use cases using different flows, I think it's feasible and would like to contribute. From phil.hunt@oracle.com Mon Feb 7 10:16:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266243A6A42 for ; Mon, 7 Feb 2011 10:16:24 -0800 (PST) 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.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZtlsJmrWXP3 for ; Mon, 7 Feb 2011 10:16:22 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 98E723A6E51 for ; Mon, 7 Feb 2011 10:16:22 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p17IGL2R031615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 18:16:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17H7Jl6000474; Mon, 7 Feb 2011 18:16:19 GMT Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 1030515621297102550; Mon, 07 Feb 2011 10:15:50 -0800 Received: from [192.168.0.102] (/24.85.255.91) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 10:15:49 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-20-967767522 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 7 Feb 2011 10:15:47 -0800 Message-Id: <55F39129-54B2-42A6-BD85-4939EE3635C0@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D5036F5.0099:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:16:24 -0000 --Apple-Mail-20-967767522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't agree that at token issued by an OAuth server is by definition = an OAuth token. OAuth describes a flow pattern around how tokens may be obtained, etc. = There are many types of tokens that could be employed. OAuth does not describe how SP's interpret and use tokens. It only = suggests how tokens are presented. Phil phil.hunt@oracle.com On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: > What don=92t you agree with? > =20 > EHL > =20 > From: Phillip Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, February 07, 2011 8:29 AM > To: Eran Hammer-Lahav > Cc: Dirk Balfanz; Manger, James H; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) > =20 > -1 > =20 > I don't agree fully here.=20 >=20 > Phil > =20 > Sent from my phone.=20 >=20 > On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote: >=20 > Yes, any token issued via OAuth by an authorization server is an OAuth = token by definition. Which makes =91token_type=3Doauth2=92 an silly and = confusing statement, given that any token issued via this method is also = an OAuth 2.0 token=85 but for some reason only one is labeled oauth2. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Dirk Balfanz > Sent: Sunday, February 06, 2011 11:16 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) > =20 > =20 >=20 > On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H = wrote: > Dirk said: >=20 > > FWIW, I agree with Brian - it [the =93Bearer=94 scheme] should say = OAuth somewhere, because it's an OAuth token. >=20 > =20 >=20 > OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque = id, anything else. >=20 > Conversely, any of these tokens can come from a variety of sources: a = user-delegation OAuth flow, a client-only OAuth flow, a flow with = nothing to do with OAuth, a device interaction, manual configuration=85. >=20 > Yes - they're all still all OAuth tokens, though. As opposed to = passwords, basic auth tokens, etc., (which are also bearer tokens, but = not OAuth tokens). > A server receives a bearer token in a request. >=20 > Dirk, are you saying the contents of the token (at that it is a bearer = token) is not enough for the server? >=20 > No - I'm sure the server can look at the token and figure out that = it's on OAuth token. All I'm saying is that if it's an OAuth token, we = should call it an OAuth token. > =20 > Dirk. > =20 > Does the server also need to know that it came from an OAuth flow? If = so, I suspect the server actually needs to know more than that: such as = which OAuth flow was used (eg user-delegation, client-only, assertion, = future device flow etc), or from which authorization server it came. I = don=92t think a scheme name saying =93OAuth=94 helps. >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-20-967767522 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = don't agree that at token issued by an OAuth server is by definition an = OAuth token.

OAuth describes a flow pattern around = how tokens may be obtained, etc. There are many types of tokens that = could be employed.

OAuth does not describe how = SP's interpret and use tokens.  It only suggests how tokens are = presented.

Phil

On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav = wrote:

What don=92t you agree = with?
 
EHL
 Phillip = Hunt [mailto:phil.hunt@oracle.com] 
Sent: Monday, February 07, 2011 = 8:29 AM
To: Eran = Hammer-Lahav
Cc: Dirk Balfanz; Manger, James = H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token = type and scheme name (deadline: = 2/10)
I don't agree fully = here. 

Phil
Sent from my = phone. 


On 2011-02-07, at 0:02, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:

Yes, any token issued via OAuth by an authorization = server is an OAuth token by definition. Which makes =91token_type=3Doauth2= =92 an silly and confusing statement, given that any token issued via = this method is also an OAuth 2.0 token=85 but for some reason only one = is labeled oauth2.
 
EHL
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Dirk = Balfanz
Sent: Sunday, February 06, 2011 = 11:16 PM
To: Manger, James = H
Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Bearer token = type and scheme name (deadline: = 2/10)
On Sun, Feb 6, 2011 = at 4:26 AM, Manger, James H <James.H.Manger@team.telstra.com> = wrote:

Dirk = said:

> FWIW, I agree with Brian - = it [the =93Bearer=94 scheme] should say OAuth somewhere, because it's an = OAuth token.

OAuth can deliver = any variety of bearer token: SAML, JWT, SWT, opaque id, anything = else.

Conversely, any of these tokens = can come from a variety of sources: a user-delegation OAuth flow, a = client-only OAuth flow, a flow with nothing to do with OAuth, a device = interaction, manual = configuration=85.

Yes - they're all still all OAuth tokens, though. As opposed = to passwords, basic auth tokens, etc., (which are also bearer tokens, = but not OAuth tokens).

A server = receives a bearer token in a request.

Dirk, are you saying the contents of the token = (at that it is a bearer token) is not enough for the = server?

No - I'm sure the server can look at the token and figure = out that it's on OAuth token. All I'm saying is that if it's an OAuth = token, we should call it an OAuth token.
 

Does the server = also need to know that it came from an OAuth flow? If so, I suspect the = server actually needs to know more than that: such as which OAuth flow = was used (eg user-delegation, client-only, assertion, future device flow = etc), or from which authorization server it came. I don=92t think a = scheme name saying =93OAuth=94 helps.

 

--

James = Manger

 
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:40:20 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC74P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given the loose definition of tokens, any token issued as part of the OAuth= flow is an OAuth token. It doesn't mean that an OAuth token cannot be (int= ernally or in practice) using a token format from another protocol. The ide= a that an OAuth token request may issue something other than an OAuth token= is not compatible with the specification language, but this is just termin= ology and has little to no practical implications. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, February 07, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Dirk Balfanz; Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) I don't agree that at token issued by an OAuth server is by definition an O= Auth token. OAuth describes a flow pattern around how tokens may be obtained, etc. Ther= e are many types of tokens that could be employed. OAuth does not describe how SP's interpret and use tokens. It only suggest= s how tokens are presented. Phil phil.hunt@oracle.com On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: What don't you agree with? EHL From: Phillip Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, February 07, 2011 8:29 AM To: Eran Hammer-Lahav Cc: Dirk Balfanz; Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) -1 I don't agree fully here. Phil Sent from my phone. On 2011-02-07, at 0:02, Eran Hammer-Lahav > wrote: Yes, any token issued via OAuth by an authorization server is an OAuth toke= n by definition. Which makes 'token_type=3Doauth2' an silly and confusing s= tatement, given that any token issued via this method is also an OAuth 2.0 = token... but for some reason only one is labeled oauth2. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Dirk Balfanz Sent: Sunday, February 06, 2011 11:16 PM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H > wrote: Dirk said: > FWIW, I agree with Brian - it [the "Bearer" scheme] should say OAuth some= where, because it's an OAuth token. OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, a= nything else. Conversely, any of these tokens can come from a variety of sources: a user-= delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do = with OAuth, a device interaction, manual configuration.... Yes - they're all still all OAuth tokens, though. As opposed to passwords, = basic auth tokens, etc., (which are also bearer tokens, but not OAuth token= s). A server receives a bearer token in a request. Dirk, are you saying the contents of the token (at that it is a bearer toke= n) is not enough for the server? No - I'm sure the server can look at the token and figure out that it's on = OAuth token. All I'm saying is that if it's an OAuth token, we should call = it an OAuth token. Dirk. Does the server also need to know that it came from an OAuth flow? If so, I= suspect the server actually needs to know more than that: such as which OA= uth flow was used (eg user-delegation, client-only, assertion, future devic= e flow etc), or from which authorization server it came. I don't think a sc= heme name saying "OAuth" helps. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC74P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given the= loose definition of tokens, any token issued as part of the OAuth flow is = an OAuth token. It doesn’t mean that an OAuth token cannot be (intern= ally or in practice) using a token format from another protocol. The idea t= hat an OAuth token request may issue something other than an OAuth token is= not compatible with the specification language, but this is just terminolo= gy and has little to no practical implications.

 

EHL

 

From: Phil Hunt [mailto:= phil.hunt@oracle.com]
Sent: Monday, February 07, 2011 10:16 AMTo: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H;= OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme na= me (deadline: 2/10)

<= o:p> 

I don't agree that at token issued= by an OAuth server is by definition an OAuth token.

 

OAut= h describes a flow pattern around how tokens may be obtained, etc. There ar= e many types of tokens that could be employed.

 

OAut= h does not describe how SP's interpret and use tokens.  It only sugges= ts how tokens are presented.

=  

Phil

<= /div>



 

<= p class=3DMsoNormal>

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>What don’t you agree with?

 

EHL

 

<= p class=3DMsoNormal>From: Phil= lip Hunt [mailto:phil.hunt@oracle.com]&= nbsp;
Sent: Monday, February 07, 2011 8:29 AM
To: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
S= ubject: Re: [OAUTH-WG] = Bearer token type and scheme name (deadline: 2/10)

 

-1

 

I = don't agree fully here. 

Phil

 

Sent from my phone. 

Yes, an= y token issued via OAuth by an authorization server is an OAuth token by de= finition. Which makes ‘token_type=3Doauth2’ an silly and confus= ing statement, given that any token issued via this method is also an OAuth= 2.0 token… but for some reason only one is labeled oauth2.

 =

EHL

<= div>

 

From: oauth-boun= ces@ietf.org [mailto:oa= uth-bounces@ietf.org] On= Behalf Of Dirk Balfanz=
Sent: Sunday, Fe= bruary 06, 2011 11:16 PM
To:&= nbsp;Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:= 2/10)

&nb= sp;

 

On Sun, Feb 6, 2011 at= 4:26 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:

Dirk said:<= /o:p>

> FWIW, I agree wit= h Brian - it [the “Bearer” scheme] should say OAuth somewhere, = because it's an OAuth token.

 

OAuth can deliver any variety of bearer token: SAML, JWT, = SWT, opaque id, anything else.

Conversely, any of these tokens can come from a variet= y of sources: a user-delegation OAuth flow, a client-only OAuth flow, a flo= w with nothing to do with OAuth, a device interaction, manual configuration= ….

Ye= s - they're all still all OAuth tokens, though. As opposed to passwords, ba= sic auth tokens, etc., (which are also bearer tokens, but not OAuth tokens)= .

A server receives a bearer token i= n a request.

Dirk, are you saying the contents of the token (at that it is a bearer t= oken) is not enough for the server?

No - I'm sure the server can look at = the token and figure out that it's on OAuth token. All I'm saying is that i= f it's an OAuth token, we should call it an OAuth token.

 

Dirk.

 

Does the server also need to know that it came from an OAuth flow?= If so, I suspect the server actually needs to know more than that: such as= which OAuth flow was used (eg user-delegation, client-only, assertion, fut= ure device flow etc), or from which authorization server it came. I donR= 17;t think a scheme name saying “OAuth” helps.

 

--

James Manger

 

 = ;

_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFC74P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Feb 7 10:41:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2213A6CAB for ; Mon, 7 Feb 2011 10:41:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTPEvfTS5dDf for ; Mon, 7 Feb 2011 10:41:03 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2220E3A6C87 for ; Mon, 7 Feb 2011 10:41:03 -0800 (PST) Received: (qmail 25107 invoked from network); 7 Feb 2011 18:41:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Feb 2011 18:41:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 11:41:02 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , Brian Eaton Date: Mon, 7 Feb 2011 11:40:49 -0700 Thread-Topic: [OAUTH-WG] who is working on security considerations? Thread-Index: AcvG9c9KjnWkK31DSJWybJk3ARtgpQAAKnVw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC77@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D503B71.5060706@lodderstedt.net> In-Reply-To: <4D503B71.5060706@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] who is working on security considerations? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:41:04 -0000 It would probably be helpful to do this work in public. If not via I-Ds (ev= en if very rough) than via github etc. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, February 07, 2011 10:35 AM > To: Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] who is working on security considerations? >=20 > Hi Brian, >=20 > Mark McGloin, Phil Hunt and I are working on a security considerations > document. We plan to submit it to the working group in the next couple of > weeks. Your contribution would be highly appreciated. What would you like > to contribute? >=20 > regards, > Torsten. >=20 > Am 07.02.2011 19:09, schrieb Brian Eaton: > > Has anyone stepped up to start writing security considerations yet? > > > > Now that the organization is back to tracking different use cases > > using different flows, I think it's feasible and would like to > > contribute. > > _______________________________________________ > > 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 Mon Feb 7 11:23:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9353A6985 for ; Mon, 7 Feb 2011 11:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5nmA4721cTN for ; Mon, 7 Feb 2011 11:23:54 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D13E73A6EA2 for ; Mon, 7 Feb 2011 11:23:53 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p17JNrnx029189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 19:23:54 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17JNq03001428; Mon, 7 Feb 2011 19:23:52 GMT Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 1030800541297106631; Mon, 07 Feb 2011 11:23:51 -0800 Received: from [25.65.250.230] (/74.198.150.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 11:23:49 -0800 References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> <55F39129-54B2-42A6-BD85-4939EE3635C0@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC74@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC74@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: multipart/alternative; boundary=Apple-Mail-5-971843227 Message-Id: <7B53EFA7-7F9F-4E39-AB28-2862358E3235@oracle.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Mon, 7 Feb 2011 11:23:38 -0800 To: Eran Hammer-Lahav X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D5046C9.00C9:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:23:55 -0000 --Apple-Mail-5-971843227 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What in oauth other than method of issue makes a token an oauth token? Is money obtained from an ATM suddenly ATM money? What if the tokens are Kerberos tokens. What makes them suddenly oauth token= s? Phil Sent from my phone.=20 On 2011-02-07, at 10:39, Eran Hammer-Lahav wrote: > Given the loose definition of tokens, any token issued as part of the OAut= h flow is an OAuth token. It doesn=E2=80=99t mean that an OAuth token cannot= be (internally or in practice) using a token format from another protocol. T= he idea that an OAuth token request may issue something other than an OAuth t= oken is not compatible with the specification language, but this is just ter= minology and has little to no practical implications. >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, February 07, 2011 10:16 AM > To: Eran Hammer-Lahav > Cc: Dirk Balfanz; Manger, James H; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)= >=20 > =20 >=20 > I don't agree that at token issued by an OAuth server is by definition an O= Auth token. >=20 > =20 >=20 > OAuth describes a flow pattern around how tokens may be obtained, etc. The= re are many types of tokens that could be employed. >=20 > =20 >=20 > OAuth does not describe how SP's interpret and use tokens. It only sugges= ts how tokens are presented. >=20 > =20 >=20 > Phil >=20 > phil.hunt@oracle.com >=20 > =20 >=20 >=20 >=20 >=20 > =20 >=20 > On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: >=20 >=20 >=20 >=20 > What don=E2=80=99t you agree with? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: Phillip Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, February 07, 2011 8:29 AM > To: Eran Hammer-Lahav > Cc: Dirk Balfanz; Manger, James H; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)= >=20 > =20 >=20 > -1 >=20 > =20 >=20 > I don't agree fully here.=20 >=20 > Phil >=20 > =20 >=20 > Sent from my phone.=20 >=20 >=20 > On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote: >=20 > Yes, any token issued via OAuth by an authorization server is an OAuth tok= en by definition. Which makes =E2=80=98token_type=3Doauth2=E2=80=99 an silly= and confusing statement, given that any token issued via this method is als= o an OAuth 2.0 token=E2=80=A6 but for some reason only one is labeled oauth2= . >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz > Sent: Sunday, February 06, 2011 11:16 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)= >=20 > =20 >=20 > =20 >=20 > On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H wrote: >=20 > Dirk said: >=20 > > FWIW, I agree with Brian - it [the =E2=80=9CBearer=E2=80=9D scheme] shou= ld say OAuth somewhere, because it's an OAuth token. >=20 > =20 >=20 > OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, a= nything else. >=20 > Conversely, any of these tokens can come from a variety of sources: a user= -delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do w= ith OAuth, a device interaction, manual configuration=E2=80=A6. >=20 > Yes - they're all still all OAuth tokens, though. As opposed to passwords,= basic auth tokens, etc., (which are also bearer tokens, but not OAuth token= s). >=20 > A server receives a bearer token in a request. >=20 > Dirk, are you saying the contents of the token (at that it is a bearer tok= en) is not enough for the server? >=20 > No - I'm sure the server can look at the token and figure out that it's on= OAuth token. All I'm saying is that if it's an OAuth token, we should call i= t an OAuth token. >=20 > =20 >=20 > Dirk. >=20 > =20 >=20 > Does the server also need to know that it came from an OAuth flow? If so, I= suspect the server actually needs to know more than that: such as which OAu= th flow was used (eg user-delegation, client-only, assertion, future device f= low etc), or from which authorization server it came. I don=E2=80=99t think a= scheme name saying =E2=80=9COAuth=E2=80=9D helps. >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 --Apple-Mail-5-971843227 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
What in oauth other than method of issu= e makes a token an oauth token?

Is money obtained f= rom an ATM suddenly ATM money?

What if the tokens a= re Kerberos tokens. What makes them suddenly oauth tokens?

Phi= l

Sent from my phone. 

Given the loose definition of tokens, any token issued as pa= rt of the OAuth flow is an OAuth token. It doesn=E2=80=99t mean that an OAut= h token cannot be (internally or in practice) using a token format from anot= her protocol. The idea that an OAuth token request may issue something other= than an OAuth token is not compatible with the specification language, but t= his is just terminology and has little to no practical implications.

 

EHL

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Monday, February 07, 2011 10:16 AM
To: Eran Hammer-Lahav
C= c: Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH= -WG] Bearer token type and scheme name (deadline: 2/10)

 

I don't agree that at token issued by an OAuth server is by definition a= n OAuth token.

 

OAuth describes a flow pattern around ho= w tokens may be obtained, etc. There are many types of tokens that could be e= mployed.

 

OAuth does not describe how SP's interpr= et and use tokens.  It only suggests how tokens are presented.

 

Phil

 

On 2= 011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote:



What don=E2=80=99t you agree with?

 

EHL=

 

From: Phillip Hunt [mailto:phi= l.hunt@oracle.com] 
= Sent: Monday, February= 07, 2011 8:29 AM
To: <= /span>Eran Hammer-Lahav
Cc:&= nbsp;Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type= and scheme name (deadline: 2/10)

 

-1

 = ;

I don't agree f= ully here. 

Phil

 

Sent= from my phone. 


On 2011-02-07, at 0:02, Eran Hammer= -Lahav <eran@hueniverse.com> wrote:

Yes, any token issued via OAuth b= y an authorization server is an OAuth token by definition. Which makes =E2=80= =98token_type=3Doauth2=E2=80=99 an silly and confusing statement, given that= any token issued via this method is also an OAuth 2.0 token=E2=80=A6 but fo= r some reason only one is labeled oauth2.

 

<= /div>

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ie= tf.org] On Behalf Of Dirk Balfanz
Sent:=  Sunday, February 06, 2= 011 11:16 PM
To: Manger, James H
Cc: OAuth WG
Subject: = Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

 <= /o:p>

 <= o:p>

On Sun, Feb 6, 2011 at 4:26 A= M, Manger, James H <James.H.Manger@team.telstra= .com> wrote:

Dirk said:

> FWIW, I agree with Brian - it [the =E2=80=9CB= earer=E2=80=9D scheme] should say OAuth somewhere, because it's an OAuth tok= en.

 = ;

OAuth c= an deliver any variety of bearer token: SAML, JWT, SWT, opaque id, anything e= lse.

Conv= ersely, any of these tokens can come from a variety of sources: a user-deleg= ation OAuth flow, a client-only OAuth flow, a flow with nothing to do with O= Auth, a device interaction, manual configuration=E2=80=A6.=

Yes - they're all still all= OAuth tokens, though. As opposed to passwords, basic auth tokens, etc., (wh= ich are also bearer tokens, but not OAuth tokens).

A server receives a bearer token in a request.

Dirk, are you saying the c= ontents of the token (at that it is a bearer token) is not enough for the se= rver?

No - I'm sure the server can look at the token and figure out that i= t's on OAuth token. All I'm saying is that if it's an OAuth token, we should= call it an OAuth token.

 

Di= rk.

 

Does the server also n= eed to know that it came from an OAuth flow? If so, I suspect the server act= ually needs to know more than that: such as which OAuth flow was used (eg us= er-delegation, client-only, assertion, future device flow etc), or from whic= h authorization server it came. I don=E2=80=99t think a scheme name saying =E2= =80=9COAuth=E2=80=9D helps.

 

--

James Manger

 

<= /blockquote>

 

________________________________= _______________
OAuth mailing list
<= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /o:p>

<= o:p> 

= --Apple-Mail-5-971843227-- From torsten@lodderstedt.net Mon Feb 7 12:02:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8683A6EB3 for ; Mon, 7 Feb 2011 12:02:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM2aqHcWYaSa for ; Mon, 7 Feb 2011 12:02:36 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id C1E873A6EA4 for ; Mon, 7 Feb 2011 12:02:35 -0800 (PST) Received: from [79.253.48.145] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PmXIF-00029y-4p; Mon, 07 Feb 2011 21:02:39 +0100 Message-ID: <4D504FDE.4070707@lodderstedt.net> Date: Mon, 07 Feb 2011 21:02:38 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hannes Tschofenig References: <4D4AD58E.9090407@gmx.net> In-Reply-To: <4D4AD58E.9090407@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:02:37 -0000 > Long introduction - here are the documents: > > A) Simple Web Discovery (SWD) > http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt I consider authorization server endpoints and capabilities discovery an important aspect and would be willed to review. > > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ Review. > > C) Token Revocation > http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01 Editor. I will submit another revision based on the WG feedback before IETF-80. > > D) OAuth 2.0 Device Profile > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 I'm very interested to bring this forward (reviewer). > > E) OAuth 2.0 User Experience Extension > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 Review. > > F) Request by Reference ver.1.0 for OAuth 2.0 > http://tools.ietf.org/html/draft-sakimura-oauth-requrl > > G) OAuth Dynamic Client Registration Protocol > http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 Another important aspect I would like to support (reviewer). > > H) OAuth Use Cases > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases co-author > > I) OAuth Client Instance Extension > http://datatracker.ietf.org/doc/draft-richer-oauth-instance/ This is, in my opinion, the same problem domain as http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 and I would suggest to align those I-Ds. > > J) XML Encoding for OAuth 2 > http://datatracker.ietf.org/doc/draft-richer-oauth-xml/ > > K) OAuth 2.0 support for the Kerberos V5 Authentication Protocol > http://datatracker.ietf.org/doc/draft-hardjono-oauth-kerberos > > Please let me know if I have forgotten something. > > I also hope that Torsten is able to submit a security document soon! You can bet on it! regards, Torsten. > > Ciao > Hannes > > PS: You may notice that I haven't placed > http://tools.ietf.org/html/draft-jones-json-web-token-01 on the list > yet since I believe we will get push-back from the IESG on that item > at the moment. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From balfanz@google.com Mon Feb 7 12:10:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DA73A6921 for ; Mon, 7 Feb 2011 12:10:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3018me5NcDHa for ; Mon, 7 Feb 2011 12:10:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 962B93A6EBA for ; Mon, 7 Feb 2011 12:10:00 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p17KA4Fw012755 for ; Mon, 7 Feb 2011 12:10:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297109405; bh=Y792x8geQ8Ta590TVTiXU1BFI5E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=fPhvErNffMCCCPn7UXOOYtYG3ix4r2fW4V8iX5UTbZ3v8L+THrBLarFzQVjk8ptWh nSPtM6/Ap07O6zf7SSB/Q== Received: from iye19 (iye19.prod.google.com [10.241.50.19]) by hpaq13.eem.corp.google.com with ESMTP id p17K9RV3013140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Feb 2011 12:10:02 -0800 Received: by iye19 with SMTP id 19so5084965iye.10 for ; Mon, 07 Feb 2011 12:10:02 -0800 (PST) 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=wzkiU1A2Reme40ftWOS6DsMUR5e8IlwiEz7b0WvI7+8=; b=dTjHI+stBtysVwEFnZ6F6N+JaqWHX8IjXsYkNCARKXlBSc22rNTCh2Gd2XsOUpEGDl 26FDE5MC5VuGDoT154tA== 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=hxkvJ43kQ2txyJGTy4aLlbVpIxfbWNERcU4+AgbvlSDsNLPEVUKVAAvBzZ1a4tK4Cg xngfVp2VT6CdLSVRsXmQ== MIME-Version: 1.0 Received: by 10.231.40.2 with SMTP id i2mr17715846ibe.95.1297109401948; Mon, 07 Feb 2011 12:10:01 -0800 (PST) Received: by 10.231.12.73 with HTTP; Mon, 7 Feb 2011 12:10:01 -0800 (PST) In-Reply-To: <7B53EFA7-7F9F-4E39-AB28-2862358E3235@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> <55F39129-54B2-42A6-BD85-4939EE3635C0@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC74@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7B53EFA7-7F9F-4E39-AB28-2862358E3235@oracle.com> Date: Mon, 7 Feb 2011 12:10:01 -0800 Message-ID: From: Dirk Balfanz To: Phillip Hunt Content-Type: multipart/alternative; boundary=002215048ddf235601049bb6d1be X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:10:02 -0000 --002215048ddf235601049bb6d1be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt wrote: > What in oauth other than method of issue makes a token an oauth token? > > Is money obtained from an ATM suddenly ATM money? > It would be if some vendors would only accept money which came out of ATMs. Which is the situation we're in with OAuth. > > What if the tokens are Kerberos tokens. What makes them suddenly oauth > tokens? > What makes them OAuth tokens is that they came out of an OAuth flow. What makes them OAuth token is that the resource server, upon receiving such a token, will contact the local AS (not the kerberos server) and say "hey, I received this OAuth token, can you please verify it for me". (If the AS chooses to hand out kerberos tokens as OAuth tokens, that's its business). Dirk. > > Phil > > Sent from my phone. > > On 2011-02-07, at 10:39, Eran Hammer-Lahav wrote: > > Given the loose definition of tokens, any token issued as part of the OAu= th > flow is an OAuth token. It doesn=92t mean that an OAuth token cannot be > (internally or in practice) using a token format from another protocol. T= he > idea that an OAuth token request may issue something other than an OAuth > token is not compatible with the specification language, but this is just > terminology and has little to no practical implications. > > > > EHL > > > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Monday, February 07, 2011 10:16 AM > *To:* Eran Hammer-Lahav > *Cc:* Dirk Balfanz; Manger, James H; OAuth WG > *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > > > I don't agree that at token issued by an OAuth server is by definition an > OAuth token. > > > > OAuth describes a flow pattern around how tokens may be obtained, etc. > There are many types of tokens that could be employed. > > > > OAuth does not describe how SP's interpret and use tokens. It only > suggests how tokens are presented. > > > > Phil > > phil.hunt@oracle.com > > > > > > > > On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: > > > > What don=92t you agree with? > > > > EHL > > > > *From:* Phillip Hunt [mailto:phil.hunt@oracle.com] > *Sent:* Monday, February 07, 2011 8:29 AM > *To:* Eran Hammer-Lahav > *Cc:* Dirk Balfanz; Manger, James H; OAuth WG > *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > > > -1 > > > > I don't agree fully here. > > Phil > > > > Sent from my phone. > > > On 2011-02-07, at 0:02, Eran Hammer-Lahav < > eran@hueniverse.com> wrote: > > Yes, any token issued via OAuth by an authorization server is an OAuth > token by definition. Which makes =91token_type=3Doauth2=92 an silly and c= onfusing > statement, given that any token issued via this method is also an OAuth 2= .0 > token=85 but for some reason only one is labeled oauth2. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto: > oauth-bounces@ietf.org] *On Behalf Of *Dirk Balfanz > *Sent:* Sunday, February 06, 2011 11:16 PM > *To:* Manger, James H > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > > > > > On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > Dirk said: > > > FWIW, I agree with Brian - it [the =93Bearer=94 scheme] should say OAut= h > somewhere, because it's an OAuth token. > > > > OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, > anything else. > > Conversely, any of these tokens can come from a variety of sources: a > user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing= to > do with OAuth, a device interaction, manual configuration=85. > > Yes - they're all still all OAuth tokens, though. As opposed to passwords= , > basic auth tokens, etc., (which are also bearer tokens, but not OAuth > tokens). > > A server receives a bearer token in a request. > > Dirk, are you saying the contents of the token (at that it is a bearer > token) is not enough for the server? > > No - I'm sure the server can look at the token and figure out that it's o= n > OAuth token. All I'm saying is that if it's an OAuth token, we should cal= l > it an OAuth token. > > > > Dirk. > > > > Does the server also need to know that it came from an OAuth flow? If so,= I > suspect the server actually needs to know more than that: such as which > OAuth flow was used (eg user-delegation, client-only, assertion, future > device flow etc), or from which authorization server it came. I don=92t t= hink > a scheme name saying =93OAuth=94 helps. > > > > -- > > James Manger > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > --002215048ddf235601049bb6d1be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 7, 2011 at 11:23 AM, Phillip= Hunt <phil.hu= nt@oracle.com> wrote:
What in oauth other than method of issue make= s a token an oauth token?

Is money obtained from a= n ATM suddenly ATM money?

It wo= uld be if some vendors would only accept money which came out of ATMs. Whic= h is the situation we're in with OAuth.
=A0

What if the tokens are Kerberos tokens. What makes them sud= denly oauth tokens?

What makes them OAuth tokens is that= they came out of an OAuth flow. What makes them OAuth token is that the re= source server, upon receiving such a token, will contact the local AS (not = the kerberos server) and say "hey, I received this OAuth token, can yo= u please verify it for me". (If the AS chooses to hand out kerberos to= kens as OAuth tokens, that's its business).

Dirk.
=A0

Phil

Sent from my phone.=A0

On 2011-02-07, at 10= :39, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Given the loose definition of tokens, any token issued as part of the = OAuth flow is an OAuth token. It doesn=92t mean that an OAuth token cannot = be (internally or in practice) using a token format from another protocol. = The idea that an OAuth token request may issue something other than an OAut= h token is not compatible with the specification language, but this is just= terminology and has little to no practical implications.

=A0

EHL

=A0

From: Phil Hunt [mailto:phil.hunt@oracle.co= m]
Sent: Monday, February 07, 2011 10:16 AM
To: Eran Hammer-L= ahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)=

=A0

I don'= t agree that at token issued by an OAuth server is by definition an OAuth t= oken.

=A0

OAuth describes a flow pattern around how tokens may be obtained, etc. T= here are many types of tokens that could be employed.

=A0

= OAuth does not describe how SP's interpret and use tokens. =A0It only s= uggests how tokens are presented.

=A0<= /p>

Phil

=A0

On 2011-02-07, at 9:54 AM, Eran Hammer-Lah= av wrote:



What don=92t you= agree with?

=A0

EHL

<= span style=3D"font-size:11.0pt;color:#1F497D">=A0

From:=A0Phillip Hunt [mailto:phil.hunt@oracle.com]=A0
Sent:=A0Monday, February 07, 2011 8:29 AM
To:= =A0Eran Hammer-Lahav
Cc:=A0Dirk Balfanz= ; Manger, James H; OAuth WG
Subject:=A0Re: [OAUTH-WG= ] Bearer token type and scheme name (deadline: 2/10)

=A0

-1

=A0

=

I don't agree fully here.= =A0

Phil

=A0

Sent from my phone.=A0


On 2011-02-07, at 0= :02, Eran Hammer-Lahav <eran@= hueniverse.com> wrote:

=

= Yes, any token issued via OAuth by an authorization server is an OAuth toke= n by definition. Which makes =91token_type=3Doauth2=92 an silly and confusi= ng statement, given that any token issued via this method is also an OAuth = 2.0 token=85 but for some reason only one is labeled oauth2.

=A0

EHL

<= span style=3D"font-size:11.0pt;color:#1F497D">=A0

From:=A0oauth-b= ounces@ietf.org=A0[mailto:oauth-bounces@ietf.org]=A0O= n Behalf Of=A0Dirk Balfanz
Sent:=A0Sunday, February 06, 2011 11:16 PM
To:=A0Manger, James H
Cc:=A0OAuth WG
<= b>Subject:=A0Re: [OAUTH-WG] Bearer token type and scheme n= ame (deadline: 2/10)

=A0

=A0

On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <James.H.Manger@team.telstra.= com> wrote:

Dirk said:

> FWIW, I agree wi= th Brian - it [the =93Bearer=94 scheme] should say OAuth somewhere, because= it's an OAuth token.

=A0

OAuth can deliver any variety of bearer to= ken: SAML, JWT, SWT, opaque id, anything else.

Conversely, any of these tokens can come from a= variety of sources: a user-delegation OAuth flow, a client-only OAuth flow= , a flow with nothing to do with OAuth, a device interaction, manual config= uration=85.

Yes - they're all still al= l OAuth tokens, though. As opposed to passwords, basic auth tokens, etc., (= which are also bearer tokens, but not OAuth tokens).

A server receives a bearer token in a req= uest.

Dirk, are you= saying the contents of the token (at that it is a bearer token) is not eno= ugh for the server?

No - I'm sure= the server can look at the token and figure out that it's on OAuth tok= en. All I'm saying is that if it's an OAuth token, we should call i= t an OAuth token.

=A0

<= p class=3D"MsoNormal">Dirk.

=A0

Does the server als= o need to know that it came from an OAuth flow? If so, I suspect the server= actually needs to know more than that: such as which OAuth flow was used (= eg user-delegation, client-only, assertion, future device flow etc), or fro= m which authorization server it came. I don=92t think a scheme name saying = =93OAuth=94 helps.

=A0

--

James Manger

=A0

=A0<= /p>

__________________= _____________________________
OAuth mailing list
<= /a>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

=A0

--002215048ddf235601049bb6d1be-- From torsten@lodderstedt.net Mon Feb 7 12:43:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEB83A6EBA for ; Mon, 7 Feb 2011 12:43:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek9BH4VtWOhf for ; Mon, 7 Feb 2011 12:43:55 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by core3.amsl.com (Postfix) with ESMTP id 7C5363A69C0 for ; Mon, 7 Feb 2011 12:43:55 -0800 (PST) Received: from [79.253.48.145] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PmXwB-0006Z6-Ek; Mon, 07 Feb 2011 21:43:55 +0100 Message-ID: <4D50598A.70401@lodderstedt.net> Date: Mon, 07 Feb 2011 21:43:54 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Manger, James H" References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <255B9BB34FB7D647A506DC292726F6E1127D51DE35@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D51DE35@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] WWW-Auth. OAuth scheme (was RE: Bearer token type and scheme name (deadline: 2/10)) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:43:56 -0000 Hi James, Am 06.02.2011 14:07, schrieb Manger, James H: > Phil Hunt said: >> The only other issue would be determining whether the token is obtained via an OAuth profile or> via some default profile. That could be handled with something like: >> >> WWW-Authenticate: Basic realm="somerealm" >> WWW-Authenticate: MAC realm="somerealm" >> WWW-Authenticate: OAuth token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy" >> >> The above would suggest that MAC tokens could be used alone as described in some specification> for "MAC". However, the presence of the OAuth header indicates that MAC and BEARER tokens can> be used in the OAuth pattern. >> >> I think this allows both de-coupling of tokens from OAuth but also informs clients what tokens> can be used with OAuth. >> >> There may be other ways to do this. But it does help with the decoupling. > > I agree that this is a good approach. A separate WWW-Authenticate header indicating that an OAuth delegation flow can be used to get access. I am not sure that you need to token="MAC;BEARER" at this point -- you can get that detail from the token response. I don't think a WWW-Authenticate header is the right way to transmit supplementary data to other WWW-Authenticate headers, such as hints how to obtain credentials (e.g. OAuth). If such data belong to a authentication scheme, then it should be provided with the respective WWW-Authentication header. Alternatively, some other discovery mechanismus could be used, such as host-meta on the resource server. > > Torsten Lodderstedt said: >> I would expect the WWW-Authenticate header to return all the data required to obtain the credentials/tokens, such as >> >> WWW-Authenticate: MAC realm="somerealm", tokenUrl="yyyyy&token_secret=yes" >> WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy" > > I don't really like this approach. > Existing WWW-Auth headers do NOT "return all the data required to obtain the credentials". They assume the client already has the credentials -- perhaps from a config file, perhaps from prompting a user. > I don't think we can add tokenUrl etc to existing (non-OAuth-specific) auth schemes -- the existing specs and existing implementations just don't support it. That shouldn't mean those schemes cannot be used for the authentication part of an OAuth authorization flow, though. > > I would expect a 401 HTTP error response to return all the data required (except any client credentials (if required)) for the client to make a successful request. Or at least the data required for the next step towards making a successful request (eg an authorization URI). What the difference to my proposal? authorizationURL instead of tokenURL? regards, Torsten. > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Feb 7 12:56:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B263B3A6ECD for ; Mon, 7 Feb 2011 12:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlIHDLO1TSX4 for ; Mon, 7 Feb 2011 12:56:14 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 57AC43A6ECC for ; Mon, 7 Feb 2011 12:56:12 -0800 (PST) Received: from [79.253.48.145] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PmY88-0004WH-4y; Mon, 07 Feb 2011 21:56:16 +0100 Message-ID: <4D505C6F.7090209@lodderstedt.net> Date: Mon, 07 Feb 2011 21:56:15 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eric References: <4D39442B.2090408@cs.stanford.edu> In-Reply-To: <4D39442B.2090408@cs.stanford.edu> Content-Type: multipart/alternative; boundary="------------030000010106010002060400" X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:56:15 -0000 This is a multi-part message in MIME format. --------------030000010106010002060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call. What do you think? regards, Torsten. Am 21.01.2011 09:30, schrieb Eric: > Eran, and others, > > A few of us had some discussions on the authorization code flow, as > depicted in Fig. 3 of the current (12th) draft. We think that it is > probably worthwhile to suggest in the specification that an OAuth > implementation SHOULD provide a way for the client to validate the > authorization code before sending it to the Authorization Server > (AS). From what we have heard, this has been done in some of the > current OAuth deployments. There are other people who do not think > this is such a big security risk, although so far no one has objected > that there is some risk here. > > The issue is that according to the current draft, someone who owns a > botnet can locate the redirect URIs of clients that listen on HTTP, > and access them with random authorization codes, and cause HTTPS > connections to be made on the Authorization Server (AS). There are a > few things that the attacker can achieve with this OAuth flow that he > cannot easily achieve otherwise : > > 1. Cost magnification: the attacker incurs the cost of an HTTP > connection and causes an HTTPS connection to be made on the AS; and he > can co-ordinate the timing of such HTTPS connections across multiple > clients relatively easily, if these clients blindly connect to the AS > without first validating the authorization codes received. > > Although the attacker could achieve something similar, say by > including an iframe pointing to the HTTPS URL of the AS in an HTTP web > page and lure web users to visit that page, timing attacks using such > a scheme is (say for the purpose of DDoS) more difficult . > > 2. Connection laundering: if the AS realizes it is flooded by HTTPS > connections with illegitimate codes, it collects no useful information > about the attacker, since the clients act as relays. > > 3. CSRF defense/the 'state' parameter don't completely address this > problem. With such a defense, the attacker might need to incur an > additional HTTP request to obtain a valid CSRF code/ state parameter. > This does cut down the effectiveness of the attack by a factor of 2, > which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 > (the cost factor is estimated to be around 3.5x at > http://www.semicomplete.com/blog/geekery/ssl-latency.html), the > attacker still achieves a cost magnification. > > Our proposal is that the OAuth specification suggests that an OAuth > implementation SHOULD provide a way for the client to validate the > authorization code before sending it to the Authorization Server > (AS). The specifics of how to validate the authorization code may not > need to be part of the core specification. We sketch a design below > for consideration for future implementation. It might be reasonable to > assume that OAuth implementations provide some API for the client to > call to validate and send the authorization code to the AS. There are > two possible schemes for implementation: a) if the client and the AS > already share a symmetric secret, an HMAC key can be created from the > shared secret, and the authorization code will be HMAC'ed and standard > techniques can be employed in the client-side API implementation to > detect replay and forgery attempts on the code; b) an alternative is > for the AS to sign the code using the private key from its SSL > certificate, and for the client API to validate the signature using > the public key. > > > > On Thu, Jan 20, 2011 at 4:56 PM, Eran > Hammer-Lahavwrote: > > Draft -12 is finally out. > > This is almost a complete rewrite of the entire document, with the > primary goal of moving it back to a similar structure used in -05. > I have been thinking about this for a few months and finally came > up with a structure that combines the two approaches. > > The draft includes some major cleanups, significantly simpler > language, reduces repeated prose, and tried to keep prose to the > introduction and normative language in the rest of the > specification. I took out sections that broke the flow, and did my > best to give this a linear narrative that is easy to follow. > > The draft includes the following normative changes: > > o Clarified 'token_type' as case insensitive. > o Authorization endpoint requires TLS when an access token is > issued. > o Removed client assertion credentials, mandatory HTTP Basic > authentication support for client credentials, WWW-Authenticate > header, and the OAuth2 authentication scheme. > o Changed implicit grant (aka user-agent flow) error response > from query to fragment. > o Removed the 'redirect_uri_mismatch' error code since in such > a case, the authorization server must not send the error back to > the client. > o Defined access token type registry. > > I would like to spend the coming week receiving and applying > feedback before requesting a WGLC for everything but the security > considerations section (missing) 2/1. > > EHL > > > > > -----Original Message----- > > From:oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ] On Behalf > > OfInternet-Drafts@ietf.org > > Sent: Thursday, January 20, 2011 4:45 PM > > To:i-d-announce@ietf.org > > Cc:oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > 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-12.txt > > Pages : 46 > > Date : 2011-01-20 > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.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. > _______________________________________________ > 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 --------------030000010106010002060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Eric,

I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call.

What do you think?

regards,
Torsten.

Am 21.01.2011 09:30, schrieb Eric:
Eran, and others,

A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here.

The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise :

1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received.

Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web  users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult .

2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays. 

3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the attacker still achieves a cost magnification.

Our proposal is that the OAuth specification suggests that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key.

 

On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Draft -12 is finally out.

This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

The draft includes the following normative changes:

  o  Clarified 'token_type' as case insensitive.
  o  Authorization endpoint requires TLS when an access token is issued.
  o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
  o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
  o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
  o  Defined access token type registry.

I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Thursday, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
>
> 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-12.txt
>       Pages           : 46
>       Date            : 2011-01-20
>
> This specification describes the OAuth 2.0 authorization protocol.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.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.
_______________________________________________
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
--------------030000010106010002060400-- From kristoffer.gronowski@ericsson.com Mon Feb 7 13:10:58 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F503A6F36 for ; Mon, 7 Feb 2011 13:10:58 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjg9Y7IDS5Be for ; Mon, 7 Feb 2011 13:10:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id C7F1D3A6F2C for ; Mon, 7 Feb 2011 13:10:55 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p17LB0H8019597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Feb 2011 15:11:00 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 7 Feb 2011 16:10:59 -0500 From: Kristoffer Gronowski To: "oauth@ietf.org" Date: Mon, 7 Feb 2011 16:10:58 -0500 Thread-Topic: Re: [OAUTH-WG] New Working Group Items? Thread-Index: AcvHC4Ppr+2HhX4nRrGGt6pmylMQxw== Message-ID: 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_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50440EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:10:58 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50440EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Torsten! Great that you compiled the list on WG items. IMO there is one item missing and that is to create an optional formal inte= rface between the authorization server and the protected resource. It could increase the productivity of creating the oauth protected web serv= ices when the auth server can be treated as an off the shelf piece of code. Then it would be up to the auth server to also provide an number of other e= xtension like the discovery, token revocation and other. The next most important for me is the discovery but here I would rather wan= t to tie on to existing technologies that already describe REST resources l= ike WADL. So that the Oauth discovery metadata just deals with two levels of metadata= . First being more static information about the oauth server that is author= ative over the protected resource. Second would be the endpoint specific authorization data about the resource= what kind of scopes are required for me to fulfill a successful request. B= ut here it needs to be more innovative since it might be a different answer= if I am trying to do a HTTP GET then what would be needed if I am trying t= o do a HTTP DELETE request on a protected resource. We are actually trying to experiment with the two different API for auth se= rver <-> protected resource IF and for resource discovery to get hands on e= xperience on how they could look like. So if other sees the same value we would be happy to collaborate and try to= contribute it becoming something agreed upon within this WG. The good part is that all of our experiments are shared in open source so o= thers could also join in and we do not have any strong opinion that it has = to be solved our way. BR Kristoffer --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50440EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Torsten!
 
Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional formal= interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected web= services when the auth server can be treated as an off the shelf piece of = code.
Then it would be up to the auth server to also provide an number of ot= her extension like the discovery, token revocation and other.
 
The next most important for me is the discovery but here I would rathe= r want to tie on to existing technologies that already describe REST resour= ces like WADL.
So that the Oauth discovery metadata just deals with two levels of met= adata. First being more static information about the oauth server that is a= uthorative over the protected resource.
Second would be the endpoint specific authorization data about the res= ource what kind of scopes are required for me to fulfill a successful reque= st. But here it needs to be more innovative since it might be a different a= nswer if I am trying to do a HTTP GET then what would be needed if I am trying to do a HTTP DELETE request on= a protected resource.
 
We are actually trying to experiment with the two different API for au= th server <-> protected resource IF and for resource discovery to get= hands on experience on how they could look like.
So if other sees the same value we would be happy to collaborate and t= ry to contribute it becoming something agreed upon within this WG.
The good part is that all of our experiments are shared in open source= so others could also join in and we do not have any strong opinion that it= has to be solved our way.
 
BR Kristoffer
 
 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50440EUSAACMS0701e_-- From torsten@lodderstedt.net Mon Feb 7 13:14:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D2A3A69F2 for ; Mon, 7 Feb 2011 13:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZORFih7OI40S for ; Mon, 7 Feb 2011 13:14:18 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 9976D3A6ECA for ; Mon, 7 Feb 2011 13:14:17 -0800 (PST) Received: from [79.253.48.145] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PmYPc-0004hY-Ko; Mon, 07 Feb 2011 22:14:20 +0100 Message-ID: <4D5060AB.2010603@lodderstedt.net> Date: Mon, 07 Feb 2011 22:14:19 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kristoffer Gronowski References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303000405050906030200" X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:14:18 -0000 This is a multi-part message in MIME format. --------------060303000405050906030200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kristoffer, Hannes compiled the list :-) regards, Torsten. Am 07.02.2011 22:10, schrieb Kristoffer Gronowski: > Hi Torsten! > Great that you compiled the list on WG items. > IMO there is one item missing and that is to create an optional formal > interface between the authorization server and the protected resource. > It could increase the productivity of creating the oauth protected web > services when the auth server can be treated as an off the shelf piece > of code. > Then it would be up to the auth server to also provide an number of > other extension like the discovery, token revocation and other. > The next most important for me is the discovery but here I would > rather want to tie on to existing technologies that already describe > REST resources like WADL. > So that the Oauth discovery metadata just deals with two levels of > metadata. First being more static information about the oauth server > that is authorative over the protected resource. > Second would be the endpoint specific authorization data about the > resource what kind of scopes are required for me to fulfill a > successful request. But here it needs to be more innovative since it > might be a different answer if I am trying to do a HTTP GET then what > would be needed if I am trying to do a HTTP DELETE request on a > protected resource. > We are actually trying to experiment with the two different API for > auth server <-> protected resource IF and for resource discovery to > get hands on experience on how they could look like. > So if other sees the same value we would be happy to collaborate and > try to contribute it becoming something agreed upon within this WG. > The good part is that all of our experiments are shared in open source > so others could also join in and we do not have any strong opinion > that it has to be solved our way. > BR Kristoffer > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060303000405050906030200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kristoffer,

Hannes compiled the list :-)

regards,
Torsten.

Am 07.02.2011 22:10, schrieb Kristoffer Gronowski:
Hi Torsten!
 
Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional formal interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected web services when the auth server can be treated as an off the shelf piece of code.
Then it would be up to the auth server to also provide an number of other extension like the discovery, token revocation and other.
 
The next most important for me is the discovery but here I would rather want to tie on to existing technologies that already describe REST resources like WADL.
So that the Oauth discovery metadata just deals with two levels of metadata. First being more static information about the oauth server that is authorative over the protected resource.
Second would be the endpoint specific authorization data about the resource what kind of scopes are required for me to fulfill a successful request. But here it needs to be more innovative since it might be a different answer if I am trying to do a HTTP GET then what would be needed if I am trying to do a HTTP DELETE request on a protected resource.
 
We are actually trying to experiment with the two different API for auth server <-> protected resource IF and for resource discovery to get hands on experience on how they could look like.
So if other sees the same value we would be happy to collaborate and try to contribute it becoming something agreed upon within this WG.
The good part is that all of our experiments are shared in open source so others could also join in and we do not have any strong opinion that it has to be solved our way.
 
BR Kristoffer
 
 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060303000405050906030200-- From kristoffer.gronowski@ericsson.com Mon Feb 7 13:19:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91B03A6F3D for ; Mon, 7 Feb 2011 13:19:31 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9vsyRYM1fnN for ; Mon, 7 Feb 2011 13:19:30 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id BEDE63A6F3B for ; Mon, 7 Feb 2011 13:19:30 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p17M34gF028953; Mon, 7 Feb 2011 16:03:08 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 7 Feb 2011 16:19:27 -0500 From: Kristoffer Gronowski To: Torsten Lodderstedt Date: Mon, 7 Feb 2011 16:19:25 -0500 Thread-Topic: [OAUTH-WG] New Working Group Items? Thread-Index: AcvHDANkU80lzUxDSdWGvf+tCTy2pQAAB7zQ Message-ID: References: <4D5060AB.2010603@lodderstedt.net> In-Reply-To: <4D5060AB.2010603@lodderstedt.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_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50455EUSAACMS0701e_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:19:31 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50455EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, sorry did not want to steal anyone's thunder! Just a honest indentation mistake, great list Hannes. BR Kristoffer ________________________________ From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Monday, February 07, 2011 1:14 PM To: Kristoffer Gronowski Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Working Group Items? Hi Kristoffer, Hannes compiled the list :-) regards, Torsten. Am 07.02.2011 22:10, schrieb Kristoffer Gronowski: Hi Torsten! Great that you compiled the list on WG items. IMO there is one item missing and that is to create an optional formal inte= rface between the authorization server and the protected resource. It could increase the productivity of creating the oauth protected web serv= ices when the auth server can be treated as an off the shelf piece of code. Then it would be up to the auth server to also provide an number of other e= xtension like the discovery, token revocation and other. The next most important for me is the discovery but here I would rather wan= t to tie on to existing technologies that already describe REST resources l= ike WADL. So that the Oauth discovery metadata just deals with two levels of metadata= . First being more static information about the oauth server that is author= ative over the protected resource. Second would be the endpoint specific authorization data about the resource= what kind of scopes are required for me to fulfill a successful request. B= ut here it needs to be more innovative since it might be a different answer= if I am trying to do a HTTP GET then what would be needed if I am trying t= o do a HTTP DELETE request on a protected resource. We are actually trying to experiment with the two different API for auth se= rver <-> protected resource IF and for resource discovery to get hands on e= xperience on how they could look like. So if other sees the same value we would be happy to collaborate and try to= contribute it becoming something agreed upon within this WG. The good part is that all of our experiments are shared in open source so o= thers could also join in and we do not have any strong opinion that it has = to be solved our way. BR Kristoffer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50455EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Oops, sorry did not want to steal anyone's=20 thunder!
Just a honest indentation mistake, great list=20 Hannes.
 
BR Kristoffer

From: Torsten Lodderstedt=20 [mailto:torsten@lodderstedt.net]
Sent: Monday, February 07, 2011= 1:14=20 PM
To: Kristoffer Gronowski
Cc:=20 oauth@ietf.org
Subject: Re: [OAUTH-WG] New Working Group=20 Items?

Hi Kristoffer,

Hannes compiled the list=20 :-)

regards,
Torsten.

Am 07.02.2011 22:10, schrieb Kristof= fer=20 Gronowski:=20
Hi Torsten!
 
Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional form= al=20 interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected w= eb=20 services when the auth server can be treated as an off the shelf piece of= =20 code.
Then it would be up to the auth server to also provide an number of = other=20 extension like the discovery, token revocation and other.
 
The next most important for me is the discovery but here I would rat= her=20 want to tie on to existing technologies that already describe REST resour= ces=20 like WADL.
So that the Oauth discovery metadata just deals with two levels of=20 metadata. First being more static information about the oauth server that= is=20 authorative over the protected resource.
Second would be the endpoint specific authorization data about the=20 resource what kind of scopes are required for me to fulfill a successful= =20 request. But here it needs to be more innovative since it might be a diff= erent=20 answer if I am trying to do a HTTP GET then what would be needed if I am= =20 trying to do a HTTP DELETE request on a protected resource.
 
We are actually trying to experiment with the two different API for = auth=20 server <-> protected resource IF and for resource discovery to get = hands=20 on experience on how they could look like.
So if other sees the same value we would be happy to collaborate and= try=20 to contribute it becoming something agreed upon within this WG.
The good part is that all of our experiments are shared in open sour= ce so=20 others could also join in and we do not have any strong opinion that it h= as to=20 be solved our way.
 
BR Kristoffer
 

_______________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_C0AC8FAB6849AB4FADACCC70A949E2F1092BD50455EUSAACMS0701e_-- From phil.hunt@oracle.com Mon Feb 7 14:03:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E4D3A6E39 for ; Mon, 7 Feb 2011 14:03:05 -0800 (PST) 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.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqXWg50ZvoH7 for ; Mon, 7 Feb 2011 14:03:04 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2842B3A6E19 for ; Mon, 7 Feb 2011 14:03:04 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p17M31qO015605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 22:03:03 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17M2xnj025279; Mon, 7 Feb 2011 22:03:00 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 1031332071297116175; Mon, 07 Feb 2011 14:02:55 -0800 Received: from [192.168.0.102] (/24.85.255.91) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 14:02:54 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-22-981391505 From: Phil Hunt In-Reply-To: Date: Mon, 7 Feb 2011 14:02:51 -0800 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D45802A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB3526@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D51DE34@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFB5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC55@P3PW5EX1MB01.EX1.SECURESERVER.NET> <55F39129-54B2-42A6-BD85-4939EE3635C0@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC74@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7B53EFA7-7F9F-4E39-AB28-2862358E3235@oracle.com> To: Dirk Balfanz X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D506C15.022C:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:03:06 -0000 --Apple-Mail-22-981391505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Phil phil.hunt@oracle.com On 2011-02-07, at 12:10 PM, Dirk Balfanz wrote: >=20 >=20 > On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt = wrote: > What in oauth other than method of issue makes a token an oauth token? >=20 > Is money obtained from an ATM suddenly ATM money? >=20 > It would be if some vendors would only accept money which came out of = ATMs. Which is the situation we're in with OAuth. My analogy was more of the form that you can go anywhere in the world = and use an ATM to obtain 'local currency'. All ATMs work more or less = the same. The vendors around that ATM accept local currency. The same = is true here. Tokens are issued for a particular security domain. The = domain dictates the token types they want to use. Those tokens may turn = out to be proprietary, or based entirely on another standard (e.g. = Kerberos). =20 > =20 >=20 > What if the tokens are Kerberos tokens. What makes them suddenly oauth = tokens? >=20 > What makes them OAuth tokens is that they came out of an OAuth flow. = What makes them OAuth token is that the resource server, upon receiving = such a token, will contact the local AS (not the kerberos server) and = say "hey, I received this OAuth token, can you please verify it for me". = (If the AS chooses to hand out kerberos tokens as OAuth tokens, that's = its business). I don't see how the method of issue defines what something is. To do so = implies that there must be a specification that defines an OAuth token. = Method of verification and use of a token should be defined within the = definition of the token. It sounds to me like people are after a universal token. Is that the = case? I would prefer a scheme where the right type of token can be used for = the job at hand. This means artifacts, bearer, MAC, etc can all be used. = Even potentially Kerberos. It all depends on security requirements of = the use case. >=20 > Dirk. > =20 >=20 > Phil >=20 > Sent from my phone.=20 >=20 > On 2011-02-07, at 10:39, Eran Hammer-Lahav = wrote: >=20 >> Given the loose definition of tokens, any token issued as part of the = OAuth flow is an OAuth token. It doesn=92t mean that an OAuth token = cannot be (internally or in practice) using a token format from another = protocol. The idea that an OAuth token request may issue something other = than an OAuth token is not compatible with the specification language, = but this is just terminology and has little to no practical = implications. >>=20 >> =20 >> EHL >>=20 >> =20 >> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Monday, February 07, 2011 10:16 AM >> To: Eran Hammer-Lahav >> Cc: Dirk Balfanz; Manger, James H; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) >>=20 >> =20 >> I don't agree that at token issued by an OAuth server is by = definition an OAuth token. >>=20 >> =20 >> OAuth describes a flow pattern around how tokens may be obtained, = etc. There are many types of tokens that could be employed. >>=20 >> =20 >> OAuth does not describe how SP's interpret and use tokens. It only = suggests how tokens are presented. >>=20 >> =20 >> Phil >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >>=20 >> =20 >> On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: >>=20 >>=20 >>=20 >>=20 >> What don=92t you agree with? >>=20 >> =20 >> EHL >>=20 >> =20 >> From: Phillip Hunt [mailto:phil.hunt@oracle.com]=20 >> Sent: Monday, February 07, 2011 8:29 AM >> To: Eran Hammer-Lahav >> Cc: Dirk Balfanz; Manger, James H; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) >>=20 >> =20 >> -1 >>=20 >> =20 >> I don't agree fully here.=20 >>=20 >> Phil >>=20 >> =20 >> Sent from my phone.=20 >>=20 >>=20 >> On 2011-02-07, at 0:02, Eran Hammer-Lahav = wrote: >>=20 >> Yes, any token issued via OAuth by an authorization server is an = OAuth token by definition. Which makes =91token_type=3Doauth2=92 an = silly and confusing statement, given that any token issued via this = method is also an OAuth 2.0 token=85 but for some reason only one is = labeled oauth2. >>=20 >> =20 >> EHL >>=20 >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Dirk Balfanz >> Sent: Sunday, February 06, 2011 11:16 PM >> To: Manger, James H >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: = 2/10) >>=20 >> =20 >> =20 >> On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H = wrote: >>=20 >> Dirk said: >>=20 >> > FWIW, I agree with Brian - it [the =93Bearer=94 scheme] should say = OAuth somewhere, because it's an OAuth token. >>=20 >> =20 >> OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque = id, anything else. >>=20 >> Conversely, any of these tokens can come from a variety of sources: a = user-delegation OAuth flow, a client-only OAuth flow, a flow with = nothing to do with OAuth, a device interaction, manual configuration=85. >>=20 >> Yes - they're all still all OAuth tokens, though. As opposed to = passwords, basic auth tokens, etc., (which are also bearer tokens, but = not OAuth tokens). >>=20 >> A server receives a bearer token in a request. >>=20 >> Dirk, are you saying the contents of the token (at that it is a = bearer token) is not enough for the server? >>=20 >> No - I'm sure the server can look at the token and figure out that = it's on OAuth token. All I'm saying is that if it's an OAuth token, we = should call it an OAuth token. >>=20 >> =20 >> Dirk. >>=20 >> =20 >> Does the server also need to know that it came from an OAuth flow? If = so, I suspect the server actually needs to know more than that: such as = which OAuth flow was used (eg user-delegation, client-only, assertion, = future device flow etc), or from which authorization server it came. I = don=92t think a scheme name saying =93OAuth=94 helps. >>=20 >> =20 >> -- >>=20 >> James Manger >>=20 >> =20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> =20 >=20 --Apple-Mail-22-981391505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2011-02-07, at 12:10 PM, Dirk Balfanz wrote:



On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt = <phil.hunt@oracle.com> = wrote:
What in oauth other than method of issue = makes a token an oauth token?

Is money obtained = from an ATM suddenly ATM = money?

It would be if some = vendors would only accept money which came out of ATMs. Which is the = situation we're in with OAuth.

My = analogy was more of the form that you can go anywhere in the world and = use an ATM to obtain 'local currency'. All ATMs work more or less the = same.  The vendors around that ATM accept local currency. The same = is true here. Tokens are issued for a particular security domain. The = domain dictates the token types they want to use. Those tokens may turn = out to be proprietary, or based entirely on another standard (e.g. = Kerberos).
 
 

What= if the tokens are Kerberos tokens. What makes them suddenly oauth = tokens?

What makes them OAuth tokens is = that they came out of an OAuth flow. What makes them OAuth token is that = the resource server, upon receiving such a token, will contact the local = AS (not the kerberos server) and say "hey, I received this OAuth token, = can you please verify it for me". (If the AS chooses to hand out = kerberos tokens as OAuth tokens, that's its = business).

I don't see how the = method of issue defines what something is.  To do so implies that = there must be a specification that defines an OAuth token.  Method = of verification and use of a token should be defined within the = definition of the token.

It sounds to me like = people are after a universal token. Is that the = case?

I would prefer a scheme where the right = type of token can be used for the job at hand. This means artifacts, = bearer, MAC, etc can all be used. Even potentially Kerberos. It all = depends on security requirements of the use = case.


Dirk.
 

Phil

Sent from my = phone. 

On 2011-02-07, at = 10:39, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:

Given the loose definition of = tokens, any token issued as part of the OAuth flow is an OAuth token. It = doesn=92t mean that an OAuth token cannot be (internally or in practice) = using a token format from another protocol. The idea that an OAuth token = request may issue something other than an OAuth token is not compatible = with the specification language, but this is just terminology and has = little to no practical implications.

 

EHL

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Monday, February 07, 2011 10:16 AM
To: Eran = Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth = WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name = (deadline: 2/10)

 

I don't agree that at token issued by an OAuth = server is by definition an OAuth token.

 

OAuth describes a flow pattern around how tokens may = be obtained, etc. There are many types of tokens that could be = employed.

 

OAuth does not describe how SP's interpret and use = tokens.  It only suggests how tokens are = presented.

 

Phil

 = ;

On 2011-02-07, at 9:54 AM, Eran = Hammer-Lahav wrote:



What don=92t you agree = with?

 

EHL

 

From: Phillip Hunt [mailto:phil.hunt@oracle.com] 
Sent: Monday, February 07, 2011 8:29 = AM
To: Eran = Hammer-Lahav
Cc: Dirk Balfanz; Manger, James = H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer = token type and scheme name (deadline: 2/10)

 

-1

 

I don't agree fully here. 

Phil

 

Sent from my = phone. 


On 2011-02-07, at 0:02, Eran = Hammer-Lahav <eran@hueniverse.com> wrote:

Yes, = any token issued via OAuth by an authorization server is an OAuth token = by definition. Which makes =91token_type=3Doauth2=92 an silly and = confusing statement, given that any token issued via this method is also = an OAuth 2.0 token=85 but for some reason only one is labeled = oauth2.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Dirk Balfanz
Sent: Sunday, February 06, 2011 11:16 = PM
To: Manger, James = H
Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Bearer token type = and scheme name (deadline: 2/10)

 
 

On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H = <James.H.Manger@team.telstra.com> wrote:

Dirk = said:

> FWIW, = I agree with Brian - it [the =93Bearer=94 scheme] should say OAuth = somewhere, because it's an OAuth token.

 

OAuth can deliver any variety of bearer token: = SAML, JWT, SWT, opaque id, anything else.

Conversely, any of these tokens can = come from a variety of sources: a user-delegation OAuth flow, a = client-only OAuth flow, a flow with nothing to do with OAuth, a device = interaction, manual configuration=85.

Yes - they're all still all = OAuth tokens, though. As opposed to passwords, basic auth tokens, etc., = (which are also bearer tokens, but not OAuth = tokens).

A server receives a bearer token in a = request.

Dirk, = are you saying the contents of the token (at that it is a bearer token) = is not enough for the server?

No - I'm sure = the server can look at the token and figure out that it's on OAuth = token. All I'm saying is that if it's an OAuth token, we should call it = an OAuth token.

 

Dirk.

 

Does the server = also need to know that it came from an OAuth flow? If so, I suspect the = server actually needs to know more than that: such as which OAuth flow = was used (eg user-delegation, client-only, assertion, future device flow = etc), or from which authorization server it came. I don=92t think a = scheme name saying =93OAuth=94 helps.

 

--

James Manger

 
 

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

 


= --Apple-Mail-22-981391505-- From wmills@yahoo-inc.com Mon Feb 7 14:06:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7EE3A6E5B for ; Mon, 7 Feb 2011 14:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.263 X-Spam-Level: X-Spam-Status: No, score=-17.263 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3lNjE12yUFO for ; Mon, 7 Feb 2011 14:06:48 -0800 (PST) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 9DDAE3A6A48 for ; Mon, 7 Feb 2011 14:06:48 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p17M6LgC081938; Mon, 7 Feb 2011 14:06:21 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Mon, 7 Feb 2011 14:06:20 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Mon, 7 Feb 2011 14:06:19 -0800 Thread-Topic: draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu50HMZE3ElIG/6SjSQTXJNzEiUCwLgpcKAAADDeiAAbzag8A== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFA9C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFA9C@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_FFDFD7371D517847AD71FBB08F9A31563849221CF3SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:06:53 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563849221CF3SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nevermind. I have found the source of my confusion, and it was self-inflic= ted. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Saturday, February 05, 2011 9:00 AM To: William Mills; OAuth WG Subject: RE: draft-hammer-oauth-v2-mac-token-02 I'm confused. Can you cut-and-paste the problematic text? From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Saturday, February 05, 2011 8:42 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: draft-hammer-oauth-v2-mac-token-02 Reading through and looking at your example in 1.1 I think you don't have e= nough lines. Your text specified 9 elements to be signed, but you only hav= e 7 lines in the text to be signed. The way I read the text you should hav= e 9 elements followed by newlines, which can be empty, but the newlines sho= uld be there. -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 21, 2011 5:10 PM To: OAuth WG Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 New version includes the following changes: o Added body-hash support. o Updated OAuth 2.0 reference to -12 and added token type registration = template. o Removed error and error URI attributes (codes were just a duplication= of the HTTP status codes). Feedback would be greatly appreciated. EHL --_000_FFDFD7371D517847AD71FBB08F9A31563849221CF3SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nevermind.  I have = found the source of my confusion, and it was self-inflicted.

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Saturday, February 05, 2011 9:00 AM
To: William Mills; OAuth WG
Subject: RE: draft-hammer-oauth-v2-mac-token-02

 

I’m confused. Can = you cut-and-paste the problematic text?

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Saturday, February 05, 2011 8:42 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: draft-hammer-oauth-v2-mac-token-02

 

Reading through and look= ing at your example in 1.1 I think you don’t have enough lines.  Your t= ext specified 9 elements to be signed, but you only have 7 lines in the text to= be signed.  The way I read the text you should have 9 elements followed b= y newlines, which can be empty, but the newlines should be there.<= /span>

 =

-bill<= /p>

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 21, 2011 5:10 PM
To: OAuth WG
Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

 

http= ://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

 

New version includes the following changes:=

 

   o  Added body-hash support.

   o  Updated OAuth 2.0 reference to -= 12 and added token type registration template.

   o  Removed error and error URI attributes (codes were just a duplication of the HTTP status codes).

 

Feedback would be greatly appreciated.

 

EHL

 

 

--_000_FFDFD7371D517847AD71FBB08F9A31563849221CF3SP2EX07VS06ds_-- From wmills@yahoo-inc.com Mon Feb 7 14:50:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76503A6FAE for ; Mon, 7 Feb 2011 14:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.43 X-Spam-Level: X-Spam-Status: No, score=-17.43 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI2lIRChxQNZ for ; Mon, 7 Feb 2011 14:50:05 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id A690E3A6EFE for ; Mon, 7 Feb 2011 14:50:01 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p17MnqMR024522; Mon, 7 Feb 2011 14:49:52 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Mon, 7 Feb 2011 14:49:52 -0800 From: William Mills To: Torsten Lodderstedt Date: Mon, 7 Feb 2011 14:49:50 -0800 Thread-Topic: Discovery RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4yg Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> In-Reply-To: <4D4D9514.2090604@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:50:09 -0000 OK. So then the question is the right way to communicate token endpoints. Is i= t cleaner/preferred to have everything in the WWW-Authenticate header, or t= o break things out so we're not stuffing a lot into those headers and repea= ting outselves? So, all in one would be: WWW-Authenticate: MAC realm=3D"somerealm" token_url=3D"http://login.exa= mple.com/token" auth_url=3D"http://login.example.com/webauth" Broken out might be: WWW-Authenticate: MAC realm=3D"OAuth2" Link: rel=3D"oath2-to= ken" Link: rel=3D"oath2-auth" -bill > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Saturday, February 05, 2011 10:21 AM > To: William Mills > Cc: Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > that's not the way WWW-Authenticate headers are used today. Instead the > resource server should return a single WWW-Authenticate header _per_ > supported authentication scheme, such as >=20 > WWW-Authenticate: MAC realm=3D"somerealm" > WWW-Authenticate: BEARER realm=3D"somerealm" >=20 > furthermore, I think interdependencies among WWW-Authenticate headers > as suggested by Phil >=20 > WWW-Authenticate: OAuth > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyy >=20 > could be rather fragile. >=20 > I would expect the WWW-Authenticate header to return all the data > required to obtain the credentials/tokens, such as >=20 > WWW-Authenticate: MAC realm=3D"somerealm", > tokenUrl=3D"yyyyy&token_secret=3Dyes" > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" >=20 > Which raises the question whether the coupling between authentication > schemes and the OAuth2 core protocol is stronger than assumed. >=20 > please als see http://www.ietf.org/mail- > archive/web/oauth/current/msg04988.html >=20 > regards, > Torsten. >=20 > Am 04.02.2011 22:39, schrieb William Mills: >=20 > > I was thinking along the lines of simply returning the HTTP > Authorization header schemes that are supported. In the OAuth 2 > context that would be > > > > WWW-Authenticate: 401 error=3D"blah blah blah" auth_types=3D"Bearer > MAC Basic" > > > > The client has to be aware of the authentication scheme names. > > > > -bill > > > >> -----Original Message----- > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > >> Sent: Friday, February 04, 2011 1:14 PM > >> To: William Mills > >> Cc: Marius Scurtescu; OAuth WG > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > >> 2/10) > >> > >> I agree, that is still to be defined. There seems to be some push > back > >> on discovery, but this is likely warranted. If only because web > sites > >> may have both browser clients and app clients. > >> > >> In a previous message, I did suggest the web site return HTTP 401 as > >> below... > >>>> 401 Unauthorized > >>>> WWW-Authenticate: Basic realm=3D"tokenSvc" > >>>> WWW-Authenticate: Digest realm=3D"tokenSvc" > >>>> WWW-Authenticate: Form > >> url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" > >> > >> It could also include other items for "MAC", etc. > >> > >> The only other issue would be determining whether the token is > obtained > >> via an OAuth profile or via some default profile. That could be > >> handled with something like: > >> > >> WWW-Authenticate: Basic realm=3D"somerealm" > >> WWW-Authenticate: MAC realm=3D"somerealm" > >> WWW-Authenticate: OAuth > >> token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy" > >> > >> The above would suggest that MAC tokens could be used alone as > >> described in some specification for "MAC". However, the presence of > >> the OAuth header indicates that MAC and BEARER tokens can be used in > >> the OAuth pattern. > >> > >> I think this allows both de-coupling of tokens from OAuth but also > >> informs clients what tokens can be used with OAuth. > >> > >> There may be other ways to do this. But it does help with the > >> decoupling. > >> > >> Phil > >> phil.hunt@oracle.com > >> > >> > >> > >> > >> On 2011-02-04, at 11:44 AM, William Mills wrote: > >> > >>> I was thinking more about how the client knows what to use. The > >> ubiquitous "service documentation" may come in to play here. Some > form > >> of serv ice discovery/webfinger thing could also be used. > >>>> -----Original Message----- > >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] > >>>> Sent: Friday, February 04, 2011 11:37 AM > >>>> To: William Mills > >>>> Cc: Marius Scurtescu; OAuth WG > >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > (deadline: > >>>> 2/10) > >>>> > >>>> Yes. This should be defined in each token type specification. > >>>> > >>>> Phil > >>>> phil.hunt@oracle.com > >>>> > >>>> > >>>> > >>>> > >>>> On 2011-02-04, at 11:29 AM, William Mills wrote: > >>>> > >>>>> The only challenge is to know what scheme to use and what the > >> nuances > >>>> are of how to present the credential. > >>>>>> -----Original Message----- > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf > >>>>>> Of Phil Hunt > >>>>>> Sent: Friday, February 04, 2011 9:42 AM > >>>>>> To: Marius Scurtescu > >>>>>> Cc: OAuth WG > >>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > >> (deadline: > >>>>>> 2/10) > >>>>>> > >>>>>> OAuth should be able to support other token schemes. > >>>>>> > >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, or > >>>>>> whatever. > >>>>>> > >>>>>> Phil > >>>>>> phil.hunt@oracle.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > >>>>>> > >>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > >>>>>> wrote: > >>>>>>>> Hey Marius, > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM > >>>>>>>>> To: Eran Hammer-Lahav > >>>>>>>>> Cc: OAuth WG > >>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > >>>>>> (deadline: > >>>>>>>>> 2/10) > >>>>>>>>> > >>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes > >>>>>>>>>> > >>>>>>>>>> Define a single authentication scheme for all token types > with > >>>>>> some > >>>>>>>>>> attribute used to detect which scheme is actually being > used. > >>>>>>>>>> > >>>>>>>>>> Benefits: > >>>>>>>>>> > >>>>>>>>>> - single scheme, reuse of the 1.0 pattern. > >>>>>>>>>> > >>>>>>>>>> Downsides: > >>>>>>>>>> > >>>>>>>>>> - requires a new registry for authentication header > >> parameters. > >>>>>>>>> How is this different from option 1? Wouldn't that need some > >>>>>> registry? > >>>>>>>> #1 relies on the existing practice of creating HTTP scheme > names > >>>> (no > >>>>>> current registry but httpbis might be creating one), as well as > >> the > >>>> -12 > >>>>>> token type registry. Using a sub-scheme means you also need a > >>>> registry > >>>>>> for the header attributes that each token type will need (unless > >> you > >>>>>> just don't care about using the same attribute name for > different > >>>>>> needs). > >>>>>>> Sure, there is no registry for schemes yet, but we would still > >> need > >>>>>>> some coordination. The fact that a sub-scheme needs a registry > >> that > >>>>>> we > >>>>>>> control is a benefit not a downside IMO. > >>>>>>> > >>>>>>> > >>>>>>>>>> - schemes are not easily reusable outside OAuth. > >>>>>>>>> Sure. But I really don't see this group trying to create > >> generic > >>>>>> authentication > >>>>>>>>> schemes. > >>>>>>>> MAC is exactly that. > >>>>>>> May or may not be. My point is that this group is not focused > on > >>>>>>> creating generic authentication schemes. Are you aware of any > >> other > >>>>>>> protocols that might use MAC or BEARER? Are we willing to put > in > >>>> the > >>>>>>> effort to create generic schemes? Is it our charter? > >>>>>>> > >>>>>>> > >>>>>>>>>> - existing frameworks usually switch on scheme name, not on > >> sub > >>>>>>>>>> scheme, which will cause difficulty in some deployments. > >>>>>>>>> I can see this as a potential problem. But considering that > >> there > >>>>>> wasn't much > >>>>>>>>> objection to use "OAuth" as a scheme name before (total > overlap > >>>>>> with > >>>>>>>>> OAuth 1, and the suggested solution was to look for the > >> signature > >>>>>>>>> parameter) I don't see how this is suddenly an issue. > >>>>>>>> There was pretty strong objection to reusing OAuth. > >>>>>>> Yes, because there was no sub-scheme nor version (and the > grammar > >>>> was > >>>>>>> totally broken). Even so, lots of implementations went ahead > and > >>>> did > >>>>>>> it. Were there any scheme switching issues we are aware of? > >>>>>>> > >>>>>>> > >>>>>>>>> Do we have a concrete problem here or this is just > theoretical? > >>>>>>>> This came up during the review of draft-hammer-http-token-auth > >>>> [1]. > >>>>>> There was a long thread about it where people posted actual > >>>> framework > >>>>>> issues. > >>>>>>>>>> - potential to produce a very complicated scheme once many > sub > >>>>>> schemes > >>>>>>>>>> are added. > >>>>>>>>> Why? I would argue that this option actually produces more > >>>> uniform > >>>>>>>>> schemes because it forces all of them to be name/value pairs. > >>>>>> Beyond > >>>>>>>>> token_type everything is scheme specific. I really don't see > >> what > >>>>>> is very > >>>>>>>>> complicate here. > >>>>>>>> It is still a single scheme with many different sub-schemes, > >> each > >>>>>> with different key-value pairs that may have conflicting > meaning. > >>>> The > >>>>>> way I look at it is that if I try to fully implement this mega > >>>> scheme > >>>>>> (which means all its sub-schemes), it will likely be a > complicated > >>>>>> task. On the other hand, if you split it across scheme name, we > >>>> already > >>>>>> have a well-established system in place to pick and choose HTTP > >>>>>> authentication schemes. > >>>>>>> No one has to implement a mega scheme. All schemes must use > >>>>>> name/value > >>>>>>> pairs and that's where the common part stops. > >>>>>>> > >>>>>>> > >>>>>>>>>> - requires its own discovery method for which schemes are > >>>>>> supported. > >>>>>>>>> Why is this a downside only for this option? > >>>>>>>> Because the other options get this for free by using the WWW- > >>>>>> Authenticate header (since each scheme has a unique name). You > can > >>>> list > >>>>>> multiple headers in the 401 response. > >>>>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- > >> Authenticate > >>>>>>> work for sub-schemes as well? > >>>>>>> > >>>>>>> > >>>>>>>> Should I record your vote for #2? > >>>>>>> #2 or #3 > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> 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 eran@hueniverse.com Mon Feb 7 15:07:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718833A6E5B for ; Mon, 7 Feb 2011 15:07:12 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGa9W5TTfPoy for ; Mon, 7 Feb 2011 15:07:10 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D16353A69E7 for ; Mon, 7 Feb 2011 15:07:10 -0800 (PST) Received: (qmail 13881 invoked from network); 7 Feb 2011 23:07:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Feb 2011 23:07:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 16:07:06 -0700 From: Eran Hammer-Lahav To: William Mills , Torsten Lodderstedt Date: Mon, 7 Feb 2011 16:06:52 -0700 Thread-Topic: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4ygAAFylZA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:07:12 -0000 I'm a strong advocate of the Link approach, given that authorization inform= ation does not belong on the authentication headers. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Monday, February 07, 2011 2:50 PM > To: Torsten Lodderstedt > Cc: OAuth WG > Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme name > (deadline: 2/10) >=20 > OK. >=20 > So then the question is the right way to communicate token endpoints. Is= it > cleaner/preferred to have everything in the WWW-Authenticate header, or > to break things out so we're not stuffing a lot into those headers and > repeating outselves? So, all in one would be: >=20 > WWW-Authenticate: MAC realm=3D"somerealm" > token_url=3D"http://login.example.com/token" > auth_url=3D"http://login.example.com/webauth" >=20 > Broken out might be: >=20 > WWW-Authenticate: MAC realm=3D"OAuth2" > Link: rel=3D"oath2- > token" > Link: > ah> rel=3D"oath2-auth" >=20 > -bill >=20 > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Saturday, February 05, 2011 10:21 AM > > To: William Mills > > Cc: Phil Hunt; OAuth WG > > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > > 2/10) > > > > that's not the way WWW-Authenticate headers are used today. Instead > > the resource server should return a single WWW-Authenticate header > > _per_ supported authentication scheme, such as > > > > WWW-Authenticate: MAC realm=3D"somerealm" > > WWW-Authenticate: BEARER realm=3D"somerealm" > > > > furthermore, I think interdependencies among WWW-Authenticate > headers > > as suggested by Phil > > > > WWW-Authenticate: OAuth > > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyy > > > > could be rather fragile. > > > > I would expect the WWW-Authenticate header to return all the data > > required to obtain the credentials/tokens, such as > > > > WWW-Authenticate: MAC realm=3D"somerealm", > > tokenUrl=3D"yyyyy&token_secret=3Dyes" > > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" > > > > Which raises the question whether the coupling between authentication > > schemes and the OAuth2 core protocol is stronger than assumed. > > > > please als see http://www.ietf.org/mail- > > archive/web/oauth/current/msg04988.html > > > > regards, > > Torsten. > > > > Am 04.02.2011 22:39, schrieb William Mills: > > > > > I was thinking along the lines of simply returning the HTTP > > Authorization header schemes that are supported. In the OAuth 2 > > context that would be > > > > > > WWW-Authenticate: 401 error=3D"blah blah blah" auth_types=3D"Bearer > > MAC Basic" > > > > > > The client has to be aware of the authentication scheme names. > > > > > > -bill > > > > > >> -----Original Message----- > > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > >> Sent: Friday, February 04, 2011 1:14 PM > > >> To: William Mills > > >> Cc: Marius Scurtescu; OAuth WG > > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > (deadline: > > >> 2/10) > > >> > > >> I agree, that is still to be defined. There seems to be some push > > back > > >> on discovery, but this is likely warranted. If only because web > > sites > > >> may have both browser clients and app clients. > > >> > > >> In a previous message, I did suggest the web site return HTTP 401 > > >> as below... > > >>>> 401 Unauthorized > > >>>> WWW-Authenticate: Basic realm=3D"tokenSvc" > > >>>> WWW-Authenticate: Digest realm=3D"tokenSvc" > > >>>> WWW-Authenticate: Form > > >> url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" > > >> > > >> It could also include other items for "MAC", etc. > > >> > > >> The only other issue would be determining whether the token is > > obtained > > >> via an OAuth profile or via some default profile. That could be > > >> handled with something like: > > >> > > >> WWW-Authenticate: Basic realm=3D"somerealm" > > >> WWW-Authenticate: MAC realm=3D"somerealm" > > >> WWW-Authenticate: OAuth > > >> token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy" > > >> > > >> The above would suggest that MAC tokens could be used alone as > > >> described in some specification for "MAC". However, the presence > > >> of the OAuth header indicates that MAC and BEARER tokens can be > > >> used in the OAuth pattern. > > >> > > >> I think this allows both de-coupling of tokens from OAuth but also > > >> informs clients what tokens can be used with OAuth. > > >> > > >> There may be other ways to do this. But it does help with the > > >> decoupling. > > >> > > >> Phil > > >> phil.hunt@oracle.com > > >> > > >> > > >> > > >> > > >> On 2011-02-04, at 11:44 AM, William Mills wrote: > > >> > > >>> I was thinking more about how the client knows what to use. The > > >> ubiquitous "service documentation" may come in to play here. Some > > form > > >> of serv ice discovery/webfinger thing could also be used. > > >>>> -----Original Message----- > > >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > >>>> Sent: Friday, February 04, 2011 11:37 AM > > >>>> To: William Mills > > >>>> Cc: Marius Scurtescu; OAuth WG > > >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > (deadline: > > >>>> 2/10) > > >>>> > > >>>> Yes. This should be defined in each token type specification. > > >>>> > > >>>> Phil > > >>>> phil.hunt@oracle.com > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On 2011-02-04, at 11:29 AM, William Mills wrote: > > >>>> > > >>>>> The only challenge is to know what scheme to use and what the > > >> nuances > > >>>> are of how to present the credential. > > >>>>>> -----Original Message----- > > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On > > >>>> Behalf > > >>>>>> Of Phil Hunt > > >>>>>> Sent: Friday, February 04, 2011 9:42 AM > > >>>>>> To: Marius Scurtescu > > >>>>>> Cc: OAuth WG > > >>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > >> (deadline: > > >>>>>> 2/10) > > >>>>>> > > >>>>>> OAuth should be able to support other token schemes. > > >>>>>> > > >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, or > > >>>>>> whatever. > > >>>>>> > > >>>>>> Phil > > >>>>>> phil.hunt@oracle.com > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > > >>>>>> > > >>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > > >>>>>> wrote: > > >>>>>>>> Hey Marius, > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > > >>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM > > >>>>>>>>> To: Eran Hammer-Lahav > > >>>>>>>>> Cc: OAuth WG > > >>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme > name > > >>>>>> (deadline: > > >>>>>>>>> 2/10) > > >>>>>>>>> > > >>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes > > >>>>>>>>>> > > >>>>>>>>>> Define a single authentication scheme for all token types > > with > > >>>>>> some > > >>>>>>>>>> attribute used to detect which scheme is actually being > > used. > > >>>>>>>>>> > > >>>>>>>>>> Benefits: > > >>>>>>>>>> > > >>>>>>>>>> - single scheme, reuse of the 1.0 pattern. > > >>>>>>>>>> > > >>>>>>>>>> Downsides: > > >>>>>>>>>> > > >>>>>>>>>> - requires a new registry for authentication header > > >> parameters. > > >>>>>>>>> How is this different from option 1? Wouldn't that need some > > >>>>>> registry? > > >>>>>>>> #1 relies on the existing practice of creating HTTP scheme > > names > > >>>> (no > > >>>>>> current registry but httpbis might be creating one), as well as > > >> the > > >>>> -12 > > >>>>>> token type registry. Using a sub-scheme means you also need a > > >>>> registry > > >>>>>> for the header attributes that each token type will need > > >>>>>> (unless > > >> you > > >>>>>> just don't care about using the same attribute name for > > different > > >>>>>> needs). > > >>>>>>> Sure, there is no registry for schemes yet, but we would still > > >> need > > >>>>>>> some coordination. The fact that a sub-scheme needs a registry > > >> that > > >>>>>> we > > >>>>>>> control is a benefit not a downside IMO. > > >>>>>>> > > >>>>>>> > > >>>>>>>>>> - schemes are not easily reusable outside OAuth. > > >>>>>>>>> Sure. But I really don't see this group trying to create > > >> generic > > >>>>>> authentication > > >>>>>>>>> schemes. > > >>>>>>>> MAC is exactly that. > > >>>>>>> May or may not be. My point is that this group is not focused > > on > > >>>>>>> creating generic authentication schemes. Are you aware of any > > >> other > > >>>>>>> protocols that might use MAC or BEARER? Are we willing to put > > in > > >>>> the > > >>>>>>> effort to create generic schemes? Is it our charter? > > >>>>>>> > > >>>>>>> > > >>>>>>>>>> - existing frameworks usually switch on scheme name, not on > > >> sub > > >>>>>>>>>> scheme, which will cause difficulty in some deployments. > > >>>>>>>>> I can see this as a potential problem. But considering that > > >> there > > >>>>>> wasn't much > > >>>>>>>>> objection to use "OAuth" as a scheme name before (total > > overlap > > >>>>>> with > > >>>>>>>>> OAuth 1, and the suggested solution was to look for the > > >> signature > > >>>>>>>>> parameter) I don't see how this is suddenly an issue. > > >>>>>>>> There was pretty strong objection to reusing OAuth. > > >>>>>>> Yes, because there was no sub-scheme nor version (and the > > grammar > > >>>> was > > >>>>>>> totally broken). Even so, lots of implementations went ahead > > and > > >>>> did > > >>>>>>> it. Were there any scheme switching issues we are aware of? > > >>>>>>> > > >>>>>>> > > >>>>>>>>> Do we have a concrete problem here or this is just > > theoretical? > > >>>>>>>> This came up during the review of > > >>>>>>>> draft-hammer-http-token-auth > > >>>> [1]. > > >>>>>> There was a long thread about it where people posted actual > > >>>> framework > > >>>>>> issues. > > >>>>>>>>>> - potential to produce a very complicated scheme once many > > sub > > >>>>>> schemes > > >>>>>>>>>> are added. > > >>>>>>>>> Why? I would argue that this option actually produces more > > >>>> uniform > > >>>>>>>>> schemes because it forces all of them to be name/value pairs. > > >>>>>> Beyond > > >>>>>>>>> token_type everything is scheme specific. I really don't see > > >> what > > >>>>>> is very > > >>>>>>>>> complicate here. > > >>>>>>>> It is still a single scheme with many different sub-schemes, > > >> each > > >>>>>> with different key-value pairs that may have conflicting > > meaning. > > >>>> The > > >>>>>> way I look at it is that if I try to fully implement this mega > > >>>> scheme > > >>>>>> (which means all its sub-schemes), it will likely be a > > complicated > > >>>>>> task. On the other hand, if you split it across scheme name, we > > >>>> already > > >>>>>> have a well-established system in place to pick and choose HTTP > > >>>>>> authentication schemes. > > >>>>>>> No one has to implement a mega scheme. All schemes must use > > >>>>>> name/value > > >>>>>>> pairs and that's where the common part stops. > > >>>>>>> > > >>>>>>> > > >>>>>>>>>> - requires its own discovery method for which schemes are > > >>>>>> supported. > > >>>>>>>>> Why is this a downside only for this option? > > >>>>>>>> Because the other options get this for free by using the WWW- > > >>>>>> Authenticate header (since each scheme has a unique name). You > > can > > >>>> list > > >>>>>> multiple headers in the 401 response. > > >>>>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- > > >> Authenticate > > >>>>>>> work for sub-schemes as well? > > >>>>>>> > > >>>>>>> > > >>>>>>>> Should I record your vote for #2? > > >>>>>>> #2 or #3 > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Mon Feb 7 17:20:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19E03A6FB4 for ; Mon, 7 Feb 2011 17:20:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtMexkbVcWit for ; Mon, 7 Feb 2011 17:20:55 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 15DA43A6FBB for ; Mon, 7 Feb 2011 17:20:54 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p181Kvk4011206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 19:20:58 -0600 (CST) Received: from [135.244.41.162] (faynberg.lra.lucent.com [135.244.41.162]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p181KvgV017628; Mon, 7 Feb 2011 19:20:57 -0600 (CST) Message-ID: <4D509A79.706@alcatel-lucent.com> Date: Mon, 07 Feb 2011 20:20:57 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kristoffer Gronowski 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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 01:20:56 -0000 Kristoffer, I assume you mean an interface between the authorization server and the resource server. If so, I believe it definitely merits a serious discussion, and I support the idea in principle. On this subject, I think we need even more work defining the token and linking it to the resource owner. Today's discussion between Eran and Phil once again made me think of insufficiency of the "opaque tokens." Indeed, anything that comes with the OAuth flow is an OAuth token. (From the security point of view, of course, that also means that anything that can be INSERTED into an OAuth flow will be an OAuth token...) I am not criticizing the design decisions--I have agreed with all of them. But going forward, I would like the resource owner, the end user (both human and virtual) to 1) issue tokens or 2) outsource this work it it wishes. In the latter case, the resource owner must at least understand what the token has rather than just pass the token. Ideally, I would like this to be an OAuth work item: OAuth WG works very well, and it has gathered the best people to judge the task. I understand though that token specification is not presently in the charter, and therefore it can be discussed only in the context of changing the charter. And so I first wrote this in response to the item that you proposed, which I think is one step toward what I thought should be done. Igor Kristoffer Gronowski wrote: > ... > IMO there is one item missing and that is to create an optional formal > interface between the authorization server and the protected resource. > It could increase the productivity of creating the oauth protected web > services when the auth server can be treated as an off the shelf piece > of code. > Then it would be up to the auth server to also provide an number of > other extension like the discovery, token revocation and other. > > From kristoffer.gronowski@ericsson.com Mon Feb 7 18:26:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3A03A7006 for ; Mon, 7 Feb 2011 18:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcDphrFDR+BA for ; Mon, 7 Feb 2011 18:26:12 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 4AC553A6FF3 for ; Mon, 7 Feb 2011 18:26:12 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1839pwp015676; Mon, 7 Feb 2011 21:09:52 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 7 Feb 2011 21:26:10 -0500 From: Kristoffer Gronowski To: "igor.faynberg@alcatel-lucent.com" Date: Mon, 7 Feb 2011 21:26:09 -0500 Thread-Topic: [OAUTH-WG] New Working Group Items? Thread-Index: AcvHLoRgr6puVVVfQBe8Ogs/2J1taQABmYuA Message-ID: References: <4D509A79.706@alcatel-lucent.com> In-Reply-To: <4D509A79.706@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" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 02:26:13 -0000 Hi Igor! That is exactly what I would like to explore! My thinking was that the authorization server should be quite simple. There should be no advanced things like a policy server inside it. As long as the authorization (AS) and the resource servers (RS) use the sam= e identity source (or trusted federation of it). I was thinking of a simple interface that can work in layers. 1) The RS can ask the AS is this a valid token yes/no 2) Is this a valid token containing the following scopes? 3) Was this a token issued by a particular user X. (Based on sharing or tru= sting in the identity source) Or a combination of the above. In this way you can at least do a good separ= ation of concerns. Except of the answer if the criteria was met I have been experimenting also= in returning metadata from the AS so that a RS interceptor can be built. You would get all data about token lifetime, scopes attached and owner info= rmation. This would be a combination with the request input parameters. So you can s= tart off with making sure that #1 is valid. Since the token needs to have been generated by the AS. Then if you have a more dynamic policy that is very endpoint specific it is= far easier to implement it in code then in a general purpose policy server= . Then you can easily implement things like this protected resource needs sco= pe X or Y Mon-Fri while Z on weekends. Another advantage is that the same code can work on your behalf in discover= y mode to actually give you a clue what is needed at this very moment to ac= cess. The AS is just following strict rules and giving facts to you as a RS. It is a pretty clean design but I am sure that it will not fit everyone's n= eeds. And I am not saying that policy server would go away but for simple REST se= rvices this is a powerful framework where you do not have to mash all of yo= u implementation into one big thing. So that it why I was thinking that it might be a candidate for an optional = interface that might be good to have. With it people can develop Oauth protected services quicker since there is = more ready code to start from. Does this still fit your vision too described this way? BR Kristoffer =20 -----Original Message----- From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 Sent: Monday, February 07, 2011 5:21 PM To: Kristoffer Gronowski Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Working Group Items? Kristoffer, I assume you mean an interface between the authorization server and the res= ource server. If so, I believe it definitely merits a serious discussion, a= nd I support the idea in principle. On this subject, I think we need even more work defining the token and link= ing it to the resource owner. Today's discussion between Eran and Phil onc= e again made me think of insufficiency of the "opaque tokens."=20 Indeed, anything that comes with the OAuth flow is an OAuth token. (From th= e security point of view, of course, that also means that anything that can= be INSERTED into an OAuth flow will be an OAuth token...) I am not critic= izing the design decisions--I have agreed with all of them. But going forward, I would like the resource owner, the end user (both huma= n and virtual) to 1) issue tokens or 2) outsource this work it it wishes. I= n the latter case, the resource owner must at least understand what the tok= en has rather than just pass the token. Ideally, I would like this to be an OAuth work item: OAuth WG works very we= ll, and it has gathered the best people to judge the task. I understand tho= ugh that token specification is not presently in the charter, and therefore= it can be discussed only in the context of changing the charter. And so I = first wrote this in response to the item that you proposed, which I think i= s one step toward what I thought should be done. Igor Kristoffer Gronowski wrote: > ... > IMO there is one item missing and that is to create an optional formal=20 > interface between the authorization server and the protected resource. > It could increase the productivity of creating the oauth protected web=20 > services when the auth server can be treated as an off the shelf piece=20 > of code. > Then it would be up to the auth server to also provide an number of=20 > other extension like the discovery, token revocation and other. > =20 > From wmills@yahoo-inc.com Mon Feb 7 20:41:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A043C3A6C9E for ; Mon, 7 Feb 2011 20:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.347 X-Spam-Level: X-Spam-Status: No, score=-17.347 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfyrE-5Kyi8P for ; Mon, 7 Feb 2011 20:41:14 -0800 (PST) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 943713A6C9C for ; Mon, 7 Feb 2011 20:41:14 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p184euKg002083; Mon, 7 Feb 2011 20:40:57 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Mon, 7 Feb 2011 20:40:56 -0800 From: William Mills To: Kristoffer Gronowski , "igor.faynberg@alcatel-lucent.com" Date: Mon, 7 Feb 2011 20:40:54 -0800 Thread-Topic: [OAUTH-WG] New Working Group Items? Thread-Index: AcvHLoRgr6puVVVfQBe8Ogs/2J1taQABmYuAAATE6vA= Message-ID: References: <4D509A79.706@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:41:15 -0000 I'm on the other side of this. I think the opaque token is clean and allow= s for easy separation. What more information do we need to provide to the = client? =20 I am not in favor of having a call back to the authenticating site as a req= uirement for OAuth in general, but if someone wants to define a token type = to do that it's fine. =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Kristoffer Gronowski > Sent: Monday, February 07, 2011 6:26 PM > To: igor.faynberg@alcatel-lucent.com > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Working Group Items? >=20 > Hi Igor! >=20 > That is exactly what I would like to explore! > My thinking was that the authorization server should be quite simple. > There should be no advanced things like a policy server inside it. >=20 > As long as the authorization (AS) and the resource servers (RS) use the > same identity source (or trusted federation of it). > I was thinking of a simple interface that can work in layers. > 1) The RS can ask the AS is this a valid token yes/no > 2) Is this a valid token containing the following scopes? > 3) Was this a token issued by a particular user X. (Based on sharing or > trusting in the identity source) >=20 > Or a combination of the above. In this way you can at least do a good > separation of concerns. > Except of the answer if the criteria was met I have been experimenting > also in returning metadata from the AS so that a RS interceptor can be > built. > You would get all data about token lifetime, scopes attached and owner > information. > This would be a combination with the request input parameters. So you > can start off with making sure that #1 is valid. > Since the token needs to have been generated by the AS. > Then if you have a more dynamic policy that is very endpoint specific > it is far easier to implement it in code then in a general purpose > policy server. >=20 > Then you can easily implement things like this protected resource needs > scope X or Y Mon-Fri while Z on weekends. > Another advantage is that the same code can work on your behalf in > discovery mode to actually give you a clue what is needed at this very > moment to access. > The AS is just following strict rules and giving facts to you as a RS. >=20 > It is a pretty clean design but I am sure that it will not fit > everyone's needs. > And I am not saying that policy server would go away but for simple > REST services this is a powerful framework where you do not have to > mash all of you implementation into one big thing. >=20 > So that it why I was thinking that it might be a candidate for an > optional interface that might be good to have. > With it people can develop Oauth protected services quicker since there > is more ready code to start from. >=20 > Does this still fit your vision too described this way? >=20 > BR Kristoffer >=20 > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > Sent: Monday, February 07, 2011 5:21 PM > To: Kristoffer Gronowski > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Working Group Items? >=20 > Kristoffer, >=20 > I assume you mean an interface between the authorization server and the > resource server. If so, I believe it definitely merits a serious > discussion, and I support the idea in principle. >=20 > On this subject, I think we need even more work defining the token and > linking it to the resource owner. Today's discussion between Eran and > Phil once again made me think of insufficiency of the "opaque tokens." > Indeed, anything that comes with the OAuth flow is an OAuth token. > (From the security point of view, of course, that also means that > anything that can be INSERTED into an OAuth flow will be an OAuth > token...) I am not criticizing the design decisions--I have agreed > with all of them. >=20 > But going forward, I would like the resource owner, the end user (both > human and virtual) to 1) issue tokens or 2) outsource this work it it > wishes. In the latter case, the resource owner must at least understand > what the token has rather than just pass the token. >=20 > Ideally, I would like this to be an OAuth work item: OAuth WG works > very well, and it has gathered the best people to judge the task. I > understand though that token specification is not presently in the > charter, and therefore it can be discussed only in the context of > changing the charter. And so I first wrote this in response to the item > that you proposed, which I think is one step toward what I thought > should be done. >=20 > Igor >=20 > Kristoffer Gronowski wrote: > > ... > > IMO there is one item missing and that is to create an optional > formal > > interface between the authorization server and the protected > resource. > > It could increase the productivity of creating the oauth protected > web > > services when the auth server can be treated as an off the shelf > piece > > of code. > > Then it would be up to the auth server to also provide an number of > > other extension like the discovery, token revocation and other. >=20 >=20 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pflam@cs.stanford.edu Mon Feb 7 20:52:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6EE3A6C86 for ; Mon, 7 Feb 2011 20:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47-61zL6suoU for ; Mon, 7 Feb 2011 20:52:31 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 6E8DA3A6BDF for ; Mon, 7 Feb 2011 20:52:31 -0800 (PST) Received: from secllab.stanford.edu ([171.64.65.88] helo=css-macbook-pro-9.local) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1PmfZ4-0003T1-Uy; Mon, 07 Feb 2011 20:52:36 -0800 Message-ID: <4D50CC12.3080300@cs.stanford.edu> Date: Mon, 07 Feb 2011 20:52:34 -0800 From: pflam@cs.stanford.edu User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.7 MIME-Version: 1.0 To: Torsten Lodderstedt , Eran Hammer-Lahav , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------040707090606070007020400" X-Scan-Signature: 3e4de42ed275f26c8502e905a5d8b6ad Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:52:36 -0000 This is a multi-part message in MIME format. --------------040707090606070007020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Torsten, Thanks for getting back to me and raising this interesting point. Are you hinting that while a web application allows anonymous access, it shouldn't participate in OAuth? If so, this assumption has not been spelled out in the core specification. From what I read, the current specification seems to put user authentication with the client as an orthogonal issue, and I can't seem to find any hinting of such a dependency of OAuth in this specification. I do not represent an industry vendor, so the example I use below might not be appropriate, and I welcome feedback from the members of this audience. Currently there are quite a few websites that allow free, anonymous access to their service. Suppose a website similar to YouTube intends to allow the users to play not only media files hosted on its site, but also files hosted somewhere else as long as the user can provide the proper authorization to access them (using OAuth). I don't see an inherent reason why the site needs to authenticate the user locally before retrieving such remote resources. What do you think? Best, Eric ---------- Forwarded message ---------- From:*Torsten Lodderstedt* Date: Mon, Feb 7, 2011 at 12:56 PM Subject: Re: [OAUTH-WG] validate authorization code in draft 12 To: Eric Cc: Eran Hammer-Lahav , "oauth@ietf.org" Hi Eric, I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional httpcall. What do you think? regards, Torsten. Am 21.01.2011 09:30, schrieb Eric: > Eran, and others, > > A few of us had some discussions on the authorization code flow, as > depicted in Fig. 3 of the current (12th) draft. We think that it is > probably worthwhile to suggest in the specification that an OAuth > implementation SHOULD provide a way for the client to validate the > authorization code before sending it to the Authorization Server > (AS). From what we have heard, this has been done in some of the > current OAuth deployments. There are other people who do not think > this is such a big security risk, although so far no one has objected > that there is some risk here. > > The issue is that according to the current draft, someone who owns a > botnet can locate the redirect URIs of clients that listen on HTTP, > and access them with random authorization codes, and cause HTTPS > connections to be made on the Authorization Server (AS). There are a > few things that the attacker can achieve with this OAuth flow that he > cannot easily achieve otherwise : > > 1. Cost magnification: the attacker incurs the cost of an HTTP > connection and causes an HTTPS connection to be made on the AS; and he > can co-ordinate the timing of such HTTPS connections across multiple > clients relatively easily, if these clients blindly connect to the AS > without first validating the authorization codes received. > > Although the attacker could achieve something similar, say by > including an iframe pointing to the HTTPS URL of the AS in an HTTP web > page and lure web users to visit that page, timing attacks using such > a scheme is (say for the purpose of DDoS) more difficult . > > 2. Connection laundering: if the AS realizes it is flooded by HTTPS > connections with illegitimate codes, it collects no useful information > about the attacker, since the clients act as relays. > > 3. CSRF defense/the 'state' parameter don't completely address this > problem. With such a defense, the attacker might need to incur an > additional HTTP request to obtain a valid CSRF code/ state parameter. > This does cut down the effectiveness of the attack by a factor of 2, > which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 > (the cost factor is estimated to be around 3.5x > athttp://www.semicomplete.com/blog/geekery/ssl-latency.html > ), the > attacker still achieves a cost magnification. > > Our proposal is that the OAuth specification suggests that an OAuth > implementation SHOULD provide a way for the client to validate the > authorization code before sending it to the Authorization Server > (AS). The specifics of how to validate the authorization code may not > need to be part of the core specification. We sketch a design below > for consideration for future implementation. It might be reasonable to > assume that OAuth implementations provide some API for the client to > call to validate and send the authorization code to the AS. There are > two possible schemes for implementation: a) if the client and the AS > already share a symmetric secret, an HMAC key can be created from the > shared secret, and the authorization code will be HMAC'ed and standard > techniques can be employed in the client-side API implementation to > detect replay and forgery attempts on the code; b) an alternative is > for the AS to sign the code using the private key from its SSL > certificate, and for the client API to validate the signature using > the public key. > > > > On Thu, Jan 20, 2011 at 4:56 PM, Eran > Hammer-Lahav wrote: > > Draft -12 is finally out. > > This is almost a complete rewrite of the entire document, with the > primary goal of moving it back to a similar structure used in -05. > I have been thinking about this for a few months and finally came > up with a structure that combines the two approaches. > > The draft includes some major cleanups, significantly simpler > language, reduces repeated prose, and tried to keep prose to the > introduction and normative language in the rest of the > specification. I took out sections that broke the flow, and did my > best to give this a linear narrative that is easy to follow. > > The draft includes the following normative changes: > > o Clarified 'token_type' as case insensitive. > o Authorization endpoint requires TLS when an access token is > issued. > o Removed client assertion credentials, mandatory HTTP Basic > authentication support for client credentials, WWW-Authenticate > header, and the OAuth2 authentication scheme. > o Changed implicit grant (aka user-agent flow) error response > from query to fragment. > o Removed the 'redirect_uri_mismatch' error code since in such > a case, the authorization server must not send the error back to > the client. > o Defined access token type registry. > > I would like to spend the coming week receiving and applying > feedback before requesting a WGLC for everything but the security > considerations section (missing) 2/1. > > EHL > > > > > -----Original Message----- > > From:oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ] On Behalf > > OfInternet-Drafts@ietf.org > > Sent: Thursday, January 20, 2011 4:45 PM > > To:i-d-announce@ietf.org > > Cc:oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > 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-12.txt > > Pages : 46 > > Date : 2011-01-20 > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.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. > _______________________________________________ > 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 --------------040707090606070007020400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Torsten,

Thanks for getting back to me and raising this interesting point.

Are you hinting that while a web application allows anonymous access, it shouldn't participate in OAuth? If so, this assumption has not been spelled out in the core specification. From what I read, the current specification seems to put user authentication with the client as an orthogonal issue, and I can't seem to find any hinting of such a dependency of OAuth in this specification.

I do not represent an industry vendor, so the example I use below might not be appropriate, and I welcome feedback from the members of this audience. Currently there are quite a few websites that allow free, anonymous access to their service. Suppose a website similar to YouTube intends to allow the users to play not only media files hosted on its site, but also files hosted somewhere else as long as the user can provide the proper authorization to access them (using OAuth). I don't see an inherent reason why the site needs to authenticate the user locally before retrieving such remote resources.  

What do you think?

Best,
Eric



---------- Forwarded message ----------
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Mon, Feb 7, 2011 at 12:56 PM
Subject: Re: [OAUTH-WG] validate authorization code in draft 12
To: Eric <pflam@cs.stanford.edu>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org>


Hi Eric,

I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http     call.

What do you think?

regards,
Torsten. 

Am 21.01.2011 09:30, schrieb Eric:
Eran, and others,

A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here.

The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : 

1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received.

Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web  users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult .

2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays.  

3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the attacker still achieves a cost magnification.

Our proposal is that the OAuth specification suggests that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key.

 

On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Draft -12 is finally out.

This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

The draft includes the following normative changes:

  o  Clarified 'token_type' as case insensitive.
  o  Authorization endpoint requires TLS when an access token is issued.
  o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
  o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
  o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
  o  Defined access token type registry.

I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Thursday, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
>
> 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-12.txt
>       Pages           : 46
>       Date            : 2011-01-20
>
> This specification describes the OAuth 2.0 authorization protocol.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.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.
_______________________________________________
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


--------------040707090606070007020400-- From eran@hueniverse.com Mon Feb 7 21:46:09 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590003A7012 for ; Mon, 7 Feb 2011 21:46:09 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tJ-4LSx+qh2 for ; Mon, 7 Feb 2011 21:46:08 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C32493A6C9A for ; Mon, 7 Feb 2011 21:46:07 -0800 (PST) Received: (qmail 27392 invoked from network); 8 Feb 2011 05:46:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 05:46:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 22:46:10 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , OAuth WG Date: Mon, 7 Feb 2011 22:45:56 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvG6+zzWEcHzevzR2iwFVcy1BpGKgAZhIvg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> In-Reply-To: <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@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 Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:46:09 -0000 Hi Skylar,=20 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Monday, February 07, 2011 9:25 AM > On including parameters for signing... >=20 > I'd retract my suggestion that we'd include parameter-hash in the header. > Instead, I would suggest making parameters optional in calculating the > signature using a flag as with bodyhash. Providers could require includin= g > parameters if so desired. Parameters could be included as currently defin= ed, > or with a hash method similar to entity-body (which I find both simpler a= nd > more congruent). >=20 > Again, the goal in making query parameters optional is to allow providers= to > make signature calculation as simple as possible for clients (so much as = it is in > line with the security requirements of the provider) and avoid complexiti= es in > implementation such as those that tripped up OAuth 1. I have been opposed this line of thinking for over two years now. As actual code shows, producing the normalized request string per this spec= ification is straight-forward. Developers finding it hard should use a libr= ary and not try to write their own. They can also cut-and-paste the 10 or s= o lines it takes to produce the string. This authentication method comes with well understood security properties. = By making query parameters optional because of developer ease, providers wi= ll be giving up an important part of the protection this protocol offers. T= his is especially true for the majority of APIs where query parameters are = critical to the request integrity. The right solution here is to provide either a library for your developers,= or an API without any parameters. EHL >=20 >=20 >=20 > On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: >=20 > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > > > > New version includes the following changes: > > > > o Added body-hash support. > > o Updated OAuth 2.0 reference to -12 and added token type registrat= ion > template. > > o Removed error and error URI attributes (codes were just a duplica= tion > of the HTTP status codes). > > > > Feedback would be greatly appreciated. > > > > EHL > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Feb 7 21:59:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003B13A7012 for ; Mon, 7 Feb 2011 21:59:30 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juk5Xhi57z6H for ; Mon, 7 Feb 2011 21:59:23 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5B6523A6C9A for ; Mon, 7 Feb 2011 21:59:23 -0800 (PST) Received: (qmail 4786 invoked from network); 8 Feb 2011 05:59:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 05:59:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Feb 2011 22:59:26 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 7 Feb 2011 22:59:12 -0700 Thread-Topic: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwD1zY4A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@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_90C41DD21FB7C64BB94121FBBC2E723445A90BFDDBP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 05:59:30 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFDDBP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is where we stand so far: Option 1 -- 14 votes William Mills Eran Hammer-Lahav Franklin Tse David Recordon Peter Saint-Andre Phil Hunt Skylar Woodward Michael Adams Igor Faynberg Justin Hart Brian Campbell Luke Shepard James Manger Minoo Hamilton Option 2 -- 1 vote Marius Scurtescu (or #3) Option 3 -- 1 vote Torsten Lodderstedt (or #1) Option 4 -- 3 votes Mike Jones Brian Eaton (??) Dirk Balfanz Option #1 has clear support. However, given my strong feeling on the subject, it is only fair that those= voting for other options get to decide if they are willing to let #1 stand= as the working group consensus, or would like to continue this debate in h= ope of a different result. Mike, Brian, Dirk, and Marius - can you live with #1? EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, February 03, 2011 12:34 AM To: OAuth WG Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) After a long back-and-forth, I think it is time to present a few options an= d have people express their preferences. These are the options mentioned so far and their +/-: 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) Each token type gets its own name (which does not include the word 'oauth' = in it), as well as a matching HTTP authentication scheme if a new one is be= ing defined. Benefits: - works cleanly with the HTTP authentication framework by simply defining n= ew methods or reusing existing ones. - schemes can be used outside the OAuth authorization flow (e.g. 2-legged O= Auth 1.0 use cases). - all schemes are presented equally without giving any a preferred treatmen= t. - built-in discovery using 401 challenge header for which schemes are suppo= rted (with their respective information). Downsides: - potential creation of many new HTTP authentication schemes which has been= stable for a long time. 2. Single OAuth2 scheme with sub-schemes Define a single authentication scheme for all token types with some attribu= te used to detect which scheme is actually being used. Benefits: - single scheme, reuse of the 1.0 pattern. Downsides: - requires a new registry for authentication header parameters. - schemes are not easily reusable outside OAuth. - existing frameworks usually switch on scheme name, not on sub scheme, whi= ch will cause difficulty in some deployments. - potential to produce a very complicated scheme once many sub schemes are = added. - requires its own discovery method for which schemes are supported. 3. Name prefix (e.g. oauth2_bearer) Benefits: - makes the protocol a bit easier to newbies since it will look all inclusi= ve (authorization and authentication). Downsides: - makes reuse outside OAuth awkward without any technical benefit. 4. OAuth2 for bearer, MAC for mac Name the bearer token 'OAuth2' and everything else gets a different name (w= ith or without OAuth in it). Benefits: - Matches current draft. Downsides: - Elevates bearer token to the preferred token type, instead of promoting c= omparison of the various token types available. - Creates a very odd usage where the authorization server issues an access = token of type 'OAuth2' which is non-descriptive and very confusing (since t= here are other token types). - Uses the name OAuth2 which stands for authorization in an authentication = flow, continuing the confusion about what OAuth is (an authorization protoc= ol). --- Please reply with your preference by 2/10. As always, please provide feedba= ck on the options and analysis. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFDDBP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is where we stand so far:

 

Option 1  -- 14 votes

 

= William Mills

Eran Hammer-Lahav

Franklin Tse

David Recordon

Peter Saint-Andre

Phil Hunt

Skyla= r Woodward

Michael Adams

Igor Faynberg

= Justin Hart

Brian Campbell

=

Luke Shepard<= /span>

James Manger

Mino= o Hamilton

 

Option 2 -- 1 vote

 

Marius Scurtescu (or #3)<= /p>

 

Option 3  --= 1 vote

 

Torsten Lodderstedt (or #1)

 

Option 4 -- 3 votes=

 

Mike Jones<= /o:p>

Brian Ea= ton (??)

Dirk Balfanz

 

 

Option #1 has clear support.

<= p class=3DMsoNormal> <= /p>

However, given my str= ong feeling on the subject, it is only fair that those voting for other opt= ions get to decide if they are willing to let #1 stand as the working group= consensus, or would like to continue this debate in hope of a different re= sult.

 

Mike, Brian, Dirk, and Marius – can you live with #1?

 =

EHL

=  

<= o:p> 

From: oa= uth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Er= an Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
= To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme= name (deadline: 2/10)

 

After a long back-and-forth, I = think it is time to present a few options and have people express their pre= ferences.

 

These are the options mentioned so far and their +/-:

 

1. Des= criptive, non-OAuth-specific scheme names (Bearer, MAC)

 

Each token type g= ets its own name (which does not include the word ‘oauth’ in it= ), as well as a matching HTTP authentication scheme if a new one is being d= efined.

 

Benefits:

 

- works cleanly with the HTTP authentication framewor= k by simply defining new methods or reusing existing ones.

- schemes can be used outside the OAuth authorization fl= ow (e.g. 2-legged OAuth 1.0 use cases).

= - all schemes are presented equally without giving any a preferred treatmen= t.

- built-in discovery using 401 challe= nge header for which schemes are supported (with their respective informati= on).

 

Downsides:

 

<= p class=3DMsoNormal>- potential creation of many new HTTP authentication sc= hemes which has been stable for a long time.

 

2. Single OAuth2 scheme with= sub-schemes

 

Define a single authentication scheme for all token types wi= th some attribute used to detect which scheme is actually being used.<= /o:p>

 

Ben= efits:

 

- single scheme, reuse of the 1.0 pattern.

 

Downsides:

 

- requi= res a new registry for authentication header parameters.

- schemes are not easily reusable outside OAuth.

- existing frameworks usually switch on scheme na= me, not on sub scheme, which will cause difficulty in some deployments.

- potential to produce a very complicated s= cheme once many sub schemes are added.

-= requires its own discovery method for which schemes are supported.

 

3. Na= me prefix (e.g. oauth2_bearer)

&nbs= p;

Benefits:

 

- makes the protocol a bit eas= ier to newbies since it will look all inclusive (authorization and authenti= cation).

 

Downsides:

 

- makes reuse outside OAuth awkward without any t= echnical benefit.

 

<= p class=3DMsoNormal>4. OAuth2 for bearer, MAC for mac

 

Name the bearer tok= en ‘OAuth2’ and everything else gets a different name (with or = without OAuth in it).

 <= /p>

Benefits:

&= nbsp;

- Matches current draft.

=

 

Downsides:

 

- Elevates bearer token to the preferred token type, instead of promoting = comparison of the various token types available.

- Creates a very odd usage where the authorization server issues a= n access token of type ‘OAuth2’ which is non-descriptive and ve= ry confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorization in an authe= ntication flow, continuing the confusion about what OAuth is (an authorizat= ion protocol).

 

---

 

Please reply with your preference by 2/10. As always= , please provide feedback on the options and analysis.

 

EHL

=

 

 <= /o:p>

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFDDBP3PW5EX1MB01E_-- From allentomdude@gmail.com Mon Feb 7 22:37:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51A73A7029 for ; Mon, 7 Feb 2011 22:37:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y81As5ImVGum for ; Mon, 7 Feb 2011 22:37:54 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 04C6F3A6B69 for ; Mon, 7 Feb 2011 22:37:53 -0800 (PST) Received: by ewy8 with SMTP id 8so3058055ewy.31 for ; Mon, 07 Feb 2011 22:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pMQQGFGOKEy4frvh2tc3/pbTo0yQroy6cH5ZHZB/+/Q=; b=H/b0IxX5shKeVgChMBOw/Gww54Fel8CSXnozUCh3ctJc+8L28ASaIvU5TD+d9LmVsF DgG+l41+Say85guzk/dbfpn6f/jcQsIKjrRWOdD5FW3dkzpXhpggIJeQdDAT5GnIMb2M Q+CJ5Tr1atOarM/8IL4oU4qky5dkkhH1O/yXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MISHS3WdJRGNJDeKMwgPPY/9z0WyqFE5eSC3VOYuQMe478eJoroJknXqsF9cRs0CSM Kh2tEaQy+hKlOj1NGS+ba4Pm57tOPEbh6dtMiQFs0UvcAPdf2cpWJVRVWuSp2827D/42 hu/QH8XoOLj7h3te8dJltZ9nWL6n0H53CeZz4= MIME-Version: 1.0 Received: by 10.213.32.208 with SMTP id e16mr20489729ebd.35.1297147079433; Mon, 07 Feb 2011 22:37:59 -0800 (PST) Received: by 10.213.108.200 with HTTP; Mon, 7 Feb 2011 22:37:59 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 7 Feb 2011 22:37:59 -0800 Message-ID: From: Allen Tom To: Eran Hammer-Lahav , OAuth WG Content-Type: multipart/alternative; boundary=000e0cd50a70e41cde049bbf9651 Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 06:38:52 -0000 --000e0cd50a70e41cde049bbf9651 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I vote for #1 - the proposal is simple and straightforward. However, as one of the authors of WRAP - I am rather fond of bearer tokens. Replacing OAuth 1.0 tokens with bearer tokens was one of the primary goals of WRAP, so #4 makes a lot of sense to me too. That being said, #1 is simple and straightforward, and has the advantage that choice #1 can move the process forward. Allen --000e0cd50a70e41cde049bbf9651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

I vote for #1 - the proposal is simple and strai= ghtforward.=A0

However, as one of the authors of W= RAP - I am rather fond of bearer tokens. =A0Replacing OAuth 1.0 tokens with= bearer tokens was one of the primary goals of WRAP, so #4 makes a lot of s= ense to me too.

That being said, #1 is simple and straightforward, and = has the advantage that choice #1 can move the process forward.
Allen

--000e0cd50a70e41cde049bbf9651-- From James.H.Manger@team.telstra.com Mon Feb 7 23:31:03 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5863A703E for ; Mon, 7 Feb 2011 23:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=1.300, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KImWrMKAjiea for ; Mon, 7 Feb 2011 23:31:02 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 665993A67B6 for ; Mon, 7 Feb 2011 23:31:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,440,1291554000"; d="scan'208";a="24303223" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Feb 2011 18:31:07 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6250"; a="19195528" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Feb 2011 18:31:07 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 8 Feb 2011 18:31:06 +1100 From: "Manger, James H" To: OAuth WG Date: Tue, 8 Feb 2011 18:31:02 +1100 Thread-Topic: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4ygAAFylZAAD7GLgA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D604DE0@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:31:03 -0000 I see 4 suggestions for discovery (getting details about the OAuth endpoint= s etc to client apps): 1. Include it as extra params when advertising authentication mechanisms. WWW-Authenticate: MAC realm=3D"...", , auth_url= =3D"http..." I don't like this as it changes WWW-Auth headers for other auth schemes, which might be theoretically feasible for new schemes this WG defines, but is not really possible for other schemes. It unnecessarily binds the delegation flow to a specific auth mechanism up = front. There is nowhere to put the info if a server support delegation, but doesn'= t use an HTTP auth scheme to exchange the resulting state from the authz se= rver to resource servers. When we specify a new parameter it affects all other auth schemes as well. Do we really want a discovery spec adding params to the WWW-Auth header def= ined in the MAC spec? If you updated the discovery spec you would need to check every other auth = scheme (past & future) for param name clashes. 2. Define a WWW-Auth scheme specifically for announcing support for delegat= ion flows. WWW-Authenticate: OAuth2 realm=3D"..." token_url=3D"http..." auth_url=3D= "http..." This is my preference. The only downside is that there is no matching Authorization header (and it= is more about authz than auth) so some feel it not how WWW-Auth is suppose= d to be used. I see WWW-Auth as accompanying responses when a better response is possible= with more authentication -- and providing details about how to "improve" t= he authentication. Providing the info required to perform an OAuth delegation flow is a close = enough fit in my mind. When a client app gets a 401, it looks at WWW-Auth headers to decide if it = can continue. Orchestrating an OAuth delegation flow is a way to continue. 3. Define link relations. Link: rel=3D"oauth2-auth" This feels possible, but not ideal. Details about how to delegate is not quite a "relationship". There is probably more than a single URI that you want to specify, and a ha= ndful of other parameters. 4. Something else entirely, such a host-meta. I would prefer to offer discovery inline -- in the 401 response. -- James Manger ---------- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, 8 February 2011 10:07 AM I'm a strong advocate of the Link approach, given that authorization inform= ation does not belong on the authentication headers. > ---------- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Monday, February 07, 2011 2:50 PM >=20 > OK. >=20 > So then the question is the right way to communicate token endpoints. Is= it > cleaner/preferred to have everything in the WWW-Authenticate header, or > to break things out so we're not stuffing a lot into those headers and > repeating outselves? So, all in one would be: >=20 > WWW-Authenticate: MAC realm=3D"somerealm" > token_url=3D"http://login.example.com/token" > auth_url=3D"http://login.example.com/webauth" >=20 > Broken out might be: >=20 > WWW-Authenticate: MAC realm=3D"OAuth2" > Link: rel=3D"oath2- > token" > Link: > ah> rel=3D"oath2-auth" From skylar@kiva.org Mon Feb 7 23:43:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0445E3A7047 for ; Mon, 7 Feb 2011 23:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qh4ISuk6S5U for ; Mon, 7 Feb 2011 23:43:12 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id 6A8A93A6CAF for ; Mon, 7 Feb 2011 23:43:11 -0800 (PST) Received: from source ([74.125.82.49]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTVD0FBRt1iqQsEC8f8n1Wec8F9PucOM6@postini.com; Mon, 07 Feb 2011 23:43:18 PST Received: by wwb17 with SMTP id 17so5813560wwb.6 for ; Mon, 07 Feb 2011 23:43:15 -0800 (PST) Received: by 10.227.127.84 with SMTP id f20mr16846942wbs.160.1297150993950; Mon, 07 Feb 2011 23:43:13 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id x1sm4141221wbh.14.2011.02.07.23.43.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 23:43:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC42@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 8 Feb 2011 08:43:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EFA9E76-1E3B-411A-852F-5640167A9AA4@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC42@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:43:13 -0000 Here's a thought: signed_content=3D"request,query,body" If not included, it defaults to "request,query". It's non-breaking = (except for the implied removal of bodyhash), allows for either body or = query content to be omitted from the signature, and looks less ugly than = bodyhash=3Dtrue. If you prefer, the value of this attribute could be = one of a predefined string (request_query, request_query_body, request, = etc.) rather than individual parsed elements. On Feb 7, 2011, at 6:26 PM, Eran Hammer-Lahav wrote: > Yeah... >=20 > I struggled with that. There is no reason to include the body hash = with the request other than to indicate a body hash is included in the = normalized request string. It's just that an attribute like = 'bodyhash=3Dtrue' is so ugly... >=20 > I'm still thinking about this. >=20 > EHL >=20 >> -----Original Message----- >> From: Skylar Woodward [mailto:skylar@kiva.org] >> Sent: Monday, February 07, 2011 9:25 AM >> To: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >>=20 >> On body-hash... >>=20 >> Having completed a trial implementation, it seems redundant, and >> potentially problematic, to include the body-hash in the = Authentication >> header. The danger is that implementors may neglect to recalculate = the hash >> themselves, reusing the value (even if incorrect) provided by the = client. Why >> not just require the provider to calculate this and validate it by = comparing the >> final signature? This way it's clearer for everyone what the = expectations are >> in validating the signature. >>=20 >> I propose either a flag (eg, usebodyhash=3D"1") or an algorithm >> (bodyhashalgorithm=3D"sha1"). If this parameter was provided, the = correct >> hash would be added to the base string for signing. If omitted (or = set false?) >> then an empty string is used for base string element #4. >>=20 >>=20 >> On including parameters for signing... >>=20 >> I'd retract my suggestion that we'd include parameter-hash in the = header. >> Instead, I would suggest making parameters optional in calculating = the >> signature using a flag as with bodyhash. Providers could require = including >> parameters if so desired. Parameters could be included as currently = defined, >> or with a hash method similar to entity-body (which I find both = simpler and >> more congruent). >>=20 >> Again, the goal in making query parameters optional is to allow = providers to >> make signature calculation as simple as possible for clients (so much = as it is in >> line with the security requirements of the provider) and avoid = complexities in >> implementation such as those that tripped up OAuth 1. >>=20 >>=20 >>=20 >> On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: >>=20 >>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 >>>=20 >>> New version includes the following changes: >>>=20 >>> o Added body-hash support. >>> o Updated OAuth 2.0 reference to -12 and added token type = registration >> template. >>> o Removed error and error URI attributes (codes were just a = duplication >> of the HTTP status codes). >>>=20 >>> Feedback would be greatly appreciated. >>>=20 >>> EHL >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Feb 8 00:19:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BFC3A6CB8 for ; Tue, 8 Feb 2011 00:19:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZLYL9VPCAgU for ; Tue, 8 Feb 2011 00:19:43 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1FEFF3A6CB4 for ; Tue, 8 Feb 2011 00:19:43 -0800 (PST) Received: (qmail 9682 invoked from network); 8 Feb 2011 08:19:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 08:19:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Feb 2011 01:19:36 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Tue, 8 Feb 2011 01:19:21 -0700 Thread-Topic: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4ygAAFylZAAD7GLgAADj8oQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDE5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127D604DE0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D604DE0@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 08:19:43 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, February 07, 2011 11:31 PM > 3. Define link relations. > Link: rel=3D"oauth2-auth" >=20 > This feels possible, but not ideal. > Details about how to delegate is not quite a "relationship". Sure it is. "My authorization server". > There is probably more than a single URI that you want to specify, and a > handful of other parameters. Link allows defining addition extension attributes if needed, which can inc= lude other URIs, but I would just include multiple links as needed. For exa= mple, one link per client profile. EHL From eran@hueniverse.com Tue Feb 8 00:21:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591303A6CB7 for ; Tue, 8 Feb 2011 00:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM34hbjWjTZo for ; Tue, 8 Feb 2011 00:21:02 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 70A593A6CB4 for ; Tue, 8 Feb 2011 00:21:02 -0800 (PST) Received: (qmail 6083 invoked from network); 8 Feb 2011 08:21:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 08:21:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Feb 2011 01:20:55 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Tue, 8 Feb 2011 01:20:41 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvHY9racjEC58uqQPuLeBSpsdjjCgABRuhQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDE6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A90BFC42@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2EFA9E76-1E3B-411A-852F-5640167A9AA4@kiva.org> In-Reply-To: <2EFA9E76-1E3B-411A-852F-5640167A9AA4@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] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 08:21:05 -0000 There is no way I'm going to allow not signing the request URI and any quer= y parameters. That leaves just the body... EHL > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Monday, February 07, 2011 11:43 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > Here's a thought: >=20 > signed_content=3D"request,query,body" >=20 > If not included, it defaults to "request,query". It's non-breaking (excep= t for > the implied removal of bodyhash), allows for either body or query content= to > be omitted from the signature, and looks less ugly than bodyhash=3Dtrue. = If > you prefer, the value of this attribute could be one of a predefined stri= ng > (request_query, request_query_body, request, etc.) rather than individual > parsed elements. >=20 > On Feb 7, 2011, at 6:26 PM, Eran Hammer-Lahav wrote: >=20 > > Yeah... > > > > I struggled with that. There is no reason to include the body hash with= the > request other than to indicate a body hash is included in the normalized > request string. It's just that an attribute like 'bodyhash=3Dtrue' is so = ugly... > > > > I'm still thinking about this. > > > > EHL > > > >> -----Original Message----- > >> From: Skylar Woodward [mailto:skylar@kiva.org] > >> Sent: Monday, February 07, 2011 9:25 AM > >> To: Eran Hammer-Lahav; OAuth WG > >> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 > >> > >> On body-hash... > >> > >> Having completed a trial implementation, it seems redundant, and > >> potentially problematic, to include the body-hash in the > >> Authentication header. The danger is that implementors may neglect to > >> recalculate the hash themselves, reusing the value (even if > >> incorrect) provided by the client. Why not just require the provider > >> to calculate this and validate it by comparing the final signature? > >> This way it's clearer for everyone what the expectations are in valida= ting > the signature. > >> > >> I propose either a flag (eg, usebodyhash=3D"1") or an algorithm > >> (bodyhashalgorithm=3D"sha1"). If this parameter was provided, the > >> correct hash would be added to the base string for signing. If > >> omitted (or set false?) then an empty string is used for base string > element #4. > >> > >> > >> On including parameters for signing... > >> > >> I'd retract my suggestion that we'd include parameter-hash in the head= er. > >> Instead, I would suggest making parameters optional in calculating > >> the signature using a flag as with bodyhash. Providers could require > >> including parameters if so desired. Parameters could be included as > >> currently defined, or with a hash method similar to entity-body > >> (which I find both simpler and more congruent). > >> > >> Again, the goal in making query parameters optional is to allow > >> providers to make signature calculation as simple as possible for > >> clients (so much as it is in line with the security requirements of > >> the provider) and avoid complexities in implementation such as those t= hat > tripped up OAuth 1. > >> > >> > >> > >> On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: > >> > >>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > >>> > >>> New version includes the following changes: > >>> > >>> o Added body-hash support. > >>> o Updated OAuth 2.0 reference to -12 and added token type > >>> registration > >> template. > >>> o Removed error and error URI attributes (codes were just a > >>> duplication > >> of the HTTP status codes). > >>> > >>> Feedback would be greatly appreciated. > >>> > >>> EHL > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > From skylar@kiva.org Tue Feb 8 00:57:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F123A6CC1 for ; Tue, 8 Feb 2011 00:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3-2-Q7WGSsg for ; Tue, 8 Feb 2011 00:57:01 -0800 (PST) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by core3.amsl.com (Postfix) with SMTP id E74323A6CB9 for ; Tue, 8 Feb 2011 00:57:00 -0800 (PST) Received: from source ([74.125.82.46]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTVEFYjmrdUVOgd9d5P8aM1mBKn/k7wcN@postini.com; Tue, 08 Feb 2011 00:57:07 PST Received: by wwj40 with SMTP id 40so6266266wwj.27 for ; Tue, 08 Feb 2011 00:57:05 -0800 (PST) Received: by 10.227.156.76 with SMTP id v12mr17072650wbw.177.1297155425112; Tue, 08 Feb 2011 00:57:05 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id x1sm4196125wbh.20.2011.02.08.00.57.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 00:57:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 8 Feb 2011 09:57:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B90B5BF-913C-402C-8A51-757B93EFD108@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 08:57:02 -0000 On Feb 8, 2011, at 6:45 AM, Eran Hammer-Lahav wrote: > This authentication method comes with well understood security = properties. By making query parameters optional because of developer = ease, providers will be giving up an important part of the protection = this protocol offers. This is especially true for the majority of APIs = where query parameters are critical to the request integrity. Is the same then not true of content body? Why require one and not the = other? Either you trust providers to decide when the content/parameter = portions of a request (or an API) are critical to request integrity, or = you don't. With that argument you should just require a body hash and be done with = it. What's the argument to make it an optional part of the base string? From anilbhat21@gmail.com Tue Feb 8 01:45:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FD33A7093 for ; Tue, 8 Feb 2011 01:45:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKVVroNSsLgT for ; Tue, 8 Feb 2011 01:45:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9243D3A7091 for ; Tue, 8 Feb 2011 01:45:17 -0800 (PST) Received: by vxi40 with SMTP id 40so2433814vxi.31 for ; Tue, 08 Feb 2011 01:45:23 -0800 (PST) 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=Dc+jCmEsy3JiNKhtXS3qIM/Ycm4vStX/xtgz4i9zHKQ=; b=JMXriarwPxDjepuR66aK801tVwzYtaDogVPWyLAQT1a9UdKrlYJJ2eRcC5OXnUbdhu G4Sgeq/1tCduBpyA98n90rF5X+PHZrF5S04lV85KclJk4cXVSkCk0QZdzfJrWTu3m3tb RAwIwth8AJnPGTKkWgDJru4sZQfVzvaIl6nqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KYIvxKkx6k38ZBKtxV3QffBrNNeGiMSS5vLcRx8cuDGCPJdkbDpnIkk+5puvbeCEq/ 8OFtMZPTwGwk7xr98Plzt3O9w/iLGHmbb4rX7IbqjNpU/J6PqA0Tu2ToI6RF+DieGbvI 36dXkT3/ObDmv2A+pDRL/RIS/dUHZ8XuU480c= MIME-Version: 1.0 Received: by 10.220.161.68 with SMTP id q4mr1255539vcx.211.1297158323691; Tue, 08 Feb 2011 01:45:23 -0800 (PST) Received: by 10.220.182.71 with HTTP; Tue, 8 Feb 2011 01:45:23 -0800 (PST) Date: Tue, 8 Feb 2011 15:15:23 +0530 Message-ID: From: Anil Bhat To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016e6476eaa19e127049bc2356a Subject: [OAUTH-WG] How to send parameter from facebook app and return the same X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:49:35 -0000 --0016e6476eaa19e127049bc2356a Content-Type: text/plain; charset=ISO-8859-1 Hi, I want to send user id as a parameter in my facebook app and want to return the same to keep track of the user who's connected to facebook from my app. I'm using Oauth2 methods - authorize_url and get_access_token. I tried to add parameter here but didn't work. If anyone has any idea, please share... -- Thanks and Regards, Anil Bhat +919811706514 --0016e6476eaa19e127049bc2356a Content-Type: text/html; charset=ISO-8859-1 Hi,

I want to send user id as a parameter in my facebook app and want to
return the same to keep track of the user who's connected to facebook
from my app. I'm using Oauth2 methods - authorize_url and
get_access_token. I tried to add parameter here but didn't work. If
anyone has any idea, please share...

--
Thanks and Regards,
Anil Bhat
+919811706514
--0016e6476eaa19e127049bc2356a-- From hannes.tschofenig@nsn.com Tue Feb 8 05:28:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69AF3A68D4 for ; Tue, 8 Feb 2011 05:28:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52z5hhKC8tyF for ; Tue, 8 Feb 2011 05:28:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 682663A6FF3 for ; Tue, 8 Feb 2011 05:28:03 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p18DRx0b014080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Feb 2011 14:27:59 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p18DRvsf007297; Tue, 8 Feb 2011 14:27:59 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 14:27:48 +0100 Received: from 10.144.239.25 ([10.144.239.25]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Feb 2011 13:27:47 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 08 Feb 2011 15:27:36 +0200 From: Hannes Tschofenig To: Hammer-Lahav Hammer-Lahav , Torsten Lodderstedt , Brian Eaton Message-ID: Thread-Topic: [OAUTH-WG] who is working on security considerations? Thread-Index: AcvG9c9KjnWkK31DSJWybJk3ARtgpQAAKnVwACdedGY= In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFC77@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2011 13:27:48.0554 (UTC) FILETIME=[FA69AAA0:01CBC793] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] who is working on security considerations? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:28:04 -0000 Certainly right, Eran. Torsten, submit the draft ASAP. On 2/7/11 8:40 PM, "Hammer-Lahav Hammer-Lahav" wrote: > It would probably be helpful to do this work in public. If not via I-Ds (even > if very rough) than via github etc. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Monday, February 07, 2011 10:35 AM >> To: Brian Eaton >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] who is working on security considerations? >> >> Hi Brian, >> >> Mark McGloin, Phil Hunt and I are working on a security considerations >> document. We plan to submit it to the working group in the next couple of >> weeks. Your contribution would be highly appreciated. What would you like >> to contribute? >> >> regards, >> Torsten. >> >> Am 07.02.2011 19:09, schrieb Brian Eaton: >>> Has anyone stepped up to start writing security considerations yet? >>> >>> Now that the organization is back to tracking different use cases >>> using different flows, I think it's feasible and would like to >>> contribute. >>> _______________________________________________ >>> 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 Feb 8 07:46:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DE53A67FB for ; Tue, 8 Feb 2011 07:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9HoBbItKN77 for ; Tue, 8 Feb 2011 07:46:25 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC0D93A67E5 for ; Tue, 8 Feb 2011 07:46:23 -0800 (PST) Received: (qmail 12311 invoked from network); 8 Feb 2011 15:46:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 15:46:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 8 Feb 2011 08:46:23 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Tue, 8 Feb 2011 08:46:09 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvHbixZvFmeCygKRrS/vly66OXzxgAOOMDg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFE6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A4C1B6B-7D51-4D12-A468-5A5991D72DCB@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8B90B5BF-913C-402C-8A51-757B93EFD108@kiva.org> In-Reply-To: <8B90B5BF-913C-402C-8A51-757B93EFD108@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] draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:46:26 -0000 While important, the body is not always available for inspection and hashin= g. All the parameters normalization is done to ensure it will be possible o= n even the most limited platform. The same cannot be done for the body. Tha= t's why it is optional. EHL > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Tuesday, February 08, 2011 12:57 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > On Feb 8, 2011, at 6:45 AM, Eran Hammer-Lahav wrote: > > This authentication method comes with well understood security > properties. By making query parameters optional because of developer > ease, providers will be giving up an important part of the protection thi= s > protocol offers. This is especially true for the majority of APIs where q= uery > parameters are critical to the request integrity. >=20 > Is the same then not true of content body? Why require one and not the > other? Either you trust providers to decide when the content/parameter > portions of a request (or an API) are critical to request integrity, or y= ou don't. >=20 > With that argument you should just require a body hash and be done with = it. > What's the argument to make it an optional part of the base string? From mscurtescu@google.com Tue Feb 8 09:23:54 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E546D3A67F3 for ; Tue, 8 Feb 2011 09:23:54 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIebCPnkGKUj for ; Tue, 8 Feb 2011 09:23:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9B0873A67AD for ; Tue, 8 Feb 2011 09:23:53 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p18HNxpk028455 for ; Tue, 8 Feb 2011 09:24:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297185840; bh=AF8yaPvaDqavXFFn/HZZ2HUzVOM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Hg9O9D+blxv72DrP+3rT8dqbx/deQWChqnHVyKM0+AM6oHgkjdq7qCgSh9nsXSvL/ eTqe8dyTx4FS8XEhqndAQ== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by kpbe19.cbf.corp.google.com with ESMTP id p18HNfQm031253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 09:23:58 -0800 Received: by yxl31 with SMTP id 31so2644697yxl.4 for ; Tue, 08 Feb 2011 09:23:58 -0800 (PST) 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=oF0SoWS3Ob8xzmWGX7+pXWB9+rm/msV878kIkHOnQnM=; b=vhZE3lWuSCm3Wcwp1cwKQ72dnL0YYviIQtt7HRO7kAVzAwrWnUUsbVHFRQg6zfRiRk wN5IfnqtFnrgGCF6vYoA== 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=I40NmbGG6eVdSG2U0pX9veO0jlwb6nFEJ1DiiFHKL3Tggx2A2wuWl+HIACU8kwwGcQ ftEzG8c1cDZfl7lemZww== Received: by 10.101.8.27 with SMTP id l27mr7312673ani.130.1297185838481; Tue, 08 Feb 2011 09:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Tue, 8 Feb 2011 09:23:38 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 8 Feb 2011 09:23:38 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:23:55 -0000 On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav wro= te: > Mike, Brian, Dirk, and Marius =96 can you live with #1? Works for me. Marius From Michael.Jones@microsoft.com Tue Feb 8 09:45:44 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA7E3A681B for ; Tue, 8 Feb 2011 09:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXaY1gg3dp9n for ; Tue, 8 Feb 2011 09:45:44 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 105923A6814 for ; Tue, 8 Feb 2011 09:45:43 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 09:45:51 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 09:45:50 -0800 From: Mike Jones To: Marius Scurtescu , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwD1zY4AACkZkAAAECDlUA== Date: Tue, 8 Feb 2011 17:45:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432472DEA5@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] 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 type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:45:44 -0000 I'm likewise OK with #1. As I'd written previously, I wasn't religious abo= ut the name "OAuth2"; I was for it for to be consistent with past drafts an= d so as not to introduce a breaking change. Given that there appears to be= consensus to make a change, I'll plan on publishing a draft later this wee= k that contains it unless discussion in the next few days convinces us that= we should follow a different course. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Tuesday, February 08, 2011 9:24 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav wro= te: > Mike, Brian, Dirk, and Marius - can you live with #1? Works for me. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Tue Feb 8 11:49:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF2C3A67C3 for ; Tue, 8 Feb 2011 11:49:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S+rMVpnNxDx for ; Tue, 8 Feb 2011 11:49:41 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C8C5F3A67F6 for ; Tue, 8 Feb 2011 11:49:40 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p18JnicS025191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 13:49:44 -0600 (CST) 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 p18JnhSq017510; Tue, 8 Feb 2011 13:49:43 -0600 (CST) Message-ID: <4D519E57.8040201@alcatel-lucent.com> Date: Tue, 08 Feb 2011 14:49:43 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kristoffer Gronowski References: <4D509A79.706@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 19:49:45 -0000 Definitely, we have many common ideas! I think we need to get an I-D out with a crisp proposal. Igor Kristoffer Gronowski wrote: > Hi Igor! > > That is exactly what I would like to explore! > My thinking was that the authorization server should be quite simple. > There should be no advanced things like a policy server inside it. > > As long as the authorization (AS) and the resource servers (RS) use the same identity source (or trusted federation of it). > I was thinking of a simple interface that can work in layers. > 1) The RS can ask the AS is this a valid token yes/no > 2) Is this a valid token containing the following scopes? > 3) Was this a token issued by a particular user X. (Based on sharing or trusting in the identity source) > > Or a combination of the above. In this way you can at least do a good separation of concerns. > Except of the answer if the criteria was met I have been experimenting also in returning metadata from the AS so that a RS interceptor can be built. > You would get all data about token lifetime, scopes attached and owner information. > This would be a combination with the request input parameters. So you can start off with making sure that #1 is valid. > Since the token needs to have been generated by the AS. > Then if you have a more dynamic policy that is very endpoint specific it is far easier to implement it in code then in a general purpose policy server. > > Then you can easily implement things like this protected resource needs scope X or Y Mon-Fri while Z on weekends. > Another advantage is that the same code can work on your behalf in discovery mode to actually give you a clue what is needed at this very moment to access. > The AS is just following strict rules and giving facts to you as a RS. > > It is a pretty clean design but I am sure that it will not fit everyone's needs. > And I am not saying that policy server would go away but for simple REST services this is a powerful framework where you do not have to mash all of you implementation into one big thing. > > So that it why I was thinking that it might be a candidate for an optional interface that might be good to have. > With it people can develop Oauth protected services quicker since there is more ready code to start from. > > Does this still fit your vision too described this way? > > BR Kristoffer > > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] > Sent: Monday, February 07, 2011 5:21 PM > To: Kristoffer Gronowski > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Working Group Items? > > Kristoffer, > > I assume you mean an interface between the authorization server and the resource server. If so, I believe it definitely merits a serious discussion, and I support the idea in principle. > > On this subject, I think we need even more work defining the token and linking it to the resource owner. Today's discussion between Eran and Phil once again made me think of insufficiency of the "opaque tokens." > Indeed, anything that comes with the OAuth flow is an OAuth token. (From the security point of view, of course, that also means that anything that can be INSERTED into an OAuth flow will be an OAuth token...) I am not criticizing the design decisions--I have agreed with all of them. > > But going forward, I would like the resource owner, the end user (both human and virtual) to 1) issue tokens or 2) outsource this work it it wishes. In the latter case, the resource owner must at least understand what the token has rather than just pass the token. > > Ideally, I would like this to be an OAuth work item: OAuth WG works very well, and it has gathered the best people to judge the task. I understand though that token specification is not presently in the charter, and therefore it can be discussed only in the context of changing the charter. And so I first wrote this in response to the item that you proposed, which I think is one step toward what I thought should be done. > > Igor > > Kristoffer Gronowski wrote: > >> ... >> IMO there is one item missing and that is to create an optional formal >> interface between the authorization server and the protected resource. >> It could increase the productivity of creating the oauth protected web >> services when the auth server can be treated as an off the shelf piece >> of code. >> Then it would be up to the auth server to also provide an number of >> other extension like the discovery, token revocation and other. >> > > > >> >> >> From jricher@mitre.org Tue Feb 8 12:01:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98AAD3A67C3 for ; Tue, 8 Feb 2011 12:01:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAznP7B0vB+6 for ; Tue, 8 Feb 2011 12:01:00 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 1D68C3A686C for ; Tue, 8 Feb 2011 12:00:58 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6205821B1033 for ; Tue, 8 Feb 2011 15:01:06 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5EAE921B1031 for ; Tue, 8 Feb 2011 15:01:06 -0500 (EST) Received: from [172.31.17.166] (172.31.17.166) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 8 Feb 2011 15:01:05 -0500 Message-ID: <4D51A100.6040608@mitre.org> Date: Tue, 8 Feb 2011 15:01:04 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <4D4AD58E.9090407@gmx.net> In-Reply-To: <4D4AD58E.9090407@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:01:01 -0000 > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ In favor of adopting as WG item, willing to review. > C) Token Revocation > http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01 In favor of adopting as WG item, willing to review. > E) OAuth 2.0 User Experience Extension > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 In favor of adopting as WG item, willing to review. > H) OAuth Use Cases > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases Don't think it's really a WG item, but worth keeping around. Also, should be merged with UMA use cases. > I) OAuth Client Instance Extension > http://datatracker.ietf.org/doc/draft-richer-oauth-instance/ > > J) XML Encoding for OAuth 2 > http://datatracker.ietf.org/doc/draft-richer-oauth-xml/ I'm the editor for both of these and would like to see them adopted as WG items. -- Justin From igor.faynberg@alcatel-lucent.com Tue Feb 8 12:23:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164433A681D for ; Tue, 8 Feb 2011 12:23:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifn2pWcr4svW for ; Tue, 8 Feb 2011 12:23:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 061733A680E for ; Tue, 8 Feb 2011 12:23:38 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18KNhEP010551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 14:23:43 -0600 (CST) 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 p18KNdGi019659; Tue, 8 Feb 2011 14:23:40 -0600 (CST) Message-ID: <4D51A64A.4050001@alcatel-lucent.com> Date: Tue, 08 Feb 2011 15:23:38 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hannes Tschofenig References: <4D4AD58E.9090407@gmx.net> In-Reply-To: <4D4AD58E.9090407@gmx.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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 20:23:40 -0000 Hannes, A comprehensive list! I am in support of all items listed, and I commit to reviewing all of them (and contributing where I will see significant gaps). One comment on the use cases (my pet peeve). Those were specifically requested by Peter at the first OAuth meeting, and I think they were requested for a very good reason. Even then--and more often now--whenever a feature appears, there comes up a question "What is the use case?" Then a discussion starts. Then the feature is agreed on and added. And then... someone who was not present at the previous discussion looks at the protocol spec asks a question: "What is the use case for this?.." I think a lot of time would have been saved, if every feature had been linked to a crisp use case. As the capabilities of OAuth grow, the protocol specification will become soon overwhelming if not altogether unreadable: people think it terms of services rather than combinations of parameters and messages. I strongly believe that we will much more effective if we develop--and document the protocol--top down. Igor Hannes Tschofenig wrote: > .... > > * I need your feedback (hence this mail) of what you guys want to work on > * I have to draft a charter text (and the group needs to be happy with > it) > * the IESG (who receives the charter text) also needs to agree with it > * finally the documents need to be submitted as working group items > and progressed in the group. > > > > > > A) Simple Web Discovery (SWD) > http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ > C) Token Revocation > http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01 Review. > > D) OAuth 2.0 Device Profile > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 > > E) OAuth 2.0 User Experience Extension > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > F) Request by Reference ver.1.0 for OAuth 2.0 > http://tools.ietf.org/html/draft-sakimura-oauth-requrl > > G) OAuth Dynamic Client Registration Protocol > http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 > > H) OAuth Use Cases > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases > > I) OAuth Client Instance Extension > http://datatracker.ietf.org/doc/draft-richer-oauth-instance/ > > J) XML Encoding for OAuth 2 > http://datatracker.ietf.org/doc/draft-richer-oauth-xml/ > > K) OAuth 2.0 support for the Kerberos V5 Authentication Protocol > http://datatracker.ietf.org/doc/draft-hardjono-oauth-kerberos > > Please let me know if I have forgotten something. > > I also hope that Torsten is able to submit a security document soon! > > Ciao > Hannes > > PS: You may notice that I haven't placed > http://tools.ietf.org/html/draft-jones-json-web-token-01 on the list > yet since I believe we will get push-back from the IESG on that item > at the moment. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From michael.d.adams@gmail.com Tue Feb 8 13:05:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0EA3A6857 for ; Tue, 8 Feb 2011 13:05:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJcOmGSYdKoB for ; Tue, 8 Feb 2011 13:05:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C04163A67F3 for ; Tue, 8 Feb 2011 13:05:35 -0800 (PST) Received: by fxm9 with SMTP id 9so7017904fxm.31 for ; Tue, 08 Feb 2011 13:05:42 -0800 (PST) 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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=vcOugJAIzn7ou3RzkwSoTVpUDMyH5z3C4Elo6hQjlTQ=; b=DdZLvOEyl+WHenV7KC/CDvw1SaKQkQBqT+y8D+PgcNjifmP3QE7Uld+a787LGZa+4X z/wfoJnDZ0OTkV5loRuQKSAjn3rVa5klME1yHCwyhaZawA1+Q8Um2nI4kCOK0u6dXOmW 7olzenyqI4hT6LflarBN+fD0U4YlDL4Y5bbso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=enfeWoQ1YiJwbzsZgLk/3AJbBzdZ+oDzIKIk/NywSNv6BUOwRospUpGOUhLO0DPsDH JvqeueWD8CSBFzmCKD9iWk4WJOikM7/1PRKuIxVxWb3hrw2D6QnIBScVCgtggeTCd4er QupOmgVZRoCp1NJ0RFMnmQMuM980wDvFwk5Zo= Received: by 10.223.86.135 with SMTP id s7mr16946333fal.70.1297199142648; Tue, 08 Feb 2011 13:05:42 -0800 (PST) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.223.13.5 with HTTP; Tue, 8 Feb 2011 13:05:22 -0800 (PST) In-Reply-To: References: From: Michael D Adams Date: Tue, 8 Feb 2011 13:05:22 -0800 X-Google-Sender-Auth: pi71C8JeQE0vW52MEvtjNjX-z3c Message-ID: To: Anil Bhat Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] How to send parameter from facebook app and return the same X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:05:37 -0000 On Tue, Feb 8, 2011 at 1:45 AM, Anil Bhat wrote: > Hi, > > I want to send user id as a parameter in my facebook app and want to > return the same to keep track of the user who's connected to facebook > from my app. I'm using Oauth2 methods - authorize_url and > get_access_token. I tried to add parameter here but didn't work. If > anyone has any idea, please share... Hi Anil, This mailing list is for discussing the design of the OAuth2 protocol itself, not for how to use its implementation on specific sites (such as Facebook). I believe you'll find the help you need at: http://developers.facebook.com/docs/ http://forum.developers.facebook.net/ From wmills@yahoo-inc.com Tue Feb 8 14:40:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF83A6884 for ; Tue, 8 Feb 2011 14:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.486 X-Spam-Level: X-Spam-Status: No, score=-17.486 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bSwZY0hvhKx for ; Tue, 8 Feb 2011 14:40:29 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 1DFD63A687A for ; Tue, 8 Feb 2011 14:40:29 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p18MdxcP055019; Tue, 8 Feb 2011 14:39:59 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Tue, 8 Feb 2011 14:39:58 -0800 From: William Mills To: Eran Hammer-Lahav , Torsten Lodderstedt Date: Tue, 8 Feb 2011 14:39:57 -0800 Thread-Topic: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4ygAAFylZAAJx9DsA== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@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: Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:40:30 -0000 So, if we go with the Link approach and we are thinking in the context of t= he MAC token draft, how is realm used in some sane way? Am I right that a = server might know of multiple ways to obtain a MAC token? Should we define= the realm "oauth2" and then have that imply the link relationship names? = This would mean we can support: WWW-Authenticate: MAC realm=3D"oauth2" WWW-Authenticate: MAC realm=3D"x-newspec" Link: rel=3D"oath2-toke= n" Link: rel=3D"oath2-auth" Link: rel=3D"x-newspec" If we do define the realm this way, should this go into the core spec? -bill > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Monday, February 07, 2011 3:07 PM > To: William Mills; Torsten Lodderstedt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme name > (deadline: 2/10) > > I'm a strong advocate of the Link approach, given that authorization > information does not belong on the authentication headers. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of William Mills > > Sent: Monday, February 07, 2011 2:50 PM > > To: Torsten Lodderstedt > > Cc: OAuth WG > > Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme name > > (deadline: 2/10) > > > > OK. > > > > So then the question is the right way to communicate token endpoints. > Is it > > cleaner/preferred to have everything in the WWW-Authenticate header, > or > > to break things out so we're not stuffing a lot into those headers > and > > repeating outselves? So, all in one would be: > > > > WWW-Authenticate: MAC realm=3D"somerealm" > > token_url=3D"http://login.example.com/token" > > auth_url=3D"http://login.example.com/webauth" > > > > Broken out might be: > > > > WWW-Authenticate: MAC realm=3D"OAuth2" > > Link: rel=3D"oath= 2- > > token" > > Link: > > > > ah> rel=3D"oath2-auth" > > > > -bill > > > > > -----Original Message----- > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > > Sent: Saturday, February 05, 2011 10:21 AM > > > To: William Mills > > > Cc: Phil Hunt; OAuth WG > > > Subject: Re: [OAUTH-WG] Bearer token type and scheme name > (deadline: > > > 2/10) > > > > > > that's not the way WWW-Authenticate headers are used today. Instead > > > the resource server should return a single WWW-Authenticate header > > > _per_ supported authentication scheme, such as > > > > > > WWW-Authenticate: MAC realm=3D"somerealm" > > > WWW-Authenticate: BEARER realm=3D"somerealm" > > > > > > furthermore, I think interdependencies among WWW-Authenticate > > headers > > > as suggested by Phil > > > > > > WWW-Authenticate: OAuth > > > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyy > > > > > > could be rather fragile. > > > > > > I would expect the WWW-Authenticate header to return all the data > > > required to obtain the credentials/tokens, such as > > > > > > WWW-Authenticate: MAC realm=3D"somerealm", > > > tokenUrl=3D"yyyyy&token_secret=3Dyes" > > > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" > > > > > > Which raises the question whether the coupling between > authentication > > > schemes and the OAuth2 core protocol is stronger than assumed. > > > > > > please als see http://www.ietf.org/mail- > > > archive/web/oauth/current/msg04988.html > > > > > > regards, > > > Torsten. > > > > > > Am 04.02.2011 22:39, schrieb William Mills: > > > > > > > I was thinking along the lines of simply returning the HTTP > > > Authorization header schemes that are supported. In the OAuth 2 > > > context that would be > > > > > > > > WWW-Authenticate: 401 error=3D"blah blah blah" > auth_types=3D"Bearer > > > MAC Basic" > > > > > > > > The client has to be aware of the authentication scheme names. > > > > > > > > -bill > > > > > > > >> -----Original Message----- > > > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > > >> Sent: Friday, February 04, 2011 1:14 PM > > > >> To: William Mills > > > >> Cc: Marius Scurtescu; OAuth WG > > > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > (deadline: > > > >> 2/10) > > > >> > > > >> I agree, that is still to be defined. There seems to be some > push > > > back > > > >> on discovery, but this is likely warranted. If only because web > > > sites > > > >> may have both browser clients and app clients. > > > >> > > > >> In a previous message, I did suggest the web site return HTTP > 401 > > > >> as below... > > > >>>> 401 Unauthorized > > > >>>> WWW-Authenticate: Basic realm=3D"tokenSvc" > > > >>>> WWW-Authenticate: Digest realm=3D"tokenSvc" > > > >>>> WWW-Authenticate: Form > > > >> url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" > > > >> > > > >> It could also include other items for "MAC", etc. > > > >> > > > >> The only other issue would be determining whether the token is > > > obtained > > > >> via an OAuth profile or via some default profile. That could be > > > >> handled with something like: > > > >> > > > >> WWW-Authenticate: Basic realm=3D"somerealm" > > > >> WWW-Authenticate: MAC realm=3D"somerealm" > > > >> WWW-Authenticate: OAuth > > > >> token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyyy= " > > > >> > > > >> The above would suggest that MAC tokens could be used alone as > > > >> described in some specification for "MAC". However, the > presence > > > >> of the OAuth header indicates that MAC and BEARER tokens can be > > > >> used in the OAuth pattern. > > > >> > > > >> I think this allows both de-coupling of tokens from OAuth but > also > > > >> informs clients what tokens can be used with OAuth. > > > >> > > > >> There may be other ways to do this. But it does help with the > > > >> decoupling. > > > >> > > > >> Phil > > > >> phil.hunt@oracle.com > > > >> > > > >> > > > >> > > > >> > > > >> On 2011-02-04, at 11:44 AM, William Mills wrote: > > > >> > > > >>> I was thinking more about how the client knows what to use. > The > > > >> ubiquitous "service documentation" may come in to play here. > Some > > > form > > > >> of serv ice discovery/webfinger thing could also be used. > > > >>>> -----Original Message----- > > > >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > > >>>> Sent: Friday, February 04, 2011 11:37 AM > > > >>>> To: William Mills > > > >>>> Cc: Marius Scurtescu; OAuth WG > > > >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > > (deadline: > > > >>>> 2/10) > > > >>>> > > > >>>> Yes. This should be defined in each token type specification. > > > >>>> > > > >>>> Phil > > > >>>> phil.hunt@oracle.com > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 2011-02-04, at 11:29 AM, William Mills wrote: > > > >>>> > > > >>>>> The only challenge is to know what scheme to use and what the > > > >> nuances > > > >>>> are of how to present the credential. > > > >>>>>> -----Original Message----- > > > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > On > > > >>>> Behalf > > > >>>>>> Of Phil Hunt > > > >>>>>> Sent: Friday, February 04, 2011 9:42 AM > > > >>>>>> To: Marius Scurtescu > > > >>>>>> Cc: OAuth WG > > > >>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > > >> (deadline: > > > >>>>>> 2/10) > > > >>>>>> > > > >>>>>> OAuth should be able to support other token schemes. > > > >>>>>> > > > >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, > or > > > >>>>>> whatever. > > > >>>>>> > > > >>>>>> Phil > > > >>>>>> phil.hunt@oracle.com > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > > > >>>>>> > > > >>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > > > >>>>>> wrote: > > > >>>>>>>> Hey Marius, > > > >>>>>>>> > > > >>>>>>>>> -----Original Message----- > > > >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > > > >>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM > > > >>>>>>>>> To: Eran Hammer-Lahav > > > >>>>>>>>> Cc: OAuth WG > > > >>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme > > name > > > >>>>>> (deadline: > > > >>>>>>>>> 2/10) > > > >>>>>>>>> > > > >>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > > > >>>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes > > > >>>>>>>>>> > > > >>>>>>>>>> Define a single authentication scheme for all token > types > > > with > > > >>>>>> some > > > >>>>>>>>>> attribute used to detect which scheme is actually being > > > used. > > > >>>>>>>>>> > > > >>>>>>>>>> Benefits: > > > >>>>>>>>>> > > > >>>>>>>>>> - single scheme, reuse of the 1.0 pattern. > > > >>>>>>>>>> > > > >>>>>>>>>> Downsides: > > > >>>>>>>>>> > > > >>>>>>>>>> - requires a new registry for authentication header > > > >> parameters. > > > >>>>>>>>> How is this different from option 1? Wouldn't that need > some > > > >>>>>> registry? > > > >>>>>>>> #1 relies on the existing practice of creating HTTP scheme > > > names > > > >>>> (no > > > >>>>>> current registry but httpbis might be creating one), as well > as > > > >> the > > > >>>> -12 > > > >>>>>> token type registry. Using a sub-scheme means you also need > a > > > >>>> registry > > > >>>>>> for the header attributes that each token type will need > > > >>>>>> (unless > > > >> you > > > >>>>>> just don't care about using the same attribute name for > > > different > > > >>>>>> needs). > > > >>>>>>> Sure, there is no registry for schemes yet, but we would > still > > > >> need > > > >>>>>>> some coordination. The fact that a sub-scheme needs a > registry > > > >> that > > > >>>>>> we > > > >>>>>>> control is a benefit not a downside IMO. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>>> - schemes are not easily reusable outside OAuth. > > > >>>>>>>>> Sure. But I really don't see this group trying to create > > > >> generic > > > >>>>>> authentication > > > >>>>>>>>> schemes. > > > >>>>>>>> MAC is exactly that. > > > >>>>>>> May or may not be. My point is that this group is not > focused > > > on > > > >>>>>>> creating generic authentication schemes. Are you aware of > any > > > >> other > > > >>>>>>> protocols that might use MAC or BEARER? Are we willing to > put > > > in > > > >>>> the > > > >>>>>>> effort to create generic schemes? Is it our charter? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>>> - existing frameworks usually switch on scheme name, not > on > > > >> sub > > > >>>>>>>>>> scheme, which will cause difficulty in some deployments. > > > >>>>>>>>> I can see this as a potential problem. But considering > that > > > >> there > > > >>>>>> wasn't much > > > >>>>>>>>> objection to use "OAuth" as a scheme name before (total > > > overlap > > > >>>>>> with > > > >>>>>>>>> OAuth 1, and the suggested solution was to look for the > > > >> signature > > > >>>>>>>>> parameter) I don't see how this is suddenly an issue. > > > >>>>>>>> There was pretty strong objection to reusing OAuth. > > > >>>>>>> Yes, because there was no sub-scheme nor version (and the > > > grammar > > > >>>> was > > > >>>>>>> totally broken). Even so, lots of implementations went > ahead > > > and > > > >>>> did > > > >>>>>>> it. Were there any scheme switching issues we are aware of? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> Do we have a concrete problem here or this is just > > > theoretical? > > > >>>>>>>> This came up during the review of > > > >>>>>>>> draft-hammer-http-token-auth > > > >>>> [1]. > > > >>>>>> There was a long thread about it where people posted actual > > > >>>> framework > > > >>>>>> issues. > > > >>>>>>>>>> - potential to produce a very complicated scheme once > many > > > sub > > > >>>>>> schemes > > > >>>>>>>>>> are added. > > > >>>>>>>>> Why? I would argue that this option actually produces > more > > > >>>> uniform > > > >>>>>>>>> schemes because it forces all of them to be name/value > pairs. > > > >>>>>> Beyond > > > >>>>>>>>> token_type everything is scheme specific. I really don't > see > > > >> what > > > >>>>>> is very > > > >>>>>>>>> complicate here. > > > >>>>>>>> It is still a single scheme with many different sub- > schemes, > > > >> each > > > >>>>>> with different key-value pairs that may have conflicting > > > meaning. > > > >>>> The > > > >>>>>> way I look at it is that if I try to fully implement this > mega > > > >>>> scheme > > > >>>>>> (which means all its sub-schemes), it will likely be a > > > complicated > > > >>>>>> task. On the other hand, if you split it across scheme name, > we > > > >>>> already > > > >>>>>> have a well-established system in place to pick and choose > HTTP > > > >>>>>> authentication schemes. > > > >>>>>>> No one has to implement a mega scheme. All schemes must use > > > >>>>>> name/value > > > >>>>>>> pairs and that's where the common part stops. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>>> - requires its own discovery method for which schemes > are > > > >>>>>> supported. > > > >>>>>>>>> Why is this a downside only for this option? > > > >>>>>>>> Because the other options get this for free by using the > WWW- > > > >>>>>> Authenticate header (since each scheme has a unique name). > You > > > can > > > >>>> list > > > >>>>>> multiple headers in the 401 response. > > > >>>>>>> I thought we dropped WWW-Authenticate. Why cannot WWW- > > > >> Authenticate > > > >>>>>>> work for sub-schemes as well? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> Should I record your vote for #2? > > > >>>>>>> #2 or #3 > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> 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 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Feb 8 14:47:10 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C30B3A68CC for ; Tue, 8 Feb 2011 14:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG2Z5JSONEyC for ; Tue, 8 Feb 2011 14:47:08 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2F2D43A68C8 for ; Tue, 8 Feb 2011 14:47:07 -0800 (PST) Received: (qmail 12918 invoked from network); 8 Feb 2011 22:47:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 22:47:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 8 Feb 2011 15:47:09 -0700 From: Eran Hammer-Lahav To: William Mills , Torsten Lodderstedt Date: Tue, 8 Feb 2011 15:46:53 -0700 Thread-Topic: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvFYX8Vj/ZV19FNT6ieMus6FZUBtwBtF4ygAAFylZAAJx9DsAAKbF7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFFD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB341C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <500DC355-E308-4BDA-817F-FC5CCED45172@oracle.com> <97468434-860E-4E65-BBF2-A61088C9FB02@oracle.com> <120D927A-EC25-4ED2-A8DA-887FEACC9143@oracle.com> <4D4D9514.2090604@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A90BFD67@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] Discovery RE: Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:47:10 -0000 Realm is really only useful when MAC is used outside of OAuth like Basic or= Digest and informs the client when it should try and reuse the same creden= tials. But with OAuth, presumably, the server will tell the client (using a= parameter or documentation) where to use the token, making realm pointless= . EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Tuesday, February 08, 2011 2:40 PM > To: Eran Hammer-Lahav; Torsten Lodderstedt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme > name (deadline: 2/10) > > So, if we go with the Link approach and we are thinking in the context of= the > MAC token draft, how is realm used in some sane way? Am I right that a > server might know of multiple ways to obtain a MAC token? Should we > define the realm "oauth2" and then have that imply the link relationship > names? This would mean we can support: > > WWW-Authenticate: MAC realm=3D"oauth2" > WWW-Authenticate: MAC realm=3D"x-newspec" > Link: rel=3D"oath2- > token" > Link: rel=3D"oath2-auth" > Link: rel=3D"x-newspec" > > If we do define the realm this way, should this go into the core spec? > > -bill > > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Monday, February 07, 2011 3:07 PM > > To: William Mills; Torsten Lodderstedt > > Cc: OAuth WG > > Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme > > name > > (deadline: 2/10) > > > > I'm a strong advocate of the Link approach, given that authorization > > information does not belong on the authentication headers. > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > Behalf > > > Of William Mills > > > Sent: Monday, February 07, 2011 2:50 PM > > > To: Torsten Lodderstedt > > > Cc: OAuth WG > > > Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme > name > > > (deadline: 2/10) > > > > > > OK. > > > > > > So then the question is the right way to communicate token endpoints. > > Is it > > > cleaner/preferred to have everything in the WWW-Authenticate header, > > or > > > to break things out so we're not stuffing a lot into those headers > > and > > > repeating outselves? So, all in one would be: > > > > > > WWW-Authenticate: MAC realm=3D"somerealm" > > > token_url=3D"http://login.example.com/token" > > > auth_url=3D"http://login.example.com/webauth" > > > > > > Broken out might be: > > > > > > WWW-Authenticate: MAC realm=3D"OAuth2" > > > Link: > > > rel=3D"oath2- token" > > > Link: > > > > > > > l > > > ah> rel=3D"oath2-auth" > > > > > > -bill > > > > > > > -----Original Message----- > > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > > > Sent: Saturday, February 05, 2011 10:21 AM > > > > To: William Mills > > > > Cc: Phil Hunt; OAuth WG > > > > Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > (deadline: > > > > 2/10) > > > > > > > > that's not the way WWW-Authenticate headers are used today. > > > > Instead the resource server should return a single > > > > WWW-Authenticate header _per_ supported authentication scheme, > > > > such as > > > > > > > > WWW-Authenticate: MAC realm=3D"somerealm" > > > > WWW-Authenticate: BEARER realm=3D"somerealm" > > > > > > > > furthermore, I think interdependencies among WWW-Authenticate > > > headers > > > > as suggested by Phil > > > > > > > > WWW-Authenticate: OAuth > > > > token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyyy > > > > > > > > could be rather fragile. > > > > > > > > I would expect the WWW-Authenticate header to return all the data > > > > required to obtain the credentials/tokens, such as > > > > > > > > WWW-Authenticate: MAC realm=3D"somerealm", > > > > tokenUrl=3D"yyyyy&token_secret=3Dyes" > > > > WWW-Authenticate: BEARER realm=3D"somerealm", tokenUrl=3D""yyyyy" > > > > > > > > Which raises the question whether the coupling between > > authentication > > > > schemes and the OAuth2 core protocol is stronger than assumed. > > > > > > > > please als see http://www.ietf.org/mail- > > > > archive/web/oauth/current/msg04988.html > > > > > > > > regards, > > > > Torsten. > > > > > > > > Am 04.02.2011 22:39, schrieb William Mills: > > > > > > > > > I was thinking along the lines of simply returning the HTTP > > > > Authorization header schemes that are supported. In the OAuth 2 > > > > context that would be > > > > > > > > > > WWW-Authenticate: 401 error=3D"blah blah blah" > > auth_types=3D"Bearer > > > > MAC Basic" > > > > > > > > > > The client has to be aware of the authentication scheme names. > > > > > > > > > > -bill > > > > > > > > > >> -----Original Message----- > > > > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > > > >> Sent: Friday, February 04, 2011 1:14 PM > > > > >> To: William Mills > > > > >> Cc: Marius Scurtescu; OAuth WG > > > > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > > (deadline: > > > > >> 2/10) > > > > >> > > > > >> I agree, that is still to be defined. There seems to be some > > push > > > > back > > > > >> on discovery, but this is likely warranted. If only because > > > > >> web > > > > sites > > > > >> may have both browser clients and app clients. > > > > >> > > > > >> In a previous message, I did suggest the web site return HTTP > > 401 > > > > >> as below... > > > > >>>> 401 Unauthorized > > > > >>>> WWW-Authenticate: Basic realm=3D"tokenSvc" > > > > >>>> WWW-Authenticate: Digest realm=3D"tokenSvc" > > > > >>>> WWW-Authenticate: Form > > > > >> url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" > > > > >> > > > > >> It could also include other items for "MAC", etc. > > > > >> > > > > >> The only other issue would be determining whether the token is > > > > obtained > > > > >> via an OAuth profile or via some default profile. That could > > > > >> be handled with something like: > > > > >> > > > > >> WWW-Authenticate: Basic realm=3D"somerealm" > > > > >> WWW-Authenticate: MAC realm=3D"somerealm" > > > > >> WWW-Authenticate: OAuth > > > > >> token=3D"MAC;BEARER",authorizationUrl=3D"xxxxx",tokenUrl=3D"yyyy= yy" > > > > >> > > > > >> The above would suggest that MAC tokens could be used alone as > > > > >> described in some specification for "MAC". However, the > > presence > > > > >> of the OAuth header indicates that MAC and BEARER tokens can be > > > > >> used in the OAuth pattern. > > > > >> > > > > >> I think this allows both de-coupling of tokens from OAuth but > > also > > > > >> informs clients what tokens can be used with OAuth. > > > > >> > > > > >> There may be other ways to do this. But it does help with the > > > > >> decoupling. > > > > >> > > > > >> Phil > > > > >> phil.hunt@oracle.com > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On 2011-02-04, at 11:44 AM, William Mills wrote: > > > > >> > > > > >>> I was thinking more about how the client knows what to use. > > The > > > > >> ubiquitous "service documentation" may come in to play here. > > Some > > > > form > > > > >> of serv ice discovery/webfinger thing could also be used. > > > > >>>> -----Original Message----- > > > > >>>> From: Phil Hunt [mailto:phil.hunt@oracle.com] > > > > >>>> Sent: Friday, February 04, 2011 11:37 AM > > > > >>>> To: William Mills > > > > >>>> Cc: Marius Scurtescu; OAuth WG > > > > >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > > > > (deadline: > > > > >>>> 2/10) > > > > >>>> > > > > >>>> Yes. This should be defined in each token type specification. > > > > >>>> > > > > >>>> Phil > > > > >>>> phil.hunt@oracle.com > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 2011-02-04, at 11:29 AM, William Mills wrote: > > > > >>>> > > > > >>>>> The only challenge is to know what scheme to use and what > > > > >>>>> the > > > > >> nuances > > > > >>>> are of how to present the credential. > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: oauth-bounces@ietf.org > > > > >>>>>> [mailto:oauth-bounces@ietf.org] > > > On > > > > >>>> Behalf > > > > >>>>>> Of Phil Hunt > > > > >>>>>> Sent: Friday, February 04, 2011 9:42 AM > > > > >>>>>> To: Marius Scurtescu > > > > >>>>>> Cc: OAuth WG > > > > >>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme > name > > > > >> (deadline: > > > > >>>>>> 2/10) > > > > >>>>>> > > > > >>>>>> OAuth should be able to support other token schemes. > > > > >>>>>> > > > > >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT, > > or > > > > >>>>>> whatever. > > > > >>>>>> > > > > >>>>>> Phil > > > > >>>>>> phil.hunt@oracle.com > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > > > > >>>>>> > > > > >>>>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > > > > >>>>>> wrote: > > > > >>>>>>>> Hey Marius, > > > > >>>>>>>> > > > > >>>>>>>>> -----Original Message----- > > > > >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > > > > >>>>>>>>> Sent: Thursday, February 03, 2011 10:36 AM > > > > >>>>>>>>> To: Eran Hammer-Lahav > > > > >>>>>>>>> Cc: OAuth WG > > > > >>>>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme > > > name > > > > >>>>>> (deadline: > > > > >>>>>>>>> 2/10) > > > > >>>>>>>>> > > > > >>>>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > > > > >>>>>>>>> wrote: > > > > >>>>>>>>> > > > > >>>>>>>>>> 2. Single OAuth2 scheme with sub-schemes > > > > >>>>>>>>>> > > > > >>>>>>>>>> Define a single authentication scheme for all token > > types > > > > with > > > > >>>>>> some > > > > >>>>>>>>>> attribute used to detect which scheme is actually being > > > > used. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Benefits: > > > > >>>>>>>>>> > > > > >>>>>>>>>> - single scheme, reuse of the 1.0 pattern. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Downsides: > > > > >>>>>>>>>> > > > > >>>>>>>>>> - requires a new registry for authentication header > > > > >> parameters. > > > > >>>>>>>>> How is this different from option 1? Wouldn't that need > > some > > > > >>>>>> registry? > > > > >>>>>>>> #1 relies on the existing practice of creating HTTP > > > > >>>>>>>> scheme > > > > names > > > > >>>> (no > > > > >>>>>> current registry but httpbis might be creating one), as > > > > >>>>>> well > > as > > > > >> the > > > > >>>> -12 > > > > >>>>>> token type registry. Using a sub-scheme means you also need > > a > > > > >>>> registry > > > > >>>>>> for the header attributes that each token type will need > > > > >>>>>> (unless > > > > >> you > > > > >>>>>> just don't care about using the same attribute name for > > > > different > > > > >>>>>> needs). > > > > >>>>>>> Sure, there is no registry for schemes yet, but we would > > still > > > > >> need > > > > >>>>>>> some coordination. The fact that a sub-scheme needs a > > registry > > > > >> that > > > > >>>>>> we > > > > >>>>>>> control is a benefit not a downside IMO. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>> - schemes are not easily reusable outside OAuth. > > > > >>>>>>>>> Sure. But I really don't see this group trying to create > > > > >> generic > > > > >>>>>> authentication > > > > >>>>>>>>> schemes. > > > > >>>>>>>> MAC is exactly that. > > > > >>>>>>> May or may not be. My point is that this group is not > > focused > > > > on > > > > >>>>>>> creating generic authentication schemes. Are you aware of > > any > > > > >> other > > > > >>>>>>> protocols that might use MAC or BEARER? Are we willing to > > put > > > > in > > > > >>>> the > > > > >>>>>>> effort to create generic schemes? Is it our charter? > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>> - existing frameworks usually switch on scheme name, > > > > >>>>>>>>>> not > > on > > > > >> sub > > > > >>>>>>>>>> scheme, which will cause difficulty in some deployments. > > > > >>>>>>>>> I can see this as a potential problem. But considering > > that > > > > >> there > > > > >>>>>> wasn't much > > > > >>>>>>>>> objection to use "OAuth" as a scheme name before (total > > > > overlap > > > > >>>>>> with > > > > >>>>>>>>> OAuth 1, and the suggested solution was to look for the > > > > >> signature > > > > >>>>>>>>> parameter) I don't see how this is suddenly an issue. > > > > >>>>>>>> There was pretty strong objection to reusing OAuth. > > > > >>>>>>> Yes, because there was no sub-scheme nor version (and the > > > > grammar > > > > >>>> was > > > > >>>>>>> totally broken). Even so, lots of implementations went > > ahead > > > > and > > > > >>>> did > > > > >>>>>>> it. Were there any scheme switching issues we are aware of? > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>> Do we have a concrete problem here or this is just > > > > theoretical? > > > > >>>>>>>> This came up during the review of > > > > >>>>>>>> draft-hammer-http-token-auth > > > > >>>> [1]. > > > > >>>>>> There was a long thread about it where people posted actual > > > > >>>> framework > > > > >>>>>> issues. > > > > >>>>>>>>>> - potential to produce a very complicated scheme once > > many > > > > sub > > > > >>>>>> schemes > > > > >>>>>>>>>> are added. > > > > >>>>>>>>> Why? I would argue that this option actually produces > > more > > > > >>>> uniform > > > > >>>>>>>>> schemes because it forces all of them to be name/value > > pairs. > > > > >>>>>> Beyond > > > > >>>>>>>>> token_type everything is scheme specific. I really don't > > see > > > > >> what > > > > >>>>>> is very > > > > >>>>>>>>> complicate here. > > > > >>>>>>>> It is still a single scheme with many different sub- > > schemes, > > > > >> each > > > > >>>>>> with different key-value pairs that may have conflicting > > > > meaning. > > > > >>>> The > > > > >>>>>> way I look at it is that if I try to fully implement this > > mega > > > > >>>> scheme > > > > >>>>>> (which means all its sub-schemes), it will likely be a > > > > complicated > > > > >>>>>> task. On the other hand, if you split it across scheme > > > > >>>>>> name, > > we > > > > >>>> already > > > > >>>>>> have a well-established system in place to pick and choose > > HTTP > > > > >>>>>> authentication schemes. > > > > >>>>>>> No one has to implement a mega scheme. All schemes must > > > > >>>>>>> use > > > > >>>>>> name/value > > > > >>>>>>> pairs and that's where the common part stops. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>> - requires its own discovery method for which schemes > > are > > > > >>>>>> supported. > > > > >>>>>>>>> Why is this a downside only for this option? > > > > >>>>>>>> Because the other options get this for free by using the > > WWW- > > > > >>>>>> Authenticate header (since each scheme has a unique name). > > You > > > > can > > > > >>>> list > > > > >>>>>> multiple headers in the 401 response. > > > > >>>>>>> I thought we dropped WWW-Authenticate. Why cannot > WWW- > > > > >> Authenticate > > > > >>>>>>> work for sub-schemes as well? > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> Should I record your vote for #2? > > > > >>>>>>> #2 or #3 > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Thanks, > > > > >>>>>>> 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 > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Feb 8 14:48:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7763A682B for ; Tue, 8 Feb 2011 14:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvJfAO15shMz for ; Tue, 8 Feb 2011 14:48:18 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E86B83A681B for ; Tue, 8 Feb 2011 14:48:16 -0800 (PST) Received: (qmail 7141 invoked from network); 8 Feb 2011 22:48:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 22:48:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Feb 2011 15:48:19 -0700 From: Eran Hammer-Lahav To: Mike Jones , Marius Scurtescu Date: Tue, 8 Feb 2011 15:48:04 -0700 Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwD1zY4AACkZkAAAECDlUAAVlmwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFFD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739432472DEA5@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472DEA5@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:48:18 -0000 Thanks Mike. How are you going to show the scheme name? bearer, Bearer, BEARER, ...? It = is case-insensitive but want to be consistent. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Tuesday, February 08, 2011 9:46 AM > To: Marius Scurtescu; Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > I'm likewise OK with #1. As I'd written previously, I wasn't religious a= bout the > name "OAuth2"; I was for it for to be consistent with past drafts and so = as not > to introduce a breaking change. Given that there appears to be consensus= to > make a change, I'll plan on publishing a draft later this week that conta= ins it > unless discussion in the next few days convinces us that we should follow= a > different course. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, February 08, 2011 9:24 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav > wrote: > > Mike, Brian, Dirk, and Marius - can you live with #1? >=20 > Works for me. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Feb 8 15:04:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7D43A68C6 for ; Tue, 8 Feb 2011 15:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GepaZrtHDWeL for ; Tue, 8 Feb 2011 15:04:45 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B390D3A67D4 for ; Tue, 8 Feb 2011 15:04:45 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 15:04:53 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 15:04:51 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH5JZovDkNiB5jT4KXAg0G1notQg== Date: Tue, 8 Feb 2011 23:04:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739432472E64ETK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:04:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739432472E64ETK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739432472E64ETK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given that people are clearly voting to change the b= earer token scheme name, but that there is also significant discussion aski= ng for “OAuth2” to be part of the name, I’d like to settl= e the matter by vote on the list.  Please vote for one of the following names:

 

1.  OAuth2Bearer

2.  Bearer

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739432472E64ETK5EX14MBXC201r_-- From Michael.Jones@microsoft.com Tue Feb 8 15:06:49 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD163A68C8 for ; Tue, 8 Feb 2011 15:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkc7rmqcgjfA for ; Tue, 8 Feb 2011 15:06:47 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 367903A68C6 for ; Tue, 8 Feb 2011 15:06:45 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 15:06:52 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 15:06:52 -0800 From: Mike Jones To: Eran Hammer-Lahav , Marius Scurtescu Thread-Topic: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thread-Index: AcvDfF3PHa2W5m+AT7mI3LoSyiYYSwD1zY4AACkZkAAAECDlUAAVlmwAACqE9aA= Date: Tue, 8 Feb 2011 23:06:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432472E66F@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB32B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A90BFDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739432472DEA5@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A90BFFD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90BFFD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] 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 type and scheme name (deadline: 2/10) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:06:49 -0000 It will be either OAuth2Bearer or Bearer, depending upon the outcome of the= vote just sent to the list. -- Mike -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Tuesday, February 08, 2011 2:48 PM To: Mike Jones; Marius Scurtescu Cc: OAuth WG Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) Thanks Mike. How are you going to show the scheme name? bearer, Bearer, BEARER, ...? It = is case-insensitive but want to be consistent. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Tuesday, February 08, 2011 9:46 AM > To: Marius Scurtescu; Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > I'm likewise OK with #1. As I'd written previously, I wasn't=20 > religious about the name "OAuth2"; I was for it for to be consistent=20 > with past drafts and so as not to introduce a breaking change. Given=20 > that there appears to be consensus to make a change, I'll plan on=20 > publishing a draft later this week that contains it unless discussion=20 > in the next few days convinces us that we should follow a different cours= e. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Marius Scurtescu > Sent: Tuesday, February 08, 2011 9:24 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) >=20 > On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav=20 > wrote: > > Mike, Brian, Dirk, and Marius - can you live with #1? >=20 > Works for me. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Tue Feb 8 15:13:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D823A680D for ; Tue, 8 Feb 2011 15:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8oBfjl6zSQQ for ; Tue, 8 Feb 2011 15:13:14 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 85B5A3A67A1 for ; Tue, 8 Feb 2011 15:13:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,444,1291554000"; d="scan'208,217";a="24535168" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Feb 2011 10:13:10 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6251"; a="18743528" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccvi.tcif.telstra.com.au with ESMTP; 09 Feb 2011 10:13:10 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 9 Feb 2011 10:13:09 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Wed, 9 Feb 2011 10:13:08 +1100 Thread-Topic: Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH5JZovDkNiB5jT4KXAg0G1notQgAADaAw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127D6A4AF9WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:13:17 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127D6A4AF9WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The previous poll already had these two options, with the non-OAuth-specifi= c name getting 14 votes to 1 vote for an OAuth prefix. 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 3. Name prefix (e.g. oauth2_bearer) I vote for 2 "Bearer". -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, 9 February 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_255B9BB34FB7D647A506DC292726F6E1127D6A4AF9WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The previous poll alre= ady had these two options, with the non-OAuth-specific name getting 14 vote= s to 1 vote for an OAuth prefix.

1. Descriptive, non-OAuth-speci= fic scheme names (Bearer, MAC)

…=

3. Name prefix (e.g. oauth2_bea= rer)

 

 

I vote for 2 “Be= arer”.

 

--

James Manger

 

From: oauth-bounces@ietf.= org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, 9 February 2011 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat= , 2/12

 

Given that people are clearly v= oting to change the bearer token scheme name, but that there is also signif= icant discussion asking for “OAuth2” to be part of the name, I&= #8217;d like to settle the matter by vote on the list.  Please vote for one of the following names:

 

1.  OAuth2Bearer

2.  Bearer

 

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

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

 

--_000_255B9BB34FB7D647A506DC292726F6E1127D6A4AF9WSMSG3153Vsrv_-- From eran@hueniverse.com Tue Feb 8 15:15:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9683A68CB for ; Tue, 8 Feb 2011 15:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riNl44fcETgj for ; Tue, 8 Feb 2011 15:15:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 36E8A3A680D for ; Tue, 8 Feb 2011 15:15:27 -0800 (PST) Received: (qmail 22116 invoked from network); 8 Feb 2011 23:15:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 23:15:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 8 Feb 2011 16:15:26 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Tue, 8 Feb 2011 16:15:11 -0700 Thread-Topic: Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH5JZovDkNiB5jT4KXAg0G1notQgAAWIpA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFFEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.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_90C41DD21FB7C64BB94121FBBC2E723445A90BFFEAP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:15:30 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFEAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why are we doing this again??? This was clearly option #3 which got no supp= ort. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, February 08, 2011 3:05 PM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFEAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why are we doing this again??? This was clearly option #3 whi= ch got no support.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Tuesday, February 08, 2011 3= :05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer to= ken scheme name - new vote deadline Sat, 2/12

 

Given th= at people are clearly voting to change the bearer token scheme name, but th= at there is also significant discussion asking for “OAuth2” to = be part of the name, I’d like to settle the matter by vote on the lis= t.  Please vote for one of the following names:

 

1.  OAuth2Beare= r

2.  Bearer

 

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      Thanks,

            =             &nb= sp;            =             &nb= sp;          -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFEAP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Tue Feb 8 15:16:29 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0643A680D for ; Tue, 8 Feb 2011 15:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPDRNnahcU-L for ; Tue, 8 Feb 2011 15:16:25 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A29893A67A1 for ; Tue, 8 Feb 2011 15:16:25 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 15:16:33 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Tue, 8 Feb 2011 15:16:33 -0800 From: Mike Jones To: "Manger, James H" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AQHLx+XebI8pMaGrek6/y2FWkxYmT5P4PBUw Date: Tue, 8 Feb 2011 23:16:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432472E771@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739432472E771TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:16:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739432472E771TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, but it also had other options that were "none of the above" relative t= o this naming issue. I'd like to obtain an unambiguous outcome on this poi= nt by having people vote between two choices. I personally agree with those that made the case that it is presumptive to = claim the generic name "Bearer". Hence, I will personal vote for #1. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Tuesday, February 08, 2011 3:13 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2= /12 The previous poll already had these two options, with the non-OAuth-specifi= c name getting 14 votes to 1 vote for an OAuth prefix. 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 3. Name prefix (e.g. oauth2_bearer) I vote for 2 "Bearer". -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, 9 February 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739432472E771TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, but it also had o= ther options that were “none of the above” relative to this nam= ing issue.  I’d like to obtain an unambiguous outcome on this po= int by having people vote between two choices.

 

I personally agree wit= h those that made the case that it is presumptive to claim the generic name= “Bearer”.  Hence, I will personal vote for #1.=

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, February 08, 2011 3:13 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline= Sat, 2/12

 

The pre= vious poll already had these two options, with the non-OAuth-specific name = getting 14 votes to 1 vote for an OAuth prefix.

1. Descriptive, non-OAuth-specific scheme names (Bea= rer, MAC)

…

3. Name prefix (e.g. oauth2_bearer)

&n= bsp;

&n= bsp;

I vote = for 2 “Bearer”.

&n= bsp;

--=

James M= anger

&n= bsp;

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, 9 February 2011 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat= , 2/12

 

Given that people are clearly voting to change the b= earer token scheme name, but that there is also significant discussion aski= ng for “OAuth2” to be part of the name, I’d like to settl= e the matter by vote on the list.  Please vote for one of the following names:

 

1.  OAuth2Bearer

2.  Bearer

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739432472E771TK5EX14MBXC201r_-- From eran@hueniverse.com Tue Feb 8 15:36:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3053A6866 for ; Tue, 8 Feb 2011 15:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOfyMF41yj0m for ; Tue, 8 Feb 2011 15:36:20 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BE0CA3A67AD for ; Tue, 8 Feb 2011 15:36:20 -0800 (PST) Received: (qmail 15198 invoked from network); 8 Feb 2011 23:36:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Feb 2011 23:36:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Feb 2011 16:36:20 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 8 Feb 2011 16:36:04 -0700 Thread-Topic: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AQHLx+XebI8pMaGrek6/y2FWkxYmT5P4PBUwgAAF87A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90BFFFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739432472E771@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E771@TK5EX14MBXC201.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_90C41DD21FB7C64BB94121FBBC2E723445A90BFFFCP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:36:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFFCP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #2 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, February 08, 2011 3:17 PM To: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2= /12 Yes, but it also had other options that were "none of the above" relative t= o this naming issue. I'd like to obtain an unambiguous outcome on this poi= nt by having people vote between two choices. I personally agree with those that made the case that it is presumptive to = claim the generic name "Bearer". Hence, I will personal vote for #1. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Tuesday, February 08, 2011 3:13 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2= /12 The previous poll already had these two options, with the non-OAuth-specifi= c name getting 14 votes to 1 vote for an OAuth prefix. 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) ... 3. Name prefix (e.g. oauth2_bearer) I vote for 2 "Bearer". -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, 9 February 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFFCP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#2

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of Mike Jones
Sent: Tuesday, February 08, 2011 3:17 PM<= br>To: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH= -WG] Bearer token scheme name - new vote deadline Sat, 2/12

 

Yes, but it also had other options that= were “none of the above” relative to this naming issue.  = I’d like to obtain an unambiguous outcome on this point by having peo= ple vote between two choices.

 

I personally agree with those that made the = case that it is presumptive to claim the generic name “Bearer”.=   Hence, I will personal vote for #1.

 

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

<= span style=3D'color:#002060'> 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of Manger, James H
Sent: Tuesday, February 08, = 2011 3:13 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG]= Bearer token scheme name - new vote deadline Sat, 2/12

 

The previous poll already had = these two options, with the non-OAuth-specific name getting 14 votes to 1 v= ote for an OAuth prefix.

1. Descr= iptive, non-OAuth-specific scheme names (Bearer, MAC)

…

3. Name prefix (e.g. oauth2_bearer)

 =

=  

I vote for 2 “Bearer”.

=

 =

--

James Manger

 

From: oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wed= nesday, 9 February 2011 10:05 AM
To: oauth@ietf.org
Subject= : [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12

=  

Given that people are clearly v= oting to change the bearer token scheme name, but that there is also signif= icant discussion asking for “OAuth2” to be part of the name, I&= #8217;d like to settle the matter by vote on the list.  Please vote fo= r one of the following names:

 = ;

1.  OAuth2Bearer

2.  Bearer

 = ;

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

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A90BFFFCP3PW5EX1MB01E_-- From michael.d.adams@gmail.com Tue Feb 8 16:02:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6A63A6864 for ; Tue, 8 Feb 2011 16:02:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s813gRRTFpvK for ; Tue, 8 Feb 2011 16:02:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 082303A6837 for ; Tue, 8 Feb 2011 16:02:21 -0800 (PST) Received: by fxm9 with SMTP id 9so7179529fxm.31 for ; Tue, 08 Feb 2011 16:02:29 -0800 (PST) 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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=y7S6ldy6GFxcdQ0YiF1MH/+Rg8roRvgFRBOatEDBjck=; b=Jj/4Zh3BNuW0wFf/LMRGgflj23Ag4iTI0VzDjcwhlORDRo8lHq/D5WfwkWyWNiHNoJ 2xXtOEXeUW53QyC0GzJ6OuiPSnFhyD8XLs42BKU26V6XyB4EaZFNAzBqTumMyCmAr8qR J6gI/0Yff6IgtjnqZC0d8l7AYOIHh38NVGA3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=tltzHkdbwPZopoP0g8dX1nFLWjRuVyo++bKXSvilHuOXIjLDmRRqkFesQ98hdiBGt/ KNnOWhcRHlsLQdAOwzEmyR05zuBevgzW8HNpCONrdg01CE5ErOzu2ZpGzXAI9nbyH0a6 JgEYb44O9v+DI9K+U23nr4K8DGpNRkO2fjJrk= Received: by 10.223.85.204 with SMTP id p12mr2315590fal.146.1297209749356; Tue, 08 Feb 2011 16:02:29 -0800 (PST) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.223.13.5 with HTTP; Tue, 8 Feb 2011 16:02:09 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> From: Michael D Adams Date: Tue, 8 Feb 2011 16:02:09 -0800 X-Google-Sender-Auth: eo3Kn1j7uX6EwuNRHkUudiFWb-0 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:02:23 -0000 On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones wr= ote: > Given that people are clearly voting to change the bearer token scheme na= me, > but that there is also significant discussion asking for =93OAuth2=94 to = be part > of the name, I=92d like to settle the matter by vote on the list.=A0 Plea= se vote > for one of the following names: > > 1.=A0 OAuth2Bearer > > 2.=A0 Bearer #2 Bearer From jhart@photobucket.com Tue Feb 8 16:21:58 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B3A3A68B1 for ; Tue, 8 Feb 2011 16:21:58 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn4Pzn6zho31 for ; Tue, 8 Feb 2011 16:21:57 -0800 (PST) Received: from EXHUB003-3.exch003intermedia.net (exhub003-3.exch003intermedia.net [207.5.74.110]) by core3.amsl.com (Postfix) with ESMTP id E49523A6857 for ; Tue, 8 Feb 2011 16:21:57 -0800 (PST) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by EXHUB003-3.exch003intermedia.net ([207.5.74.110]) with mapi; Tue, 8 Feb 2011 16:22:05 -0800 From: Justin Hart To: Mike Jones Date: Tue, 8 Feb 2011 16:22:04 -0800 Thread-Topic: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH72GI0hDhtMqcQquT8PrFugHuzg== Message-ID: <0D64B8F5-AA3C-47B5-A9A9-2FB1891BE64C@photobucket.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.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_0D64B8F5AA3C47B5A9A92FB1891BE64Cphotobucketcom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:21:58 -0000 --_000_0D64B8F5AA3C47B5A9A92FB1891BE64Cphotobucketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable #2 ---- Justin Hart jhart@photobucket.com On Feb 8, 2011, at 4:04 PM, Mike Jones wrote: Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for =93OAuth2=94 to = be part of the name, I=92d like to settle the matter by vote on the list. = Please vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_0D64B8F5AA3C47B5A9A92FB1891BE64Cphotobucketcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ----
Justin Hart
jhart@photobucket.com



On Feb 8, 2011, at 4:04 PM, Mike Jones wrote:

Giv= en that people are clearly voting to change the bearer token scheme name, b= ut that there is also significant discussion asking for =93OAuth2=94 to be = part of the name, I=92d like to settle the matter by vote on the list. = ; Please vote for one of the following names:
 =
2.  Bearer
 =
           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           Thanks,=
           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           -- Mike

= --_000_0D64B8F5AA3C47B5A9A92FB1891BE64Cphotobucketcom_-- From phil.hunt@oracle.com Tue Feb 8 16:22:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135983A68D1 for ; Tue, 8 Feb 2011 16:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x72SItoqnQS5 for ; Tue, 8 Feb 2011 16:22:14 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1BB033A6837 for ; Tue, 8 Feb 2011 16:22:14 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p190MKSD025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Feb 2011 00:22:21 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p190Fjaf021509 for ; Wed, 9 Feb 2011 00:22:19 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 1035682941297210909; Tue, 08 Feb 2011 16:21:49 -0800 Received: from [192.168.1.4] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Feb 2011 16:21:49 -0800 From: Phil Hunt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-29--1071355560 Date: Tue, 8 Feb 2011 16:21:47 -0800 In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> To: OAuth WG References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Message-Id: X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D51DE3C.00FC:SCFMA4539814,ss=1,fgs=0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:22:15 -0000 --Apple-Mail-29--1071355560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 #2. Phil phil.hunt@oracle.com On 2011-02-08, at 3:04 PM, Mike Jones wrote: > Given that people are clearly voting to change the bearer token scheme = name, but that there is also significant discussion asking for =93OAuth2=94= to be part of the name, I=92d like to settle the matter by vote on the = list. Please vote for one of the following names: > =20 > 1. OAuth2Bearer > 2. Bearer > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-29--1071355560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2011-02-08, at 3:04 PM, Mike Jones wrote:

Given that people are clearly = voting to change the bearer token scheme name, but that there is also = significant discussion asking for =93OAuth2=94 to be part of the name, = I=92d like to settle the matter by vote on the list.  Please vote = for one of the following names:
1.  = OAuth2Bearer
2.  = Bearer
 
Date: Tue, 8 Feb 2011 17:31:22 -0800 Thread-Topic: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH5JZovDkNiB5jT4KXAg0G1notQgAADaAwAAUN4aA= Message-ID: References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127D6A4AF9@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A315638493F428FSP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 01:31:46 -0000 --_000_FFDFD7371D517847AD71FBB08F9A315638493F428FSP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #2 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, 9 February 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_FFDFD7371D517847AD71FBB08F9A315638493F428FSP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#2

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Wednesday, 9 February 2011 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat= , 2/12

 

Given that people are clearly voting to change the bea= rer token scheme name, but that there is also significant discussion asking for “OAuth2” to be part of the name, I’d like to settle the m= atter by vote on the list.  Please vote for one of the following names:

 

1.  OAuth2Bearer

2.  Bearer

 

         =             &nb= sp;            =             &nb= sp;             Thanks,

         =             &nb= sp;            =             &nb= sp;             -- Mike

 

--_000_FFDFD7371D517847AD71FBB08F9A315638493F428FSP2EX07VS06ds_-- From peaceable_whale@hotmail.com Tue Feb 8 19:16:19 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBF83A68DB for ; Tue, 8 Feb 2011 19:16:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPlWAqhUrm0z for ; Tue, 8 Feb 2011 19:16:18 -0800 (PST) Received: from col0-omc1-s2.col0.hotmail.com (col0-omc1-s2.col0.hotmail.com [65.55.34.12]) by core3.amsl.com (Postfix) with ESMTP id CD6233A6879 for ; Tue, 8 Feb 2011 19:16:18 -0800 (PST) Received: from COL122-DS10 ([65.55.34.7]) by col0-omc1-s2.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 19:16:26 -0800 X-Originating-IP: [14.136.19.151] X-Originating-Email: [peaceable_whale@hotmail.com] Message-ID: From: "Franklin Tse" To: References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Wed, 9 Feb 2011 11:16:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-OriginalArrivalTime: 09 Feb 2011 03:16:26.0905 (UTC) FILETIME=[BCDBF890:01CBC807] Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 03:16:19 -0000 IzINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkZyb206ICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KRGF0ZTog V2VkbmVzZGF5LCAwOSBGZWJydWFyeSwgMjAxMSAwNzowNA0KVG86IDxvYXV0aEBpZXRmLm9yZz4N ClN1YmplY3Q6IFtPQVVUSC1XR10gQmVhcmVyIHRva2VuIHNjaGVtZSBuYW1lIC0gbmV3IHZvdGUg ZGVhZGxpbmUgU2F0LCAyLzEyDQoNCj4gR2l2ZW4gdGhhdCBwZW9wbGUgYXJlIGNsZWFybHkgdm90 aW5nIHRvIGNoYW5nZSB0aGUgYmVhcmVyIHRva2VuIHNjaGVtZSBuYW1lLCBidXQgdGhhdCB0aGVy ZSBpcyBhbHNvIHNpZ25pZmljYW50IGRpc2N1c3Npb24gYXNraW5nIGZvciAiT0F1dGgyIiB0byBi ZSBwYXJ0IG9mIHRoZSBuYW1lLCBJJ2QgbGlrZSB0byBzZXR0bGUgdGhlIG1hdHRlciBieSB2b3Rl IG9uIHRoZSBsaXN0LiAgUGxlYXNlIHZvdGUgZm9yIG9uZSBvZiB0aGUgZm9sbG93aW5nIG5hbWVz Og0KPiANCj4gMS4gIE9BdXRoMkJlYXJlcg0KPiAyLiAgQmVhcmVyDQo+IA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQo+IA0KPg0KDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA= From tonynad@microsoft.com Tue Feb 8 21:16:44 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C383A68F2 for ; Tue, 8 Feb 2011 21:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4TxIgVGgFp2 for ; Tue, 8 Feb 2011 21:16:42 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 111673A68ED for ; Tue, 8 Feb 2011 21:16:41 -0800 (PST) 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; Tue, 8 Feb 2011 21:16:48 -0800 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 8 Feb 2011 21:16:49 -0800 Received: from mail214-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.8; Wed, 9 Feb 2011 05:16:48 +0000 Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1-R.bigfish.com (Postfix) with ESMTP id 049401AE0A9B for ; Wed, 9 Feb 2011 05:16:48 +0000 (UTC) X-SpamScore: -34 X-BigFish: PS-34(zz4015L9371PzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1 (MessageSwitch) id 1297228607711842_26986; Wed, 9 Feb 2011 05:16:47 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail214-ch1.bigfish.com (Postfix) with ESMTP id A9C93EF004E for ; Wed, 9 Feb 2011 05:16:47 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 9 Feb 2011 05:16:44 +0000 Received: from SN1PRD0302MB097.namprd03.prod.outlook.com ([169.254.8.45]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.023; Wed, 9 Feb 2011 05:16:42 +0000 From: Anthony Nadalin To: Mike Jones , "oauth@ietf.org" Thread-Topic: Bearer token scheme name - new vote deadline Sat, 2/12 Thread-Index: AcvH5JZovDkNiB5jT4KXAg0G1notQgAM+zPg Date: Wed, 9 Feb 2011 05:16:41 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.111.76.230] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E709A384SN1PRD0302MB097na_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.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: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 05:16:45 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E709A384SN1PRD0302MB097na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #1 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, February 08, 2011 3:05 PM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 Given that people are clearly voting to change the bearer token scheme name= , but that there is also significant discussion asking for "OAuth2" to be p= art of the name, I'd like to settle the matter by vote on the list. Please= vote for one of the following names: 1. OAuth2Bearer 2. Bearer Thanks, -- Mike --_000_B26C1EF377CB694EAB6BDDC8E624B6E709A384SN1PRD0302MB097na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#1

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, February 08, 2011 3:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat= , 2/12

 

Given that people are clearly voting to change the b= earer token scheme name, but that there is also significant discussion aski= ng for “OAuth2” to be part of the name, I’d like to settl= e the matter by vote on the list.  Please vote for one of the following names:

 

1.  OAuth2Bearer

2.  Bearer

 

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

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

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E709A384SN1PRD0302MB097na_-- From recordond@gmail.com Tue Feb 8 22:08:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5E13A6908 for ; Tue, 8 Feb 2011 22:08:38 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCneAymqCYBE for ; Tue, 8 Feb 2011 22:08:37 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5B8E83A6905 for ; Tue, 8 Feb 2011 22:08:37 -0800 (PST) Received: by vws7 with SMTP id 7so3582009vws.31 for ; Tue, 08 Feb 2011 22:08:45 -0800 (PST) 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=TH/8vTbvog/2+2LC7zTUssVtRKnKAB2Uwl6mIoQMpPQ=; b=ejZufZU1opVhahRmGsHy9C7akrBwFlGebVQlBu0D2h0OCMXvyrc9agmogKbfvjvGg2 3xFrnkZvOjrGe6ma2stCgOAGk4RdwnPqbPdqRbe/4/wO9M9iEgIvAy8GhIakE9NyHFkZ KvtW8S0x5KPDy/OAa/VPFLHPrgwfeeMVN8hvc= 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=jYCRSM2E2aYp2lxvWVFaS55oM35W7WgM7RdN7VIm2ZYmIHL8nu4yWrQTlqDyRAdDNU ozpm8zY5w2XcdglS4AGzfZfpCKZKWsBtOUScRmwhdAjtZhoeolnXyDOiliSpxCN5nXYF OiaRHBFglsP790LQdEHjxs4OTO8xV9GK8fWvc= MIME-Version: 1.0 Received: by 10.220.200.69 with SMTP id ev5mr5146174vcb.45.1297231724035; Tue, 08 Feb 2011 22:08:44 -0800 (PST) Received: by 10.220.187.197 with HTTP; Tue, 8 Feb 2011 22:08:43 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Tue, 8 Feb 2011 22:08:43 -0800 Message-ID: From: David Recordon To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:08:38 -0000 #1 On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones wr= ote: > Given that people are clearly voting to change the bearer token scheme na= me, > but that there is also significant discussion asking for =93OAuth2=94 to = be part > of the name, I=92d like to settle the matter by vote on the list.=A0 Plea= se vote > for one of the following names: > > > > 1.=A0 OAuth2Bearer > > 2.=A0 Bearer > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From recordond@gmail.com Tue Feb 8 22:08:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631AA3A690B for ; Tue, 8 Feb 2011 22:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqOK9RXuh7-x for ; Tue, 8 Feb 2011 22:08:54 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id BEEA03A6908 for ; Tue, 8 Feb 2011 22:08:53 -0800 (PST) Received: by vxi40 with SMTP id 40so3168217vxi.31 for ; Tue, 08 Feb 2011 22:09:02 -0800 (PST) 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=fLqQCvrVul0OoeX3jGd3wjHMbMnJkor11a4jiSDIKxQ=; b=yAxIE51uyCb7Rhjfxrv9jSmteQEihdmgqZBJiJGxzNRc5OJpwAoDLHWbiXafkrOlqQ 81+Xe9+G+/VtJcCzuQ8EexLTGRpcVggC2GE/vBNB3915amZEHNmBOfZp/5iRbvj7UDSQ saeZHnHywHSQOGZI+1nU1cFYaQu+S4dXD3HXI= 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=du1D9Lj1eyWvHbbqg2CAEWK/L79HHnzSItdohuSaUbDYkWTfl0UAe++pjD/AWxN4IU vg7T3TRD36K+pNWrDd4jNzDmN5eP5+YLTBR3/RpwkpPUjzt/yaK++cMLEhl0k0hCLBR3 CX17+jiKHsWrAs6NYN1o6z0XxjnR2P9YSrJYg= MIME-Version: 1.0 Received: by 10.220.202.194 with SMTP id ff2mr389369vcb.115.1297231740673; Tue, 08 Feb 2011 22:09:00 -0800 (PST) Received: by 10.220.187.197 with HTTP; Tue, 8 Feb 2011 22:09:00 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Tue, 8 Feb 2011 22:09:00 -0800 Message-ID: From: David Recordon To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:08:55 -0000 Sorry, read the previous version of this poll. Meant #2 in this one. On Tue, Feb 8, 2011 at 10:08 PM, David Recordon wrote= : > #1 > > On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones = wrote: >> Given that people are clearly voting to change the bearer token scheme n= ame, >> but that there is also significant discussion asking for =93OAuth2=94 to= be part >> of the name, I=92d like to settle the matter by vote on the list.=A0 Ple= ase vote >> for one of the following names: >> >> >> >> 1.=A0 OAuth2Bearer >> >> 2.=A0 Bearer >> >> >> >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks, >> >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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 >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From fcorella@pomcor.com Tue Feb 8 23:51:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630043A6921 for ; Tue, 8 Feb 2011 23:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX-TD13yrffL for ; Tue, 8 Feb 2011 23:51:51 -0800 (PST) Received: from nm19-vm0.bullet.mail.ac4.yahoo.com (nm19-vm0.bullet.mail.ac4.yahoo.com [98.139.53.212]) by core3.amsl.com (Postfix) with SMTP id 1DA873A68B1 for ; Tue, 8 Feb 2011 23:51:50 -0800 (PST) Received: from [98.139.52.191] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 09 Feb 2011 07:51:59 -0000 Received: from [98.139.52.168] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 09 Feb 2011 07:51:59 -0000 Received: from [127.0.0.1] by omp1051.mail.ac4.yahoo.com with NNFMP; 09 Feb 2011 07:51:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 685682.69649.bm@omp1051.mail.ac4.yahoo.com Received: (qmail 67355 invoked by uid 60001); 9 Feb 2011 07:51:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297237919; bh=7ZjSuo7wlE24+ll9s6CPeoo68FIsycdPGFDgiBmC4dQ=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=lKN/2mcVfOichbzV08sdm8ArdJZFC2biNhoP77y4rhIVz67IrUs0Hfkau4B/GCdHstW+YssfKqI4VBWL+HJ1cLwCz0S7qWHafLiq9T6F/qVGb27YRF2JLL69L3wayV58O+YJvDXAuv4tNaxzveRvCGOC0Lspwl2KqnBvi8RiHOQ= Message-ID: <572096.67196.qm@web55802.mail.re3.yahoo.com> X-YMail-OSG: OeZ95J8VM1kfzJ010Q_uctykcuTYy8sXTuGSUL1tJuLg57x ys3TZw9Dm65AzqzV.cC_AXgp6sLOPHx.DgdROsmzvQPYy.BianfvcozOM3iP 0ZbnuIbnBR.LYgCZsN7.b5xtYxbgHh4JptbyrgdPz_uffX_0ixc4dTJytO__ WQp4IfhTt_bJyR_eli3Xl05BHtVUaSFhKd2SD_OKmINT0Rj3K070I1GwzUXV VSjGH2GeMe9TSnbAck7q7qZ8Zz37kiifi9HBugjWo7rdTHMp6jiykaEfbS7x NUQphGPAsKrb6vRopWgYH1dOZ5Dot7fb299ZJBw_0fljlXu2lmlakoeY- Received: from [174.65.103.16] by web55802.mail.re3.yahoo.com via HTTP; Tue, 08 Feb 2011 23:51:59 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.108.291010 Date: Tue, 8 Feb 2011 23:51:59 -0800 (PST) From: Francisco Corella To: oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-164434-1297237919=:67196" Cc: "Karen P. Lewison" Subject: [OAUTH-WG] FYI: security analysis of double-redirection protocols, including OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 09 Feb 2011 07:51:52 -0000 --0-164434-1297237919=:67196 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, We've written a technical report that has a security analysis of double-red= irection protocols such as OpenID and OAuth.=A0 Section 3.5 discusses OAuth= 2.0.=A0 Most of section 4 may also be of interest to this list.=A0 You can= find the report at http://www.pomcor.com/techreports/DoubleRedirection.pdf. I hope it's useful! Thanks in advance for any comments. Francisco --0-164434-1297237919=:67196 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We've written a technical report t= hat has a security analysis of double-redirection protocols such as OpenID = and OAuth.  Section 3.5 discusses OAuth 2.0.  Most of section 4 m= ay also be of interest to this list.  You can find the report at
http://ww= w.pomcor.com/techreports/DoubleRedirection.pdf.
I hope it's useful!<= br>
Thanks in advance for any comments.

Francisco

--0-164434-1297237919=:67196-- From skylar@kiva.org Wed Feb 9 06:51:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6143A6A05 for ; Wed, 9 Feb 2011 06:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+1bRuJF2N+C for ; Wed, 9 Feb 2011 06:51:21 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id 789233A6A03 for ; Wed, 9 Feb 2011 06:51:19 -0800 (PST) Received: from source ([74.125.82.50]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTVKp8SnMYrSLxai9ynr/FmTT8dj9FHP7@postini.com; Wed, 09 Feb 2011 06:51:30 PST Received: by wwf26 with SMTP id 26so246201wwf.31 for ; Wed, 09 Feb 2011 06:51:27 -0800 (PST) Received: by 10.227.138.15 with SMTP id y15mr19218089wbt.186.1297263087723; Wed, 09 Feb 2011 06:51:27 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id u2sm224335weh.36.2011.02.09.06.51.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 06:51:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Skylar Woodward In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Wed, 9 Feb 2011 15:51:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9703722E-D8F0-49EA-A20E-2E928C3F56C2@kiva.org> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:51:21 -0000 #2 On Feb 9, 2011, at 12:04 AM, Mike Jones wrote: > Given that people are clearly voting to change the bearer token scheme = name, but that there is also significant discussion asking for =93OAuth2=94= to be part of the name, I=92d like to settle the matter by vote on the = list. Please vote for one of the following names: > =20 > 1. OAuth2Bearer > 2. Bearer > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Wed Feb 9 08:05:47 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F67F3A67AE for ; Wed, 9 Feb 2011 08:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRXledCHaEDk for ; Wed, 9 Feb 2011 08:05:46 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by core3.amsl.com (Postfix) with ESMTP id 3612E3A67A7 for ; Wed, 9 Feb 2011 08:05:45 -0800 (PST) Received: from source ([209.85.215.45]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTVK7YlhHcR1h1Ry4uiZHyCu+0ktYgsy5@postini.com; Wed, 09 Feb 2011 08:05:56 PST Received: by mail-ew0-f45.google.com with SMTP id 10so182602ewy.4 for ; Wed, 09 Feb 2011 08:05:54 -0800 (PST) Received: by 10.223.102.77 with SMTP id f13mr129760fao.113.1297267552368; Wed, 09 Feb 2011 08:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Wed, 9 Feb 2011 08:05:22 -0800 (PST) In-Reply-To: <9703722E-D8F0-49EA-A20E-2E928C3F56C2@kiva.org> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> <9703722E-D8F0-49EA-A20E-2E928C3F56C2@kiva.org> From: Brian Campbell Date: Wed, 9 Feb 2011 09:05:22 -0700 Message-ID: To: Skylar Woodward Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:05:47 -0000 #2 On Wed, Feb 9, 2011 at 7:51 AM, Skylar Woodward wrote: > #2 > > On Feb 9, 2011, at 12:04 AM, Mike Jones wrote: > >> Given that people are clearly voting to change the bearer token scheme n= ame, but that there is also significant discussion asking for =93OAuth2=94 = to be part of the name, I=92d like to settle the matter by vote on the list= . =A0Please vote for one of the following names: >> >> 1. =A0OAuth2Bearer >> 2. =A0Bearer >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 =A0 =A0 =A0 =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 >> >> _______________________________________________ >> 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 dick.hardt@gmail.com Wed Feb 9 08:23:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685DF3A657C for ; Wed, 9 Feb 2011 08:23:31 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhSzv2sfQ4oP for ; Wed, 9 Feb 2011 08:23:30 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 5D4153A63EC for ; Wed, 9 Feb 2011 08:23:30 -0800 (PST) Received: by pxi6 with SMTP id 6so69447pxi.31 for ; Wed, 09 Feb 2011 08:23:40 -0800 (PST) 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=wtSMovgbMF5dWggxfg9JqgH/w33d0bzFgmut+ZDcmZs=; b=LSd4lEpZJZjGRj0EsvK4UfqGZpdFbENRYcBQUzVHqNShXaq43q151r0LNqKW1BQ6Nh k+rVSivWZmuSOtH8dw1PBWhgYjjF7zbtrQFC21rdM2UxaEFmDN/KhaZbBtfbO4Ab2K3w HV2auJhEueD76KJ+Y+yi/1SLCfisRW4hFR3YQ= 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=CYe7UeLqFzYEfHWb3g3H4zB0zH9cR8t2tEYxm2LTge4A8idtO6lS9q9vh9BVV4ini/ fognQIZdZR6juRA1VD00ySAPosb6YDrwtmLSyC6Mq0Lx4DyN52KPXOs6tC9KBnxLAYzZ bLc9UnkUQyNTPznaJNYugLOpBR//GaDPfVn9Q= Received: by 10.142.204.15 with SMTP id b15mr18607109wfg.66.1297268616743; Wed, 09 Feb 2011 08:23:36 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id v19sm597117wfh.12.2011.02.09.08.23.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 08:23:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-3--1013650919 From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Wed, 9 Feb 2011 08:23:32 -0800 Message-Id: <799EC135-9B66-448F-98CF-94E7911499AE@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739432472E64E@TK5EX14MBXC201.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:23:31 -0000 --Apple-Mail-3--1013650919 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 indifferent :) On 2011-02-08, at 3:04 PM, Mike Jones wrote: > Given that people are clearly voting to change the bearer token scheme = name, but that there is also significant discussion asking for =93OAuth2=94= to be part of the name, I=92d like to settle the matter by vote on the = list. Please vote for one of the following names: > =20 > 1. OAuth2Bearer > 2. Bearer > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3--1013650919 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 indifferent :)

On 2011-02-08, at = 3:04 PM, Mike Jones wrote:

Given that people are clearly = voting to change the bearer token scheme name, but that there is also = significant discussion asking for =93OAuth2=94 to be part of the name, = I=92d like to settle the matter by vote on the list.  Please vote = for one of the following names:
1.  = OAuth2Bearer
2.  = Bearer
 
from the draft-ietf-oauth-v2 specification and > "-" means against it. > "*" indicates some constraints. > +Eran > *Phil (was talking about a stronger version of the client assertion > credentials) > +David > *Francisco (also has a stronger version in mind) > -Mike > *Marius (Marius has plans to use client assertions in two profiles. So, I > assume he wants to have the functionality but I do not know whether he cares > about where it is document; in the main spec or in a separate document.) > > Please correct me if I have forgotten someone or misinterpreted someone's > statement. > > The feedback from the group as I have seen it was a bit difficult to > interpret (particularly from Phil, Francisco, and Marius). So, a > clarification would be good. Count me as a "-", I think client assertions should stay. > Feedback indicated that there is interesting in deploying the Client > Assertion credential functionality. That's good. > > My reading of Section 3.2 of OAuth version -11 is that this functionality is > NOT mandatory to implement. > > So, for me the question therefore is where to describe this functionality. > Here are my questions: > > 1a) Do you insist in having it documented in draft-ietf-oauth-v2? > > PLEASE NOTE: Having functionality in a separate document does not mean that > it will take longer to complete nor that it is less important. It is purely > a document management question! Not sure a separate document is the same thing. A separate document probably means an extension that fully defines how client assertions should work in a specific implementation. Other extensions that would like to do something similar now would have to either be redundant or refer to this first extension. If the basic parameters are described in the core spec then we have a clear extension point. Marius From phil.hunt@oracle.com Thu Feb 10 15:12:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1103F3A6A63 for ; Thu, 10 Feb 2011 15:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vujTPCUxe14t for ; Thu, 10 Feb 2011 15:12:30 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2468D3A6849 for ; Thu, 10 Feb 2011 15:12:30 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1ANCgEd010554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Feb 2011 23:12:43 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1AN3qrX005182 for ; Thu, 10 Feb 2011 23:12:41 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 1043423051297379463; Thu, 10 Feb 2011 15:11:03 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Feb 2011 15:11:03 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Phil Hunt In-Reply-To: Date: Thu, 10 Feb 2011 15:11:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A63D7.3000900@gmx.net> To: OAuth WG X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D5470E9.00A8:SCFMA4539814,ss=1,fgs=0 Subject: Re: [OAUTH-WG] Hum about 'Removal: Client Assertion Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:12:31 -0000 I never heard a final resolution to this. What was the vote result? Phil phil.hunt@oracle.com On 2011-02-10, at 3:07 PM, Marius Scurtescu wrote: > On Thu, Feb 3, 2011 at 12:14 AM, Hannes Tschofenig > wrote: >> Hi all, >>=20 >> Eran suggested to remove the Client Assertion functionality from the >> draft-ietf-oauth-v2 specification in his mail from last month: >> http://www.ietf.org/mail-archive/web/oauth/current/msg05027.html >>=20 >> This lead to a heated discussion. >>=20 >> Going through the discussions I got the following impression: >> "+" means in favor of removing the Client Assertion credential = functionality >> from the draft-ietf-oauth-v2 specification and >> "-" means against it. >> "*" indicates some constraints. >> +Eran >> *Phil (was talking about a stronger version of the client assertion >> credentials) >> +David >> *Francisco (also has a stronger version in mind) >> -Mike >> *Marius (Marius has plans to use client assertions in two profiles. = So, I >> assume he wants to have the functionality but I do not know whether = he cares >> about where it is document; in the main spec or in a separate = document.) >>=20 >> Please correct me if I have forgotten someone or misinterpreted = someone's >> statement. >>=20 >> The feedback from the group as I have seen it was a bit difficult to >> interpret (particularly from Phil, Francisco, and Marius). So, a >> clarification would be good. >=20 > Count me as a "-", I think client assertions should stay. >=20 >=20 >> Feedback indicated that there is interesting in deploying the Client >> Assertion credential functionality. That's good. >>=20 >> My reading of Section 3.2 of OAuth version -11 is that this = functionality is >> NOT mandatory to implement. >>=20 >> So, for me the question therefore is where to describe this = functionality. >> Here are my questions: >>=20 >> 1a) Do you insist in having it documented in draft-ietf-oauth-v2? >>=20 >> PLEASE NOTE: Having functionality in a separate document does not = mean that >> it will take longer to complete nor that it is less important. It is = purely >> a document management question! >=20 > Not sure a separate document is the same thing. A separate document > probably means an extension that fully defines how client assertions > should work in a specific implementation. Other extensions that would > like to do something similar now would have to either be redundant or > refer to this first extension. >=20 > If the basic parameters are described in the core spec then we have a > clear extension point. >=20 >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Feb 10 15:14:29 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12783A6AF4 for ; Thu, 10 Feb 2011 15:14:29 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuGfgyJeXe8N for ; Thu, 10 Feb 2011 15:14:29 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2275C3A6849 for ; Thu, 10 Feb 2011 15:14:29 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5EC1140CFC for ; Thu, 10 Feb 2011 16:32:19 -0700 (MST) Message-ID: <4D547161.9070106@stpeter.im> Date: Thu, 10 Feb 2011 16:14:41 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070702030103030608050201" Subject: [OAUTH-WG] meeting in Prague? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:14:29 -0000 This is a cryptographically signed message in MIME format. --------------ms070702030103030608050201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems that this group probably could have a productive meeting in Prague. This is just a reminder that the deadline for requesting a slot is next Monday, February 14. :) http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070702030103030608050201 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx MDIzMTQ0MVowIwYJKoZIhvcNAQkEMRYEFBt1aPNs4b3xEqX8PzwSLz1C1xsuMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBWA0L67QQfM8uFFJMKPpV3Kaf2ZXlC/z3mLduc+Wm5c21fOwqIbtK4FXI0 PR0IwqcYtlAGIMUsvJlnvdSy7r5TtQbwuRirtlvFnfjRnT27ObHtFCycO74psArCKlEViltr 7W8mbxubjy3IMcGWH0r38/gkW/oNtkRGnyILnGcqqG7SdKCmygtTrpWJtn/V8fh1oKPfb4bu jq0oghidshneOWluG1DQiYG+wx6flKaAL9DbLNaXFAp5tSQGMtx8YX9M2uNYET4k5OoknP++ tjOoSrrZhjWZrX3cOaKpwFY+ieuvgBT9jtLX8XoRZDP8xXJo18tLl8v92K7dEtEy0reBAAAA AAAA --------------ms070702030103030608050201-- From phil.hunt@oracle.com Thu Feb 10 15:34:35 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0173A6B0A for ; Thu, 10 Feb 2011 15:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du-gKi94y2BS for ; Thu, 10 Feb 2011 15:34:34 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D18023A6AF7 for ; Thu, 10 Feb 2011 15:34:33 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1ANYjYP026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 23:34:46 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1ALZVBS014704; Thu, 10 Feb 2011 23:34:43 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 1043517511297380847; Thu, 10 Feb 2011 15:34:07 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Feb 2011 15:34:07 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4D547161.9070106@stpeter.im> Date: Thu, 10 Feb 2011 15:34:05 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4D547161.9070106@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D547614.00B2:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting in Prague? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:34:35 -0000 Is there anything proposed yet? Phil phil.hunt@oracle.com On 2011-02-10, at 3:14 PM, Peter Saint-Andre wrote: > It seems that this group probably could have a productive meeting in > Prague. This is just a reminder that the deadline for requesting a slot > is next Monday, February 14. :) > > http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Feb 10 23:24:33 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724743A6AEF for ; Thu, 10 Feb 2011 23:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+MCqMUp2yq4 for ; Thu, 10 Feb 2011 23:24:32 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 29F303A68BB for ; Thu, 10 Feb 2011 23:24:31 -0800 (PST) Received: (qmail 15411 invoked from network); 11 Feb 2011 07:24:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Feb 2011 07:24:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 11 Feb 2011 00:24:44 -0700 From: Eran Hammer-Lahav To: Phil Hunt , OAuth WG Date: Fri, 11 Feb 2011 00:24:23 -0700 Thread-Topic: [OAUTH-WG] Hum about 'Removal: Client Assertion Credentials' Thread-Index: AcvJePdYGX03zKXnRLajZjJIxHzjxAAQ6ENg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90C057E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D4A63D7.3000900@gmx.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 Subject: Re: [OAUTH-WG] Hum about 'Removal: Client Assertion Credentials' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 07:24:33 -0000 There wasn't a vote. Just call for feedback and so far I haven't seen conse= nsus. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, February 10, 2011 3:11 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Hum about 'Removal: Client Assertion Credentials' >=20 > I never heard a final resolution to this. What was the vote result? >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-10, at 3:07 PM, Marius Scurtescu wrote: >=20 > > On Thu, Feb 3, 2011 at 12:14 AM, Hannes Tschofenig > > wrote: > >> Hi all, > >> > >> Eran suggested to remove the Client Assertion functionality from the > >> draft-ietf-oauth-v2 specification in his mail from last month: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg05027.html > >> > >> This lead to a heated discussion. > >> > >> Going through the discussions I got the following impression: > >> "+" means in favor of removing the Client Assertion credential > >> functionality from the draft-ietf-oauth-v2 specification and "-" > >> means against it. > >> "*" indicates some constraints. > >> +Eran > >> *Phil (was talking about a stronger version of the client assertion > >> credentials) > >> +David > >> *Francisco (also has a stronger version in mind) -Mike *Marius > >> (Marius has plans to use client assertions in two profiles. So, I > >> assume he wants to have the functionality but I do not know whether > >> he cares about where it is document; in the main spec or in a > >> separate document.) > >> > >> Please correct me if I have forgotten someone or misinterpreted > >> someone's statement. > >> > >> The feedback from the group as I have seen it was a bit difficult to > >> interpret (particularly from Phil, Francisco, and Marius). So, a > >> clarification would be good. > > > > Count me as a "-", I think client assertions should stay. > > > > > >> Feedback indicated that there is interesting in deploying the Client > >> Assertion credential functionality. That's good. > >> > >> My reading of Section 3.2 of OAuth version -11 is that this > >> functionality is NOT mandatory to implement. > >> > >> So, for me the question therefore is where to describe this functional= ity. > >> Here are my questions: > >> > >> 1a) Do you insist in having it documented in draft-ietf-oauth-v2? > >> > >> PLEASE NOTE: Having functionality in a separate document does not > >> mean that it will take longer to complete nor that it is less > >> important. It is purely a document management question! > > > > Not sure a separate document is the same thing. A separate document > > probably means an extension that fully defines how client assertions > > should work in a specific implementation. Other extensions that would > > like to do something similar now would have to either be redundant or > > refer to this first extension. > > > > If the basic parameters are described in the core spec then we have a > > clear extension point. > > > > > > Marius > > _______________________________________________ > > 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 hannes.tschofenig@nsn.com Fri Feb 11 01:01:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F3D3A69D4 for ; Fri, 11 Feb 2011 01:01:20 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNPd+auasxmn for ; Fri, 11 Feb 2011 01:01:19 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8B5293A6921 for ; Fri, 11 Feb 2011 01:01:18 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1B91Vam013289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Feb 2011 10:01:31 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1B90loT002189; Fri, 11 Feb 2011 10:01:30 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 10:01:25 +0100 Received: from 10.144.230.170 ([10.144.230.170]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Feb 2011 09:01:24 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 11 Feb 2011 11:01:18 +0200 From: Hannes Tschofenig To: Peter Saint-Andre , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] meeting in Prague? Thread-Index: AcvJyj6KCHk08wviGkCTsUVKB8cMXA== In-Reply-To: <4D547161.9070106@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Feb 2011 09:01:25.0238 (UTC) FILETIME=[42DA7160:01CBC9CA] Subject: Re: [OAUTH-WG] meeting in Prague? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 09:01:20 -0000 Hi Peter, I have requested a slot already very early. My request is pending scheduling. Ciao Hannes On 2/11/11 1:14 AM, "Peter Saint-Andre" wrote: > It seems that this group probably could have a productive meeting in > Prague. This is just a reminder that the deadline for requesting a slot > is next Monday, February 14. :) > > http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 > > Peter From eve@xmlgrrl.com Fri Feb 11 07:11:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343163A6AF0 for ; Fri, 11 Feb 2011 07:11:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn7aeyGTHIEP for ; Fri, 11 Feb 2011 07:10:58 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id EA5963A6A19 for ; Fri, 11 Feb 2011 07:10:57 -0800 (PST) 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 p1BFB3hm017238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Feb 2011 07:11:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Fri, 11 Feb 2011 07:11:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <13A94176-275A-4292-92AD-6418DEFA76D9@xmlgrrl.com> References: <4D509A79.706@alcatel-lucent.com> To: Kristoffer Gronowski X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] New Working Group Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:11:01 -0000 FWIW, the (OAuth-based) User-Managed Access group has done extensive = work defining an interface between the AS (which we call an = authorization manager for our use cases) and the resource server (which = we call a host). UMA's assumptions go straight to the hard case: The = two entities are in completely different domains and might even start = out without a trust relationship between them. We've made a lot of progress in the last handful of months, e.g. = defining how the host informs the AM what resource sets are being = protected and what actions are possible on them (preparatory to allowing = users to set access policy and allowing AMs to issue scoped tokens), and = the SMART project's UMA/j implementation has been tracking our specs, = but there's still more to do. We're following JWT's development closely = in order to take advantage of it for "meaningful" vs. opaque tokens when = the time is right. Eve On 7 Feb 2011, at 6:26 PM, Kristoffer Gronowski wrote: > Hi Igor! >=20 > That is exactly what I would like to explore! > My thinking was that the authorization server should be quite simple. > There should be no advanced things like a policy server inside it. >=20 > As long as the authorization (AS) and the resource servers (RS) use = the same identity source (or trusted federation of it). > I was thinking of a simple interface that can work in layers. > 1) The RS can ask the AS is this a valid token yes/no > 2) Is this a valid token containing the following scopes? > 3) Was this a token issued by a particular user X. (Based on sharing = or trusting in the identity source) >=20 > Or a combination of the above. In this way you can at least do a good = separation of concerns. > Except of the answer if the criteria was met I have been experimenting = also in returning metadata from the AS so that a RS interceptor can be = built. > You would get all data about token lifetime, scopes attached and owner = information. > This would be a combination with the request input parameters. So you = can start off with making sure that #1 is valid. > Since the token needs to have been generated by the AS. > Then if you have a more dynamic policy that is very endpoint specific = it is far easier to implement it in code then in a general purpose = policy server. >=20 > Then you can easily implement things like this protected resource = needs scope X or Y Mon-Fri while Z on weekends. > Another advantage is that the same code can work on your behalf in = discovery mode to actually give you a clue what is needed at this very = moment to access. > The AS is just following strict rules and giving facts to you as a RS. >=20 > It is a pretty clean design but I am sure that it will not fit = everyone's needs. > And I am not saying that policy server would go away but for simple = REST services this is a powerful framework where you do not have to mash = all of you implementation into one big thing. >=20 > So that it why I was thinking that it might be a candidate for an = optional interface that might be good to have. > With it people can develop Oauth protected services quicker since = there is more ready code to start from. >=20 > Does this still fit your vision too described this way? >=20 > BR Kristoffer =20 >=20 > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 > Sent: Monday, February 07, 2011 5:21 PM > To: Kristoffer Gronowski > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] New Working Group Items? >=20 > Kristoffer, >=20 > I assume you mean an interface between the authorization server and = the resource server. If so, I believe it definitely merits a serious = discussion, and I support the idea in principle. >=20 > On this subject, I think we need even more work defining the token and = linking it to the resource owner. Today's discussion between Eran and = Phil once again made me think of insufficiency of the "opaque tokens."=20= > Indeed, anything that comes with the OAuth flow is an OAuth token. = (=46rom the security point of view, of course, that also means that = anything that can be INSERTED into an OAuth flow will be an OAuth = token...) I am not criticizing the design decisions--I have agreed = with all of them. >=20 > But going forward, I would like the resource owner, the end user (both = human and virtual) to 1) issue tokens or 2) outsource this work it it = wishes. In the latter case, the resource owner must at least understand = what the token has rather than just pass the token. >=20 > Ideally, I would like this to be an OAuth work item: OAuth WG works = very well, and it has gathered the best people to judge the task. I = understand though that token specification is not presently in the = charter, and therefore it can be discussed only in the context of = changing the charter. And so I first wrote this in response to the item = that you proposed, which I think is one step toward what I thought = should be done. >=20 > Igor >=20 > Kristoffer Gronowski wrote: >> ... >> IMO there is one item missing and that is to create an optional = formal=20 >> interface between the authorization server and the protected = resource. >> It could increase the productivity of creating the oauth protected = web=20 >> services when the auth server can be treated as an off the shelf = piece=20 >> of code. >> Then it would be up to the auth server to also provide an number of=20= >> other extension like the discovery, token revocation and other. >=20 >=20 >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From toby@timetric.com Sat Feb 12 17:57:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A69A3A6839 for ; Sat, 12 Feb 2011 17:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9dfBQ6I3ZGs for ; Sat, 12 Feb 2011 17:57:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 751BB3A6A51 for ; Sat, 12 Feb 2011 17:57:14 -0800 (PST) Received: by vws7 with SMTP id 7so2570749vws.31 for ; Sat, 12 Feb 2011 17:57:32 -0800 (PST) Received: by 10.220.188.201 with SMTP id db9mr2847410vcb.279.1297562250953; Sat, 12 Feb 2011 17:57:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.72.72 with HTTP; Sat, 12 Feb 2011 17:57:09 -0800 (PST) X-Originating-IP: [78.105.57.124] From: Toby White Date: Sun, 13 Feb 2011 01:57:09 +0000 Message-ID: To: OAuth Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 10:42:29 -0000 Some queries arising, having been working through a trial implementation: * Can the timestamp parameter have leading zeroes? ie, would an authorization header be valid which read: Authorization: MAC [...] timestamp="0001297561419" [...] (assuming the same timestamp string was used for the signature.) The spec doesn't forbid it, and indeed there's no obvious reason to except that it's a thing that could be normalized and isn't. * Does the order of parameters in the authorization header matter? ie - must the parameters always appear in the order token / timestamp / nonce / (bodyhash) / signature? or is a request valid if the signature is correct but the parameters are in a different order? * I think there's an error in the parameters normalization example. The final output of the normalization algorithm at the end of 3.3.1.1 is given as: a2=r%20b\n a3=2%20q\n a3=a\n b5=%3D%253D\n c%40=\n c2=\n but I don't think the final newline should be there. By my reading of the description of the algorithm, there's no reason for the final newline to be appended - and if it should be appended, then the Normalized Request String example at the end of 3.3.1 ought to end with *two* newlines, since each of the HTTP request elements should be followed by a newline character. -- http://timetric.com 2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile) twitter: @timetric, @tow21 | skype: tobyohwhite From skylar@kiva.org Sun Feb 13 04:09:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782933A6B76 for ; Sun, 13 Feb 2011 04:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr0oZGrBWJhQ for ; Sun, 13 Feb 2011 04:09:50 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id 3E0053A6B74 for ; Sun, 13 Feb 2011 04:09:49 -0800 (PST) Received: from source ([209.85.214.46]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTVfKIVpLNGAPJrr3uwqalytzmOQNkUGq@postini.com; Sun, 13 Feb 2011 04:10:10 PST Received: by bwz15 with SMTP id 15so5521117bwz.5 for ; Sun, 13 Feb 2011 04:10:08 -0800 (PST) Received: by 10.204.64.74 with SMTP id d10mr2358597bki.7.1297599008100; Sun, 13 Feb 2011 04:10:08 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id f20sm971436bkf.16.2011.02.13.04.10.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 04:10:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Sun, 13 Feb 2011 13:10:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D532554-7BDE-435C-8A65-6CFE66594A05@kiva.org> References: To: Toby White X-Mailer: Apple Mail (2.1082) Cc: OAuth Mailing List Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 12:09:51 -0000 I think it's meant to be there. If you look at Signature Base String = construction, item 9 is a normal "line item" just like all others and = should have a newline at the end. So you can think of it as the params = as one sting w/ newline between followed by a newline. In the example, = it looks like each param is followed by a newline which is not exactly = how the spec words it, but it's the same result. For me, ending the params with a newline results in the same signature = values as the spec. What might be unclear is if there should be an empty newline if the = query string is empty. Eran? On Feb 13, 2011, at 2:57 AM, Toby White wrote: > * I think there's an error in the parameters normalization example. >=20 > The final output of the normalization algorithm at the end of 3.3.1.1 > is given as: >=20 > a2=3Dr%20b\n > a3=3D2%20q\n > a3=3Da\n > b5=3D%3D%253D\n > c%40=3D\n > c2=3D\n >=20 > but I don't think the final newline should be there. By my reading of > the description of the algorithm, there's no reason for the final > newline to be appended - and if it should be appended, then the > Normalized Request String example at the end of 3.3.1 ought to end > with *two* newlines, since each of the HTTP request elements should be > followed by a newline character. From toby@timetric.com Sun Feb 13 06:02:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A098E3A6A71 for ; Sun, 13 Feb 2011 06:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbWHFojJ7IlJ for ; Sun, 13 Feb 2011 06:02:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 0E7F13A6A1A for ; Sun, 13 Feb 2011 06:02:16 -0800 (PST) Received: by vxi40 with SMTP id 40so2324457vxi.31 for ; Sun, 13 Feb 2011 06:02:36 -0800 (PST) Received: by 10.220.100.143 with SMTP id y15mr3498303vcn.174.1297605755801; Sun, 13 Feb 2011 06:02:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.72.72 with HTTP; Sun, 13 Feb 2011 06:02:15 -0800 (PST) X-Originating-IP: [78.105.57.124] In-Reply-To: <9D532554-7BDE-435C-8A65-6CFE66594A05@kiva.org> References: <9D532554-7BDE-435C-8A65-6CFE66594A05@kiva.org> From: Toby White Date: Sun, 13 Feb 2011 14:02:15 +0000 Message-ID: To: Skylar Woodward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth Mailing List Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 14:02:18 -0000 I think you're reading the section differently from me. My reading is that the Normalized Request String is composed of each of the itemized elements, with newlines appended to them, concatenated together. "ITEM_1\nITEM_2\n[...]ITEM_8\nITEM_9\n" My reading is that none of the items - per se - end with a \n. From the list, item 1 is "The access token", not "The access token followed by a newline." So, by analogy, I read Section 3.3.1.1 as telling me how to construct the string ITEM_9 - not telling me how to construct the string "ITEM_9\n". I think you're reading the spec as saying that the NormalizedRequestString = is "ITEM_1ITEM_2[...]ITEM_8ITEM_9 so that the trailing '\n's are part of the ITEMs. But I can't square that with the description of the items in the list using the text currently there. For what it's worth, I'm not being pernickety for no reason - I came across this because I wrote a bunch of tests for my parameter-normalization function, based on reading the description of the algorithm, and then found this issue only because pasting the example from the spec into my testsuite caused it to fail, due to the extra trailing newline. Toby On Sun, Feb 13, 2011 at 12:10 PM, Skylar Woodward wrote: > I think it's meant to be there. If you look at Signature Base String cons= truction, item 9 is a normal "line item" just like all others and should ha= ve a newline at the end. So you can think of it as the params as one sting = w/ newline between followed by a newline. In the example, it looks like eac= h param is followed by a newline which is not exactly how the spec words it= , but it's the same result. > > For me, ending the params with a newline results in the same signature va= lues as the spec. > > What might be unclear is if there should be an empty newline if the query= string is empty. =A0Eran? > > > On Feb 13, 2011, at 2:57 AM, Toby White wrote: > >> * I think there's an error in the parameters normalization example. >> >> The final output of the normalization algorithm at the end of 3.3.1.1 >> is given as: >> >> =A0 =A0 a2=3Dr%20b\n >> =A0 =A0 a3=3D2%20q\n >> =A0 =A0 a3=3Da\n >> =A0 =A0 b5=3D%3D%253D\n >> =A0 =A0 c%40=3D\n >> =A0 =A0 c2=3D\n >> >> but I don't think the final newline should be there. By my reading of >> the description of the algorithm, there's no reason for the final >> newline to be appended - and if it should be appended, then the >> Normalized Request String example at the end of 3.3.1 ought to end >> with *two* newlines, since each of the HTTP request elements should be >> followed by a newline character. > > --=20 http://timetric.com 2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile) twitter: @timetric, @tow21 | skype: tobyohwhite From eran@hueniverse.com Sun Feb 13 09:57:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF653A6A1C for ; Sun, 13 Feb 2011 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w6xv0wL-nzs for ; Sun, 13 Feb 2011 09:57:33 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0B6B03A6A15 for ; Sun, 13 Feb 2011 09:57:32 -0800 (PST) Received: (qmail 4354 invoked from network); 13 Feb 2011 17:57:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Feb 2011 17:57:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 13 Feb 2011 10:57:52 -0700 From: Eran Hammer-Lahav To: Toby White , OAuth Mailing List Date: Sun, 13 Feb 2011 10:57:50 -0700 Thread-Topic: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvLasTRl5Jm8KrySmGn/+RhZ1YYHwAPBdbg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@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 Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 17:57:34 -0000 Hey Toby, > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Toby White > Sent: Saturday, February 12, 2011 5:57 PM > * Can the timestamp parameter have leading zeroes? ie, would an > authorization header be valid which read: >=20 > Authorization: MAC [...] timestamp=3D"0001297561419" [...] >=20 > (assuming the same timestamp string was used for the signature.) >=20 > The spec doesn't forbid it, and indeed there's no obvious reason to excep= t > that it's a thing that could be normalized and isn't. It must not. I'll make this explicit. The reason being is that this is a nu= merical value and is likely to be parsed out of the header first as a numbe= r, and then added to the string. =20 >=20 > * Does the order of parameters in the authorization header matter? >=20 > ie - must the parameters always appear in the order token / timestamp / > nonce / (bodyhash) / signature? or is a request valid if the signature is= correct > but the parameters are in a different order? Order does not matter. Only their order in the normalized string does. > * I think there's an error in the parameters normalization example. >=20 > The final output of the normalization algorithm at the end of 3.3.1.1 is = given > as: >=20 > a2=3Dr%20b\n > a3=3D2%20q\n > a3=3Da\n > b5=3D%3D%253D\n > c%40=3D\n > c2=3D\n >=20 > but I don't think the final newline should be there. By my reading of the > description of the algorithm, there's no reason for the final newline to = be > appended - and if it should be appended, then the Normalized Request > String example at the end of 3.3.1 ought to end with *two* newlines, sinc= e > each of the HTTP request elements should be followed by a newline > character. Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, the = new-line is a separator so that part does not end with a new-line. I'll cla= rify this. EHL From rasmus@lerdorf.com Sun Feb 13 10:47:32 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D68A3A6A1C for ; Sun, 13 Feb 2011 10:47:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q00RnbBX9r2e for ; Sun, 13 Feb 2011 10:47:31 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 467563A6A1A for ; Sun, 13 Feb 2011 10:47:31 -0800 (PST) Received: by pzk5 with SMTP id 5so892227pzk.31 for ; Sun, 13 Feb 2011 10:47:52 -0800 (PST) Received: by 10.142.131.9 with SMTP id e9mr2441038wfd.0.1297622871881; Sun, 13 Feb 2011 10:47:51 -0800 (PST) Received: from Anonymous.local (c-98-234-184-167.hsd1.ca.comcast.net [98.234.184.167]) by mx.google.com with ESMTPS id c3sm2930169wfa.2.2011.02.13.10.47.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 10:47:50 -0800 (PST) Message-ID: <4D582753.7000400@lerdorf.com> Date: Sun, 13 Feb 2011 10:47:47 -0800 From: Rasmus Lerdorf User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OAuth Mailing List Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 18:47:32 -0000 On 2/13/11 9:57 AM, Eran Hammer-Lahav wrote: > Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, the new-line is a separator so that part does not end with a new-line. I'll clarify this. This section is going to trip people up. Not much that can be done about it, other than being really explicit, and I think it might help slightly if you provide the actual signature produced by the example in section 3.3.1. I can see people leaving in the trailing newline in 3.3.1.1 and then adding another newline when add the request string to the signature string. Also, section 3.3.3 should say "hmac-sha-256" at the beginning there. -Rasmus From skylar@kiva.org Sun Feb 13 11:12:59 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2C93A69B8 for ; Sun, 13 Feb 2011 11:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onXrLggGlZdV for ; Sun, 13 Feb 2011 11:12:58 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by core3.amsl.com (Postfix) with SMTP id 274553A69A7 for ; Sun, 13 Feb 2011 11:12:57 -0800 (PST) Received: from source ([209.85.161.46]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKTVgtTcGT6g8pHpQFQq8jYZPp9+jYqDIA@postini.com; Sun, 13 Feb 2011 11:13:19 PST Received: by fxm20 with SMTP id 20so4414024fxm.19 for ; Sun, 13 Feb 2011 11:13:16 -0800 (PST) Received: by 10.223.96.198 with SMTP id i6mr3469128fan.10.1297624396401; Sun, 13 Feb 2011 11:13:16 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id 11sm702708faw.20.2011.02.13.11.13.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 11:13:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 13 Feb 2011 20:13:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <45917638-986B-448E-A048-61F728C70528@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth Mailing List Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 19:12:59 -0000 On Feb 13, 2011, at 6:57 PM, Eran Hammer-Lahav wrote: > Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, = the new-line is a separator so that part does not end with a new-line. = I'll clarify this. Yes, it's not clear that item 9 should be an empty string (followed by = of course, a new-line) if the query string is empty. That would be a = helpful point to add to 3.3.1.1 as you did in 3.3.1, item #4. +1 to removing the last new-line in 3.3.1.1 (Toby and I resolved our = confusion), and to the suggestion of adding a sample signature to 3.3.1 From wmills@yahoo-inc.com Mon Feb 14 08:41:57 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438E93A69EB for ; Mon, 14 Feb 2011 08:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.331 X-Spam-Level: X-Spam-Status: No, score=-17.331 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCicCjxuII-p for ; Mon, 14 Feb 2011 08:41:56 -0800 (PST) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 8AC6C3A699E for ; Mon, 14 Feb 2011 08:41:56 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p1EGfkb5093830; Mon, 14 Feb 2011 08:41:46 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Mon, 14 Feb 2011 08:41:46 -0800 From: William Mills To: Eran Hammer-Lahav , Toby White , OAuth Mailing List Date: Mon, 14 Feb 2011 08:41:44 -0800 Thread-Topic: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvLasTRl5Jm8KrySmGn/+RhZ1YYHwAPBdbgAC/E/4A= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@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: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:41:57 -0000 > > but I don't think the final newline should be there. By my reading of > the > > description of the algorithm, there's no reason for the final newline > to be > > appended - and if it should be appended, then the Normalized Request > > String example at the end of 3.3.1 ought to end with *two* newlines, > since > > each of the HTTP request elements should be followed by a newline > > character. >=20 > Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, > the new-line is a separator so that part does not end with a new-line. > I'll clarify this. >=20 > EHL Perhaps an explicit example would help make it lear? From James.H.Manger@team.telstra.com Mon Feb 14 17:41:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB913A6E05 for ; Mon, 14 Feb 2011 17:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.028 X-Spam-Level: X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[AWL=0.929, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4bJPJl5dHxN for ; Mon, 14 Feb 2011 17:41:17 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 45A3D3A6A0C for ; Mon, 14 Feb 2011 17:41:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,471,1291554000"; d="scan'208";a="24573336" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 Feb 2011 12:41:36 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6257"; a="19192605" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Feb 2011 12:41:37 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 15 Feb 2011 12:41:36 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , OAuth Mailing List Date: Tue, 15 Feb 2011 12:41:35 +1100 Thread-Topic: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 Thread-Index: AcvLasTRl5Jm8KrySmGn/+RhZ1YYHwAPBdbgAC/E/4AAC7v8cA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127D908530@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A90C087B@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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] Queries on draft-hammer-oauth-v2-mac-token-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 01:41:18 -0000 In my mind, the simplest normalized request string has one line for each na= me=3Dvalue query parameter. If there are no parameters, there are no lines.= The confusion in the current text seems due to some new line chars coming = from section 3.3.1 and others from 3.3.1.1. It would be better for latter t= o return a sorted array of name=3Dvalue strings, and the former to output t= hem one pair per line. My suggested text: 3.3.1. Normalized Request String ... 9. Each query parameter from the HTTP request URI (each on its own line name=3Dvalue\n), after being normalized and sorted as described in section 3.3.1.1 3.3.1.1. Parameters Normalization ... [drop step 4 "...sorted parameters are concatenated..." ... [drop the last 2 paragraphs, after the "Sorted" table. This part of the example is already repeated at the end of section 3.3.1. anyway.] -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Tuesday, 15 February 2011 3:42 AM To: Eran Hammer-Lahav; Toby White; OAuth Mailing List Subject: Re: [OAUTH-WG] Queries on draft-hammer-oauth-v2-mac-token-02 > > but I don't think the final newline should be there. By my reading of t= he > > description of the algorithm, there's no reason for the final newline t= o be > > appended - and if it should be appended, then the Normalized Request > > String example at the end of 3.3.1 ought to end with *two* newlines, si= nce > > each of the HTTP request elements should be followed by a newline > > character. >=20 > Each of the 9 items is new-line terminated, even if empty. In 3.3.1.1, > the new-line is a separator so that part does not end with a new-line. > I'll clarify this. >=20 > EHL Perhaps an explicit example would help make it lear? From c.stuebner@external.telekom.de Wed Feb 16 08:01:11 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E6C3A6E14 for ; Wed, 16 Feb 2011 08:01:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27AXDjFsbz2F for ; Wed, 16 Feb 2011 08:01:10 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 4E64A3A6D9D for ; Wed, 16 Feb 2011 08:01:09 -0800 (PST) Received: from g8p01.blf01.telekom.de ([164.25.63.135]) by tcmail81.telekom.de with ESMTP; 16 Feb 2011 17:01:30 +0100 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP for oauth@ietf.org; Wed, 16 Feb 2011 17:01:30 +0100 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Wed, 16 Feb 2011 17:01:29 +0100 From: "Stuebner, Christian (extern)" To: "'oauth@ietf.org'" Date: Wed, 16 Feb 2011 17:01:28 +0100 Thread-Topic: Missing Client Credentials on Token Endpoint - Which Error Response? Thread-Index: AcvN8sWB2Wduh3F8R3uBbRGhS9Adtg== Message-Id: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Missing Client Credentials on Token Endpoint - Which Error Response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:01:11 -0000 Hi all, I noticed a minor change in wording for the error response codes at the tok= en endpoint (see citation below). But I'm still not sure how an authorization server is expected to behave in= cases where he supports client password authentication via request paramet= ers and HTTP Basic authentication and the client included neither of them i= n the request. Since one could argue that "no credentials" are also "invalid credentials" = the authorization server could do: a) Send status code 401 and WWW-Authenticate Basic as header b) Send status code 400 and error code invalid_client I'm more in favor of a) because it seems to be more HTTP-like (or RESTful i= f you will) but I'm afraid b) is what was initially intended. How are your implementations handling this case? Should we be more specific= in the spec? draft-10 (chapter 4.3): ----------------------- If the client provided invalid credentials using an HTTP authentication sch= eme via the Authorization request header field, the authorization server MU= ST respond with the HTTP 401 (Unauthorized) status code. Otherwise, the aut= horization server SHALL respond with the HTTP 400 (Bad Request) status code= . [...] invalid_client: The client identifier provided is invalid, the client f= ailed to authenticate, the client did not include its credentials, provided= multiple client credentials, or used unsupported credentials type.=20 draft-12 (chapter 5.2):=20 ----------------------- If the client provided invalid credentials using an HTTP authentication sch= eme via the Authorization request header field, the authorization server MU= ST respond with a HTTP 401 (Unauthorized) status code, and include the WWW-= Authenticate response header field matching the authentication scheme used = by the client. Otherwise, the authorization server MUST respond with the HT= TP 400 (Bad Request) status code. [...] invalid_client: Client authentication failed (e.g. unknown client, no c= lient credentials included, multiple client credentials included, or unsupp= orted credentials type).=20 Regards, Christian St=FCbner= From eran@hueniverse.com Wed Feb 16 08:34:27 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385513A6E80 for ; Wed, 16 Feb 2011 08:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuAu0W5ZGqFO for ; Wed, 16 Feb 2011 08:34:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5EE0D3A6E7D for ; Wed, 16 Feb 2011 08:34:26 -0800 (PST) Received: (qmail 10295 invoked from network); 16 Feb 2011 16:34:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 16:34:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Feb 2011 09:34:41 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 16 Feb 2011 09:34:34 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: Acu9lPsVs7t+NAwoS3mCAH3DITsxMQQYQ/+w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3ED3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:34:27 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 26, 2011 12:09 PM > - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that > the client MUST discard the credentials once it obtains an access token. = I > think it SHOULD discard once it obtains a *refresh* token. Since this MUST cannot be confirmed, it serves as a community educational t= ool more than anything else. I rather leave it without conditions. =20 > - 4.5. Extensions. For new grant types, we are not using a registry. Is t= hat OK? No need. The registry is only to prevent name collisions and since we are u= sing URIs, they already have built-in namespaces. =20 > - 5.2. Error Response. The fist part of the first paragraph talks about 4= 01 and > client credentials in the Authorization header. Since this was dropped fr= om > core, this looks strange. This is specific to client authentication, not grant verification or protec= ted resources. I'll clarify. EHL From phil.hunt@oracle.com Wed Feb 16 09:00:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28AD3A6CD0 for ; Wed, 16 Feb 2011 09:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnY0ZDtvLlB8 for ; Wed, 16 Feb 2011 09:00:17 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2B4B33A6EA5 for ; Wed, 16 Feb 2011 09:00:17 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1GH0eri026584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 17:00:42 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1GEnU2L023467; Wed, 16 Feb 2011 17:00:38 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 1060469091297875636; Wed, 16 Feb 2011 09:00:36 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Feb 2011 09:00:35 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D3ED3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 16 Feb 2011 09:00:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <316BD51B-625D-49B2-9DB8-3368C8A01E29@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3ED3@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D5C02B7.0201:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:00:20 -0000 Re: 4.3. This could be something to put in security considerations. = Since there will be reasonable cases where for example a password hash = is retained. And as indicated by Eran, this is a best practice rather = then an inter-op issue. Phil phil.hunt@oracle.com On 2011-02-16, at 8:34 AM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Wednesday, January 26, 2011 12:09 PM >=20 >> - 4.3. Resource Owner Password Credentials. The 3rd paragraph states = that >> the client MUST discard the credentials once it obtains an access = token. I >> think it SHOULD discard once it obtains a *refresh* token. >=20 > Since this MUST cannot be confirmed, it serves as a community = educational tool more than anything else. I rather leave it without = conditions. >=20 >> - 4.5. Extensions. For new grant types, we are not using a registry. = Is that OK? >=20 > No need. The registry is only to prevent name collisions and since we = are using URIs, they already have built-in namespaces. >=20 >> - 5.2. Error Response. The fist part of the first paragraph talks = about 401 and >> client credentials in the Authorization header. Since this was = dropped from >> core, this looks strange. >=20 > This is specific to client authentication, not grant verification or = protected resources. I'll clarify. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 16 09:00:34 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511423A6E4B for ; Wed, 16 Feb 2011 09:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTg2aP230RfW for ; Wed, 16 Feb 2011 09:00:33 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6358D3A6C9F for ; Wed, 16 Feb 2011 09:00:33 -0800 (PST) Received: (qmail 25464 invoked from network); 16 Feb 2011 17:01:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 17:01:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 10:00:54 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 16 Feb 2011 10:00:48 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: Acu9lPsVs7t+NAwoS3mCAH3DITsxMQQZYtrg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:00:34 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 26, 2011 12:09 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > - 4.1. Authorization Code. It is stated that authorization code is suitab= le for > clients that can hold a secret. Not necessarily true, it is the best flow= for > native apps, for example. While the authorization code *can* be used without client authentication, i= t was designed explicitly for that use case. By defining it as such, we mak= e the security consideration section significantly simpler and more specifi= c. Now, this does not prevent using it without client authentication. Note tha= t this is prose and not normative language. I rather not change this. I think using the ability of the client to authen= ticate with confidential credentials has been a huge issue for OAuth 1.0 un= derstanding and implementers and this is the simplest way to address it. At some point, trying to make every single word be 100% compatible with eve= ry conceivable use case makes the specification unusable. EHL From eran@hueniverse.com Wed Feb 16 09:01:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214483A6C9F for ; Wed, 16 Feb 2011 09:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FwJaMNn1+GF for ; Wed, 16 Feb 2011 09:01:42 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5D2213A6C8F for ; Wed, 16 Feb 2011 09:01:42 -0800 (PST) Received: (qmail 19918 invoked from network); 16 Feb 2011 17:02:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 17:02:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 10:01:47 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , Marius Scurtescu Date: Wed, 16 Feb 2011 10:01:41 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: Acu+DiKhkBIAwtkWR6awwxxSId7QFQP6962w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3EEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:01:43 -0000 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Thursday, January 27, 2011 2:37 AM > -- 3.1.1, 4.1.2, and Out-of-Band flows >=20 > It is an important consideration for us that clients that cannot capture = a > redirect from the user-agent be able to use authentication flow. In the p= ast > this has been dubbed and Out-of-Band (OOB) flow. However, the > reorganization of the document clearly marks out both Auth and Implicit a= s > flows reserved for clients "capable of receiving incoming requests (via > redirection) from the authorization server." This language makes these > incompatible with OOB clients. In addition, other language inhibits this= use: No, it is just guidance. As defined, these are not appropriate for OOB clie= nts, but with minor adjustments, such as the definition of a special URN re= direction URI, can be made suitable. =20 EHL From mscurtescu@google.com Wed Feb 16 09:04:28 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D50E3A6C8F for ; Wed, 16 Feb 2011 09:04:28 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS9MbTUcZjup for ; Wed, 16 Feb 2011 09:04:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6953F3A6C2E for ; Wed, 16 Feb 2011 09:04:27 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p1GH4tn7011568 for ; Wed, 16 Feb 2011 09:04:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297875895; bh=jlIBsXOmJVQEIKsB1LKxSyXvaac=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TnDRNNObnZYdaLCVf9cwnPSIp1J183xDaq5Fc4sleuNlfBifiR4LTmBkXHdQ2IIYY y2SVq4awyVYwcjjdhRIjA== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by hpaq11.eem.corp.google.com with ESMTP id p1GH4rHA021173 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Feb 2011 09:04:54 -0800 Received: by gyb11 with SMTP id 11so693671gyb.19 for ; Wed, 16 Feb 2011 09:04:53 -0800 (PST) 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=H8FDcsSVYj4I23wR4Q1hCpO29Bu3FgtS6lOtk3ivS/w=; b=HSoTquqF73S8tztzRJoSHNF9ctQihBIU1KeUjX/dOxXIzL3DrEP39B95S/sq38espq /jxGEj2usjo29IkmDANA== 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=TlQvNye5tVNVUkAC84KBMP5vksvhoZT/kIXHoh38kTWtLDC4x34olTrSRBbX2P3H7V Yw3Msss//7q0R8DMEoeQ== Received: by 10.100.7.3 with SMTP id 3mr368342ang.62.1297875892899; Wed, 16 Feb 2011 09:04:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Wed, 16 Feb 2011 09:04:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 16 Feb 2011 09:04:32 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:04:28 -0000 On Wed, Feb 16, 2011 at 9:00 AM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Wednesday, January 26, 2011 12:09 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >> >> - 4.1. Authorization Code. It is stated that authorization code is suitable for >> clients that can hold a secret. Not necessarily true, it is the best flow for >> native apps, for example. > > While the authorization code *can* be used without client authentication, it was designed explicitly for that use case. By defining it as such, we make the security consideration section significantly simpler and more specific. > > Now, this does not prevent using it without client authentication. Note that this is prose and not normative language. > > I rather not change this. I think using the ability of the client to authenticate with confidential credentials has been a huge issue for OAuth 1.0 understanding and implementers and this is the simplest way to address it. > > At some point, trying to make every single word be 100% compatible with every conceivable use case makes the specification unusable. Yes, I understand. But Native Apps have no appropriate flow now, and they started the whole protocol. Marius From eran@hueniverse.com Wed Feb 16 09:33:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E61C3A6EBD for ; Wed, 16 Feb 2011 09:33:12 -0800 (PST) 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.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5PyBGMzHSAV for ; Wed, 16 Feb 2011 09:33:11 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 97EDB3A6EB0 for ; Wed, 16 Feb 2011 09:33:11 -0800 (PST) Received: (qmail 16645 invoked from network); 16 Feb 2011 17:33:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 17:33:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Feb 2011 10:33:20 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , "oauth@ietf.org" Date: Wed, 16 Feb 2011 10:33:13 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: Acu+DiRiftKVyAT6QuensmfJaoXx7AAT0zJVA+eoncA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F09@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@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 Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:33:12 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Thursday, January 27, 2011 12:05 PM > 1.2 >=20 > "Tokens may be pure capabilities." To a non-security-engineer such as > myself, this bit reads very oddly on its own. I understand that "capabili= ty" has > another meaning in the security world, so can we either reference that > definition or give a small prose example, like "capabilities, such as ...= ". I dropped this. This means nothing to most people. I have no objection for = this to be added in the security considerations section. =20 > 1.3 >=20 > Should these introductions link down to their implementation sections? > Seems like a useful xref. >=20 > 1.3.2, 4.2 Nah. I want people to read the introduction as a whole, then just use the r= est as reference. Jumping between sections is just confusing. > I'm not sold on calling this "Implicit", though "user agent" and "direct"= aren't > much better. It's descriptive. > 2. >=20 > Should we strengthen the first "SHOULD NOT" to a "MUST NOT", since this i= s > about assumptions of security made by the AS? This is possibly bikesheddi= ng > as the AS could always still say "We know that the secret-storage securit= y of > some clients might be bad but that's OK." I actually changed it to lowercase since it is not really normative. > 3.2 >=20 > Can we make the token endpoint MUST support POST and MAY support > GET? I understand the arguments for favoring POST, but they don't always > apply to all environments. (Brought this up a while ago, seems like it's = not a > breaking change to allow.) It applies to the web as a whole. What you do internally is your business..= . Requiring POST removes the need to write security consideration about the= issues with GET. > 6. >=20 > I'd like to see a paragraph on redelegation practices, but I'm not sure i= t > belongs in the core as it's really more of a way of *using* refresh token= s and > scopes in a slightly different way than it is really a *new* thing. All t= he > mechanisms are there to support it, a recipe just hasn't been written out= for > it. Is there desire for an extension doc for this? >From my experience, writing a draft works better than asking for interest. = I am sure you'll find an audience. =20 EHL From eran@hueniverse.com Wed Feb 16 10:39:38 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64923A6EE8 for ; Wed, 16 Feb 2011 10:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqTGcKZYV96B for ; Wed, 16 Feb 2011 10:39:38 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E392A3A6EE5 for ; Wed, 16 Feb 2011 10:39:37 -0800 (PST) Received: (qmail 5839 invoked from network); 16 Feb 2011 18:40:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 18:40:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 16 Feb 2011 11:39:59 -0700 From: Eran Hammer-Lahav To: "Stuebner, Christian (extern)" , "'oauth@ietf.org'" Date: Wed, 16 Feb 2011 11:39:52 -0700 Thread-Topic: [OAUTH-WG] Missing Client Credentials on Token Endpoint - Which Error Response? Thread-Index: AcvN8sWB2Wduh3F8R3uBbRGhS9AdtgAFU7uw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F42@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 Subject: Re: [OAUTH-WG] Missing Client Credentials on Token Endpoint - Which Error Response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:39:38 -0000 (a) is more appropriate. See -13 for revised language. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Stuebner, Christian (extern) > Sent: Wednesday, February 16, 2011 8:01 AM > To: 'oauth@ietf.org' > Subject: [OAUTH-WG] Missing Client Credentials on Token Endpoint - Which > Error Response? >=20 > Hi all, >=20 > I noticed a minor change in wording for the error response codes at the > token endpoint (see citation below). > But I'm still not sure how an authorization server is expected to behave = in > cases where he supports client password authentication via request > parameters and HTTP Basic authentication and the client included neither = of > them in the request. >=20 > Since one could argue that "no credentials" are also "invalid credentials= " the > authorization server could do: > a) Send status code 401 and WWW-Authenticate Basic as header > b) Send status code 400 and error code invalid_client >=20 > I'm more in favor of a) because it seems to be more HTTP-like (or RESTful= if > you will) but I'm afraid b) is what was initially intended. > How are your implementations handling this case? Should we be more > specific in the spec? >=20 >=20 > draft-10 (chapter 4.3): > ----------------------- > If the client provided invalid credentials using an HTTP authentication s= cheme > via the Authorization request header field, the authorization server MUST > respond with the HTTP 401 (Unauthorized) status code. Otherwise, the > authorization server SHALL respond with the HTTP 400 (Bad Request) status > code. > [...] > invalid_client: The client identifier provided is invalid, the client= failed to > authenticate, the client did not include its credentials, provided multip= le > client credentials, or used unsupported credentials type. >=20 >=20 > draft-12 (chapter 5.2): > ----------------------- > If the client provided invalid credentials using an HTTP authentication s= cheme > via the Authorization request header field, the authorization server MUST > respond with a HTTP 401 (Unauthorized) status code, and include the WWW- > Authenticate response header field matching the authentication scheme > used by the client. Otherwise, the authorization server MUST respond with > the HTTP 400 (Bad Request) status code. > [...] > invalid_client: Client authentication failed (e.g. unknown client, no= client > credentials included, multiple client credentials included, or unsupporte= d > credentials type). >=20 >=20 >=20 > Regards, > Christian St=FCbner > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 16 10:43:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546F73A6E25 for ; Wed, 16 Feb 2011 10:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcHpa+GSkP9u for ; Wed, 16 Feb 2011 10:42:59 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8D9753A69A6 for ; Wed, 16 Feb 2011 10:42:59 -0800 (PST) Received: (qmail 11093 invoked from network); 16 Feb 2011 18:43:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 18:43:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 11:43:15 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 16 Feb 2011 11:43:08 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvN+6TPBONTKjOoRXSZjocTCZzjlQADXRAQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:43:00 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, February 16, 2011 9:05 AM > Yes, I understand. But Native Apps have no appropriate flow now, and they > started the whole protocol. I am not sure "they started the whole protocol" (it was more like OpenID in= Twitter API), but either way, why can't they use the implicit grant type? = That's where the specification is guiding them towards. EHL From mscurtescu@google.com Wed Feb 16 10:58:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072423A6D33 for ; Wed, 16 Feb 2011 10:58:26 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aba-2RJJq5uI for ; Wed, 16 Feb 2011 10:58:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0A7073A6D2A for ; Wed, 16 Feb 2011 10:58:23 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p1GIwqcb009782 for ; Wed, 16 Feb 2011 10:58:52 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297882732; bh=T7WaPRqqk5l+Lnw6E/47BO5XOWY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pjFyeXrL/XgqdsBtBcDsJ34qv6p7eWohrMPjSWin791tpNHpHicCGC3HLf+7xeSnl XRbCWJVBGGdOq2XmDSj+Q== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by hpaq3.eem.corp.google.com with ESMTP id p1GIwfsW021547 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Feb 2011 10:58:50 -0800 Received: by yie19 with SMTP id 19so823476yie.31 for ; Wed, 16 Feb 2011 10:58:50 -0800 (PST) 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=ScJDYE8xRett9pU0CSKGQowDZDSoXXO04i7Y3NQ/Cp0=; b=AfGAgakLpu09oPPiKrKK9X96NgIMQkWXX94YBI1EWj526orfyuLLLp1efS/Iiqz9+C f3fI2TjhyAhCVA5ovOWg== 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=fTdBUY4vANEfDuNHdWa/o/KFkrVlbXVo8gHc8Cn1X5MOw+IYjsOpwCX2uGjNSSuAq8 zWZJnpbL0w7gXtVLSRJw== Received: by 10.101.182.16 with SMTP id j16mr364456anp.232.1297882730075; Wed, 16 Feb 2011 10:58:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Wed, 16 Feb 2011 10:58:29 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 16 Feb 2011 10:58:29 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:58:26 -0000 On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Wednesday, February 16, 2011 9:05 AM > >> Yes, I understand. But Native Apps have no appropriate flow now, and they >> started the whole protocol. > > I am not sure "they started the whole protocol" (it was more like OpenID in Twitter API), but either way, why can't they use the implicit grant type? That's where the specification is guiding them towards. That would be the old User-Agent flow? That's terrible for native apps, native apps need long lived credentials. Marius From eran@hueniverse.com Wed Feb 16 10:58:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84C83A6EE4 for ; Wed, 16 Feb 2011 10:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+491ln90kdQ for ; Wed, 16 Feb 2011 10:58:39 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 571013A6D2A for ; Wed, 16 Feb 2011 10:58:39 -0800 (PST) Received: (qmail 4968 invoked from network); 16 Feb 2011 18:59:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 18:59:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 11:59:02 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 16 Feb 2011 11:58:55 -0700 Thread-Topic: Working group last call request for: draft-ietf-oauth-v2-13 Thread-Index: AcvOCq/aILIy7ivDQD2kt2di3gdy5w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F4E@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_90C41DD21FB7C64BB94121FBBC2E723445A91D3F4EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Working group last call request for: draft-ietf-oauth-v2-13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:58:42 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F4EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -13 includes all feedback received (unless was noted otherwise on the= list) to date. It does not include any implementation changes since -12. G= iven the stable state of this draft and the lack of any blocking issues rai= sed for the included text, I would like to officially request the chairs to= begin a 3 weeks working group last call for everything but the missing Sec= urity Considerations section. The plan is to lock the protocol once WGLC is completed (assuming no additi= onal WGLC will be needed), and only make changes resulting from the securit= y analysis or external WG feedback as required by the IETF process. I'd like to thank everyone for their contributions. I'm really excited abou= t -13. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F4EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -13 includ= es all feedback received (unless was noted otherwise on the list) to date. = It does not include any implementation changes since -12. Given the stable = state of this draft and the lack of any blocking issues raised for the incl= uded text, I would like to officially request the chairs to begin a 3 weeks= working group last call for everything but the missing Security Considerat= ions section.

 

The plan is to lock the protocol once WGLC is completed (as= suming no additional WGLC will be needed), and only make changes resulting = from the security analysis or external WG feedback as required by the IETF = process.

 

I’d like to thank everyone for their contributions. I= 217;m really excited about -13.

&nb= sp;

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F4EP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Feb 16 10:58:57 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9691C3A6ECD for ; Wed, 16 Feb 2011 10:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7YAuMMrUXUH for ; Wed, 16 Feb 2011 10:58:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B5F443A6EA1 for ; Wed, 16 Feb 2011 10:58:56 -0800 (PST) Received: (qmail 5647 invoked from network); 16 Feb 2011 18:59:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 18:59:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Feb 2011 11:59:14 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 16 Feb 2011 11:59:07 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvOC46hWkEDrGysSs+st/168E64cwAAAXWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:58:57 -0000 Yes. > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, February 16, 2011 10:58 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav > wrote: > > > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Wednesday, February 16, 2011 9:05 AM > > > >> Yes, I understand. But Native Apps have no appropriate flow now, and > >> they started the whole protocol. > > > > I am not sure "they started the whole protocol" (it was more like OpenI= D in > Twitter API), but either way, why can't they use the implicit grant type? > That's where the specification is guiding them towards. >=20 > That would be the old User-Agent flow? >=20 > That's terrible for native apps, native apps need long lived credentials. >=20 > Marius From Internet-Drafts@ietf.org Wed Feb 16 11:00:03 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06743A6E74; Wed, 16 Feb 2011 11:00:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNPnJnmujpt4; Wed, 16 Feb 2011 11:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95E83A6CB0; Wed, 16 Feb 2011 11:00:01 -0800 (PST) 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.12 Message-ID: <20110216190001.21140.55325.idtracker@localhost> Date: Wed, 16 Feb 2011 11:00:01 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19: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 : The OAuth 2.0 Authorization Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-13.txt Pages : 43 Date : 2011-02-16 This specification describes the OAuth 2.0 authorization protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16105115.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Wed Feb 16 11:02:28 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CF43A6E25 for ; Wed, 16 Feb 2011 11:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnED6Ygb9Nl8 for ; Wed, 16 Feb 2011 11:02:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 860D93A6D33 for ; Wed, 16 Feb 2011 11:02:27 -0800 (PST) Received: (qmail 12063 invoked from network); 16 Feb 2011 19:02:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 19:02:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 12:02:51 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 16 Feb 2011 12:02:45 -0700 Thread-Topic: -13 4.3.2: internationalization consideration for username and password Thread-Index: AcvOC/iQzATQaPWxSbeso9r0AiPmCQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F54@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_90C41DD21FB7C64BB94121FBBC2E723445A91D3F54P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] -13 4.3.2: internationalization consideration for username and password X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:02:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F54P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unless someone provides a proposed text to address internationalization con= sideration for username and password, I am going to remove this note unaddr= essed. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F54P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unless someone p= rovides a proposed text to address internationalization consideration for u= sername and password, I am going to remove this note unaddressed.

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D3F54P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Wed Feb 16 11:07:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6328E3A6EFC for ; Wed, 16 Feb 2011 11:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.486 X-Spam-Level: X-Spam-Status: No, score=-17.486 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRBrneyh94LR for ; Wed, 16 Feb 2011 11:07:01 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 7CAD23A6D5F for ; Wed, 16 Feb 2011 11:06:59 -0800 (PST) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p1GJ6tWH086065; Wed, 16 Feb 2011 11:06:55 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Wed, 16 Feb 2011 11:06:55 -0800 From: William Mills To: Marius Scurtescu , Eran Hammer-Lahav Date: Wed, 16 Feb 2011 11:06:54 -0800 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvOC6CVwcFP1oXoSbyKJUqhKt9gUgAAOCEA Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:07:02 -0000 Token endpoint with username/password credential doesn't solve this? Depen= ds on the auth scheme of course, but Bearer should provide a solution? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Wednesday, February 16, 2011 10:58 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav > wrote: > > > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Wednesday, February 16, 2011 9:05 AM > > > >> Yes, I understand. But Native Apps have no appropriate flow now, and > they > >> started the whole protocol. > > > > I am not sure "they started the whole protocol" (it was more like > OpenID in Twitter API), but either way, why can't they use the implicit > grant type? That's where the specification is guiding them towards. >=20 > That would be the old User-Agent flow? >=20 > That's terrible for native apps, native apps need long lived > credentials. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Feb 16 11:14:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF453A6D2A for ; Wed, 16 Feb 2011 11:14:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7lOAJqxIfBh for ; Wed, 16 Feb 2011 11:14:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2432D3A6AAE for ; Wed, 16 Feb 2011 11:14:02 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p1GJEUPb003538 for ; Wed, 16 Feb 2011 11:14:31 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297883671; bh=spl2E52iPCor5bVk4efLHyHGOIY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Atweza4Xd0bCSP/Sgc6WJGDGPzik7x4aRWC8K44r9EQ7mqtz8u+6Nmjz+WTRqWI9/ bjUnSZMgyTMJjoka58fGQ== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by kpbe17.cbf.corp.google.com with ESMTP id p1GJEODf007534 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Feb 2011 11:14:29 -0800 Received: by gyd12 with SMTP id 12so813371gyd.3 for ; Wed, 16 Feb 2011 11:14:28 -0800 (PST) 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=1uT0k9dqn/sE0BIgrQpPS1xhFApvUwWs9UuH3s/RLzs=; b=ZLyzoZb2fOFaul4LduIVXaPXNC2CxjsQDzdJR2l55bfnePTjrB80RTtnPc75ZPUoeS v615/8i45mZZiqromcog== 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=LjUWJ40TOVu2syXfSwoCSCwyecjXWbddeC21jn9pv7tG+UP4v1wfaAABXY8obczVd6 gNUJCH7aVTd0sy1PazrA== Received: by 10.100.33.16 with SMTP id g16mr424304ang.96.1297883668810; Wed, 16 Feb 2011 11:14:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Wed, 16 Feb 2011 11:14:08 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 16 Feb 2011 11:14:08 -0800 Message-ID: To: William Mills 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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:14:04 -0000 On Wed, Feb 16, 2011 at 11:06 AM, William Mills wrot= e: > Token endpoint with username/password credential doesn't solve this? =A0D= epends on the auth scheme of course, but Bearer should provide a solution? Not at all, in most case native apps must use the browser based 3-legged da= nce. Marius From bcampbell@pingidentity.com Wed Feb 16 12:07:29 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0AB3A6CFF for ; Wed, 16 Feb 2011 12:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j40Smife388K for ; Wed, 16 Feb 2011 12:07:28 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with ESMTP id 10B6C3A6C32 for ; Wed, 16 Feb 2011 12:07:27 -0800 (PST) Received: from source ([209.85.161.41]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTVwumk6tqURnZYEYXWnSqDLPrO8usczR@postini.com; Wed, 16 Feb 2011 12:07:57 PST Received: by mail-fx0-f41.google.com with SMTP id 12so1844564fxm.0 for ; Wed, 16 Feb 2011 12:07:54 -0800 (PST) Received: by 10.223.123.142 with SMTP id p14mr1260610far.56.1297886874447; Wed, 16 Feb 2011 12:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Wed, 16 Feb 2011 12:07:24 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Wed, 16 Feb 2011 13:07:24 -0700 Message-ID: To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:07:29 -0000 Exactly Marius, and in most cases the app will want to procure a refresh token as a result of the dance so it won't have to put the user though the authorization process again and again. Unless I'm mistaken, the implicit grant provides no means of obtaining a refresh token (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2). So unless the access tokens themselves are extremely long lived, the implicit grant flow doesn't seem very useful to native clients. I've heard a number of people suggest the native client -> implicit grant thing but it doesn't make sense to me. Is there something I'm not seeing? On Wed, Feb 16, 2011 at 12:14 PM, Marius Scurtescu wrote: > On Wed, Feb 16, 2011 at 11:06 AM, William Mills wr= ote: >> Token endpoint with username/password credential doesn't solve this? =A0= Depends on the auth scheme of course, but Bearer should provide a solution? > > Not at all, in most case native apps must use the browser based 3-legged = dance. > > Marius From jricher@mitre.org Wed Feb 16 12:20:08 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6601F3A6CE3 for ; Wed, 16 Feb 2011 12:20:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuxD2aMDBIfs for ; Wed, 16 Feb 2011 12:20:06 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 0B83A3A6C32 for ; Wed, 16 Feb 2011 12:20:05 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6B97A21B06C3 for ; Wed, 16 Feb 2011 15:20:34 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 66B3421B0047 for ; Wed, 16 Feb 2011 15:20:34 -0500 (EST) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Feb 2011 15:20:33 -0500 Message-ID: <4D5C3192.5020508@mitre.org> Date: Wed, 16 Feb 2011 15:20:34 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:20:08 -0000 The implicit grant still requires a redirect of some kind, so many native apps can just as easily use the web server flow as the implicit flow. I personally don't see how the implicit flow is better suited than the web flow in this case. However, neither of these are ideally suited for native apps without a few tricks, which is the native apps extension that Marius is working on, to get the token back to the native app. From what I can see, the real question here is dealing with cases where a redirect doesn't actually make any sense. In those cases, I'd rather see a separate flow profiled end to end than to have hacks like the "uri:oob" put in place to patch it into an existing spot. -- Justin On 2/16/2011 3:07 PM, Brian Campbell wrote: > Exactly Marius, and in most cases the app will want to procure a > refresh token as a result of the dance so it won't have to put the > user though the authorization process again and again. Unless I'm > mistaken, the implicit grant provides no means of obtaining a refresh > token (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2). > So unless the access tokens themselves are extremely long lived, the > implicit grant flow doesn't seem very useful to native clients. > > I've heard a number of people suggest the native client -> implicit > grant thing but it doesn't make sense to me. Is there something I'm > not seeing? > > On Wed, Feb 16, 2011 at 12:14 PM, Marius Scurtescu > wrote: >> On Wed, Feb 16, 2011 at 11:06 AM, William Mills wrote: >>> Token endpoint with username/password credential doesn't solve this? Depends on the auth scheme of course, but Bearer should provide a solution? >> Not at all, in most case native apps must use the browser based 3-legged dance. >> >> Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Feb 16 12:28:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520C63A6CE3 for ; Wed, 16 Feb 2011 12:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRoRZ0LQ6Xk7 for ; Wed, 16 Feb 2011 12:28:24 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E51E23A6D4B for ; Wed, 16 Feb 2011 12:28:23 -0800 (PST) Received: (qmail 24026 invoked from network); 16 Feb 2011 20:28:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 20:28:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Feb 2011 13:28:49 -0700 From: Eran Hammer-Lahav To: Brian Campbell , Marius Scurtescu Date: Wed, 16 Feb 2011 13:28:43 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvOFTcgCEWEpfn+RpOd/8m9YaPR6QAAq4ZQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:28:25 -0000 The reason why we don't return a refresh token in the implicit grant is exa= ctly because there is no client authentication... These are all well-balanc= ed flows with specific security properties. If you need something else, eve= n if it is just a tweak, it must be considered a different flow. That doesn= 't mean you need to register a new grant type, just that you are dealing wi= th different implementation details unique to your server. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Wednesday, February 16, 2011 12:07 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > Exactly Marius, and in most cases the app will want to procure a refresh > token as a result of the dance so it won't have to put the user though th= e > authorization process again and again. Unless I'm mistaken, the implicit= grant > provides no means of obtaining a refresh token > (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2). > So unless the access tokens themselves are extremely long lived, the imp= licit > grant flow doesn't seem very useful to native clients. >=20 > I've heard a number of people suggest the native client -> implicit grant= thing > but it doesn't make sense to me. Is there something I'm not seeing? >=20 > On Wed, Feb 16, 2011 at 12:14 PM, Marius Scurtescu > wrote: > > On Wed, Feb 16, 2011 at 11:06 AM, William Mills > wrote: > >> Token endpoint with username/password credential doesn't solve > this? =A0Depends on the auth scheme of course, but Bearer should provide = a > solution? > > > > Not at all, in most case native apps must use the browser based 3-legge= d > dance. > > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Feb 16 13:38:40 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EA43A6EE0 for ; Wed, 16 Feb 2011 13:38:40 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m42BMMYb1yQ for ; Wed, 16 Feb 2011 13:38:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7BCE43A6DDF for ; Wed, 16 Feb 2011 13:38:39 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p1GLd80k025567 for ; Wed, 16 Feb 2011 13:39:08 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297892348; bh=A0noJ/rLsV9ZYJrrZA30cUvsyJE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=cgKiADrZmFtFcJIw8kXrV9NeYQQhm8u8JcZAFNzBHjeDGKr/ZIRFsvH6vGk5BLWX7 pvmwNvlhOBfVkl6DpFvhQ== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by kpbe20.cbf.corp.google.com with ESMTP id p1GLc679024988 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Feb 2011 13:39:07 -0800 Received: by yib12 with SMTP id 12so934364yib.24 for ; Wed, 16 Feb 2011 13:39:06 -0800 (PST) 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=UEsM6BP4SOFpBDIUPBx4FbuzAbndf1vLjBWbNnhqmtI=; b=xBLdakSxrIcemwbNIxa01OiPFBVfUF8jMvwOPmZGlfPdtWouqIzAeqEktn0UmlPUGO TuPrTU/6Y1umImVW6Z8g== 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=j1LE6/HpEg5XXIgpACSQgc8xjNeczZKcwWcqkQB/cKrcCYWgNlB9phr01een5UwJPL zntftI3W2xKJjgbfbLYA== Received: by 10.101.8.27 with SMTP id l27mr485449ani.130.1297892346697; Wed, 16 Feb 2011 13:39:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Wed, 16 Feb 2011 13:38:45 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 16 Feb 2011 13:38:45 -0800 Message-ID: To: Eran Hammer-Lahav 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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 21:38:40 -0000 On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav w= rote: > The reason why we don't return a refresh token in the implicit grant is e= xactly because there is no client authentication... Not sure that's the main reason. AFAIK it is because the response is sent through the user-agent and it could leak. > These are all well-balanced flows with specific security properties. If y= ou need something else, even if it is just a tweak, it must be considered a= different flow. That doesn't mean you need to register a new grant type, j= ust that you are dealing with different implementation details unique to yo= ur server. The Authorization Code flow, with no client secret, is perfectly fine for Native Apps IMO. Marius From eran@hueniverse.com Wed Feb 16 13:57:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4707F3A6DE1 for ; Wed, 16 Feb 2011 13:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ5HtIVGZKu6 for ; Wed, 16 Feb 2011 13:57:21 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 774363A6EB2 for ; Wed, 16 Feb 2011 13:57:21 -0800 (PST) Received: (qmail 13692 invoked from network); 16 Feb 2011 21:57:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Feb 2011 21:57:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Feb 2011 14:57:43 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 16 Feb 2011 14:57:35 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvOIfJAGmn/yIwbT66vW0bOFYoGQQAAmnbQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D3FE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@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] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 21:57:22 -0000 Feel free to propose alternative preamble for the implicit and authorizatio= n code sections, describing the characteristics of what they are good for. = It should fit in a single paragraph. Such a proposal would fit right in wit= h last call feedback to -13. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, February 16, 2011 1:39 PM > To: Eran Hammer-Lahav > Cc: Brian Campbell; OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > wrote: > > The reason why we don't return a refresh token in the implicit grant is > exactly because there is no client authentication... >=20 > Not sure that's the main reason. AFAIK it is because the response is sent > through the user-agent and it could leak. >=20 >=20 > > These are all well-balanced flows with specific security properties. If= you > need something else, even if it is just a tweak, it must be considered a > different flow. That doesn't mean you need to register a new grant type, = just > that you are dealing with different implementation details unique to your > server. >=20 > The Authorization Code flow, with no client secret, is perfectly fine for= Native > Apps IMO. >=20 > Marius From stpeter@stpeter.im Wed Feb 16 15:06:49 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0AC43A6D92 for ; Wed, 16 Feb 2011 15:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NveIBFDJsV8d for ; Wed, 16 Feb 2011 15:06:48 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B62D03A6AD5 for ; Wed, 16 Feb 2011 15:06:48 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 68741400F6 for ; Wed, 16 Feb 2011 16:25:26 -0700 (MST) Message-ID: <4D5C58A1.2010908@stpeter.im> Date: Wed, 16 Feb 2011 16:07:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090309080307050305050701" Subject: [OAUTH-WG] Fwd: I-D Action:draft-mills-kitten-sasl-oauth-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 23:06:50 -0000 This is a cryptographically signed message in MIME format. --------------ms090309080307050305050701 Content-Type: multipart/mixed; boundary="------------020900000501070209040900" This is a multi-part message in MIME format. --------------020900000501070209040900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just saw this come across the wire... -------- Original Message -------- Subject: I-D Action:draft-mills-kitten-sasl-oauth-01.txt Date: Wed, 16 Feb 2011 14:45:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A SASL Mechanism for OAuth Author(s) : W. Mills, et al. Filename : draft-mills-kitten-sasl-oauth-01.txt Pages : 19 Date : 2011-02-16 Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection- oriented protocols via replaceable mechanisms. OAuth is a protocol framework for delegated HTTP authentication and thereby provides a method for clients to access a protected resource on behalf of a resource owner. This document defines the use of HTTP authentication over SASL, and additionally defines authoriation and token issuing endpoint discovery. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. A future version of this document will describe the integration into the Generic Security Services Application Program Interface (GSS-APIO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-01.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. --------------020900000501070209040900 Content-Type: Message/External-body; name="draft-mills-kitten-sasl-oauth-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mills-kitten-sasl-oauth-01.txt" Content-Type: text/plain Content-ID: <2011-02-16144358.I-D@ietf.org> --------------020900000501070209040900 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------020900000501070209040900-- --------------ms090309080307050305050701 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx NjIzMDcxM1owIwYJKoZIhvcNAQkEMRYEFNkB717PS6uijcLxNj7KYGUL8bFvMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBkYIwu6RAHpxg/P5u6ix0U8YEYqYRSolgRQBh9l0lz+JthKmOYCKpyTPPi eJnZVoFd04cDs/Oj1BC5fnlkk4Qq6snjceeGnALNqHyzLa7TvUFJJ7NDpKlT4C6CEVv2fgbm yTCUXrugwL8bGy4Jor7wk/KqWz/KWKqhk4a6ud+Zs06cltGPg4t6f14EaTytErxlKknwZDP4 ohAi77KdjOSelLxsAzvUsMDoPtvANBYbDHFBllklfjCNQqst21rpXZ67YQMOBaDz1UQ5w4lX HCOROyIIBF+mUHcil2kk70n4FKsqA/zwvvF17m9C6P8YSyiBWbSTj3VqjLFXplGqmyvkAAAA AAAA --------------ms090309080307050305050701-- From wmills@yahoo-inc.com Wed Feb 16 16:28:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30E73A6C3E for ; Wed, 16 Feb 2011 16:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHlh7jB4vamg for ; Wed, 16 Feb 2011 16:28:11 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 7CDDF3A6C31 for ; Wed, 16 Feb 2011 16:28:11 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p1H0SaRn086549; Wed, 16 Feb 2011 16:28:36 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Wed, 16 Feb 2011 16:28:36 -0800 From: William Mills To: Peter Saint-Andre , OAuth WG Date: Wed, 16 Feb 2011 16:28:34 -0800 Thread-Topic: [OAUTH-WG] Fwd: I-D Action:draft-mills-kitten-sasl-oauth-01.txt Thread-Index: AcvOLlZkcEDrkqRyS52T0NzNNR+y5AACwr1A Message-ID: References: <4D5C58A1.2010908@stpeter.im> In-Reply-To: <4D5C58A1.2010908@stpeter.im> 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 Subject: Re: [OAUTH-WG] Fwd: I-D Action:draft-mills-kitten-sasl-oauth-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:28:13 -0000 SSdtIGhhcHB5IChlY3N0YXRpYywgaG9wZWZ1bCwgeWVhcm5pbmcpIHRvIHRha2UgY29tbWVudHMs IGFsdGhvdWdoIEkgZ3Vlc3MgdGhlIGV0aXF1ZXR0ZSBpcyB0aGF0IGl0IHNob3VsZCBoYXBwZW4g b24gdGhlIEtpdHRlbiBXRyBtYWlsaW5nIGxpc3Q/ICAgDQoNCi1iaWxsDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBQZXRlciBTYWludC1BbmRy ZQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE2LCAyMDExIDM6MDcgUE0NCj4gVG86IE9B dXRoIFdHDQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gRndkOiBJLUQgQWN0aW9uOmRyYWZ0LW1pbGxz LWtpdHRlbi1zYXNsLW9hdXRoLQ0KPiAwMS50eHQNCj4gDQo+IEp1c3Qgc2F3IHRoaXMgY29tZSBh Y3Jvc3MgdGhlIHdpcmUuLi4NCj4gDQo+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0t LS0NCj4gU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC1taWxscy1raXR0ZW4tc2FzbC1vYXV0aC0w MS50eHQNCj4gRGF0ZTogV2VkLCAxNiBGZWIgMjAxMSAxNDo0NTowMSAtMDgwMA0KPiBGcm9tOiBJ bnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcNCj4gUmVwbHktVG86IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZw0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGly ZWN0b3JpZXMuDQo+IA0KPiAJVGl0bGUgICAgICAgICAgIDogQSBTQVNMIE1lY2hhbmlzbSBmb3Ig T0F1dGgNCj4gCUF1dGhvcihzKSAgICAgICA6IFcuIE1pbGxzLCBldCBhbC4NCj4gCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LW1pbGxzLWtpdHRlbi1zYXNsLW9hdXRoLTAxLnR4dA0KPiAJUGFnZXMg ICAgICAgICAgIDogMTkNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTEtMDItMTYNCj4gDQo+IFNp bXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNBU0wpIGlzIGEgZnJhbWV3 b3JrIGZvcg0KPiBwcm92aWRpbmcgYXV0aGVudGljYXRpb24gYW5kIGRhdGEgc2VjdXJpdHkgc2Vy dmljZXMgaW4gY29ubmVjdGlvbi0NCj4gb3JpZW50ZWQgcHJvdG9jb2xzIHZpYSByZXBsYWNlYWJs ZSBtZWNoYW5pc21zLiAgT0F1dGggaXMgYSBwcm90b2NvbA0KPiBmcmFtZXdvcmsgZm9yIGRlbGVn YXRlZCBIVFRQIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGVyZWJ5IHByb3ZpZGVzIGENCj4gbWV0aG9k IGZvciBjbGllbnRzIHRvIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZSBvbiBiZWhhbGYgb2Yg YQ0KPiByZXNvdXJjZSBvd25lci4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgdXNl IG9mIEhUVFAgYXV0aGVudGljYXRpb24gb3ZlciBTQVNMLCBhbmQNCj4gYWRkaXRpb25hbGx5IGRl ZmluZXMgYXV0aG9yaWF0aW9uIGFuZCB0b2tlbiBpc3N1aW5nIGVuZHBvaW50IGRpc2NvdmVyeS4N Cj4gVGhlcmVieSwgaXQgZW5hYmxlcyBzY2hlbWVzIGRlZmluZWQgd2l0aGluIHRoZSBPQXV0aCBm cmFtZXdvcmsgZm9yIG5vbi0NCj4gSFRUUC1iYXNlZCBhcHBsaWNhdGlvbiBwcm90b2NvbHMuICBB IGZ1dHVyZSB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQNCj4gd2lsbCBkZXNjcmliZSB0aGUgaW50 ZWdyYXRpb24gaW50byB0aGUgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlcw0KPiBBcHBsaWNhdGlv biBQcm9ncmFtIEludGVyZmFjZSAoR1NTLUFQSU8pLg0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50 ZXJuZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LW1pbGxzLWtpdHRlbi1zYXNsLW9hdXRoLQ0KPiAwMS50eHQNCj4gDQo+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNo IHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXINCj4gaW1wbGVtZW50YXRp b24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4g SW50ZXJuZXQtRHJhZnQuDQoNCg== From stpeter@stpeter.im Wed Feb 16 16:49:33 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0F13A6C3E for ; Wed, 16 Feb 2011 16:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vnM4WIurfoo for ; Wed, 16 Feb 2011 16:49:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B99B53A6A0C for ; Wed, 16 Feb 2011 16:49:31 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 12D56400F6; Wed, 16 Feb 2011 18:08:09 -0700 (MST) Message-ID: <4D5C70B6.40007@stpeter.im> Date: Wed, 16 Feb 2011 17:49:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: William Mills References: <4D5C58A1.2010908@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020202070107090002080003" Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: I-D Action:draft-mills-kitten-sasl-oauth-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:49:33 -0000 This is a cryptographically signed message in MIME format. --------------ms020202070107090002080003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I think the kitten list is the right place: https://www.ietf.org/mailman/listinfo/kitten But it would be good for OAuth folks to review the spec and post their comments on the kitten list (or directly to the authors). /psa On 2/16/11 5:28 PM, William Mills wrote: > I'm happy (ecstatic, hopeful, yearning) to take comments, although I > guess the etiquette is that it should happen on the Kitten WG mailing > list? >=20 > -bill >=20 >> -----Original Message----- From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On Behalf Of Peter Saint-Andre=20 >> Sent: Wednesday, February 16, 2011 3:07 PM To: OAuth WG Subject: >> [OAUTH-WG] Fwd: I-D Action:draft-mills-kitten-sasl-oauth- 01.txt >>=20 >> Just saw this come across the wire... >>=20 >> -------- Original Message -------- Subject: I-D >> Action:draft-mills-kitten-sasl-oauth-01.txt Date: Wed, 16 Feb 2011 >> 14:45:01 -0800 From: Internet-Drafts@ietf.org Reply-To: >> internet-drafts@ietf.org To: i-d-announce@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >>=20 >> Title : A SASL Mechanism for OAuth Author(s) : W. >> Mills, et al. Filename : >> draft-mills-kitten-sasl-oauth-01.txt Pages : 19 Date >> : 2011-02-16 >>=20 >> Simple Authentication and Security Layer (SASL) is a framework for=20 >> providing authentication and data security services in connection-=20 >> oriented protocols via replaceable mechanisms. OAuth is a >> protocol framework for delegated HTTP authentication and thereby >> provides a method for clients to access a protected resource on >> behalf of a resource owner. >>=20 >> This document defines the use of HTTP authentication over SASL, >> and additionally defines authoriation and token issuing endpoint >> discovery. Thereby, it enables schemes defined within the OAuth >> framework for non- HTTP-based application protocols. A future >> version of this document will describe the integration into the >> Generic Security Services Application Program Interface >> (GSS-APIO). >>=20 >> A URL for this Internet-Draft is:=20 >> http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-=20 >> 01.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at:=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. --------------ms020202070107090002080003 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx NzAwNDk1OFowIwYJKoZIhvcNAQkEMRYEFBwf5S7QwioZtYJxIaNlmx/8nXDaMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCfOy2TnVGoI91NaNB5GSWFaEcB8D3WBor4LAeuJ19z+U8Jak/SAD/ppvHp brT0qTDEOr3LuHHWPetp3/njneGm7P18Mv3cW1m58A8m/GkYvToG3GRO3W1rG1xChOtM0M3g Ti7VyCkN4xImEUn70PeLQsgZqB2ksMZ+XtBYmASmBaGDYvkJzeKoNMy54s7IHdyWX+hbPsJ+ H24+fcL84MzBQMyingi5xXzVP3ptZYQCZ+EXvfE8r0cMoWvAWd8m3zR2NNd0OKtWkc6Ck/vL UfZFjuS+Biai/6Iex8Ce7V/Xuo3Zqg/BTo25U/ACkzm/Gl2zz99jG0TqZ8AWeg0XzIc+AAAA AAAA --------------ms020202070107090002080003-- From breno.demedeiros@gmail.com Thu Feb 17 10:29:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E20A3A6E1F for ; Thu, 17 Feb 2011 10:29:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ueo8z5uRiV42 for ; Thu, 17 Feb 2011 10:29:11 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 516C63A6D9D for ; Thu, 17 Feb 2011 10:29:11 -0800 (PST) Received: by iwc10 with SMTP id 10so2960048iwc.31 for ; Thu, 17 Feb 2011 10:29:42 -0800 (PST) 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=/pBERJcp39HdAS4wvdKipJzrqtXuglDQYEEYJSamDBg=; b=QYDCWGBFTQJuLKG6/NBFG6Ori3CAF4/AMPhkmeAR2CM5meocDD4hLFwmfyWTf2K+Qy 2p3CSLL5G09kQkqeGgC9ccpRptboESlbn+7qskY3SBCs8dTon05IchWoRQeNCkO6V6Ym WQCFxFZ5eRidAva2puI6+q0M6eL404uZGYiWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JUpuzW/t8QSbG6/3M6k5oEbbWsXMOUr9tjZYVvaHYmTagiSzrB02XwsANW/L+lrmsJ CH0/kkQ8fylHCtRYCkLHvEJ2gIIUpsg9dKVQubHBb4/pNmH3JZ56GFQ9dAMRBxfwB371 OSXs4/qT+Oj6lC10vbdbJvHGyaFDdNhtGRMY0= MIME-Version: 1.0 Received: by 10.231.40.12 with SMTP id i12mr1882159ibe.183.1297967382155; Thu, 17 Feb 2011 10:29:42 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 10:29:42 -0800 (PST) Date: Thu, 17 Feb 2011 10:29:42 -0800 Message-ID: From: Breno To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00248c711397be5490049c7e9441 Subject: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:29:14 -0000 --00248c711397be5490049c7e9441 Content-Type: text/plain; charset=ISO-8859-1 - Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. -- Breno de Medeiros --00248c711397be5490049c7e9441 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable - Problem 1: Several WG participan= ts are working on deploying a federated signon protocol based on OAuth2 (ak= a OpenIDConnect) and would like to return an additional 'session cookie= ' together with the auth_token. Or sometimes return only a cookie as th= e result of authorization, since cookies will likely have shorter lifetimes= than access tokens, for security and usability reasons, and require more f= requent refresh requirements. In any case, there aremultiple reasons for making the cookie separat= e from the auth_token, including both security and flexibility of deploymen= t. However, there is no way to express this except adding an arbitrary exte= nsion parameter (to effectively express a different response type).<= div>

- Problem 2: Codification of code= _and_token created controversy as there was not enough traction among parti= cipants to put it in the core. However, it is entirely possible that deploy= ment experience will lead players to revisit this topic.


- Proposed solution:

1. Allow response_type to be a space separated list of arbitrary strings

E.g.:

response_type=3Dcode=
response_type=3Dtoken
response_type=3Dcode+token
r= esponse_type=3Dcookie
response_type=3Dcode+cookie
respo= nse_type=3Dtoken+cookie
response_type=3Dfoo+bar

Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values.


2. Defi= ne behaviors in the core only for values 'code' and 'token'= . Allow extensions to define what do with 'code+token' or with any = other values or combinations of values.=A0

--
Breno de Medeiros

--00248c711397be5490049c7e9441-- From stpeter@stpeter.im Thu Feb 17 13:19:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DDF3A6CC3 for ; Thu, 17 Feb 2011 13:19:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pca1fLQZjB1P for ; Thu, 17 Feb 2011 13:19:01 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 58A5B3A6C32 for ; Thu, 17 Feb 2011 13:19:01 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29EB9400F6 for ; Thu, 17 Feb 2011 14:37:46 -0700 (MST) Message-ID: <4D5D90E3.7080405@stpeter.im> Date: Thu, 17 Feb 2011 14:19:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: oauth@ietf.org References: <4D4A88D0.9050409@gmx.net> In-Reply-To: <4D4A88D0.9050409@gmx.net> 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="------------ms060100090408080604040307" Subject: Re: [OAUTH-WG] JSON Cryptographic Syntax and Processing: BOF Status and Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 21:19:02 -0000 This is a cryptographically signed message in MIME format. --------------ms060100090408080604040307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, a dedicated list has been established for discussion about requirements and potential implementation of JSON to provide security services for Web-based applications. You can subscribe here: https://www.ietf.org/mailman/listinfo/woes On 2/3/11 3:52 AM, Hannes Tschofenig wrote: > Hi all, >=20 > as mentioned earlier I have requested a BOF about the JSON signature > topic and the IESG discussed the various BOF proposals this Tuesday. >=20 > FYI, here are all the BOF proposals: > http://trac.tools.ietf.org/bof/trac/ >=20 > The BOF was not approved because the IESG felt we need more time for > preparation. That's not a problem. >=20 > We will discuss the topic in the OAuth working group meeting, and the > security area director, Sean Turner, will create a separate mailing lis= t > to involve a larger audience. >=20 > So, you might ask yourself what is the big issue here. Well. In some > sense, the main question that seems to be there is why aren't we using > CMS to protect JSON payloads (instead of developing our own signature > mechanisms). I believe that this is a fair question to ask why existing= > and deployed functionality hasn't been used. >=20 > To some extend this question relates to the overall question of what > cryptographic functionality is available with browsers, what are the > usage scenarios (e.g. does JavaScript need to be used to compute a > signature over the JSON token, what functionality can reside in a > browser, etc.). >=20 > These types of topics will be raised and we should discuss them on the > mailing list, once it is created (which should happen today according t= o > Sean). >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------ms060100090408080604040307 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx NzIxMTkzMVowIwYJKoZIhvcNAQkEMRYEFOymo+zloM9JXK8AuyfITYNwbsq8MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCcD7hn/3AU0aPNKtdtMkO2QrF1M17hFv8YjafMgPxrFhAUER3Z3tdP19gd 9NDuGdDHKk2QK4rhdqwr9CmEIRSw/fmzZlGXz0IJqTDG29ylxXijsJ0BmSKI4rkDSF39t6Mi Je9GR5zQzfiLlJrXwaPmBrk76Q3yt1IRytsThdbWIvcuQ5giJ1V9f+mLTqGTr3cw7DIXHIjy l1f9b82lHEFDoLIhJkk4p4jc7Ut7QYD7hsIe6ibFixRCHSkvPWkgofXD5GEHxiebZ4ATJhl0 M61KEcClnTpXWjblQj4Kfo9NRmPPM7/RvlVB310RV223uUbtYANQr+OQJ0LPjZ+bp3aXAAAA AAAA --------------ms060100090408080604040307-- From eran@hueniverse.com Thu Feb 17 13:51:50 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A473A6DB1 for ; Thu, 17 Feb 2011 13:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98jcRKqrnjsb for ; Thu, 17 Feb 2011 13:51:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7F11A3A6CDD for ; Thu, 17 Feb 2011 13:51:49 -0800 (PST) Received: (qmail 6743 invoked from network); 17 Feb 2011 21:52:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Feb 2011 21:52:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Feb 2011 14:51:59 -0700 From: Eran Hammer-Lahav To: Breno , "oauth@ietf.org" Date: Thu, 17 Feb 2011 14:51:50 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvO0KtBYqy8hZ80R7+YSRrfunKa/wAG2xjw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@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_90C41DD21FB7C64BB94121FBBC2E723445A91D4242P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 21:51:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4242P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= reno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4242P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The best = approach (at this point) is to leave the spec unchanged. However, another s= pec can update the definition of the response_type parameter, including def= ining a registry or other methods for extensibility.

<= p class=3DMsoNormal> 

We can define this now, and it will not have any impact on existing= code, but I am leery of adding yet another extensibility vector without su= fficient requirement. I also think that adding extension parameters can han= dle this cleanly.

&nb= sp;

EHL

 

=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 = 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom= of assembly for response_type

 

-= Problem 1: Several WG participants are working on deploying a federated si= gnon protocol based on OAuth2 (aka OpenIDConnect) and would like to return = an additional 'session cookie' together with the auth_token. Or sometimes r= eturn only a cookie as the result of authorization, since cookies will like= ly have shorter lifetimes than access tokens, for security and usability re= asons, and require more frequent refresh requirements. In any case, there a= remultiple reasons for making the cookie separate from the auth_token, incl= uding both security and flexibility of deployment. However, there is no way= to express this except adding an arbitrary extension parameter (to effecti= vely express a different response type).

<= div>

 

- Problem 2: Codification of code_and_token create= d controversy as there was not enough traction among participants to put it= in the core. However, it is entirely possible that deployment experience w= ill lead players to revisit this topic.

 

 <= /o:p>

- Proposed solution:

 

1. Allow response_type to be a space separated list of arbitrary strin= gs

 

=

E.g.:

 

response_type=3Dcode<= /o:p>

response_type=3Dtoken

response_type=3Dcode+token<= /p>

response_type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar

 

Would all be synta= ctically valid responses from the perspective of OAuth2.0 Core response_typ= e values.

 

 

2. Define behaviors in the core only for values 'code' and 'token'. = Allow extensions to define what do with 'code+token' or with any other valu= es or combinations of values. 


--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4242P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 13:57:35 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2523A6CC6 for ; Thu, 17 Feb 2011 13:57:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoeRFEDRhPl4 for ; Thu, 17 Feb 2011 13:57:34 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E758A3A6A9D for ; Thu, 17 Feb 2011 13:57:33 -0800 (PST) Received: by iwc10 with SMTP id 10so3168501iwc.31 for ; Thu, 17 Feb 2011 13:58:05 -0800 (PST) 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=iq2EhKqYZxyWGCa08UxNyZasG6kQU/Yrnv3HLNMyw50=; b=Rx6UprB9aTrMoHz9zXD9gYH+Oxy3HDZO9qFRW6jT/1tc56rho2gSlxgJ+v3bn2T5Em nnpNLdX6xG00rKb+Dnnx6Ne8e06JXjWG8wIlaCgelKlINg6s+95QaPElycn65eHtd4Ry L7GoFbirRhJNj89Ubqcr1IKdc4a78y4xb1oGU= 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=Q4D1EJnfoZbvbBOq980y2URhcfkj08nMAguLxXr3qjnNprNP9hWmfBzfqXETTiw/Of 0lvh3mYfLEtcFia62ALGT+FMTwCdi0Qr5yNsTRb/jpWwaDr+794hUS/1EcIz9Hlya6yh QopbQkuwqKa61S+vh4REQVJBn528TtbG4Xh4I= MIME-Version: 1.0 Received: by 10.42.179.2 with SMTP id bo2mr3570328icb.360.1297979885703; Thu, 17 Feb 2011 13:58:05 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 13:58:05 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 13:58:05 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba6e8d78035321049c817ee6 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 21:57:35 -0000 --90e6ba6e8d78035321049c817ee6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav wrote: > The best approach (at this point) is to leave the spec unchanged. However, > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without sufficient > requirement. I also think that adding extension parameters can handle this > cleanly. > The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usability > reasons, and require more frequent refresh requirements. In any case, there > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However, > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=code > > response_type=token > > response_type=code+token > > response_type=cookie > > response_type=code+cookie > > response_type=token+cookie > > response_type=foo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2.0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values or > combinations of values. > > > -- > Breno de Medeiros > -- Breno de Medeiros --90e6ba6e8d78035321049c817ee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 1:51 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

The best approach (at th= is point) is to leave the spec unchanged. However, another spec can update = the definition of the response_type parameter, including defining a registr= y or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.


The spec, as currently written= does not imply that the only possible values are 'code' and 't= oken'. The only concern is that libraries may implement such restrictio= n and make extending this behavior different.

I do not think that extension parameters can handle thi= s cleanly. In particular, if the response_type is neither code nor token.= =A0
=A0

=A0

EHL

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG = participants are working on deploying a federated signon protocol based on = OAuth2 (aka OpenIDConnect) and would like to return an additional 'sess= ion cookie' together with the auth_token. Or sometimes return only a co= okie as the result of authorization, since cookies will likely have shorter= lifetimes than access tokens, for security and usability reasons, and requ= ire more frequent refresh requirements. In any case, there aremultiple reas= ons for making the cookie separate from the auth_token, including both secu= rity and flexibility of deployment. However, there is no way to express thi= s except adding an arbitrary extension parameter (to effectively express a = different response type).

=A0

<= span>- Problem 2: Codification of code_and= _token created controversy as there was not enough traction among participa= nts to put it in the core. However, it is entirely possible that deployment= experience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros

--90e6ba6e8d78035321049c817ee6-- From Michael.Jones@microsoft.com Thu Feb 17 14:27:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B533A6CDD for ; Thu, 17 Feb 2011 14:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8muqPmr1PmuH for ; Thu, 17 Feb 2011 14:27:54 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id CD4983A6CCC for ; Thu, 17 Feb 2011 14:27:54 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Feb 2011 14:28:26 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.173]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0270.002; Thu, 17 Feb 2011 14:28:26 -0800 From: Mike Jones To: Breno , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AQHLztCt/LhrW68QeUu7vJeWTtn9eJQGwj0AgAABv4D//4JAgA== Date: Thu, 17 Feb 2011 22:28:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394324747378@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394324747378TK5EX14MBXC201r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 22:27:56 -0000 --_000_4E1F6AAD24975D4BA5B168042967394324747378TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also support the proposed refinement of the specification. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= reno Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros --_000_4E1F6AAD24975D4BA5B168042967394324747378TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also support the propos= ed refinement of the specification.

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav &= lt;eran@hueniverse.com> wrote= :

The best approach (= at this point) is to leave the spec unchanged. However, another spec can up= date the definition of the response_type parameter, including defining a registry or other methods for extensibilit= y.

 <= /o:p>

We can define this = now, and it will not have any impact on existing code, but I am leery of ad= ding yet another extensibility vector without sufficient requirement. I also think that adding extension paramet= ers can handle this cleanly.

 

The spec, as currently written does not imply that t= he only possible values are 'code' and 'token'. The only concern is that li= braries may implement such restriction and make extending this behavior dif= ferent.

 

I do not think that extension parameters can handle = this cleanly. In particular, if the response_type is neither code nor token= . 

 

 <= /o:p>

EHL

 <= /o:p>

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Freedom of assembly for response_type

 

- Problem 1: Several WG participa= nts are working on deploying a federated signon protocol based on OAuth2 (a= ka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making th= e cookie separate from the auth_token, including both security and flexibil= ity of deployment. However, there is no way to express this except adding a= n arbitrary extension parameter (to effectively express a different response type).

 

- Problem 2: Codification of code= _and_token created controversy as there was not enough traction among parti= cipants to put it in the core. However, it is entirely possible that deployment experience will lead players to re= visit this topic.

 

 

- Proposed solution:<= /o:p>

 

1. Allow response_type to be a sp= ace separated list of arbitrary strings

 

E.g.:

 

response_type=3Dcode<= /o:p>

response_type=3Dtoken=

response_type=3Dcode+token

response_type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie<= /span>

response_type=3Dfoo+bar

 

Would all be syntactically valid = responses from the perspective of OAuth2.0 Core response_type values.

 

 

2. Define behaviors in the core o= nly for values 'code' and 'token'. Allow extensions to define what do with = 'code+token' or with any other values or combinations of values. 


--
Breno de Medeiros




--
Breno de Medeiros

--_000_4E1F6AAD24975D4BA5B168042967394324747378TK5EX14MBXC201r_-- From eran@hueniverse.com Thu Feb 17 16:12:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63C93A6F75 for ; Thu, 17 Feb 2011 16:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt+7-m87N5vF for ; Thu, 17 Feb 2011 16:12:31 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E515A3A6F72 for ; Thu, 17 Feb 2011 16:12:27 -0800 (PST) Received: (qmail 11976 invoked from network); 18 Feb 2011 00:12:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 00:12:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Feb 2011 17:12:53 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 17:12:45 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvO7cIDYTya+p63Q1i7HEt/lC6inQAEYpuA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4299P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:12:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4299P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4299P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You need = to define how this proposed extension works with the overall architecture.<= o:p>

 

This is not just an endpoint people can basta= rdize (I am not suggesting *you* are) as they see fit. It must fit w= ith the overall model which is that this endpoint returns either an access = token or an authorization grant. An authorization grant has to be exchanged= for an access token.

 

If you are going to ret= urn something else, instead or in addition to the token/code options, you n= eed to explain how it fits within the model. I am opposed to an open-ended = extension point that is not consistent (and restricted) to the model we spe= nt a year to define and refine. The token+code response type was well defin= ed (it was the use case that wasn’t).

 

To move this forward, you need to come up with specific requirements, not = just making something extensible without understanding what it is you are t= rying to extend. That’s like the OAuth 1.0 utterly broken oauth_versi= on parameter and the long confusion it created later on.<= /p>

 

EHL

 = ;

From: Breno [mai= lto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
<= b>Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:=

T= he best approach (at this point) is to leave the spec unchanged. However, a= nother spec can update the definition of the response_type parameter, inclu= ding defining a registry or other methods for extensibility.

 <= o:p>

We can = define this now, and it will not have any impact on existing code, but I am= leery of adding yet another extensibility vector without sufficient requir= ement. I also think that adding extension parameters can handle this cleanl= y.

 

The spec, as currently written does= not imply that the only possible values are 'code' and 'token'. The only c= oncern is that libraries may implement such restriction and make extending = this behavior different.

 

I do not think that extens= ion parameters can handle this cleanly. In particular, if the response_type= is neither code nor token. 

 

&n= bsp;

EHL

 

From:= oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent:= Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-W= G] Freedom of assembly for response_type

<= div>

 

- Problem 1: Several WG participants are working on deploying a federated= signon protocol based on OAuth2 (aka OpenIDConnect) and would like to retu= rn an additional 'session cookie' together with the auth_token. Or sometime= s return only a cookie as the result of authorization, since cookies will l= ikely have shorter lifetimes than access tokens, for security and usability= reasons, and require more frequent refresh requirements. In any case, ther= e aremultiple reasons for making the cookie separate from the auth_token, i= ncluding both security and flexibility of deployment. However, there is no = way to express this except adding an arbitrary extension parameter (to effe= ctively express a different response type).

=

 

- Problem 2: Codification of code_and_token created controversy as ther= e was not enough traction among participants to put it in the core. However= , it is entirely possible that deployment experience will lead players to r= evisit this topic.

 

 

- Proposed solution:

&nbs= p;

= 1. Allow response_type to be a space separated list of arbitrary strings

 = ;

E= .g.:

 

response_type=3Dcode

response_type=3Dtoken

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>response_type=3Dtoken+cookie<= o:p>

response_t= ype=3Dfoo+bar

 

Would all be syntactically valid responses from the perspect= ive of OAuth2.0 Core response_type values.

=

 

<= div>

 

2. Define behaviors in the = core only for values 'code' and 'token'. Allow extensions to define what do= with 'code+token' or with any other values or combinations of values. = ;


--
Breno de Medeiros




--
Breno de= Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4299P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 16:21:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D9A3A6D85 for ; Thu, 17 Feb 2011 16:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2h2lJyMf2ND for ; Thu, 17 Feb 2011 16:21:29 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D5FD83A6C72 for ; Thu, 17 Feb 2011 16:21:28 -0800 (PST) Received: by iwc10 with SMTP id 10so3288391iwc.31 for ; Thu, 17 Feb 2011 16:22:01 -0800 (PST) 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=gZd1t3m9UeLVHQImhpzUG9azJYdSelxwg0lcZqZRXek=; b=cKAXAjJ/Y6w6iHLcivv6DKbnhEGJ7UukwKqfVd0oj9Iy5nH+OenallCh/eK5kFbM6W 5ElVBoZaDVFNxITuhISRQIvdDOZJ5g3hnxE+4CMwAVUUOEWiYqPPsE9aHOBp/KBlpVxE ceDAjVCerTXkjiMxTc2Q0wE3/Ga50/t6KuUcI= 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=wM0nPWtcghP2I0kaJpr4rYN3k5iYQmHAXKFbivMvyWsT2oSKJbhI2x0i3yj5AXyxbD Bi6BXyIF1dSg5v1c0fLJG6YOGkENqVB1Ar9l76OJhGOTSZJqyvMjxoIsdTrmlyRmkpBg kZ1ITu1BskROTzggv9z+d+O0+BPv+S+8RSuzk= MIME-Version: 1.0 Received: by 10.231.16.137 with SMTP id o9mr40748iba.158.1297988520928; Thu, 17 Feb 2011 16:22:00 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 16:22:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 16:22:00 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00221532c6f0b6648b049c8380db Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:21:30 -0000 --00221532c6f0b6648b049c8380db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management o= f security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav wro= te: > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --00221532c6f0b6648b049c8380db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The use case is very straightforward:

- SAML provides se= ssion management. Facebook Connect provides session management. Both use co= okies. These are authentication protocols but common usages of both SAML an= d FB Connect imply authorization grants.
- OpenID2.0 does not provide session management. This has proven to re= duce the value of OpenID and make it unsuitable for many scenarios.

We would like federation protocols based on OAuth2 to be = high-value. We would rather that they not be be hacks built on top of OAuth= 2. That means that we need a first-order concept of cookie. A cookie can be= refreshed independent of the grant associated with it. A cookie is somethi= ng the client holds on to that identifies the user (i.e., it's for user= -client authentication), but that the client is happy to outsource the mana= gement of security/crypto/logged-in/logged-out state to the server.

The cookie is produced and returned by the server, in c= ombination with a grant, but it can be refreshed independently.
<= br>
This is a solid and proven use case, and is of fundamental va= lue to many planned OAuth2 implementations.

On Thu, Feb 17, 2011 at 4:12 PM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how t= his proposed extension works with the overall architecture.

=A0

This is not just an= endpoint people can bastardize (I am not suggesting *you* are) as t= hey see fit. It must fit with the overall model which is that this endpoint= returns either an access token or an authorization grant. An authorization= grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 = PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [= OAUTH-WG] Freedom of assembly for response_type

= =A0

=A0

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <= ;eran@hueniverse.c= om> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros

--00221532c6f0b6648b049c8380db-- From eran@hueniverse.com Thu Feb 17 16:40:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8BC3A6F76 for ; Thu, 17 Feb 2011 16:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHCEJnN27vT8 for ; Thu, 17 Feb 2011 16:39:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DD3F63A6EF2 for ; Thu, 17 Feb 2011 16:39:55 -0800 (PST) Received: (qmail 9671 invoked from network); 18 Feb 2011 00:40:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 00:40:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Feb 2011 17:40:28 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 17:40:19 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPAd0yGDkM+jP4STqVbC9HWRKauQAAWaKQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42A5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:40:05 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42A5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42A5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not = questioning the use case, only how it fits within the OAuth framework.=

 

I don’t understand how such an extension is= expected to work with the existing grant types. The response_type paramete= r is used to identify if the flow being used is for an implicit grant or au= thorization code. Are you suggesting a new grant type? Are you suggesting a= dditional response parameters/headers (in the case of a cookie) with both g= rant types?

 

Without full requirements we can&= #8217;t design an extension point. Asking to make this parameter a free tex= t field is not helpful.

 

EHL=

 

Fr= om: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday,= February 17, 2011 4:22 PM
To: Eran Hammer-Lahav
Cc: oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for resp= onse_type

 =

The use case is very straightforward:

 

- SAML provides session management. Facebook Connect provides = session management. Both use cookies. These are authentication protocols bu= t common usages of both SAML and FB Connect imply authorization grants.

- OpenID2.0 does not provide ses= sion management. This has proven to reduce the value of OpenID and make it = unsuitable for many scenarios.

 

We would like federa= tion protocols based on OAuth2 to be high-value. We would rather that they = not be be hacks built on top of OAuth2. That means that we need a first-ord= er concept of cookie. A cookie can be refreshed independent of the grant as= sociated with it. A cookie is something the client holds on to that identif= ies the user (i.e., it's for user-client authentication), but that the clie= nt is happy to outsource the management of security/crypto/logged-in/logged= -out state to the server.

 

The cookie is produced an= d returned by the server, in combination with a grant, but it can be refres= hed independently.

 = ;

This is a solid and proven use c= ase, and is of fundamental value to many planned OAuth2 implementations.

 

=

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:<= o:p>

You need to define how this proposed extension works with the overall ar= chitecture.

 

This is not just an endpoint people can bastardize (I am= not suggesting *you* are) as they see fit. It must fit with the ove= rall model which is that this endpoint returns either an access token or an= authorization grant. An authorization grant has to be exchanged for an acc= ess token.

 

If you are going to return something else, instead or in = addition to the token/code options, you need to explain how it fits within = the model. I am opposed to an open-ended extension point that is not consis= tent (and restricted) to the model we spent a year to define and refine. Th= e token+code response type was well defined (it was the use case that wasn&= #8217;t).

 

To move this forward, you need to come up with specific re= quirements, not just making something extensible without understanding what= it is you are trying to extend. That’s like the OAuth 1.0 utterly br= oken oauth_version parameter and the long confusion it created later on.

&n= bsp;

EHL

 

From:= Breno [mailto:breno.demedeiros@gmail.com]

Sent: Thursday, February 17, 2011 1:58 PM
To: Era= n Hammer-Lahav
Cc: oauth@ietf.org

Subjec= t: Re: [OAUTH-WG] Freedom of assembly for response_type

<= /div>

 

 

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote:

The best approach (at this point) is to leave the spec unchanged. H= owever, another spec can update the definition of the response_type paramet= er, including defining a registry or other methods for extensibility.

 = ;

We can define this now, and it will not have any impact on existing code,= but I am leery of adding yet another extensibility vector without sufficie= nt requirement. I also think that adding extension parameters can handle th= is cleanly.

 <= /p>

The spec, as currently written does not imply that the= only possible values are 'code' and 'token'. The only concern is that libr= aries may implement such restriction and make extending this behavior diffe= rent.

 

I do not think that extension parameters can handle this cleanly. In part= icular, if the response_type is neither code nor token. 

 

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Breno
Sent: Thursday, February 17, = 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of assembly f= or response_type

 

- Problem 1: Several W= G participants are working on deploying a federated signon protocol based o= n OAuth2 (aka OpenIDConnect) and would like to return an additional 'sessio= n cookie' together with the auth_token. Or sometimes return only a cookie a= s the result of authorization, since cookies will likely have shorter lifet= imes than access tokens, for security and usability reasons, and require mo= re frequent refresh requirements. In any case, there aremultiple reasons fo= r making the cookie separate from the auth_token, including both security a= nd flexibility of deployment. However, there is no way to express this exce= pt adding an arbitrary extension parameter (to effectively express a differ= ent response type).

 =

- Problem 2: Codific= ation of code_and_token created controversy as there was not enough tractio= n among participants to put it in the core. However, it is entirely possibl= e that deployment experience will lead players to revisit this topic.

 

 

- Proposed solution:

 

=

1. Allow response_type t= o be a space separated list of arbitrary strings

 

<= /div>

E.g.:

 

response_type=3Dco= de

= response_type=3Dtoken

response_type=3Dcode+token

response_type=3Dcookie

response_typ= e=3Dcode+cookie

response_type=3Dtoken+cookie

=

response_type=3Dfoo+bar=

 <= o:p>

Would all = be syntactically valid responses from the perspective of OAuth2.0 Core resp= onse_type values.

 

 

2. Define behaviors in the core only for values 'cod= e' and 'token'. Allow extensions to define what do with 'code+token' or wit= h any other values or combinations of values. 


--
Breno de Medeiros




--
Breno de = Medeiros




--
Breno de= Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42A5P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 16:49:57 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC003A6CE0 for ; Thu, 17 Feb 2011 16:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM+Y9-Mb2Sx3 for ; Thu, 17 Feb 2011 16:49:55 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 43E8C3A6C72 for ; Thu, 17 Feb 2011 16:49:55 -0800 (PST) Received: by iwc10 with SMTP id 10so3309551iwc.31 for ; Thu, 17 Feb 2011 16:50:27 -0800 (PST) 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=cR3FPJNaXmigbrXTdHVBdad5crYVw2SXPRTZZS4IEpE=; b=ubVxab0nhRsph6Ap9mUWksIwydMboM+9UF3J7XFsVqtZWIA2/zWa70kR1o2YtpA/bT l+8FYQhT3yuB12/soRPJqW2Gw14AhPcd+7P6G6CtWfsbCDABviIX0NSYvkx5N1zlXymu gYptZnmBGSpaA3pfausyXY4j7GTjg2yrR1R1s= 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=YjhYpxePPdHqSY2BBnz7GD7gtL0g4G5Fv0YIVEqYMwk03jU4NcCFSGxMTuWc8CU2v2 bG70R81FJzm+6WZdM6IIXQc4H97lCRnZ2CPstkCAyqdKqsdkykYE104QptKvVlVF+wxw ounzB/mqaNr2kOYhyJojEiI760qaysI5DGQds= MIME-Version: 1.0 Received: by 10.231.172.75 with SMTP id k11mr59406ibz.133.1297990227247; Thu, 17 Feb 2011 16:50:27 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 16:50:27 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 16:50:27 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0050450141b06ac2e8049c83e6cc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:49:57 -0000 --0050450141b06ac2e8049c83e6cc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav wro= te: > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don=92t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if = the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > It's a separate grant type that can be combined with either of the previous types. > > > Without full requirements we can=92t design an extension point. Asking to > make this parameter a free text field is not helpful. > The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token - If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --0050450141b06ac2e8049c83e6cc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 4:40 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

I am not questioning the= use case, only how it fits within the OAuth framework.

=A0

I don=92t understan= d how such an extension is expected to work with the existing grant types. = The response_type parameter is used to identify if the flow being used is f= or an implicit grant or authorization code. Are you suggesting a new grant = type? Are you suggesting additional response parameters/headers (in the cas= e of a cookie) with both grant types?


It's a separate grant type= that can be combined with either of the previous types.

=A0

=A0

Without full = requirements we can=92t design an extension point. Asking to make this para= meter a free text field is not helpful.


The requirement is to allow an= other grant type, cookie.

- cookie can be used sep= arately or in combination with code or token.

- if specified by itself or in combination with token, it's returned in= the End User Authorization Response, in analogy/in addition to the access_= token

- If specified in combination with code, it&= #39;s returned in exchange for the code, in analogy with the access_token
=A0

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Thursday, February 17, 2011 4:22 PM

=

To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:= Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

The use case is very straightforward:<= /p>

=A0

- S= AML provides session management. Facebook Connect provides session manageme= nt. Both use cookies. These are authentication protocols but common usages = of both SAML and FB Connect imply authorization grants.

- OpenID2.0 does not provide session mana= gement. This has proven to reduce the value of OpenID and make it unsuitabl= e for many scenarios.

=A0

We would like federation protocols based on OAuth2 t= o be high-value. We would rather that they not be be hacks built on top of = OAuth2. That means that we need a first-order concept of cookie. A cookie c= an be refreshed independent of the grant associated with it. A cookie is so= mething the client holds on to that identifies the user (i.e., it's for= user-client authentication), but that the client is happy to outsource the= management of security/crypto/logged-in/logged-out state to the server.

=A0

= The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently.

=A0

This is a solid and proven use cas= e, and is of fundamental value to many planned OAuth2 implementations.

<= /div>

=A0

On= Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall = architecture.

=A0

This = is not just an endpoint people can bastardize (I am not suggesting *you<= /b>* are) as they see fit. It must fit with the overall model which is that= this endpoint returns either an access token or an authorization grant. An= authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, F= eb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros

--0050450141b06ac2e8049c83e6cc-- From eran@hueniverse.com Thu Feb 17 16:55:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139FE3A6C72 for ; Thu, 17 Feb 2011 16:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7Qz-Z4a-6GL for ; Thu, 17 Feb 2011 16:55:37 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AC7BD3A6C58 for ; Thu, 17 Feb 2011 16:55:37 -0800 (PST) Received: (qmail 2822 invoked from network); 18 Feb 2011 00:56:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 00:56:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Feb 2011 17:56:09 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 17:56:00 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPBdZCbwAoz66ZTE+8cmcmRKsvWwAAIRtQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42AAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:55:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42AAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. Can you request only a cookie? Or is it always with either a token or code? EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42AAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is cookie= exchanged for an access token? Authorization grants are not meant to be us= eful by themselves, only exchanged for an access token.

 

Can you request only a cookie? Or is it always with either a tok= en or code?

 

EHL

 

 

 <= /span>

From: Breno [mailto:bren= o.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 4:50 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subjec= t: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I am not = questioning the use case, only how it fits within the OAuth framework.

&nbs= p;

I don’t understand how such an extension is expected to work with = the existing grant types. The response_type parameter is used to identify i= f the flow being used is for an implicit grant or authorization code. Are y= ou suggesting a new grant type? Are you suggesting additional response para= meters/headers (in the case of a cookie) with both grant types?=

 

=

It's a separate grant type that can be combined w= ith either of the previous types.

 

 =

 =

Without full requ= irements we can’t design an extension point. Asking to make this para= meter a free text field is not helpful.

 

The requirement is to allow another grant type, cookie.=

 

<= p class=3DMsoNormal>- cookie can be used separately or in combination with = code or token.

 

- if specified by itself or in combi= nation with token, it's returned in the End User Authorization Response, in= analogy/in addition to the access_token

 

- If spec= ified in combination with code, it's returned in exchange for the code, in = analogy with the access_token

 

 =

EHL

 

From: Bre= no [mailto:= breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of= assembly for response_type

 

The use case is very straightforward:

 

- SAML prov= ides session management. Facebook Connect provides session management. Both= use cookies. These are authentication protocols but common usages of both = SAML and FB Connect imply authorization grants.

- OpenID2.0 does not provide session management. This has proven to re= duce the value of OpenID and make it unsuitable for many scenarios.

 

We would li= ke federation protocols based on OAuth2 to be high-value. We would rather t= hat they not be be hacks built on top of OAuth2. That means that we need a = first-order concept of cookie. A cookie can be refreshed independent of the= grant associated with it. A cookie is something the client holds on to tha= t identifies the user (i.e., it's for user-client authentication), but that= the client is happy to outsource the management of security/crypto/logged-= in/logged-out state to the server.

 

The cookie is produced and returned by the s= erver, in combination with a grant, but it can be refreshed independently.<= o:p>

 

This= is a solid and proven use case, and is of fundamental value to many planne= d OAuth2 implementations.

 <= /o:p>

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <= ;eran@hueniverse.c= om> wrote:

You need to define how this proposed extension works w= ith the overall architecture.

 

This is not just an endpoint people ca= n bastardize (I am not suggesting *you* are) as they see fit. It mus= t fit with the overall model which is that this endpoint returns either an = access token or an authorization grant. An authorization grant has to be ex= changed for an access token.

 

If you are going to return something el= se, instead or in addition to the token/code options, you need to explain h= ow it fits within the model. I am opposed to an open-ended extension point = that is not consistent (and restricted) to the model we spent a year to def= ine and refine. The token+code response type was well defined (it was the u= se case that wasn’t).

 

To move this forward, you need to come = up with specific requirements, not just making something extensible without= understanding what it is you are trying to extend. That’s like the O= Auth 1.0 utterly broken oauth_version parameter and the long confusion it c= reated later on.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]

Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: R= e: [OAUTH-WG] Freedom of assembly for response_type

 

 

= On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

= The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility.

 =

We can= define this now, and it will not have any impact on existing code, but I a= m leery of adding yet another extensibility vector without sufficient requi= rement. I also think that adding extension parameters can handle this clean= ly.

 

The spec, as currently written does not imply that the only po= ssible values are 'code' and 'token'. The only concern is that libraries ma= y implement such restriction and make extending this behavior different.

 

I do n= ot think that extension parameters can handle this cleanly. In particular, = if the response_type is neither code nor token. 

<= div>

 

 

EHL

 

From:<= /span> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:= 30 AM
To: oau= th@ietf.org
Subject: [OAUTH-WG] Freedom of assembly for respo= nse_type

 

- Problem 1: Several WG partic= ipants are working on deploying a federated signon protocol based on OAuth2= (aka OpenIDConnect) and would like to return an additional 'session cookie= ' together with the auth_token. Or sometimes return only a cookie as the re= sult of authorization, since cookies will likely have shorter lifetimes tha= n access tokens, for security and usability reasons, and require more frequ= ent refresh requirements. In any case, there aremultiple reasons for making= the cookie separate from the auth_token, including both security and flexi= bility of deployment. However, there is no way to express this except addin= g an arbitrary extension parameter (to effectively express a different resp= onse type).

 

- Problem 2: Codification of= code_and_token created controversy as there was not enough traction among = participants to put it in the core. However, it is entirely possible that d= eployment experience will lead players to revisit this topic.

 

 

- Proposed solution:

=

 

<= div>

1. Allow response_type to be a = space separated list of arbitrary strings

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

E.g.:

 

<= /div>

response_type=3Dcode

respons= e_type=3Dtoken

response_type=3Dcode+token

response_type=3Dcookie

response_type=3Dc= ode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar=

 

Would all be syn= tactically valid responses from the perspective of OAuth2.0 Core response_t= ype values.

 

 

2. Define behaviors in the core only for values 'code' an= d 'token'. Allow extensions to define what do with 'code+token' or with any= other values or combinations of values. 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'>=
--
Breno de Medeiros




--
Breno de Medei= ros



=
--
Breno de Medeiros




--
Breno de Medeiros

=
= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42AAP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 17:09:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C053A6A0C for ; Thu, 17 Feb 2011 17:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNNBS24nXCq8 for ; Thu, 17 Feb 2011 17:09:34 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5ECC73A6C72 for ; Thu, 17 Feb 2011 17:09:34 -0800 (PST) Received: by iwc10 with SMTP id 10so3323928iwc.31 for ; Thu, 17 Feb 2011 17:10:06 -0800 (PST) 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=DlTK4AgwFLjKBVh7niOdBuqdxj6WJHdwbN0fNSVHN5U=; b=tTrzqLhG1DJr7O7qKG8pmL0VUxqySQ91nGPMNMrmKQrCLZzg0KW6ErLxwuBfdNJ8Zz 8HH4NakIP5AVQ5fk16AC26hgPuq8wnHf0FWEidkWschVIQs0ZeaQdpZ8yQ6VBA2lJQvg fVbav4M7tq7VSfz8VekI1eO/o4ImZ013UtUeo= 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=vCTq4DQgEYynLmGeTsYbXRkfwtg2+9BGBuZJF2zwN6CzEbFbJRtDbvZU3pRnTpO89M bLtxD7FvzBdstNRBI61xW2x9DJn5FyoWC9u/bb6fU+ECLdlnFEZsvGRZ1q6I5mFB9sRP SiejeQNCreGOAdyIHuhdCECznRi+S0TLW8qjI= MIME-Version: 1.0 Received: by 10.231.172.75 with SMTP id k11mr72091ibz.133.1297991406462; Thu, 17 Feb 2011 17:10:06 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 17:10:06 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 17:10:06 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0050450141b0b4261f049c842cf6 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 01:09:36 -0000 --0050450141b0b4261f049c842cf6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav wro= te: > Is cookie exchanged for an access token? Authorization grants are not mea= nt > to be useful by themselves, only exchanged for an access token. > In this scenario, grants are exchanged for access tokens and/or cookies. > > > Can you request only a cookie? Or is it always with either a token or cod= e? > The idea is that a grant can be exchanged for only a cookie in some cases. > > > EHL > > > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:50 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: > > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don=92t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if = the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > > > > It's a separate grant type that can be combined with either of the previo= us > types. > > > > > > > > Without full requirements we can=92t design an extension point. Asking to > make this parameter a free text field is not helpful. > > > > The requirement is to allow another grant type, cookie. > > > > - cookie can be used separately or in combination with code or token. > > > > - if specified by itself or in combination with token, it's returned in t= he > End User Authorization Response, in analogy/in addition to the access_tok= en > > > > - If specified in combination with code, it's returned in exchange for th= e > code, in analogy with the access_token > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --0050450141b0b4261f049c842cf6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 4:56 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Is cookie exchanged for = an access token? Authorization grants are not meant to be useful by themsel= ves, only exchanged for an access token.


In this scenario, grants are e= xchanged for access tokens and/or cookies.
=A0

=A0

Can you reque= st only a cookie? Or is it always with either a token or code?


The idea is that a grant can b= e exchanged for only a cookie in some cases.
=A0

=A0

EHL

=A0

=A0

=A0=

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:50 PM

=

To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:= Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

=

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:

I am not questioning the use case, only how it fits within the OAuth f= ramework.

=A0

I don= =92t understand how such an extension is expected to work with the existing= grant types. The response_type parameter is used to identify if the flow b= eing used is for an implicit grant or authorization code. Are you suggestin= g a new grant type? Are you suggesting additional response parameters/heade= rs (in the case of a cookie) with both grant types?

=A0

It's a separate grant type that can be combined with either of th= e previous types.

=A0

=A0

=

=A0

Witho= ut full requirements we can=92t design an extension point. Asking to make t= his parameter a free text field is not helpful.

=A0

The re= quirement is to allow another grant type, cookie.

=A0

- cookie can be used s= eparately or in combination with code or token.

=A0

= - if specified by itself or in combination with token, it's returned in= the End User Authorization Response, in analogy/in addition to the access_= token

=A0

= - If specified in combination with code, it's returned in exchange for = the code, in analogy with the access_token

=A0

=

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

The use case is very straightforward:

=A0

- SAML provides session mana= gement. Facebook Connect provides session management. Both use cookies. The= se are authentication protocols but common usages of both SAML and FB Conne= ct imply authorization grants.

- OpenID2.0 does not provide session mana= gement. This has proven to reduce the value of OpenID and make it unsuitabl= e for many scenarios.

=A0

We would like federation protocols based on OAuth2 t= o be high-value. We would rather that they not be be hacks built on top of = OAuth2. That means that we need a first-order concept of cookie. A cookie c= an be refreshed independent of the grant associated with it. A cookie is so= mething the client holds on to that identifies the user (i.e., it's for= user-client authentication), but that the client is happy to outsource the= management of security/crypto/logged-in/logged-out state to the server.

=A0

= The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently.

=A0

This is a solid and proven use cas= e, and is of fundamental value to many planned OAuth2 implementations.

<= /div>

=A0

On= Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall = architecture.

=A0

This = is not just an endpoint people can bastardize (I am not suggesting *you<= /b>* are) as they see fit. It must fit with the overall model which is that= this endpoint returns either an access token or an authorization grant. An= authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, F= eb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros

--0050450141b0b4261f049c842cf6-- From eran@hueniverse.com Thu Feb 17 19:31:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA31F3A6D33 for ; Thu, 17 Feb 2011 19:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjo4VKf3Oxvf for ; Thu, 17 Feb 2011 19:31:31 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 538513A6B6F for ; Thu, 17 Feb 2011 19:31:30 -0800 (PST) Received: (qmail 20112 invoked from network); 18 Feb 2011 03:32:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 03:32:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 17 Feb 2011 20:31:45 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 20:31:37 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPCJUTdPnh0rGKT5u8aQNee7CuxAAE5wAg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42E0P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 03:31:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42E0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So an implicit grant can produce just a cookie or both cookie and token, bu= t not code? EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 5:10 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42E0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So an imp= licit grant can produce just a cookie or both cookie and token, but not cod= e?

 

EHL

 

&nb= sp;

From: Breno [ma= ilto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 20= 11 5:10 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
= Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

= Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token.

 

In this scenario, grants are exchanged for acces= s tokens and/or cookies.

&nbs= p;

=

 

Can = you request only a cookie? Or is it always with either a token or code?

&= nbsp;

The idea is that a grant can= be exchanged for only a cookie in some cases.

 

 

EHL

 

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent= : Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subje= ct: Re: [OAUTH-WG] Freedom of assembly for response_type

=

 

 <= /o:p>

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <= ;eran@hueniverse.c= om> wrote:

I am not questioning the use case, only how it fits wi= thin the OAuth framework.

 

I don’t understand how such an ex= tension is expected to work with the existing grant types. The response_typ= e parameter is used to identify if the flow being used is for an implicit g= rant or authorization code. Are you suggesting a new grant type? Are you su= ggesting additional response parameters/headers (in the case of a cookie) w= ith both grant types?

 

It's a separate grant type that can be combi= ned with either of the previous types.

&nbs= p;

 

 

Wit= hout full requirements we can’t design an extension point. Asking to = make this parameter a free text field is not helpful.

=

 

The requirement is to allow another grant type, cookie.

 

- cookie can be used s= eparately or in combination with code or token.

 

- if specified by itself or in = combination with token, it's returned in the End User Authorization Respons= e, in analogy/in addition to the access_token

 

- If specified in combination wit= h code, it's returned in exchange for the code, in analogy with the access_= token

 

 <= /span>

= EHL

 

From: Bre= no [mailto:= breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 4:22 PM


To: Eran Hammer-= Lahav
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for r= esponse_type

 <= o:p>

The use case is very straightforward:

 

- SAML provides session ma= nagement. Facebook Connect provides session management. Both use cookies. T= hese are authentication protocols but common usages of both SAML and FB Con= nect imply authorization grants.

- OpenID2.= 0 does not provide session management. This has proven to reduce the value = of OpenID and make it unsuitable for many scenarios.

 

We would like federation p= rotocols based on OAuth2 to be high-value. We would rather that they not be= be hacks built on top of OAuth2. That means that we need a first-order con= cept of cookie. A cookie can be refreshed independent of the grant associat= ed with it. A cookie is something the client holds on to that identifies th= e user (i.e., it's for user-client authentication), but that the client is = happy to outsource the management of security/crypto/logged-in/logged-out s= tate to the server.

 

The cookie is produced and returned by the server, in combi= nation with a grant, but it can be refreshed independently.

<= /div>

 

This is a solid and= proven use case, and is of fundamental value to many planned OAuth2 implem= entations.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrot= e:

You need to define how this proposed extension works with the overall= architecture.

 

This is not just an endpoint people can bastardize (I= am not suggesting *you* are) as they see fit. It must fit with the = overall model which is that this endpoint returns either an access token or= an authorization grant. An authorization grant has to be exchanged for an = access token.

 

If you are going to return something else, instead or = in addition to the token/code options, you need to explain how it fits with= in the model. I am opposed to an open-ended extension point that is not con= sistent (and restricted) to the model we spent a year to define and refine.= The token+code response type was well defined (it was the use case that wa= sn’t).

 

To move this forward, you need to come up with specific= requirements, not just making something extensible without understanding w= hat it is you are trying to extend. That’s like the OAuth 1.0 utterly= broken oauth_version parameter and the long confusion it created later on.=

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]

<= b>Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-L= ahav
Cc: oaut= h@ietf.org

Subject: Re: [OAUTH-WG] Fr= eedom of assembly for response_type

 

 

On Thu, Feb 17, = 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

=

The best approac= h (at this point) is to leave the spec unchanged. However, another spec can= update the definition of the response_type parameter, including defining a= registry or other methods for extensibility.

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>We can define this now= , and it will not have any impact on existing code, but I am leery of addin= g yet another extensibility vector without sufficient requirement. I also t= hink that adding extension parameters can handle this cleanly.<= /o:p>

 

T= he spec, as currently written does not imply that the only possible values = are 'code' and 'token'. The only concern is that libraries may implement su= ch restriction and make extending this behavior different.

 

I do not think that= extension parameters can handle this cleanly. In particular, if the respon= se_type is neither code nor token. 

&= nbsp;

 

EHL

 

=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
= To: oauth@ietf.org<= /a>
Subject: [OAUTH-WG] Freedom of assembly for response_type

 

= - Problem 1: Several WG participants are w= orking on deploying a federated signon protocol based on OAuth2 (aka OpenID= Connect) and would like to return an additional 'session cookie' together w= ith the auth_token. Or sometimes return only a cookie as the result of auth= orization, since cookies will likely have shorter lifetimes than access tok= ens, for security and usability reasons, and require more frequent refresh = requirements. In any case, there aremultiple reasons for making the cookie = separate from the auth_token, including both security and flexibility of de= ployment. However, there is no way to express this except adding an arbitra= ry extension parameter (to effectively express a different response type).<= /span>

=

response_type=3Dcode+cookie

respo= nse_type=3Dtoken+cookie

response_type=3Dfoo+bar

 

Would all be syntactically v= alid responses from the perspective of OAuth2.0 Core response_type values.<= /span>

&nb= sp;

 

2. Define behaviors in the core only for values 'code' and 'token'. Al= low extensions to define what do with 'code+token' or with any other values= or combinations of values. 


--
Br= eno de Medeiros




--
Breno de Medeiros




--
Br= eno de Medeiros




--
Breno de Medeiros




--
Breno de Mede= iros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42E0P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 21:29:06 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CB53A6DE1 for ; Thu, 17 Feb 2011 21:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDd-Ay1VYciL for ; Thu, 17 Feb 2011 21:29:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4E7C13A6A9D for ; Thu, 17 Feb 2011 21:29:02 -0800 (PST) Received: by iym1 with SMTP id 1so3361468iym.31 for ; Thu, 17 Feb 2011 21:29:35 -0800 (PST) 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=IeVhm6QT+YbTteAggE2JpkvA28s8RtPoSK0gGP8OvUg=; b=rgiJ4l/jWdEDeksK/R3CkiqOxhnw441xB5w0gRREVG6q+/VjO2i8+UK4m1T30zFlIn ZywAJV9DnT1n9/Dk71TgMw20UAsW3+EXFbrSl3S6WFImXeDJxuw409ypvIfxrcQmy1Ma kgxD5uR69NZa4xRZYzu3TuPpu+mijUC6jyMno= 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=a75DCTum+7uNFe7aghMptAxSaZ5uaInikN94pmlq9sCkwvK8MK/+MN0UjAiSLs0/ko rd1Kibd9gIIsGiikAHFp2pvPI+NVhX+ix4z1wksKR+VibXsyDaYlRyIA6Ju+WR1vz1cT fURx0gsSuRm38Me7ycYg4sovpWN8Gi7hmn4zQ= MIME-Version: 1.0 Received: by 10.42.175.134 with SMTP id ba6mr360481icb.427.1298006974899; Thu, 17 Feb 2011 21:29:34 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 21:29:34 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 21:29:34 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba6e8d8ca7a4da049c87ccf8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:29:06 -0000 --90e6ba6e8d8ca7a4da049c87ccf8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav wro= te: > So an implicit grant can produce just a cookie or both cookie and token, > but not code? > Yes, cookies would be returned in the same context of access_tokens, either as the result of an implicit grant or resulting from an explicit exchange from a code-type grant. > > > EHL > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 5:10 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: > > Is cookie exchanged for an access token? Authorization grants are not mea= nt > to be useful by themselves, only exchanged for an access token. > > > > In this scenario, grants are exchanged for access tokens and/or cookies. > > > > > > Can you request only a cookie? Or is it always with either a token or cod= e? > > > > The idea is that a grant can be exchanged for only a cookie in some cases= . > > > > > > EHL > > > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:50 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: > > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don=92t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if = the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > > > > It's a separate grant type that can be combined with either of the previo= us > types. > > > > > > > > Without full requirements we can=92t design an extension point. Asking to > make this parameter a free text field is not helpful. > > > > The requirement is to allow another grant type, cookie. > > > > - cookie can be used separately or in combination with code or token. > > > > - if specified by itself or in combination with token, it's returned in t= he > End User Authorization Response, in analogy/in addition to the access_tok= en > > > > - If specified in combination with code, it's returned in exchange for th= e > code, in analogy with the access_token > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --90e6ba6e8d8ca7a4da049c87ccf8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 7:31 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

So an implicit grant can= produce just a cookie or both cookie and token, but not code?


Yes, cookies would be returned in the same= context of access_tokens, either as the result of an implicit grant or res= ulting from an explicit exchange from a code-type grant.

=A0

=A0

EHL

=A0

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Thursday, February 17, 2011 5:10 PM

=

To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:= Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

=

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:

Is cookie exchanged for an access token? Authorization grants are not = meant to be useful by themselves, only exchanged for an access token.

=A0

In this scenario, grants are exchanged for access tokens and/or cooki= es.

=A0

=A0

Can you request only a cookie? Or is it always with either a = token or code?

=A0

The idea is that a grant can be exchanged for only a coo= kie in some cases.

=A0

=A0

EHL

=A0

=A0

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I am not questioning the use case, only how it fits within the OAuth f= ramework.

=A0

I don= =92t understand how such an extension is expected to work with the existing= grant types. The response_type parameter is used to identify if the flow b= eing used is for an implicit grant or authorization code. Are you suggestin= g a new grant type? Are you suggesting additional response parameters/heade= rs (in the case of a cookie) with both grant types?

=A0

It's a separate grant type that can be combined with either of th= e previous types.

=A0

=A0

=A0

Witho= ut full requirements we can=92t design an extension point. Asking to make t= his parameter a free text field is not helpful.

=A0

The re= quirement is to allow another grant type, cookie.

=A0

- cookie can be used s= eparately or in combination with code or token.

=A0

= - if specified by itself or in combination with token, it's returned in= the End User Authorization Response, in analogy/in addition to the access_= token

=A0

= - If specified in combination with code, it's returned in exchange for = the code, in analogy with the access_token

=A0

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

The use case is very straightforward:

=A0

- SAML provides session mana= gement. Facebook Connect provides session management. Both use cookies. The= se are authentication protocols but common usages of both SAML and FB Conne= ct imply authorization grants.

- OpenID2.0 does not provide session mana= gement. This has proven to reduce the value of OpenID and make it unsuitabl= e for many scenarios.

=A0

We would like federation protocols based on OAuth2 t= o be high-value. We would rather that they not be be hacks built on top of = OAuth2. That means that we need a first-order concept of cookie. A cookie c= an be refreshed independent of the grant associated with it. A cookie is so= mething the client holds on to that identifies the user (i.e., it's for= user-client authentication), but that the client is happy to outsource the= management of security/crypto/logged-in/logged-out state to the server.

=A0

= The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently.

=A0

This is a solid and proven use cas= e, and is of fundamental value to many planned OAuth2 implementations.

<= /div>

=A0

On= Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall = architecture.

=A0

This = is not just an endpoint people can bastardize (I am not suggesting *you<= /b>* are) as they see fit. It must fit with the overall model which is that= this endpoint returns either an access token or an authorization grant. An= authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, F= eb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros



--
Breno de Medeiros

=



--
Breno de Medeiros

--90e6ba6e8d8ca7a4da049c87ccf8-- From eran@hueniverse.com Thu Feb 17 21:52:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553503A69D0 for ; Thu, 17 Feb 2011 21:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUgmui6U3xCw for ; Thu, 17 Feb 2011 21:51:52 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B560D3A6862 for ; Thu, 17 Feb 2011 21:51:52 -0800 (PST) Received: (qmail 19895 invoked from network); 18 Feb 2011 05:52:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 05:52:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 17 Feb 2011 22:52:24 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 22:52:15 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPLNR1jaAbtxmkSjarf478ovVKYQAAwc8A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F2P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 05:52:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F2P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok. So you want to request a cookie from both endpoints: the authorization endp= oint and the token endpoint? How would that work? There is no response_type= on the token endpoint. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 9:30 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: So an implicit grant can produce just a cookie or both cookie and token, bu= t not code? Yes, cookies would be returned in the same context of access_tokens, either= as the result of an implicit grant or resulting from an explicit exchange = from a code-type grant. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 5:10 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F2P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok.<= /o:p>

 

So you want to request a cookie from both endpoint= s: the authorization endpoint and the token endpoint? How would that work? = There is no response_type on the token endpoint.

 

EHL

 <= /span>

From: Breno [mailto:bren= o.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 9:30 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subjec= t: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

So an imp= licit grant can produce just a cookie or both cookie and token, but not cod= e?

 

Yes, cookies would be returned in t= he same context of access_tokens, either as the result of an implicit grant= or resulting from an explicit exchange from a code-type grant.<= /p>

 

 

 

EHL

 

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursd= ay, February 17, 2011 5:10 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [O= AUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote:

Is cookie exchanged for an access token? Authorization grants are n= ot meant to be useful by themselves, only exchanged for an access token.

 

=

In this scenario, grants are exchanged for access tokens and/or cook= ies.

 

 

C= an you request only a cookie? Or is it always with either a token or code?<= /span>

 =

The idea is that a grant can be exchanged for only a = cookie in some cases.

 

 

EHL

 

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent= : Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAU= TH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote= :

I am not questioning the use case, only how it fits within the OAuth f= ramework.

 

I don’t understand how such an extension is expected= to work with the existing grant types. The response_type parameter is used= to identify if the flow being used is for an implicit grant or authorizati= on code. Are you suggesting a new grant type? Are you suggesting additional= response parameters/headers (in the case of a cookie) with both grant type= s?

 

=

It's a separate grant type that can be combined with either of = the previous types.

 

 

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Without full requireme= nts we can’t design an extension point. Asking to make this parameter= a free text field is not helpful.

 

The requirement is= to allow another grant type, cookie.

 = ;

- cookie can be used separately or in com= bination with code or token.

 

- if specified by itself or in combination with to= ken, it's returned in the End User Authorization Response, in analogy/in ad= dition to the access_token

 

- If specified in combination with code, it's return= ed in exchange for the code, in analogy with the access_token

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@g= mail.com]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.orgSubject: Re: [OAUTH-WG] Freedom of assembly for response_type<= /o:p>

 

The use case is very straightforward:

 

- SAML provides session management. Facebook= Connect provides session management. Both use cookies. These are authentic= ation protocols but common usages of both SAML and FB Connect imply authori= zation grants.

- OpenID2.0 does not provide= session management. This has proven to reduce the value of OpenID and make= it unsuitable for many scenarios.

 

We would like federation protocols based on = OAuth2 to be high-value. We would rather that they not be be hacks built on= top of OAuth2. That means that we need a first-order concept of cookie. A = cookie can be refreshed independent of the grant associated with it. A cook= ie is something the client holds on to that identifies the user (i.e., it's= for user-client authentication), but that the client is happy to outsource= the management of security/crypto/logged-in/logged-out state to the server= .

 

T= he cookie is produced and returned by the server, in combination with a gra= nt, but it can be refreshed independently.

=  

This is a solid and proven use case,= and is of fundamental value to many planned OAuth2 implementations.

 

On Thu, Feb= 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

=

You need to= define how this proposed extension works with the overall architecture.

&n= bsp;

This is not just an endpoint people can bastardize (I am not suggestin= g *you* are) as they see fit. It must fit with the overall model whi= ch is that this endpoint returns either an access token or an authorization= grant. An authorization grant has to be exchanged for an access token.

&nb= sp;

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn’t).

&nbs= p;

To move this forward, you need to come up with specific requirements, no= t just making something extensible without understanding what it is you are= trying to extend. That’s like the OAuth 1.0 utterly broken oauth_ver= sion parameter and the long confusion it created later on.

 

EHL

 = ;

From: Breno [mailto= :breno.deme= deiros@gmail.com]

Sent: Thursd= ay, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc:= oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly = for response_type

 

 

On Thu, Feb 17, 2011 at 1:51 PM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) = is to leave the spec unchanged. However, another spec can update the defini= tion of the response_type parameter, including defining a registry or other= methods for extensibility.

 

We can define this now, and it will not= have any impact on existing code, but I am leery of adding yet another ext= ensibility vector without sufficient requirement. I also think that adding = extension parameters can handle this cleanly.

 

The spec, as curren= tly written does not imply that the only possible values are 'code' and 'to= ken'. The only concern is that libraries may implement such restriction and= make extending this behavior different.

&= nbsp;

I do not think that extension paramet= ers can handle this cleanly. In particular, if the response_type is neither= code nor token. 

 

 

EHL

 

From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of BrenoSent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:= [OAUTH-WG] Freedom of assembly for response_type

=

 

- Problem 1: Several WG participants are working on deployin= g a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would= like to return an additional 'session cookie' together with the auth_token= . Or sometimes return only a cookie as the result of authorization, since c= ookies will likely have shorter lifetimes than access tokens, for security = and usability reasons, and require more frequent refresh requirements. In a= ny case, there aremultiple reasons for making the cookie separate from the = auth_token, including both security and flexibility of deployment. However,= there is no way to express this except adding an arbitrary extension param= eter (to effectively express a different response type).<= /p>

 

- Problem 2: Codification of code_and_token created contro= versy as there was not enough traction among participants to put it in the = core. However, it is entirely possible that deployment experience will lead= players to revisit this topic.

 

 =

- Propose= d solution:

 

1. Allow response_type to be a space separated list of arbitr= ary strings

 

E.g.:

 

response_type=3Dcode

=

response_type=3Dtoken

response_type=3D= code+token

response_type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+= cookie

response_type=3Dfoo+bar

 

Would all be syntactically valid responses fro= m the perspective of OAuth2.0 Core response_type values.<= /p>

 

 

2. Define beh= aviors in the core only for values 'code' and 'token'. Allow extensions to = define what do with 'code+token' or with any other values or combinations o= f values. 


--
Breno de Medeiros

<= br>

--
Breno de Medeiros

<= /div>




--
Breno de Medeiros

<= br>

--
Breno de Medeiros

<= /div>




--
Breno d= e Medeiros

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>


= --
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F2P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Feb 17 22:06:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CFB3A68DD for ; Thu, 17 Feb 2011 22:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLeV7j7bFVGD for ; Thu, 17 Feb 2011 22:06:11 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C6F293A6D72 for ; Thu, 17 Feb 2011 22:06:09 -0800 (PST) Received: by iwc10 with SMTP id 10so3520028iwc.31 for ; Thu, 17 Feb 2011 22:06:41 -0800 (PST) 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=vJZYcOHa0FtYruEGYTVNIMlny+LX388I8pucy8w8rQc=; b=D6SEwlRocyWvIx/jtqt9/Rw+pysXlenUtzFpediXdpYvGLO/iiR8P/uP2UlUDGLqZe m1SSQ8yUVf9YD0ENm6RhLyyQRKMDPRWwIXDySBRim9c8/XoeGgVh8q2RTqjkwqkCrL4d og/lTLgSh68E+eB5hgdt+Qy9TO4a9sXiVjx4s= 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=vYSeiLrDSRFCQ6g/3irKas9TBmsOhqWMZxjF99FQ+tqhBL/mBiUNwuAyrbbwOWjlHC EetQNyAZZcllkCzPPv3pD3KFvBRQ0GmJcOCmF1xckAV5PDfyqS9mt4OhRUJgxOgzbrgI l0Im5N80jpSJuoqXutkCWd70Yf4ChxV+MzXdo= MIME-Version: 1.0 Received: by 10.231.207.66 with SMTP id fx2mr242990ibb.108.1298009200908; Thu, 17 Feb 2011 22:06:40 -0800 (PST) Received: by 10.231.158.139 with HTTP; Thu, 17 Feb 2011 22:06:40 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Feb 2011 22:06:40 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba4fc48655d8ed049c8851bc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:06:21 -0000 --90e6ba4fc48655d8ed049c8851bc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav wro= te: > Ok. > > > > So you want to request a cookie from both endpoints: the authorization > endpoint and the token endpoint? How would that work? There is no > response_type on the token endpoint. > There is no need to. The grant carries the information. > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 9:30 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: > > So an implicit grant can produce just a cookie or both cookie and token, > but not code? > > > > Yes, cookies would be returned in the same context of access_tokens, eith= er > as the result of an implicit grant or resulting from an explicit exchange > from a code-type grant. > > > > > > > > EHL > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 5:10 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: > > Is cookie exchanged for an access token? Authorization grants are not mea= nt > to be useful by themselves, only exchanged for an access token. > > > > In this scenario, grants are exchanged for access tokens and/or cookies. > > > > > > Can you request only a cookie? Or is it always with either a token or cod= e? > > > > The idea is that a grant can be exchanged for only a cookie in some cases= . > > > > > > EHL > > > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:50 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: > > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don=92t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if = the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > > > > It's a separate grant type that can be combined with either of the previo= us > types. > > > > > > > > Without full requirements we can=92t design an extension point. Asking to > make this parameter a free text field is not helpful. > > > > The requirement is to allow another grant type, cookie. > > > > - cookie can be used separately or in combination with code or token. > > > > - if specified by itself or in combination with token, it's returned in t= he > End User Authorization Response, in analogy/in addition to the access_tok= en > > > > - If specified in combination with code, it's returned in exchange for th= e > code, in analogy with the access_token > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --90e6ba4fc48655d8ed049c8851bc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 17, 2011 at 9:52 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Ok.

=A0

So you want to request a coo= kie from both endpoints: the authorization endpoint and the token endpoint?= How would that work? There is no response_type on the token endpoint.


There is no need to. The grant= carries the information.
=A0

=A0

EHL

=A0

From:= Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 9:30 PM

=A0

=A0

=

On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:

So an implicit grant can produce just a cookie or both cookie and toke= n, but not code?

=A0

<= /div>

Yes, cookies would be returned in the same cont= ext of access_tokens, either as the result of an implicit grant or resultin= g from an explicit exchange from a code-type grant.

=A0

=A0

=A0

EHL

=A0

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Thursday, February 17, 2011 5:10 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

Is cookie exchanged for an access token? Authorization grants are not = meant to be useful by themselves, only exchanged for an access token.

=A0

In this scenario, grants are exchanged for access tokens and/or cooki= es.

=A0

=A0

Can you request only a cookie? Or is it always with either a = token or code?

=A0

The idea is that a grant can be exchanged for only a coo= kie in some cases.

=A0

=A0

EHL

=A0

=A0

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I am not questioning the use case, only how it fits within the OAuth f= ramework.

=A0

I don= =92t understand how such an extension is expected to work with the existing= grant types. The response_type parameter is used to identify if the flow b= eing used is for an implicit grant or authorization code. Are you suggestin= g a new grant type? Are you suggesting additional response parameters/heade= rs (in the case of a cookie) with both grant types?

=A0

It's a separate grant type that can be combined with either of th= e previous types.

=A0

=A0

=A0

Witho= ut full requirements we can=92t design an extension point. Asking to make t= his parameter a free text field is not helpful.

=A0

The re= quirement is to allow another grant type, cookie.

=A0

- cookie can be used s= eparately or in combination with code or token.

=A0

= - if specified by itself or in combination with token, it's returned in= the End User Authorization Response, in analogy/in addition to the access_= token

=A0

= - If specified in combination with code, it's returned in exchange for = the code, in analogy with the access_token

=A0

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

The use case is very straightforward:

=A0

- SAML provides session mana= gement. Facebook Connect provides session management. Both use cookies. The= se are authentication protocols but common usages of both SAML and FB Conne= ct imply authorization grants.

- OpenID2.0 does not provide session mana= gement. This has proven to reduce the value of OpenID and make it unsuitabl= e for many scenarios.

=A0

We would like federation protocols based on OAuth2 t= o be high-value. We would rather that they not be be hacks built on top of = OAuth2. That means that we need a first-order concept of cookie. A cookie c= an be refreshed independent of the grant associated with it. A cookie is so= mething the client holds on to that identifies the user (i.e., it's for= user-client authentication), but that the client is happy to outsource the= management of security/crypto/logged-in/logged-out state to the server.

=A0

= The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently.

=A0

This is a solid and proven use cas= e, and is of fundamental value to many planned OAuth2 implementations.

<= /div>

=A0

On= Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall = architecture.

=A0

This = is not just an endpoint people can bastardize (I am not suggesting *you<= /b>* are) as they see fit. It must fit with the overall model which is that= this endpoint returns either an access token or an authorization grant. An= authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, F= eb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros



--
Breno de Medeiros

=




--
Breno de Medeiros




--
Breno de Medeiros

--90e6ba4fc48655d8ed049c8851bc-- From eran@hueniverse.com Thu Feb 17 22:47:48 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776063A6CDA for ; Thu, 17 Feb 2011 22:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-CmOaEe6Lmt for ; Thu, 17 Feb 2011 22:47:35 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 55D5A3A6D4F for ; Thu, 17 Feb 2011 22:47:34 -0800 (PST) Received: (qmail 4130 invoked from network); 18 Feb 2011 06:48:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 06:48:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 17 Feb 2011 23:48:06 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 23:47:57 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPMgNjY6t8x/fXTW+KpOY+JVac1wABbtPQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:47:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You mean this is encoded into the authorization code? EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 10:07 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav > wrote: Ok. So you want to request a cookie from both endpoints: the authorization endp= oint and the token endpoint? How would that work? There is no response_type= on the token endpoint. There is no need to. The grant carries the information. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 9:30 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: So an implicit grant can produce just a cookie or both cookie and token, bu= t not code? Yes, cookies would be returned in the same context of access_tokens, either= as the result of an implicit grant or resulting from an explicit exchange = from a code-type grant. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 5:10 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You mean = this is encoded into the authorization code?

 

EHL

 

From: Breno [mailto:breno.de= medeiros@gmail.com]
Sent: Thursday, February 17, 2011 10:07 PMTo: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type<= /p>

 

 

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= div>

Ok.

 

S= o you want to request a cookie from both endpoints: the authorization endpo= int and the token endpoint? How would that work? There is no response_type = on the token endpoint.

 

There is no nee= d to. The grant carries the information.

 

 

EHL

 

<= b>From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, Feb= ruary 17, 2011 9:30 PM

=
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG= ] Freedom of assembly for response_type

 

 

= On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

= So an implicit grant can produce just a cookie or both cookie and token, bu= t not code?

 <= /p>

Yes, cookies would be returned in the same context of = access_tokens, either as the result of an implicit grant or resulting from = an explicit exchange from a code-type grant.

 

 

&nbs= p;

EHL

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, Februar= y 17, 2011 5:10 PM


To: Era= n Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assem= bly for response_type

 

 

On Thu, Feb 17, 20= 11 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is cookie exchange= d for an access token? Authorization grants are not meant to be useful by t= hemselves, only exchanged for an access token.

<= /div>

 

In this scenario, g= rants are exchanged for access tokens and/or cookies.

<= div>

 

 

Can you request only a cook= ie? Or is it always with either a token or code?

 

The = idea is that a grant can be exchanged for only a cookie in some cases.=

 

<= div>

 

EHL=

 =

 

 

From: = Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, = 2011 4:50 PM


To: Eran Hamm= er-Lahav
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly fo= r response_type

&nbs= p;

 

On Thu, Feb 17, 2011 at = 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I am not questioning the= use case, only how it fits within the OAuth framework.

 <= /o:p>

I don’= t understand how such an extension is expected to work with the existing gr= ant types. The response_type parameter is used to identify if the flow bein= g used is for an implicit grant or authorization code. Are you suggesting a= new grant type? Are you suggesting additional response parameters/headers = (in the case of a cookie) with both grant types?

 

It's a separate g= rant type that can be combined with either of the previous types.

 

 

 

Without full requirements we can’t design an = extension point. Asking to make this parameter a free text field is not hel= pful.

 =

The requirement is to allow another grant type,= cookie.

 

- cookie can be used separately or in combination with code or token.<= o:p>

 

- if= specified by itself or in combination with token, it's returned in the End= User Authorization Response, in analogy/in addition to the access_token

 

- If s= pecified in combination with code, it's returned in exchange for the code, = in analogy with the access_token

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent:= Thursday, February 17, 2011 4:22 PM

=
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG= ] Freedom of assembly for response_type

 

The use case is very straig= htforward:

 

- SAML provides session management. Facebook Connect provides session mana= gement. Both use cookies. These are authentication protocols but common usa= ges of both SAML and FB Connect imply authorization grants.

<= /div>

- OpenID2.0 does not provide session management. This has = proven to reduce the value of OpenID and make it unsuitable for many scenar= ios.

 

We would like federation protocols based on OAuth2 to be high-value. We wo= uld rather that they not be be hacks built on top of OAuth2. That means tha= t we need a first-order concept of cookie. A cookie can be refreshed indepe= ndent of the grant associated with it. A cookie is something the client hol= ds on to that identifies the user (i.e., it's for user-client authenticatio= n), but that the client is happy to outsource the management of security/cr= ypto/logged-in/logged-out state to the server.

 

The cookie is produced and retur= ned by the server, in combination with a grant, but it can be refreshed ind= ependently.

 

This is a solid and proven use case, and is of fundamental value to= many planned OAuth2 implementations.

=  

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hamm= er-Lahav <eran@= hueniverse.com> wrote:

You need to define how this proposed exten= sion works with the overall architecture.

 

This is not just an endpoi= nt people can bastardize (I am not suggesting *you* are) as they see= fit. It must fit with the overall model which is that this endpoint return= s either an access token or an authorization grant. An authorization grant = has to be exchanged for an access token.

 

If you are going to return = something else, instead or in addition to the token/code options, you need = to explain how it fits within the model. I am opposed to an open-ended exte= nsion point that is not consistent (and restricted) to the model we spent a= year to define and refine. The token+code response type was well defined (= it was the use case that wasn’t).

 

= To move this forward, you ne= ed to come up with specific requirements, not just making something extensi= ble without understanding what it is you are trying to extend. That’s= like the OAuth 1.0 utterly broken oauth_version parameter and the long con= fusion it created later on.

 

EHL

 

=

From: Breno [mailto:breno.demedeiros@gmail.com] <= o:p>

Sent: Thursday, February 17, 2011 1:58 PM<= br>To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Sub= ject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

<= div>

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com&g= t; wrote:

The best approach (at this point) is to leave the spec unchang= ed. However, another spec can update the definition of the response_type pa= rameter, including defining a registry or other methods for extensibility.<= /span>

=  

We can define this now, and it will not have any impact on existing = code, but I am leery of adding yet another extensibility vector without suf= ficient requirement. I also think that adding extension parameters can hand= le this cleanly.

 

The spec, as currently written does not imply tha= t the only possible values are 'code' and 'token'. The only concern is that= libraries may implement such restriction and make extending this behavior = different.

 

=

I do not think that extension parameters can handle this cleanly. In= particular, if the response_type is neither code nor token. 

 

=

 

EHL

 

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces= @ietf.org] On Behalf Of Breno
Sent: Thursday, February= 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of ass= embly for response_type

&= nbsp;

- Problem 1: Se= veral WG participants are working on deploying a federated signon protocol = based on OAuth2 (aka OpenIDConnect) and would like to return an additional = 'session cookie' together with the auth_token. Or sometimes return only a c= ookie as the result of authorization, since cookies will likely have shorte= r lifetimes than access tokens, for security and usability reasons, and req= uire more frequent refresh requirements. In any case, there aremultiple rea= sons for making the cookie separate from the auth_token, including both sec= urity and flexibility of deployment. However, there is no way to express th= is except adding an arbitrary extension parameter (to effectively express a= different response type).

 

- Problem 2: = Codification of code_and_token created controversy as there was not enough = traction among participants to put it in the core. However, it is entirely = possible that deployment experience will lead players to revisit this topic= .

 

<= span style=3D'font-size:10.0pt'> 

- Proposed solution:<= /p>

 

1. Allow response= _type to be a space separated list of arbitrary strings

 

E.g.:<= /o:p>

 

response_ty= pe=3Dcode

response_type=3Dtoken

response_type=3Dcode+token

<= /div>

response_type=3Dcookie

respo= nse_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar

 =

Wo= uld all be syntactically valid responses from the perspective of OAuth2.0 C= ore response_type values.

 

 

<= span style=3D'font-size:10.0pt'>2. Define behaviors in the core only for va= lues 'code' and 'token'. Allow extensions to define what do with 'code+toke= n' or with any other values or combinations of values. 


--
Breno de Medeiros

=




--
= Breno de Medeiros



--
Breno de Medeiros

=




--
= Breno de Medeiros

=




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F7P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Feb 17 22:49:16 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9D63A6D46 for ; Thu, 17 Feb 2011 22:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3QlT3NgDMY5 for ; Thu, 17 Feb 2011 22:49:06 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 57CE23A6CDA for ; Thu, 17 Feb 2011 22:49:06 -0800 (PST) Received: (qmail 5591 invoked from network); 18 Feb 2011 06:49:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 06:49:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Feb 2011 23:48:37 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 17 Feb 2011 23:48:28 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPMgNjY6t8x/fXTW+KpOY+JVac1wABcwvw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D42F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:49:16 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you send an example wire interaction? EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 10:07 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav > wrote: Ok. So you want to request a cookie from both endpoints: the authorization endp= oint and the token endpoint? How would that work? There is no response_type= on the token endpoint. There is no need to. The grant carries the information. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 9:30 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: So an implicit grant can produce just a cookie or both cookie and token, bu= t not code? Yes, cookies would be returned in the same context of access_tokens, either= as the result of an implicit grant or resulting from an explicit exchange = from a code-type grant. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 5:10 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can you s= end an example wire interaction?

=  

EHL

 

From: Breno [mailto:breno.demedeiros@gmai= l.com]
Sent: Thursday, February 17, 2011 10:07 PM
To: = Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Freedom of assembly for response_type

 

 

On Thu,= Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Ok.

=

 

So you want to= request a cookie from both endpoints: the authorization endpoint and the t= oken endpoint? How would that work? There is no response_type on the token = endpoint.

&= nbsp;

There is no need to. The gra= nt carries the information.

&= nbsp;

 

E= HL

 

From: Bre= no [mailto:= breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 9:30 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of= assembly for response_type

 

 

On Thu, Feb = 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= div>

So an implic= it grant can produce just a cookie or both cookie and token, but not code?<= /span>

 

Yes, cookies would be returned in the same context of access_token= s, either as the result of an implicit grant or resulting from an explicit = exchange from a code-type grant.

 

 

 <= o:p>

EHL

&nb= sp;

 

From: Bre= no [mailto:= breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 5:10 PM


To: Eran Hammer-= Lahav
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for r= esponse_type

 <= o:p>

 

On Thu, Feb 17, 2011 at 4:5= 6 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is cookie exchanged for a= n access token? Authorization grants are not meant to be useful by themselv= es, only exchanged for an access token.

 

In this scenario, grants a= re exchanged for access tokens and/or cookies.

 

 

Can you request only a cookie? O= r is it always with either a token or code?

 

The idea = is that a grant can be exchanged for only a cookie in some cases.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

EHL=

 

&nbs= p;

 

From: Bre= no [mailto:= breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 201= 1 4:50 PM


To: Eran Hammer-= Lahav
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for r= esponse_type

 <= o:p>

 

On Thu, Feb 17, 2011 at 4:4= 0 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I am not questioning the = use case, only how it fits within the OAuth framework.

 

I don’t= understand how such an extension is expected to work with the existing gra= nt types. The response_type parameter is used to identify if the flow being= used is for an implicit grant or authorization code. Are you suggesting a = new grant type? Are you suggesting additional response parameters/headers (= in the case of a cookie) with both grant types?

=

 

It's a separate gr= ant type that can be combined with either of the previous types.=

 

 

 

Without full requirements we can’t design an e= xtension point. Asking to make this parameter a free text field is not help= ful.

 <= /o:p>

The requirement is to allow another grant type, = cookie.

 

- cookie can be used separately or in combination with code or token.

 

- if = specified by itself or in combination with token, it's returned in the End = User Authorization Response, in analogy/in addition to the access_token

 

- If sp= ecified in combination with code, it's returned in exchange for the code, i= n analogy with the access_token

 =

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent:= Thursday, February 17, 2011 4:22 PM

=
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG= ] Freedom of assembly for response_type

 

The use case is very straig= htforward:

 

- SAML provides session management. Facebook Connect provides session mana= gement. Both use cookies. These are authentication protocols but common usa= ges of both SAML and FB Connect imply authorization grants.

<= /div>

- OpenID2.0 does not provide session management. This has = proven to reduce the value of OpenID and make it unsuitable for many scenar= ios.

 

We would like federation protocols based on OAuth2 to be high-value. We wo= uld rather that they not be be hacks built on top of OAuth2. That means tha= t we need a first-order concept of cookie. A cookie can be refreshed indepe= ndent of the grant associated with it. A cookie is something the client hol= ds on to that identifies the user (i.e., it's for user-client authenticatio= n), but that the client is happy to outsource the management of security/cr= ypto/logged-in/logged-out state to the server.

 

The cookie is produced and retur= ned by the server, in combination with a grant, but it can be refreshed ind= ependently.

 

This is a solid and proven use case, and is of fundamental value to= many planned OAuth2 implementations.

=  

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hamm= er-Lahav <eran@= hueniverse.com> wrote:

You need to define how this proposed exten= sion works with the overall architecture.

 

This is not just an endpoi= nt people can bastardize (I am not suggesting *you* are) as they see= fit. It must fit with the overall model which is that this endpoint return= s either an access token or an authorization grant. An authorization grant = has to be exchanged for an access token.

 

If you are going to return = something else, instead or in addition to the token/code options, you need = to explain how it fits within the model. I am opposed to an open-ended exte= nsion point that is not consistent (and restricted) to the model we spent a= year to define and refine. The token+code response type was well defined (= it was the use case that wasn’t).

 

= To move this forward, you ne= ed to come up with specific requirements, not just making something extensi= ble without understanding what it is you are trying to extend. That’s= like the OAuth 1.0 utterly broken oauth_version parameter and the long con= fusion it created later on.

 

EHL

 

=

From: Breno [mailto:breno.demedeiros@gmail.com] <= o:p>

Sent: Thursday, February 17, 2011 1:58 PM<= br>To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Sub= ject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

<= div>

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com&g= t; wrote:

The best approach (at this point) is to leave the spec unchang= ed. However, another spec can update the definition of the response_type pa= rameter, including defining a registry or other methods for extensibility.<= /span>

=  

We can define this now, and it will not have any impact on existing = code, but I am leery of adding yet another extensibility vector without suf= ficient requirement. I also think that adding extension parameters can hand= le this cleanly.

 

The spec, as currently written does not imply tha= t the only possible values are 'code' and 'token'. The only concern is that= libraries may implement such restriction and make extending this behavior = different.

 

=

I do not think that extension parameters can handle this cleanly. In= particular, if the response_type is neither code nor token. 

 

=

 

EHL

 

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces= @ietf.org] On Behalf Of Breno
Sent: Thursday, February= 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of ass= embly for response_type

&= nbsp;

- Problem 1: Se= veral WG participants are working on deploying a federated signon protocol = based on OAuth2 (aka OpenIDConnect) and would like to return an additional = 'session cookie' together with the auth_token. Or sometimes return only a c= ookie as the result of authorization, since cookies will likely have shorte= r lifetimes than access tokens, for security and usability reasons, and req= uire more frequent refresh requirements. In any case, there aremultiple rea= sons for making the cookie separate from the auth_token, including both sec= urity and flexibility of deployment. However, there is no way to express th= is except adding an arbitrary extension parameter (to effectively express a= different response type).

 

- Problem 2: = Codification of code_and_token created controversy as there was not enough = traction among participants to put it in the core. However, it is entirely = possible that deployment experience will lead players to revisit this topic= .

 

<= span style=3D'font-size:10.0pt'> 

- Proposed solution:<= /p>

 

1. Allow response= _type to be a space separated list of arbitrary strings

 

E.g.:<= /o:p>

 

response_ty= pe=3Dcode

response_type=3Dtoken

response_type=3Dcode+token

<= /div>

response_type=3Dcookie

respo= nse_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar

 =

Wo= uld all be syntactically valid responses from the perspective of OAuth2.0 C= ore response_type values.

 

 

<= span style=3D'font-size:10.0pt'>2. Define behaviors in the core only for va= lues 'code' and 'token'. Allow extensions to define what do with 'code+toke= n' or with any other values or combinations of values. 


--
Breno de Medeiros

=




--
= Breno de Medeiros



--
Breno de Medeiros

=




--
= Breno de Medeiros

=




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D42F8P3PW5EX1MB01E_-- From mark.mcgloin@ie.ibm.com Fri Feb 18 03:49:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F45A3A6DB6; Fri, 18 Feb 2011 03:49:30 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUHMOzQgm-vW; Fri, 18 Feb 2011 03:49:28 -0800 (PST) Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by core3.amsl.com (Postfix) with ESMTP id 734513A6DCE; Fri, 18 Feb 2011 03:49:28 -0800 (PST) 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 p1IBo0Jt009161; Fri, 18 Feb 2011 11:50:00 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 p1IBo7vJ1396762; Fri, 18 Feb 2011 11:50:07 GMT 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 p1IBnxB3016397; Fri, 18 Feb 2011 11:50:00 GMT 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 p1IBnxNx016394; Fri, 18 Feb 2011 11:49:59 GMT In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-KeepSent: EFAF96E1:1837BBD4-8025783B:0040108E; type=4; name=$KeepSent To: Marius Scurtescu X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Fri, 18 Feb 2011 11:49:24 +0000 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 18/02/2011 11:49:24 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 11:49:30 -0000 Marius Isn't the risk of the refresh token leaking the same as the risk of the access token leaking, i.e. why not provide both? IMO, the refresh token just provides a server side mechanism for revoking access, where resource servers are distributed, through having short lived access tokens Of course, the refresh access token flow currently requires a secret so would need to be changed or alternative flow introduced. Will wait for details of how auth code flow can be used Mark e-mail: mark.mcgloin@ie.ibm.com oauth-bounces@ietf.org wrote on 16/02/2011 21:38:45: > Marius Scurtescu > Sent by: oauth-bounces@ietf.org > > 16/02/2011 21:38 > > To > > Eran Hammer-Lahav > > cc > > OAuth WG > > Subject > > Re: [OAUTH-WG] Draft -12 feedback deadline > > On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > wrote: > > The reason why we don't return a refresh token in the implicit > grant is exactly because there is no client authentication... > > Not sure that's the main reason. AFAIK it is because the response is > sent through the user-agent and it could leak. > > > > These are all well-balanced flows with specific security > properties. If you need something else, even if it is just a tweak, > it must be considered a different flow. That doesn't mean you need > to register a new grant type, just that you are dealing with > different implementation details unique to your server. > > The Authorization Code flow, with no client secret, is perfectly fine > for Native Apps IMO. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Fri Feb 18 04:33:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66DE3A6DCB for ; Fri, 18 Feb 2011 04:33:52 -0800 (PST) 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=[AWL=-0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9FNuDwpJK34 for ; Fri, 18 Feb 2011 04:33:52 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D61533A6DA9 for ; Fri, 18 Feb 2011 04:33:51 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1ICYJR5028941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Feb 2011 13:34:19 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1ICYIRb006983 for ; Fri, 18 Feb 2011 13:34:19 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 13:34:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCF68.20FB06E5" Date: Fri, 18 Feb 2011 14:34:03 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4503D60FB7@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Oauth Security Draft? thread-index: AcvPaCB0DItVyE0yREeV1e2lxPozbw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Feb 2011 12:34:04.0808 (UTC) FILETIME=[210A9080:01CBCF68] Subject: [OAUTH-WG] Oauth Security Draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 12:33:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCF68.20FB06E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thorsten,=20 Hi all,=20 I am wondering what the status of the security draft is. The group is eagerly waiting for it. I fear that when it comes out it will be far too late and it will contain a lot of material the authors may feel comfortable but the rest of the group not necessarily. Instead of trying to make it perfect it is better to present something to the group so that we can have a discussion ASAP. Ciao Hannes ------_=_NextPart_001_01CBCF68.20FB06E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oauth Security Draft?

Hi Thorsten,
Hi all,

I am  wondering what the status of = the security draft is. The group is eagerly waiting for it. I fear that = when it comes out it will be far too late and it will contain a lot of = material the authors may feel comfortable but the rest of the group not = necessarily.

Instead of trying to make it perfect it = is better to present something to the group so that we can have a = discussion ASAP.

Ciao
Hannes

------_=_NextPart_001_01CBCF68.20FB06E5-- From paul.madsen@gmail.com Fri Feb 18 07:18:12 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745683A6F16 for ; Fri, 18 Feb 2011 07:18:12 -0800 (PST) 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_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvH7BCmVuSX0 for ; Fri, 18 Feb 2011 07:18:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9FA673A6F92 for ; Fri, 18 Feb 2011 07:18:10 -0800 (PST) Received: by iym1 with SMTP id 1so3868274iym.31 for ; Fri, 18 Feb 2011 07:18:44 -0800 (PST) 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 :cc:subject:references:in-reply-to:content-type; bh=WZ40ab3yGYsyjOQEOGtsKHNf5uGzSBEOxrCJDEnkBBg=; b=CCEkml4P6d7SDuQEXBVM+ZksBrR6GAnLvWKfbZA2qtE24s2KtQekvmqSQDAkMF/sQG wxlZtzQWrgVoupAgTmJMmfxXShcVWj6+O76zhuF1zIjDruhP2MH8Eu6iNkrkndIHzLhc RABykXVTjgVbjmph7vtONtT5gbhYxxG/Asofk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=Ru9pENV9q8mm3dadWesqNYDO4YpCUUHP9e/9ayCcjqw1KFzS2ynpxnMfsGlRKHGINg UPk8AVCE9VzOcovQkcEVI7grKZU1g3DzRoJ2Bzd/LZZkYuNnNg8w/UQlWCyULwzcFf3M EY6KJ/ecLB+9diV/p+So0rQIswfcA/UC6JHpA= Received: by 10.42.218.136 with SMTP id hq8mr1003640icb.379.1298042280923; Fri, 18 Feb 2011 07:18:00 -0800 (PST) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id d21sm1860043ibg.9.2011.02.18.07.17.58 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 07:17:59 -0800 (PST) Message-ID: <4D5E8DA6.8000409@gmail.com> Date: Fri, 18 Feb 2011 10:17:58 -0500 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Breno References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030909090504040404060404" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 15:18:12 -0000 This is a multi-part message in MIME format. --------------030909090504040404060404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Breno, why are you using 'cookie' in this context? SAML's 'session management' (I assume you are referring to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session index) Is it the session index that you are referring to as a cookie? Of course, both IdPs and SPs typically use cookies for their own local state, but this is independent of SAML. The only application of cookies in SAML are for discovery (arguably deployed even less than the above SLO). I confess I dont know how FB Connect does SLO thanks paul On 2/17/11 7:22 PM, Breno wrote: > The use case is very straightforward: > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but > common usages of both SAML and FB Connect imply authorization grants. > - OpenID2.0 does not provide session management. This has proven to > reduce the value of OpenID and make it unsuitable for many scenarios. > > We would like federation protocols based on OAuth2 to be high-value. > We would rather that they not be be hacks built on top of OAuth2. That > means that we need a first-order concept of cookie. A cookie can be > refreshed independent of the grant associated with it. A cookie is > something the client holds on to that identifies the user (i.e., it's > for user-client authentication), but that the client is happy to > outsource the management of security/crypto/logged-in/logged-out state > to the server. > > The cookie is produced and returned by the server, in combination with > a grant, but it can be refreshed independently. > > This is a solid and proven use case, and is of fundamental value to > many planned OAuth2 implementations. > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > > wrote: > > You need to define how this proposed extension works with the > overall architecture. > > This is not just an endpoint people can bastardize (I am not > suggesting **you** are) as they see fit. It must fit with the > overall model which is that this endpoint returns either an access > token or an authorization grant. An authorization grant has to be > exchanged for an access token. > > If you are going to return something else, instead or in addition > to the token/code options, you need to explain how it fits within > the model. I am opposed to an open-ended extension point that is > not consistent (and restricted) to the model we spent a year to > define and refine. The token+code response type was well defined > (it was the use case that wasn’t). > > To move this forward, you need to come up with specific > requirements, not just making something extensible without > understanding what it is you are trying to extend. That’s like the > OAuth 1.0 utterly broken oauth_version parameter and the long > confusion it created later on. > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > > wrote: > > The best approach (at this point) is to leave the spec unchanged. > However, another spec can update the definition of the > response_type parameter, including defining a registry or other > methods for extensibility. > > We can define this now, and it will not have any impact on > existing code, but I am leery of adding yet another extensibility > vector without sufficient requirement. I also think that adding > extension parameters can handle this cleanly. > > The spec, as currently written does not imply that the only > possible values are 'code' and 'token'. The only concern is that > libraries may implement such restriction and make extending this > behavior different. > > I do not think that extension parameters can handle this cleanly. > In particular, if the response_type is neither code nor token. > > EHL > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > - Problem 1: Several WG participants are working on deploying > a federated signon protocol based on OAuth2 (aka > OpenIDConnect) and would like to return an additional 'session > cookie' together with the auth_token. Or sometimes return only > a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security > and usability reasons, and require more frequent refresh > requirements. In any case, there aremultiple reasons for > making the cookie separate from the auth_token, including both > security and flexibility of deployment. However, there is no > way to express this except adding an arbitrary extension > parameter (to effectively express a different response type). > > - Problem 2: Codification of code_and_token created > controversy as there was not enough traction among > participants to put it in the core. However, it is entirely > possible that deployment experience will lead players to > revisit this topic. > > - Proposed solution: > > 1. Allow response_type to be a space separated list of > arbitrary strings > > E.g.: > > response_type=code > > response_type=token > > response_type=code+token > > response_type=cookie > > response_type=code+cookie > > response_type=token+cookie > > response_type=foo+bar > > Would all be syntactically valid responses from the > perspective of OAuth2.0 Core response_type values. > > 2. Define behaviors in the core only for values 'code' and > 'token'. Allow extensions to define what do with 'code+token' > or with any other values or combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030909090504040404060404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Breno, why are you using 'cookie' in this context?

SAML's  'session management' (I assume you are referring to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session index)

Is it the session index that you are referring to as a cookie?

Of course, both IdPs and SPs typically use cookies for their own local state, but this is independent of SAML. The only application of cookies in SAML are for discovery (arguably deployed even less than the above SLO).

I confess I dont know how FB Connect does SLO

thanks

paul

On 2/17/11 7:22 PM, Breno wrote:
The use case is very straightforward:

- SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants.
- OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios.

We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server.

The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently.

This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations.

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall architecture.

 

This is not just an endpoint people can bastardize (I am not suggesting *you* are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token.

 

If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t).

 

To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]

Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility.

 

We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly.

 

The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different.

 

I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. 

 

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of assembly for response_type

 

- Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type).

 

- Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic.

 

 

- Proposed solution:

 

1. Allow response_type to be a space separated list of arbitrary strings

 

E.g.:

 

response_type=code

response_type=token

response_type=code+token

response_type=cookie

response_type=code+cookie

response_type=token+cookie

response_type=foo+bar

 

Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values.

 

 

2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. 


--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030909090504040404060404-- From mscurtescu@google.com Fri Feb 18 09:40:10 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCFA3A6F5F for ; Fri, 18 Feb 2011 09:40:10 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7K1d0UdVDRW for ; Fri, 18 Feb 2011 09:40:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3A9823A6E69 for ; Fri, 18 Feb 2011 09:40:09 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p1IHeg4S011032 for ; Fri, 18 Feb 2011 09:40:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298050842; bh=cJEHvVJaRHiKR28lfzB4e14t+3k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dr2voTntB3nALCs4a6QN+WD7bAfNtfB1Xs8jg4gIDiNbwYcpN/PBt2lTpNInTnZSg kmf2HReJyJ1i05isM7e6w== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by hpaq12.eem.corp.google.com with ESMTP id p1IHeAXD030899 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 18 Feb 2011 09:40:41 -0800 Received: by gxk27 with SMTP id 27so1729064gxk.31 for ; Fri, 18 Feb 2011 09:40:41 -0800 (PST) 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=wO84oJ37m5iXqyv3QYBkIrLY3+W2Bg9+EGsVjfRi76c=; b=Vaouc/mk8ESPRVT5c6J7Pqi8cm3B2FktVYcfkVyxn08O48wGPHinuSs4NLDrjRyJDv wAUMynzle+so1OmBYgng== 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=wK/d4+usnErrDWxr4Hf3CVtWiED/6mMSjKZhX+URty651NgbbiEiGtxn4c4ALRDqYq omTTteuj1XDxuAj1iavw== Received: by 10.100.33.16 with SMTP id g16mr463396ang.96.1298050841114; Fri, 18 Feb 2011 09:40:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.12.3 with HTTP; Fri, 18 Feb 2011 09:40:21 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 18 Feb 2011 09:40:21 -0800 Message-ID: To: Mark Mcgloin Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:40:11 -0000 On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin wrote: > Marius > > Isn't the risk of the refresh token leaking the same as the risk of the > access token leaking, i.e. why not provide both? Sure, but refresh tokens never die. > IMO, the refresh token > just provides a server side mechanism for revoking access, where resource > servers are distributed, through having short lived access tokens > > Of course, the refresh access token flow currently requires a secret so > would need to be changed or alternative flow introduced. Will wait for > details of how auth code flow can be used The flow is not changing. For native apps the client secret can either be declared optional, or a "well known secret" can be issued for native apps. The authorization server can also insist that each native app has a unique secret and it must guard it, that may or may not make sense. Marius From hannes.tschofenig@gmx.net Fri Feb 18 10:16:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F7A3A6D6A for ; Fri, 18 Feb 2011 10:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFzQhrDw+rXP for ; Fri, 18 Feb 2011 10:16:43 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6BFA23A6D36 for ; Fri, 18 Feb 2011 10:16:43 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2011 18:17:16 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp001) with SMTP; 18 Feb 2011 19:17:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/aKCQFe1TamKQzUu/a99wohtXYUZumBG/uC2MCYp 43yg3fvEtevb6D From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 20:17:14 +0200 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Client Assertion Credentials (again) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:16:45 -0000 Hi all,=20 I asked for feedback regarding the removal of the client assertion = credentials earlier this month, see=20 http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html Unfortunately, the feedback did not lead to any new insight other than = there are three groups of people:=20 1) Those who want the functionality removed from the draft 2) Those who want it to be included.=20 3) Those who want something different in the document (namely a stronger = version).=20 These three groups are equally large (based on the feedback). I have attached the text from version -11 of the draft.=20 So, my suggestion to the group therefore is for those who are interested = in this functionality in one way or the other to provide text that the = group can agree with in time before we submit the document to the IESG = (1).=20 If that does not happen the client assertion credential will have to be = developed as a separate document (if there is enough energy and interest = in the group).=20 A note regarding (1): Currently, the security consideration section is = missing since otherwise the document is ready for a working group last = call (in my view). So, once that is there and agreed I will start a working group last = call.=20 Ciao Hannes ----- 3.2. Client Assertion Credentials The client assertion credentials are used in cases where a password (clear-text shared symmetric secret) is unsuitable or does not provide sufficient security for client authentication. In such cases it is common to use other mechanisms such as HMAC or digital signatures that do not require sending clear-text secrets. The client assertion credentials provide an extensible mechanism to use an assertion format supported by the authorization server for authentication the client. Using assertions requires the client to obtain an assertion (such as a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer or to self-issue an assertion. The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification. When using a client assertion, the client includes the following parameters: client_assertion_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example, the client sends the following access token request using a SAML 2.0 assertion to authenticate itself (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=3Dauthorization_code&code=3Di1WsRn1uB1& client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& client_assertion_type=3D urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb When obtaining an access token using a client assertion together with an authorization code (as described in Section 5.1.1), a mechanism = is needed to map between the value of "client_id" parameter used to obtain the authorization code, and the client assertion. Such mechanism is beyond the out of scope for this specification, but MUST be specified for any client assertion type used in combination with an authorization code. The authorization server MUST reject access token requests using client assertion credentials that do not contain HMAC or signed values that: o State the assertion was specifically issued to be consumed by the receiving endpoint (typically via an audience or recipient value containing the receiving endpoint's identifier). o Identify the entity that issued the assertion (typically via an issuer value). o Identify when the assertion expires as an absolute time (typically via an expiration value containing a UTC date/time value). The authorization server MUST reject expired assertions. From phil.hunt@oracle.com Fri Feb 18 10:22:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974333A6DA0 for ; Fri, 18 Feb 2011 10:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evtagzyzkzuu for ; Fri, 18 Feb 2011 10:22:41 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5A4633A6DF7 for ; Fri, 18 Feb 2011 10:22:41 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1IINAI9022294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Feb 2011 18:23:12 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1IIMw4V000841; Fri, 18 Feb 2011 18:22:59 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 1019114001298053330; Fri, 18 Feb 2011 10:22:10 -0800 Received: from [192.168.1.12] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Feb 2011 10:22:09 -0800 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: text/plain; charset=us-ascii Message-Id: <7568C117-0DD9-4A96-A186-6ED9D2D40DC3@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Fri, 18 Feb 2011 10:22:05 -0800 To: Hannes Tschofenig X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D5EB90E.004A:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Client Assertion Credentials (again) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:22:42 -0000 You can put in client_assertion but also leave the 'other' credential option= there as well=20 Phil Sent from my phone.=20 On 2011-02-18, at 10:17, Hannes Tschofenig wrote= : > Hi all,=20 >=20 > I asked for feedback regarding the removal of the client assertion credent= ials earlier this month, see=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html >=20 > Unfortunately, the feedback did not lead to any new insight other than the= re are three groups of people:=20 > 1) Those who want the functionality removed from the draft > 2) Those who want it to be included.=20 > 3) Those who want something different in the document (namely a stronger v= ersion).=20 >=20 > These three groups are equally large (based on the feedback). >=20 > I have attached the text from version -11 of the draft.=20 >=20 > So, my suggestion to the group therefore is for those who are interested i= n this functionality in one way or the other to provide text that the group c= an agree with in time before we submit the document to the IESG (1).=20 > If that does not happen the client assertion credential will have to be de= veloped as a separate document (if there is enough energy and interest in th= e group).=20 >=20 > A note regarding (1): Currently, the security consideration section is mis= sing since otherwise the document is ready for a working group last call (in= my view). > So, once that is there and agreed I will start a working group last call.=20= >=20 > Ciao > Hannes >=20 > ----- >=20 > 3.2. Client Assertion Credentials >=20 > The client assertion credentials are used in cases where a password > (clear-text shared symmetric secret) is unsuitable or does not > provide sufficient security for client authentication. In such cases > it is common to use other mechanisms such as HMAC or digital > signatures that do not require sending clear-text secrets. The > client assertion credentials provide an extensible mechanism to use > an assertion format supported by the authorization server for > authentication the client. >=20 > Using assertions requires the client to obtain an assertion (such as > a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer > or to self-issue an assertion. The assertion format, the process by > which the assertion is obtained, and the method of validating the > assertion are defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. >=20 > When using a client assertion, the client includes the following > parameters: >=20 > client_assertion_type REQUIRED. The format of the assertion as > defined by the authorization server. The value MUST be an > absolute URI. >=20 > client_assertion REQUIRED. The client assertion. >=20 > For example, the client sends the following access token request > using a SAML 2.0 assertion to authenticate itself (line breaks are > for display purposes only): >=20 >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type=3D > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > When obtaining an access token using a client assertion together with > an authorization code (as described in Section 5.1.1), a mechanism is > needed to map between the value of "client_id" parameter used to > obtain the authorization code, and the client assertion. Such > mechanism is beyond the out of scope for this specification, but MUST > be specified for any client assertion type used in combination with > an authorization code. >=20 > The authorization server MUST reject access token requests using > client assertion credentials that do not contain HMAC or signed > values that: >=20 > o State the assertion was specifically issued to be consumed by the > receiving endpoint (typically via an audience or recipient value > containing the receiving endpoint's identifier). >=20 > o Identify the entity that issued the assertion (typically via an > issuer value). >=20 > o Identify when the assertion expires as an absolute time (typically > via an expiration value containing a UTC date/time value). The > authorization server MUST reject expired assertions. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Feb 18 11:44:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872923A6FC2 for ; Fri, 18 Feb 2011 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPIOaceUIZKD for ; Fri, 18 Feb 2011 11:44:25 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6E70D3A6FC5 for ; Fri, 18 Feb 2011 11:44:25 -0800 (PST) Received: (qmail 24495 invoked from network); 18 Feb 2011 19:44:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 19:44:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 18 Feb 2011 12:44:45 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , OAuth WG Date: Fri, 18 Feb 2011 12:44:36 -0700 Thread-Topic: [OAUTH-WG] Client Assertion Credentials (again) Thread-Index: AcvPmBhvo2wnGzp5R4y/6RHRQNnmRgADBzgg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4452@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 Subject: Re: [OAUTH-WG] Client Assertion Credentials (again) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:44:26 -0000 I support this approach. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Friday, February 18, 2011 10:17 AM > To: OAuth WG > Subject: [OAUTH-WG] Client Assertion Credentials (again) >=20 > Hi all, >=20 > I asked for feedback regarding the removal of the client assertion creden= tials > earlier this month, see http://www.ietf.org/mail- > archive/web/oauth/current/msg05261.html >=20 > Unfortunately, the feedback did not lead to any new insight other than th= ere > are three groups of people: > 1) Those who want the functionality removed from the draft > 2) Those who want it to be included. > 3) Those who want something different in the document (namely a stronger > version). >=20 > These three groups are equally large (based on the feedback). >=20 > I have attached the text from version -11 of the draft. >=20 > So, my suggestion to the group therefore is for those who are interested = in > this functionality in one way or the other to provide text that the group= can > agree with in time before we submit the document to the IESG (1). > If that does not happen the client assertion credential will have to be > developed as a separate document (if there is enough energy and interest = in > the group). >=20 > A note regarding (1): Currently, the security consideration section is mi= ssing > since otherwise the document is ready for a working group last call (in m= y > view). > So, once that is there and agreed I will start a working group last call. >=20 > Ciao > Hannes >=20 > ----- >=20 > 3.2. Client Assertion Credentials >=20 > The client assertion credentials are used in cases where a password > (clear-text shared symmetric secret) is unsuitable or does not > provide sufficient security for client authentication. In such cases > it is common to use other mechanisms such as HMAC or digital > signatures that do not require sending clear-text secrets. The > client assertion credentials provide an extensible mechanism to use > an assertion format supported by the authorization server for > authentication the client. >=20 > Using assertions requires the client to obtain an assertion (such as > a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer > or to self-issue an assertion. The assertion format, the process by > which the assertion is obtained, and the method of validating the > assertion are defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. >=20 > When using a client assertion, the client includes the following > parameters: >=20 > client_assertion_type REQUIRED. The format of the assertion as > defined by the authorization server. The value MUST be an > absolute URI. >=20 > client_assertion REQUIRED. The client assertion. >=20 > For example, the client sends the following access token request > using a SAML 2.0 assertion to authenticate itself (line breaks are > for display purposes only): >=20 >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type=3D > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > When obtaining an access token using a client assertion together with > an authorization code (as described in Section 5.1.1), a mechanism is > needed to map between the value of "client_id" parameter used to > obtain the authorization code, and the client assertion. Such > mechanism is beyond the out of scope for this specification, but MUST > be specified for any client assertion type used in combination with > an authorization code. >=20 > The authorization server MUST reject access token requests using > client assertion credentials that do not contain HMAC or signed > values that: >=20 > o State the assertion was specifically issued to be consumed by the > receiving endpoint (typically via an audience or recipient value > containing the receiving endpoint's identifier). >=20 > o Identify the entity that issued the assertion (typically via an > issuer value). >=20 > o Identify when the assertion expires as an absolute time (typically > via an expiration value containing a UTC date/time value). The > authorization server MUST reject expired assertions. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Feb 18 11:45:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E123A6FC3 for ; Fri, 18 Feb 2011 11:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cao5ptJ2+usZ for ; Fri, 18 Feb 2011 11:45:17 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 14C6A3A6FBF for ; Fri, 18 Feb 2011 11:45:17 -0800 (PST) Received: (qmail 25929 invoked from network); 18 Feb 2011 19:45:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Feb 2011 19:45:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 18 Feb 2011 12:45:37 -0700 From: Eran Hammer-Lahav To: Phillip Hunt , Hannes Tschofenig Date: Fri, 18 Feb 2011 12:45:28 -0700 Thread-Topic: [OAUTH-WG] Client Assertion Credentials (again) Thread-Index: AcvPmOu/m0KrB0P8Q0SWySMm8Z1vewAC2mcA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4454@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7568C117-0DD9-4A96-A186-6ED9D2D40DC3@oracle.com> In-Reply-To: <7568C117-0DD9-4A96-A186-6ED9D2D40DC3@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] Client Assertion Credentials (again) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:45:18 -0000 By #3 Hannes meant defining another option in the spec, not just allowing i= t to be defined elsewhere. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phillip Hunt > Sent: Friday, February 18, 2011 10:22 AM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Client Assertion Credentials (again) >=20 > You can put in client_assertion but also leave the 'other' credential opt= ion > there as well >=20 > Phil >=20 > Sent from my phone. >=20 > On 2011-02-18, at 10:17, Hannes Tschofenig > wrote: >=20 > > Hi all, > > > > I asked for feedback regarding the removal of the client assertion > > credentials earlier this month, see > > http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html > > > > Unfortunately, the feedback did not lead to any new insight other than > there are three groups of people: > > 1) Those who want the functionality removed from the draft > > 2) Those who want it to be included. > > 3) Those who want something different in the document (namely a > stronger version). > > > > These three groups are equally large (based on the feedback). > > > > I have attached the text from version -11 of the draft. > > > > So, my suggestion to the group therefore is for those who are intereste= d in > this functionality in one way or the other to provide text that the group= can > agree with in time before we submit the document to the IESG (1). > > If that does not happen the client assertion credential will have to be > developed as a separate document (if there is enough energy and interest = in > the group). > > > > A note regarding (1): Currently, the security consideration section is = missing > since otherwise the document is ready for a working group last call (in m= y > view). > > So, once that is there and agreed I will start a working group last cal= l. > > > > Ciao > > Hannes > > > > ----- > > > > 3.2. Client Assertion Credentials > > > > The client assertion credentials are used in cases where a password > > (clear-text shared symmetric secret) is unsuitable or does not > > provide sufficient security for client authentication. In such cases > > it is common to use other mechanisms such as HMAC or digital > > signatures that do not require sending clear-text secrets. The > > client assertion credentials provide an extensible mechanism to use > > an assertion format supported by the authorization server for > > authentication the client. > > > > Using assertions requires the client to obtain an assertion (such as > > a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer > > or to self-issue an assertion. The assertion format, the process by > > which the assertion is obtained, and the method of validating the > > assertion are defined by the assertion issuer and the authorization > > server, and are beyond the scope of this specification. > > > > When using a client assertion, the client includes the following > > parameters: > > > > client_assertion_type REQUIRED. The format of the assertion as > > defined by the authorization server. The value MUST be an > > absolute URI. > > > > client_assertion REQUIRED. The client assertion. > > > > For example, the client sends the following access token request > > using a SAML 2.0 assertion to authenticate itself (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=3Dauthorization_code&code=3Di1WsRn1uB1& > > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > > client_assertion_type=3D > > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > > > > When obtaining an access token using a client assertion together with > > an authorization code (as described in Section 5.1.1), a mechanism i= s > > needed to map between the value of "client_id" parameter used to > > obtain the authorization code, and the client assertion. Such > > mechanism is beyond the out of scope for this specification, but MUST > > be specified for any client assertion type used in combination with > > an authorization code. > > > > The authorization server MUST reject access token requests using > > client assertion credentials that do not contain HMAC or signed > > values that: > > > > o State the assertion was specifically issued to be consumed by the > > receiving endpoint (typically via an audience or recipient value > > containing the receiving endpoint's identifier). > > > > o Identify the entity that issued the assertion (typically via an > > issuer value). > > > > o Identify when the assertion expires as an absolute time (typically > > via an expiration value containing a UTC date/time value). The > > authorization server MUST reject expired assertions. > > > > > > > > > > > > > > > > _______________________________________________ > > 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 breno.demedeiros@gmail.com Fri Feb 18 13:52:29 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7793A6D21 for ; Fri, 18 Feb 2011 13:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfZhBnGwr+wp for ; Fri, 18 Feb 2011 13:52:25 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 173FC3A6AAE for ; Fri, 18 Feb 2011 13:52:24 -0800 (PST) Received: by iwl42 with SMTP id 42so848221iwl.31 for ; Fri, 18 Feb 2011 13:52:59 -0800 (PST) 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=/mi/Oi+petLG4ozbbzu0hLOBDP2rRFj7dNtNi0CR3m4=; b=bUejpeAPAei1wUH8qrXq+zlRDV2+u4Bsk2jBMipw34jPVNBKJP3KSvcOEWBWKe3D23 1enGDYzTUJ1Fw4mLsXVRt/G036UROtEpOqXfp+yTzZXbHeNBZYmZHZX1/XqOTmZWnMth HXr5Qr5KWgEaNbAkelaruUQEuVvEjhCJDXlSk= 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=ajL4/JiQsjJCXX/9Y5N/LTzFGi3AjIphUsUu+5pWnpK6th+So6KCeFMBP2UiUASTeQ qY9V8++z8/FM6xOLKCOttPXZEaKXvhx1E6Nco93/FaxwBPQj15Xsb5MlZZ+taCUgH1Mw TXqsRMxfbsdtGRNhdBgA/Xfsr6eeMzxL28XTc= MIME-Version: 1.0 Received: by 10.42.178.134 with SMTP id bm6mr1430227icb.494.1298065979157; Fri, 18 Feb 2011 13:52:59 -0800 (PST) Received: by 10.231.158.139 with HTTP; Fri, 18 Feb 2011 13:52:59 -0800 (PST) In-Reply-To: <4D5E8DA6.8000409@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D5E8DA6.8000409@gmail.com> Date: Fri, 18 Feb 2011 13:52:59 -0800 Message-ID: From: Breno To: Paul Madsen Content-Type: multipart/alternative; boundary=90e6ba6e8d9c952e08049c958908 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 21:52:29 -0000 --90e6ba6e8d9c952e08049c958908 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Feb 18, 2011 at 7:17 AM, Paul Madsen wrote: > Breno, why are you using 'cookie' in this context? > > SAML's 'session management' (I assume you are referring to SLO?) > functionality does not rely on browser cookies, but rather on the > participants sending a LogoutRequest carrying an identifier for the Subje= ct > in question (and possibly a session index) > > Is it the session index that you are referring to as a cookie? > Yes. As far as I understand it, it is often the case that websso deployment= s based on SAML commonly use the SAML assertion for the session id as a browser cookie in practice. Facebook Connect has an authenticated user_id blob that can be used as a cookie (and the FB-provided js libraries certainly do so). I agree that 'cookie' is possibly a bad name (there's not a necessity to us= e it as a browser cookie in the proposed OpenIDConnect interaction either, though it will likely be used as such). However, names such as 'token', 'bearer', are already bound to other meanings in the OAuth2 spec. Another name that I have referred to this in the past is 'session_token'. > > Of course, both IdPs and SPs typically use cookies for their own local > state, but this is independent of SAML. The only application of cookies i= n > SAML are for discovery (arguably deployed even less than the above SLO). > See above. > > I confess I dont know how FB Connect does SLO > > thanks > > paul > > > On 2/17/11 7:22 PM, Breno wrote: > > The use case is very straightforward: > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav w= rote: > >> You need to define how this proposed extension works with the overall >> architecture. >> >> >> >> This is not just an endpoint people can bastardize (I am not suggesting = * >> *you** are) as they see fit. It must fit with the overall model which is >> that this endpoint returns either an access token or an authorization gr= ant. >> An authorization grant has to be exchanged for an access token. >> >> >> >> If you are going to return something else, instead or in addition to the >> token/code options, you need to explain how it fits within the model. I = am >> opposed to an open-ended extension point that is not consistent (and >> restricted) to the model we spent a year to define and refine. The >> token+code response type was well defined (it was the use case that wasn= =92t). >> >> >> >> To move this forward, you need to come up with specific requirements, no= t >> just making something extensible without understanding what it is you ar= e >> trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versi= on >> parameter and the long confusion it created later on. >> >> >> >> EHL >> >> >> >> *From:* Breno [mailto:breno.demedeiros@gmail.com] >> *Sent:* Thursday, February 17, 2011 1:58 PM >> *To:* Eran Hammer-Lahav >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type >> >> >> >> >> >> On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav >> wrote: >> >> The best approach (at this point) is to leave the spec unchanged. Howeve= r, >> another spec can update the definition of the response_type parameter, >> including defining a registry or other methods for extensibility. >> >> >> >> We can define this now, and it will not have any impact on existing code= , >> but I am leery of adding yet another extensibility vector without suffic= ient >> requirement. I also think that adding extension parameters can handle th= is >> cleanly. >> >> >> >> The spec, as currently written does not imply that the only possible >> values are 'code' and 'token'. The only concern is that libraries may >> implement such restriction and make extending this behavior different. >> >> >> >> I do not think that extension parameters can handle this cleanly. In >> particular, if the response_type is neither code nor token. >> >> >> >> >> >> EHL >> >> >> >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behal= f >> Of *Breno >> *Sent:* Thursday, February 17, 2011 10:30 AM >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] Freedom of assembly for response_type >> >> >> >> - Problem 1: Several WG participants are working on deploying a federate= d >> signon protocol based on OAuth2 (aka OpenIDConnect) and would like to re= turn >> an additional 'session cookie' together with the auth_token. Or sometime= s >> return only a cookie as the result of authorization, since cookies will >> likely have shorter lifetimes than access tokens, for security and usabi= lity >> reasons, and require more frequent refresh requirements. In any case, th= ere >> aremultiple reasons for making the cookie separate from the auth_token, >> including both security and flexibility of deployment. However, there is= no >> way to express this except adding an arbitrary extension parameter (to >> effectively express a different response type). >> >> >> >> - Problem 2: Codification of code_and_token created controversy as there >> was not enough traction among participants to put it in the core. Howeve= r, >> it is entirely possible that deployment experience will lead players to >> revisit this topic. >> >> >> >> >> >> - Proposed solution: >> >> >> >> 1. Allow response_type to be a space separated list of arbitrary strings >> >> >> >> E.g.: >> >> >> >> response_type=3Dcode >> >> response_type=3Dtoken >> >> response_type=3Dcode+token >> >> response_type=3Dcookie >> >> response_type=3Dcode+cookie >> >> response_type=3Dtoken+cookie >> >> response_type=3Dfoo+bar >> >> >> >> Would all be syntactically valid responses from the perspective of >> OAuth2.0 Core response_type values. >> >> >> >> >> >> 2. Define behaviors in the core only for values 'code' and 'token'. Allo= w >> extensions to define what do with 'code+token' or with any other values = or >> combinations of values. >> >> >> -- >> Breno de Medeiros >> >> >> >> >> -- >> Breno de Medeiros >> > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > --=20 Breno de Medeiros --90e6ba6e8d9c952e08049c958908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 18, 2011 at 7:17 AM, Paul Ma= dsen <paul.ma= dsen@gmail.com> wrote:
=20 =20 =20
Breno, why are you using 'cookie' in this context?

SAML's=A0 'session management' (I assume you are referring = to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session index)

Is it the session index that you are referring to as a cookie?

Yes. As far as I understand it, it is oft= en the case that websso deployments based on SAML commonly use the SAML ass= ertion for the session id as a browser cookie in practice. Facebook Connect= has an authenticated user_id blob that can be used as a cookie (and the FB= -provided js libraries certainly do so).

I agree that 'cookie' is possibly a bad name (t= here's not a necessity to use it as a browser cookie in the proposed Op= enIDConnect interaction either, though it will likely be used as such). How= ever, names such as 'token', 'bearer', are already bound to= other meanings in the OAuth2 spec. Another name that I have referred to th= is in the past is 'session_token'.

=A0

Of course, both IdPs and SPs typically use cookies for their own local state, but this is independent of SAML. The only application of cookies in SAML are for discovery (arguably deployed even less than the above SLO).

See abo= ve.
=A0

I confess I dont know how FB Connect does SLO

thanks

paul


On 2/17/11 7:22 PM, Breno wrote:
The use case is very straightforward:

- SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants.
- OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios.

We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server.

The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently.

This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations.

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall architecture.

= =A0

This is not just an endpoint people can bastardize (I am not suggesting *you* are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@g= mail.com]

Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly.

=A0

The spec, as currently written does not imply that the only possible values are 'code' and 't= oken'. The only concern is that libraries may implement such restriction and make extending this behavior different.

=A0

I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together= with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type).<= /p>

=A0

- Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic.

=A0

=A0

- Proposed solution:

=A0

1. Allow response_type to be a space separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

response_type=3Dtoken

response_type=3Dcode+token

response_type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar

=A0

Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values.

=A0

=A0

2. Define behaviors in the core only for values 'code' and 'tok= en'. Allow extensions to define what do with 'code+token' or wit= h any other values or combinations of values.=A0<= /span>


--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros


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



--
Breno de Medeiros
--90e6ba6e8d9c952e08049c958908-- From breno.demedeiros@gmail.com Fri Feb 18 14:02:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5F33A6FB1 for ; Fri, 18 Feb 2011 14:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhTgFXbq2Gi1 for ; Fri, 18 Feb 2011 14:02:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4E7303A6ECB for ; Fri, 18 Feb 2011 14:02:49 -0800 (PST) Received: by iym1 with SMTP id 1so4253328iym.31 for ; Fri, 18 Feb 2011 14:03:23 -0800 (PST) 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=gSTCjp/2FX41qXNRdABx4wnhksaDQevP+GoUCWKhX8o=; b=XTwDV6BTZGJvvRVW/qKhZVEnfNd6MCM7lsibQ+w7H2X+tvDwptyj8PFQgALhsIweLm RBaYBpMYJIFw0tge+5vKSP0nQ4D1M5SPeTuGotAW3vW2vXkrnXIMX6KDQYjz7xUGkZ+2 Ci+/iUuzi5YPQYqip8frGyQayjZ0+Yn/1Kqtc= 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=f169qDiwCBrxYeItYVCqtZrUONoGpnsY0YBWliGq2Bi1Q4LyV/DuOdw7kAv6VYY0Ar iF3UN3W+1/6YeopcoyVWFYyyn7xi4l5WG1P+xhj2ZUm2j6/wXHnObZ9URN/ISAAvrykd yhPbf6H6TTdJxHTg14NF8lhfhHvSTWvmjd+sY= MIME-Version: 1.0 Received: by 10.42.178.134 with SMTP id bm6mr1440512icb.494.1298066603524; Fri, 18 Feb 2011 14:03:23 -0800 (PST) Received: by 10.231.158.139 with HTTP; Fri, 18 Feb 2011 14:03:23 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D42F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 18 Feb 2011 14:03:23 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba6e8d9ccc4341049c95ae03 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:02:51 -0000 --90e6ba6e8d9ccc4341049c95ae03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Example 1: OpenIDConnect End User Authorization Request for '&response_type=3Dtoken+cookie' OpenIDConnect End User Authorization Response '&access_token=3Dfoo&cookie=3Dbar' Example 2: OpenIDConnect End User Authorization Request for '&response_type=3Dcode+cookie' OpenIDConnect End User Authorization Response '&code=3Dfoo' OpenIDConnect outcome of grant redemption ... '[&refresh_token=3Dfoo]&access_token=3Dbar&cookie=3Dbaz' Example 3 (specific syntax still to be agreed upon): OpenIDConnect End User Cookie Refresh Request '&response_type=3Dcookie&cookie=3D... ' OpenIDConnect End User Cookie Refresh Response '&cookie=3Dfoo' Example 4 (specific syntax still in the work): OpenIDConnect End User Logout Request '&access_token=3Dbar' (to new endpoin= t) OpenIDConnect End User Logout Response '' On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav wr= ote: > Can you send an example wire interaction? > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 10:07 PM > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav > wrote: > > Ok. > > > > So you want to request a cookie from both endpoints: the authorization > endpoint and the token endpoint? How would that work? There is no > response_type on the token endpoint. > > > > There is no need to. The grant carries the information. > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 9:30 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: > > So an implicit grant can produce just a cookie or both cookie and token, > but not code? > > > > Yes, cookies would be returned in the same context of access_tokens, eith= er > as the result of an implicit grant or resulting from an explicit exchange > from a code-type grant. > > > > > > > > EHL > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 5:10 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: > > Is cookie exchanged for an access token? Authorization grants are not mea= nt > to be useful by themselves, only exchanged for an access token. > > > > In this scenario, grants are exchanged for access tokens and/or cookies. > > > > > > Can you request only a cookie? Or is it always with either a token or cod= e? > > > > The idea is that a grant can be exchanged for only a cookie in some cases= . > > > > > > EHL > > > > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:50 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: > > I am not questioning the use case, only how it fits within the OAuth > framework. > > > > I don=92t understand how such an extension is expected to work with the > existing grant types. The response_type parameter is used to identify if = the > flow being used is for an implicit grant or authorization code. Are you > suggesting a new grant type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both grant types? > > > > It's a separate grant type that can be combined with either of the previo= us > types. > > > > > > > > Without full requirements we can=92t design an extension point. Asking to > make this parameter a free text field is not helpful. > > > > The requirement is to allow another grant type, cookie. > > > > - cookie can be used separately or in combination with code or token. > > > > - if specified by itself or in combination with token, it's returned in t= he > End User Authorization Response, in analogy/in addition to the access_tok= en > > > > - If specified in combination with code, it's returned in exchange for th= e > code, in analogy with the access_token > > > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > The use case is very straightforward: > > > > - SAML provides session management. Facebook Connect provides session > management. Both use cookies. These are authentication protocols but comm= on > usages of both SAML and FB Connect imply authorization grants. > > - OpenID2.0 does not provide session management. This has proven to reduc= e > the value of OpenID and make it unsuitable for many scenarios. > > > > We would like federation protocols based on OAuth2 to be high-value. We > would rather that they not be be hacks built on top of OAuth2. That means > that we need a first-order concept of cookie. A cookie can be refreshed > independent of the grant associated with it. A cookie is something the > client holds on to that identifies the user (i.e., it's for user-client > authentication), but that the client is happy to outsource the management= of > security/crypto/logged-in/logged-out state to the server. > > > > The cookie is produced and returned by the server, in combination with a > grant, but it can be refreshed independently. > > > > This is a solid and proven use case, and is of fundamental value to many > planned OAuth2 implementations. > > > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: > > You need to define how this proposed extension works with the overall > architecture. > > > > This is not just an endpoint people can bastardize (I am not suggesting *= * > you** are) as they see fit. It must fit with the overall model which is > that this endpoint returns either an access token or an authorization gra= nt. > An authorization grant has to be exchanged for an access token. > > > > If you are going to return something else, instead or in addition to the > token/code options, you need to explain how it fits within the model. I a= m > opposed to an open-ended extension point that is not consistent (and > restricted) to the model we spent a year to define and refine. The > token+code response type was well defined (it was the use case that wasn= =92t). > > > > To move this forward, you need to come up with specific requirements, not > just making something extensible without understanding what it is you are > trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n > parameter and the long confusion it created later on. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > > > > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: > > The best approach (at this point) is to leave the spec unchanged. However= , > another spec can update the definition of the response_type parameter, > including defining a registry or other methods for extensibility. > > > > We can define this now, and it will not have any impact on existing code, > but I am leery of adding yet another extensibility vector without suffici= ent > requirement. I also think that adding extension parameters can handle thi= s > cleanly. > > > > The spec, as currently written does not imply that the only possible valu= es > are 'code' and 'token'. The only concern is that libraries may implement > such restriction and make extending this behavior different. > > > > I do not think that extension parameters can handle this cleanly. In > particular, if the response_type is neither code nor token. > > > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for response_type > > > > - Problem 1: Several WG participants are working on deploying a federated > signon protocol based on OAuth2 (aka OpenIDConnect) and would like to ret= urn > an additional 'session cookie' together with the auth_token. Or sometimes > return only a cookie as the result of authorization, since cookies will > likely have shorter lifetimes than access tokens, for security and usabil= ity > reasons, and require more frequent refresh requirements. In any case, the= re > aremultiple reasons for making the cookie separate from the auth_token, > including both security and flexibility of deployment. However, there is = no > way to express this except adding an arbitrary extension parameter (to > effectively express a different response type). > > > > - Problem 2: Codification of code_and_token created controversy as there > was not enough traction among participants to put it in the core. However= , > it is entirely possible that deployment experience will lead players to > revisit this topic. > > > > > > - Proposed solution: > > > > 1. Allow response_type to be a space separated list of arbitrary strings > > > > E.g.: > > > > response_type=3Dcode > > response_type=3Dtoken > > response_type=3Dcode+token > > response_type=3Dcookie > > response_type=3Dcode+cookie > > response_type=3Dtoken+cookie > > response_type=3Dfoo+bar > > > > Would all be syntactically valid responses from the perspective of OAuth2= .0 > Core response_type values. > > > > > > 2. Define behaviors in the core only for values 'code' and 'token'. Allow > extensions to define what do with 'code+token' or with any other values o= r > combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --90e6ba6e8d9ccc4341049c95ae03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Example 1:

OpenIDConnect End User Authorization Request = for '<other required OAuth2 parameters>&response_type=3Dtoken= +cookie'
OpenIDConnect End User Authorization Response =A0'<other required OA= uth2 parameters>&access_token=3Dfoo&cookie=3Dbar'
Example 2:

OpenIDConnect End User Authorizati= on Request for '<other required OAuth2 parameters>&response_t= ype=3Dcode+cookie'
OpenIDConnect End User Authorization Respo= nse '<other required OAuth2 parameters>&code=3Dfoo'

OpenIDConnect outcome of grant redemption ... '<= other required OAuth2 parameters>[&refresh_token=3Dfoo]&access_t= oken=3Dbar&cookie=3Dbaz'

Example 3 (specific syntax still to be agreed upon):

OpenIDConnect End User Cookie Refresh Request '<ot= her required OAuth2 parameters>&response_type=3Dcookie&cookie=3D= ... '
OpenIDConnect End User Cookie Refresh Response '<other required O= Auth2 parameters>&cookie=3Dfoo'

Example 4 (specific syntax still in the work):
Ope= nIDConnect End User Logout Request '&access_token=3Dbar' (to ne= w endpoint)
OpenIDConnect End User Logout Response '<somet= hing to mean ok>'

On Thu, Feb 17, 2011 at 10:48 PM, Eran = Hammer-Lahav <e= ran@hueniverse.com> wrote:

Can you send an example = wire interaction?

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 10:07 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subje= ct: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

=

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:

Ok.

=A0

So you want to request a cookie from both endpoints:= the authorization endpoint and the token endpoint? How would that work? Th= ere is no response_type on the token endpoint.

=A0

There is no need to. The grant carries the information.

=A0

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Thursday, February 17, 2011 9:30 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

So an implicit grant can produce just a cookie or both cookie and toke= n, but not code?

=A0

<= /div>

Yes, cookies would be returned in the same cont= ext of access_tokens, either as the result of an implicit grant or resultin= g from an explicit exchange from a code-type grant.

=A0

=A0

=A0

EHL

=A0=

=A0

From:= Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 5:10 PM


To: Eran Hammer-Lahav
Cc:= oauth@ietf.org=
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On = Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is cookie exchanged for an access token? Authorization grants are not = meant to be useful by themselves, only exchanged for an access token.

=A0

In this scenario, grants are exchanged for access tokens and/or cooki= es.

=A0

=A0

Can you request only a cookie? Or is it always with either a = token or code?

=A0

The idea is that a grant can be exchanged for only a coo= kie in some cases.

=A0

=A0

EHL

=A0

=A0

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

I am not questioning the use case, only how it fits within the OAuth f= ramework.

=A0

I don= =92t understand how such an extension is expected to work with the existing= grant types. The response_type parameter is used to identify if the flow b= eing used is for an implicit grant or authorization code. Are you suggestin= g a new grant type? Are you suggesting additional response parameters/heade= rs (in the case of a cookie) with both grant types?

=A0

It's a separate grant type that can be combined with either of th= e previous types.

=A0

=A0

=A0

Witho= ut full requirements we can=92t design an extension point. Asking to make t= his parameter a free text field is not helpful.

=A0

The re= quirement is to allow another grant type, cookie.

=A0

- cookie can be used s= eparately or in combination with code or token.

=A0

= - if specified by itself or in combination with token, it's returned in= the End User Authorization Response, in analogy/in addition to the access_= token

=A0

= - If specified in combination with code, it's returned in exchange for = the code, in analogy with the access_token

=A0

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

The use case is very straightforward:

=A0

- SAML provides session mana= gement. Facebook Connect provides session management. Both use cookies. The= se are authentication protocols but common usages of both SAML and FB Conne= ct imply authorization grants.

- OpenID2.0 does not provide session mana= gement. This has proven to reduce the value of OpenID and make it unsuitabl= e for many scenarios.

=A0

We would like federation protocols based on OAuth2 t= o be high-value. We would rather that they not be be hacks built on top of = OAuth2. That means that we need a first-order concept of cookie. A cookie c= an be refreshed independent of the grant associated with it. A cookie is so= mething the client holds on to that identifies the user (i.e., it's for= user-client authentication), but that the client is happy to outsource the= management of security/crypto/logged-in/logged-out state to the server.

=A0

= The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently.

=A0

This is a solid and proven use cas= e, and is of fundamental value to many planned OAuth2 implementations.

<= /div>

=A0

On= Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall = architecture.

=A0

This = is not just an endpoint people can bastardize (I am not suggesting *you<= /b>* are) as they see fit. It must fit with the overall model which is that= this endpoint returns either an access token or an authorization grant. An= authorization grant has to be exchanged for an access token.

=A0

If you are going to return something else, instead or in addition to th= e token/code options, you need to explain how it fits within the model. I a= m opposed to an open-ended extension point that is not consistent (and rest= ricted) to the model we spent a year to define and refine. The token+code r= esponse type was well defined (it was the use case that wasn=92t).

=A0

To move this forward, you need to come up with specific requirements, n= ot just making something extensible without understanding what it is you ar= e trying to extend. That=92s like the OAuth 1.0 utterly broken oauth_versio= n parameter and the long confusion it created later on.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]

Sent: Thursday, February 17, 2011 1:58 P= M
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

=A0

=A0

On Thu, F= eb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. Howe= ver, another spec can update the definition of the response_type parameter,= including defining a registry or other methods for extensibility.

=A0

We can define this now, and it will not have any impact on existing cod= e, but I am leery of adding yet another extensibility vector without suffic= ient requirement. I also think that adding extension parameters can handle = this cleanly.

=A0

The spec, as currently written does not imply that the only possible = values are 'code' and 'token'. The only concern is that lib= raries may implement such restriction and make extending this behavior diff= erent.

=A0

= I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token.=A0

=A0

=A0

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject:<= /b> [OAUTH-WG] Freedom of assembly for response_type

=A0

- Problem 1: Several WG participants are working on d= eploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) an= d would like to return an additional 'session cookie' together with= the auth_token. Or sometimes return only a cookie as the result of authori= zation, since cookies will likely have shorter lifetimes than access tokens= , for security and usability reasons, and require more frequent refresh req= uirements. In any case, there aremultiple reasons for making the cookie sep= arate from the auth_token, including both security and flexibility of deplo= yment. However, there is no way to express this except adding an arbitrary = extension parameter (to effectively express a different response type).

=A0

<= span style=3D"font-size:10.0pt">- Problem 2: Codification of code_and_token= created controversy as there was not enough traction among participants to= put it in the core. However, it is entirely possible that deployment exper= ience will lead players to revisit this topic.

=A0

=A0

= - Proposed solution:

=

=A0

1. Allow response_type to be a space= separated list of arbitrary strings

=A0

E.g.:

=A0

response_type=3Dcode

=

response_type=3Dtok= en

response_type=3Dcode+token

response= _type=3Dcookie

response_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_ty= pe=3Dfoo+bar

=A0

Would al= l be syntactically valid responses from the perspective of OAuth2.0 Core re= sponse_type values.

=A0

=A0

2.= Define behaviors in the core only for values 'code' and 'token= '. Allow extensions to define what do with 'code+token' or with= any other values or combinations of values.=A0


--
Bren= o de Medeiros




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros



--
Breno de Medeiros

=




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros

--90e6ba6e8d9ccc4341049c95ae03-- From toby@timetric.com Sun Feb 20 08:11:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8513D3A6FF2 for ; Sun, 20 Feb 2011 08:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neaxMrpCQV-T for ; Sun, 20 Feb 2011 08:11:52 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 51A093A6F0E for ; Sun, 20 Feb 2011 08:11:52 -0800 (PST) Received: by vws7 with SMTP id 7so3246971vws.31 for ; Sun, 20 Feb 2011 08:12:31 -0800 (PST) Received: by 10.220.198.134 with SMTP id eo6mr79786vcb.277.1298218350144; Sun, 20 Feb 2011 08:12:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.93.9 with HTTP; Sun, 20 Feb 2011 08:12:10 -0800 (PST) X-Originating-IP: [78.105.57.124] From: Toby White Date: Sun, 20 Feb 2011 16:12:10 +0000 Message-ID: To: OAuth Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] OAuth2 queries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:11:53 -0000 Some more OAuth2 queries (based on reading -13) * There's no direct indication of expected behaviour after a failed attempt to refresh a token. Since a refresh_token workflow is an example of issuing an access token, should I read the error behaviour describe in 5.2 as applying to section 6 as well? * Can I read throughout the spec, that wherever scope is an OPTIONAL parameter, I can read a request with an absent scope parameter as being equivalent to a request with a scope="" (empty string) parameter? * In 4.2.2 (implicit grant, response from the auth server), the response includes an OPTIONAL scope parameter, whose definition includes " The authorization server SHOULD include the parameter if the requested scope is different from the one requested by the client." I'm not quite sure I'm reading this correctly, but I think that implies that if the client requests scope A, the server can actually grant scope B. - is it required/suggested that scope B be a subset of scope A? - is it true of any other workflows that a client requesting one scope can actually be granted another scope? Thanks, Toby -- http://timetric.com 2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile) twitter: @timetric, @tow21 | skype: tobyohwhite From eran@hueniverse.com Sun Feb 20 08:38:16 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3654D3A6CCA for ; Sun, 20 Feb 2011 08:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fWeT+qZDYOJ for ; Sun, 20 Feb 2011 08:38:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 51DA73A6CBF for ; Sun, 20 Feb 2011 08:38:15 -0800 (PST) Received: (qmail 23361 invoked from network); 20 Feb 2011 16:38:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Feb 2011 16:38:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 20 Feb 2011 09:38:53 -0700 From: Eran Hammer-Lahav To: Toby White , OAuth Mailing List Date: Sun, 20 Feb 2011 09:38:40 -0700 Thread-Topic: [OAUTH-WG] OAuth2 queries Thread-Index: AcvRGP0clvFGBidCTPCNzI48jhIa+gAAxrhg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4548@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 Subject: Re: [OAUTH-WG] OAuth2 queries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:38:16 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Toby White > Sent: Sunday, February 20, 2011 8:12 AM > To: OAuth Mailing List > Subject: [OAUTH-WG] OAuth2 queries >=20 > Some more OAuth2 queries (based on reading -13) >=20 > * There's no direct indication of expected behaviour after a failed attem= pt to > refresh a token. Since a refresh_token workflow is an example of issuing = an > access token, should I read the error behaviour describe in 5.2 as applyi= ng to > section 6 as well? " If the request failed verification or is invalid, the authorization server return an error response as described in Section 5.2." > * Can I read throughout the spec, that wherever scope is an OPTIONAL > parameter, I can read a request with an absent scope parameter as being > equivalent to a request with a scope=3D"" (empty string) parameter? Yes, but an empty string doesn't necessarily means no scope. That's impleme= ntation specific. There is no definition of default scope and I would expec= t most services to define it as something other than nothing. > * In 4.2.2 (implicit grant, response from the auth server), the response > includes an OPTIONAL scope parameter, whose definition includes >=20 > " The authorization server SHOULD include the parameter if the requested > scope is different from the one requested by the client." >=20 > I'm not quite sure I'm reading this correctly, but I think that implies t= hat if the > client requests scope A, the server can actually grant scope B. >=20 > - is it required/suggested that scope B be a subset of scope A? No. The client can ask for oranges and you give it apples. > - is it true of any other workflows that a client requesting one scope c= an > actually be granted another scope? Yep. That's implementation specific. EHL From toby@timetric.com Sun Feb 20 08:53:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D453A6E09 for ; Sun, 20 Feb 2011 08:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqThIWY6dW-5 for ; Sun, 20 Feb 2011 08:53:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 31E003A6CCA for ; Sun, 20 Feb 2011 08:53:40 -0800 (PST) Received: by vws7 with SMTP id 7so3262232vws.31 for ; Sun, 20 Feb 2011 08:54:20 -0800 (PST) Received: by 10.52.157.74 with SMTP id wk10mr594187vdb.173.1298220859101; Sun, 20 Feb 2011 08:54:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.93.9 with HTTP; Sun, 20 Feb 2011 08:53:59 -0800 (PST) X-Originating-IP: [78.105.57.124] In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D4548@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4548@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Toby White Date: Sun, 20 Feb 2011 16:53:59 +0000 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth Mailing List Subject: Re: [OAUTH-WG] OAuth2 queries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:53:42 -0000 Thanks - that all makes sense. Toby On Sun, Feb 20, 2011 at 4:38 PM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Toby White >> Sent: Sunday, February 20, 2011 8:12 AM >> To: OAuth Mailing List >> Subject: [OAUTH-WG] OAuth2 queries >> >> Some more OAuth2 queries (based on reading -13) >> >> * There's no direct indication of expected behaviour after a failed atte= mpt to >> refresh a token. Since a refresh_token workflow is an example of issuing= an >> access token, should I read the error behaviour describe in 5.2 as apply= ing to >> section 6 as well? > > " If the request > =A0 failed verification or is invalid, the authorization server return an > =A0 error response as described in Section 5.2." > >> * Can I read throughout the spec, that wherever scope is an OPTIONAL >> parameter, I can read a request with an absent scope parameter as being >> equivalent to a request with a scope=3D"" (empty string) parameter? > > Yes, but an empty string doesn't necessarily means no scope. That's imple= mentation specific. There is no definition of default scope and I would exp= ect most services to define it as something other than nothing. > >> * In 4.2.2 (implicit grant, response from the auth server), the response >> includes an OPTIONAL scope parameter, whose definition includes >> >> " The authorization server SHOULD include the parameter if the requested >> scope is different from the one requested by the client." >> >> I'm not quite sure I'm reading this correctly, but I think that implies = that if the >> client requests scope A, the server can actually grant scope B. >> >> =A0- is it required/suggested that scope B be a subset of scope A? > > No. The client can ask for oranges and you give it apples. > >> =A0- is it true of any other workflows that a client requesting one scop= e can >> actually be granted another scope? > > Yep. That's implementation specific. > > EHL > --=20 http://timetric.com 2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile) twitter: @timetric, @tow21 | skype: tobyohwhite From torsten@lodderstedt.net Sun Feb 20 11:04:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037333A6D3C for ; Sun, 20 Feb 2011 11:04:45 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTjesaBJzDzf for ; Sun, 20 Feb 2011 11:04:44 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id D6B103A6D2B for ; Sun, 20 Feb 2011 11:04:43 -0800 (PST) Received: from [87.142.251.102] (helo=[192.168.71.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PrEaw-0002Gv-0g for oauth@ietf.org; Sun, 20 Feb 2011 20:05:22 +0100 Message-ID: <4D6165F1.6010401@lodderstedt.net> Date: Sun, 20 Feb 2011 20:05:21 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: OAuth WG Content-Type: multipart/alternative; boundary="------------080204070105010803080204" X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 19:04:45 -0000 This is a multi-part message in MIME format. --------------080204070105010803080204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, on behalf of Mark, Phil and myself I just submitted the OAuth 2.0 security document. This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. It is intended for multiple purposes: 1) It shall be the foundation of the core draft's security considerations section. 2) It shall foster discussion about OAuth 2.0 security inside and outside the WG 3) It might become the foundation of security threat models and considerations for protocols built on top of OAuth 2.0 We highly appreciate any constructive feedback. regards, Torsten. -------- Original-Nachricht -------- Betreff: New Version Notification for draft-lodderstedt-oauth-security-00 Datum: Sun, 20 Feb 2011 10:52:50 -0800 (PST) Von: IETF I-D Submission Tool An: torsten@lodderstedt.net CC: mark.mcgloin@ie.ibm.com,phil.hunt@yahoo.com A new version of I-D, draft-lodderstedt-oauth-security-00.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename: draft-lodderstedt-oauth-security Revision: 00 Title: OAuth 2.0 Threat Model and Security Considerations Creation_date: 2011-02-20 WG ID: Independent Submission Number_of_pages: 51 Abstract: This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. The IETF Secretariat. --------------080204070105010803080204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all,

on behalf of Mark, Phil and myself I just submitted the OAuth 2.0 security document. This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol. It is intended for multiple purposes:

1) It shall be the foundation of the core draft's security considerations section.
2) It shall foster discussion about OAuth 2.0 security inside and outside the WG
3) It might become the foundation of security threat models and considerations for protocols built on top of OAuth 2.0

We highly appreciate any constructive feedback.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-security-00
Datum: Sun, 20 Feb 2011 10:52:50 -0800 (PST)
Von: IETF I-D Submission Tool <idsubmission@ietf.org>
An: torsten@lodderstedt.net
CC: mark.mcgloin@ie.ibm.com,phil.hunt@yahoo.com 


A new version of I-D, draft-lodderstedt-oauth-security-00.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Filename:	 draft-lodderstedt-oauth-security
Revision:	 00
Title:		 OAuth 2.0 Threat Model and Security Considerations
Creation_date:	 2011-02-20
WG ID:		 Independent Submission
Number_of_pages: 51

Abstract:
This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol.
                                                                                  


The IETF Secretariat.
--------------080204070105010803080204-- From torsten@lodderstedt.net Sun Feb 20 11:07:43 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7853A6D3C for ; Sun, 20 Feb 2011 11:07:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lXf6j44hvmA for ; Sun, 20 Feb 2011 11:07:42 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by core3.amsl.com (Postfix) with ESMTP id 963783A6D2B for ; Sun, 20 Feb 2011 11:07:42 -0800 (PST) Received: from [87.142.251.102] (helo=[192.168.71.26]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PrEdo-0006ka-Ft; Sun, 20 Feb 2011 20:08:20 +0100 Message-ID: <4D6166A3.6090705@lodderstedt.net> Date: Sun, 20 Feb 2011 20:08:19 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4503D60FB7@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4503D60FB7@FIESEXC015.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------060402030400010209090907" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Oauth Security Draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 19:07:43 -0000 This is a multi-part message in MIME format. --------------060402030400010209090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, just submitted the document. I'm looking forward to a fruitful discussion. regards, Torsten. Am 18.02.2011 13:34, schrieb Tschofenig, Hannes (NSN - FI/Espoo): > > Hi Thorsten, > Hi all, > > I am wondering what the status of the security draft is. The group is > eagerly waiting for it. I fear that when it comes out it will be far > too late and it will contain a lot of material the authors may feel > comfortable but the rest of the group not necessarily. > > Instead of trying to make it perfect it is better to present something > to the group so that we can have a discussion ASAP. > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060402030400010209090907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Hannes,

just submitted the document. I'm looking forward to a fruitful discussion.

regards,
Torsten.

Am 18.02.2011 13:34, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Oauth Security Draft?

Hi Thorsten,
Hi all,

I am  wondering what the status of the security draft is. The group is eagerly waiting for it. I fear that when it comes out it will be far too late and it will contain a lot of material the authors may feel comfortable but the rest of the group not necessarily.

Instead of trying to make it perfect it is better to present something to the group so that we can have a discussion ASAP.

Ciao
Hannes 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060402030400010209090907-- From eran@hueniverse.com Sun Feb 20 15:47:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66783A6F76 for ; Sun, 20 Feb 2011 15:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XypK3mjBC83j for ; Sun, 20 Feb 2011 15:47:19 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id CE8A73A6EAC for ; Sun, 20 Feb 2011 15:47:19 -0800 (PST) Received: (qmail 8922 invoked from network); 20 Feb 2011 23:47:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Feb 2011 23:47:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 20 Feb 2011 16:47:58 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Sun, 20 Feb 2011 16:47:45 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 Thread-Index: AcvRMSNef5yvsUYlROOCl/lnWbVhgQAJ1L8A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D6165F1.6010401@lodderstedt.net> In-Reply-To: <4D6165F1.6010401@lodderstedt.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_90C41DD21FB7C64BB94121FBBC2E723445A91D4581P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 23:47:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4581P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBzdWJtaXR0aW5nIHRoaXMgZHJhZnQuDQoNCkhvdyBkbyB5b3UgZW52aXNpb24g dGhpcyBiZWluZyBpbmNvcnBvcmF0ZWQgaW50byB2Mj8gSnVzdCBzZWN0aW9uIDUgb3IgdGhlIGVu dGlyZSBkb2N1bWVudD8NCg0KRUhMDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJz dGVkdA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAyMCwgMjAxMSAxMTowNSBBTQ0KVG86IE9BdXRo IFdHDQpTdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1zZWN1cml0eS0wMA0KDQpIaSBhbGwsDQoNCm9uIGJl aGFsZiBvZiBNYXJrLCBQaGlsIGFuZCBteXNlbGYgSSBqdXN0IHN1Ym1pdHRlZCB0aGUgT0F1dGgg Mi4wIHNlY3VyaXR5IGRvY3VtZW50LiBUaGlzIGRvY3VtZW50IGdpdmVzIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGJhc2VkIG9uIGEgY29tcHJlaGVuc2l2ZQ0KdGhyZWF0IG1vZGVsIGZvciB0aGUg T0F1dGggMi4wIFByb3RvY29sLiBJdCBpcyBpbnRlbmRlZCBmb3IgbXVsdGlwbGUgcHVycG9zZXM6 DQoNCjEpIEl0IHNoYWxsIGJlIHRoZSBmb3VuZGF0aW9uIG9mIHRoZSBjb3JlIGRyYWZ0J3Mgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCjIpIEl0IHNoYWxsIGZvc3RlciBkaXNjdXNz aW9uIGFib3V0IE9BdXRoIDIuMCBzZWN1cml0eSBpbnNpZGUgYW5kIG91dHNpZGUgdGhlIFdHDQoz KSBJdCBtaWdodCBiZWNvbWUgdGhlIGZvdW5kYXRpb24gb2Ygc2VjdXJpdHkgdGhyZWF0IG1vZGVs cyBhbmQgY29uc2lkZXJhdGlvbnMgZm9yIHByb3RvY29scyBidWlsdCBvbiB0b3Agb2YgT0F1dGgg Mi4wDQoNCldlIGhpZ2hseSBhcHByZWNpYXRlIGFueSBjb25zdHJ1Y3RpdmUgZmVlZGJhY2suDQoN CnJlZ2FyZHMsDQpUb3JzdGVuLg0KDQotLS0tLS0tLSBPcmlnaW5hbC1OYWNocmljaHQgLS0tLS0t LS0NCkJldHJlZmY6DQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9kZGVy c3RlZHQtb2F1dGgtc2VjdXJpdHktMDANCg0KRGF0dW06DQoNClN1biwgMjAgRmViIDIwMTEgMTA6 NTI6NTAgLTA4MDAgKFBTVCkNCg0KVm9uOg0KDQpJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgPGlk c3VibWlzc2lvbkBpZXRmLm9yZz48bWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZz4NCg0KQW46 DQoNCnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dD4NCg0KQ0M6DQoNCm1hcmsubWNnbG9pbkBpZS5pYm0uY29tLHBoaWwuaHVudEB5YWhvby5jb208 bWFpbHRvOm1hcmsubWNnbG9pbkBpZS5pYm0uY29tLHBoaWwuaHVudEB5YWhvby5jb20+DQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtc2VjdXJpdHkt MDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJz dGVkdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpGaWxlbmFtZTog ICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1zZWN1cml0eQ0KDQpSZXZpc2lvbjogICAgICAw MA0KDQpUaXRsZTogICAgICAgICBPQXV0aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBD b25zaWRlcmF0aW9ucw0KDQpDcmVhdGlvbl9kYXRlOiAgMjAxMS0wMi0yMA0KDQpXRyBJRDogICAg ICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQoNCk51bWJlcl9vZl9wYWdlczogNTENCg0KDQoN CkFic3RyYWN0Og0KDQpUaGlzIGRvY3VtZW50IGdpdmVzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGJhc2VkIG9uIGEgY29tcHJlaGVuc2l2ZQ0KDQp0aHJlYXQgbW9kZWwgZm9yIHRoZSBPQXV0aCAy LjAgUHJvdG9jb2wuDQoNCg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg0K DQo= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4581P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciBzdWJtaXR0aW5nIHRoaXMgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgZG8geW91IGVudmlzaW9uIHRoaXMgYmVpbmcgaW5j b3Jwb3JhdGVkIGludG8gdjI/IEp1c3Qgc2VjdGlvbiA1IG9yIHRoZSBlbnRpcmUgZG9jdW1lbnQ/ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Ub3JzdGVuIExv ZGRlcnN0ZWR0PGJyPjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDIwLCAyMDExIDExOjA1 IEFNPGJyPjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRo LXNlY3VyaXR5LTAwPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgYWxsLDxi cj48YnI+b24gYmVoYWxmIG9mIE1hcmssIFBoaWwgYW5kIG15c2VsZiBJIGp1c3Qgc3VibWl0dGVk IHRoZSBPQXV0aCAyLjAgc2VjdXJpdHkgZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnQgZ2l2ZXMgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgYmFzZWQgb24gYSBjb21wcmVoZW5zaXZlPGJyPnRocmVhdCBt b2RlbCBmb3IgdGhlIE9BdXRoIDIuMCBQcm90b2NvbC4gSXQgaXMgaW50ZW5kZWQgZm9yIG11bHRp cGxlIHB1cnBvc2VzOjxicj48YnI+MSkgSXQgc2hhbGwgYmUgdGhlIGZvdW5kYXRpb24gb2YgdGhl IGNvcmUgZHJhZnQncyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxicj4yKSBJdCBz aGFsbCBmb3N0ZXIgZGlzY3Vzc2lvbiBhYm91dCBPQXV0aCAyLjAgc2VjdXJpdHkgaW5zaWRlIGFu ZCBvdXRzaWRlIHRoZSBXRyA8YnI+MykgSXQgbWlnaHQgYmVjb21lIHRoZSBmb3VuZGF0aW9uIG9m IHNlY3VyaXR5IHRocmVhdCBtb2RlbHMgYW5kIGNvbnNpZGVyYXRpb25zIGZvciBwcm90b2NvbHMg YnVpbHQgb24gdG9wIG9mIE9BdXRoIDIuMDxicj48YnI+V2UgaGlnaGx5IGFwcHJlY2lhdGUgYW55 IGNvbnN0cnVjdGl2ZSBmZWVkYmFjay48YnI+PGJyPnJlZ2FyZHMsPGJyPlRvcnN0ZW4uPGJyPjxi cj4tLS0tLS0tLSBPcmlnaW5hbC1OYWNocmljaHQgLS0tLS0tLS0gPG86cD48L286cD48L3A+PHRh YmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRp bmc9MD48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJp Z2h0Jz48Yj5CZXRyZWZmOiA8bzpwPjwvbzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRp bmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+TmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1zZWN1cml0eS0wMDxvOnA+PC9vOnA+ PC9wPjwvdGQ+PC90cj48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBp biAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0 LWFsaWduOnJpZ2h0Jz48Yj5EYXR1bTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0eWxl PSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPlN1biwgMjAgRmVi IDIwMTEgMTA6NTI6NTAgLTA4MDAgKFBTVCk8bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0 ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNs YXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+Vm9u OiA8bzpwPjwvbzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+SUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxhIGhyZWY9 Im1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmciPiZsdDtpZHN1Ym1pc3Npb25AaWV0Zi5vcmcm Z3Q7PC9hPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9w IHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWdu PXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5BbjogPG86cD48L286cD48L2I+PC9w PjwvdGQ+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsPjxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZh bGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPkNDOiA8bzpwPjwvbzpw PjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWw+PGEgaHJlZj0ibWFpbHRvOm1hcmsubWNnbG9pbkBpZS5pYm0uY29tLHBoaWwu aHVudEB5YWhvby5jb20iPm1hcmsubWNnbG9pbkBpZS5pYm0uY29tLHBoaWwuaHVudEB5YWhvby5j b208L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PHByZT5B IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtc2VjdXJpdHktMDAu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVk dCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5GaWxlbmFtZTrCoMKgwqDCoCAgZHJhZnQtbG9k ZGVyc3RlZHQtb2F1dGgtc2VjdXJpdHk8bzpwPjwvbzpwPjwvcHJlPjxwcmU+UmV2aXNpb246wqDC oMKgwqAgIDAwPG86cD48L286cD48L3ByZT48cHJlPlRpdGxlOsKgwqDCoMKgwqDCoMKgICBPQXV0 aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+ PC9wcmU+PHByZT5DcmVhdGlvbl9kYXRlOiAgMjAxMS0wMi0yMDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT5XRyBJRDrCoMKgwqDCoMKgwqDCoCAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbjxvOnA+PC9vOnA+ PC9wcmU+PHByZT5OdW1iZXJfb2ZfcGFnZXM6IDUxPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+VGhp cyBkb2N1bWVudCBnaXZlcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBiYXNlZCBvbiBhIGNvbXBy ZWhlbnNpdmU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+dGhyZWF0IG1vZGVsIGZvciB0aGUgT0F1dGgg Mi4wIFByb3RvY29sLjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhlIElFVEYg U2VjcmV0YXJpYXQuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4581P3PW5EX1MB01E_-- From eran@hueniverse.com Sun Feb 20 16:07:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741473A6E5B for ; Sun, 20 Feb 2011 16:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcFkusWG-4bo for ; Sun, 20 Feb 2011 16:06:47 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DB1553A6CF5 for ; Sun, 20 Feb 2011 16:06:46 -0800 (PST) Received: (qmail 3765 invoked from network); 21 Feb 2011 00:07:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Feb 2011 00:07:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 20 Feb 2011 17:06:15 -0700 From: Eran Hammer-Lahav To: Breno Date: Sun, 20 Feb 2011 17:06:02 -0700 Thread-Topic: [OAUTH-WG] Freedom of assembly for response_type Thread-Index: AcvPt6v/Or6ATsITTuS9Ht7RaTW91gBoTaNA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D4583@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4242@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4583P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 00:07:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4583P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a few issues/comments: 1. The value 'cookie' is way to generic. What is the content of such = cookie and what is the client supposed to do with it? 2. Example 3 does not belong on the End user authorization endpoint a= s it does not produce a code or token (or any other grant type to be exchan= ged for a token). Is the user involved in this refresh? 3. Are you going to have cookie versions in the future? Is this an ex= tensible format? Overall, this feels like 'BTW, while we're at it, also give me a cookie' wh= ich belongs in another extension request parameter. Just because we have a = parameter called 'response_type' does not mean anything that impacts the re= sponse should be requested using it. Adding a new request parameter such as= 'openid_cookie=3D1.0' to request version 1.0 of the cookie used by OpenID = connect is one example. My main objection to allowing response_type to be extensible is that it req= uires defining a registry for new values, a syntax for multiple values to c= ombine them in one request, error codes to deal with unknown or unsupported= response types (combined with supported ones), and defining other restrict= ions to make sure the endpoint remains an OAuth endpoint (i.e. results in a= grant type exchanged for an access token or an access token). By leaving response_type unchanged and adding another request parameter, al= l these issues are avoided when the cost to the OpenID Connect protocol is = nothing more than a different way to add a cookie to the request. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, February 18, 2011 2:03 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type Example 1: OpenIDConnect End User Authorization Request for '&response_type=3Dtoken+cookie' OpenIDConnect End User Authorization Response '&access_token=3Dfoo&cookie=3Dbar' Example 2: OpenIDConnect End User Authorization Request for '&response_type=3Dcode+cookie' OpenIDConnect End User Authorization Response '&code=3Dfoo' OpenIDConnect outcome of grant redemption ... '[&refresh_token=3Dfoo]&access_token=3Dbar&cookie=3Dbaz' Example 3 (specific syntax still to be agreed upon): OpenIDConnect End User Cookie Refresh Request '&response_type=3Dcookie&cookie=3D... ' OpenIDConnect End User Cookie Refresh Response '&cookie=3Dfoo' Example 4 (specific syntax still in the work): OpenIDConnect End User Logout Request '&access_token=3Dbar' (to new endpoin= t) OpenIDConnect End User Logout Response '' On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav > wrote: Can you send an example wire interaction? EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 10:07 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav > wrote: Ok. So you want to request a cookie from both endpoints: the authorization endp= oint and the token endpoint? How would that work? There is no response_type= on the token endpoint. There is no need to. The grant carries the information. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 9:30 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > wrote: So an implicit grant can produce just a cookie or both cookie and token, bu= t not code? Yes, cookies would be returned in the same context of access_tokens, either= as the result of an implicit grant or resulting from an explicit exchange = from a code-type grant. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 5:10 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > wrote: Is cookie exchanged for an access token? Authorization grants are not meant= to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:50 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > wrote: I am not questioning the use case, only how it fits within the OAuth framew= ork. I don't understand how such an extension is expected to work with the exist= ing grant types. The response_type parameter is used to identify if the flo= w being used is for an implicit grant or authorization code. Are you sugges= ting a new grant type? Are you suggesting additional response parameters/he= aders (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous= types. Without full requirements we can't design an extension point. Asking to mak= e this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the= End User Authorization Response, in analogy/in addition to the access_toke= n - If specified in combination with code, it's returned in exchange for the = code, in analogy with the access_token EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 4:22 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session manag= ement. Both use cookies. These are authentication protocols but common usag= es of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce = the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We wou= ld rather that they not be be hacks built on top of OAuth2. That means that= we need a first-order concept of cookie. A cookie can be refreshed indepen= dent of the grant associated with it. A cookie is something the client hold= s on to that identifies the user (i.e., it's for user-client authentication= ), but that the client is happy to outsource the management of security/cry= pto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a gr= ant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many pl= anned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > wrote: You need to define how this proposed extension works with the overall archi= tecture. This is not just an endpoint people can bastardize (I am not suggesting *yo= u* are) as they see fit. It must fit with the overall model which is that t= his endpoint returns either an access token or an authorization grant. An a= uthorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the to= ken/code options, you need to explain how it fits within the model. I am op= posed to an open-ended extension point that is not consistent (and restrict= ed) to the model we spent a year to define and refine. The token+code respo= nse type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not j= ust making something extensible without understanding what it is you are tr= ying to extend. That's like the OAuth 1.0 utterly broken oauth_version para= meter and the long confusion it created later on. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > wrote: The best approach (at this point) is to leave the spec unchanged. However, = another spec can update the definition of the response_type parameter, incl= uding defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, b= ut I am leery of adding yet another extensibility vector without sufficient= requirement. I also think that adding extension parameters can handle this= cleanly. The spec, as currently written does not imply that the only possible values= are 'code' and 'token'. The only concern is that libraries may implement s= uch restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In partic= ular, if the response_type is neither code nor token. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: oauth@ietf.org Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated s= ignon protocol based on OAuth2 (aka OpenIDConnect) and would like to return= an additional 'session cookie' together with the auth_token. Or sometimes = return only a cookie as the result of authorization, since cookies will lik= ely have shorter lifetimes than access tokens, for security and usability r= easons, and require more frequent refresh requirements. In any case, there = aremultiple reasons for making the cookie separate from the auth_token, inc= luding both security and flexibility of deployment. However, there is no wa= y to express this except adding an arbitrary extension parameter (to effect= ively express a different response type). - Problem 2: Codification of code_and_token created controversy as there wa= s not enough traction among participants to put it in the core. However, it= is entirely possible that deployment experience will lead players to revis= it this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=3Dcode response_type=3Dtoken response_type=3Dcode+token response_type=3Dcookie response_type=3Dcode+cookie response_type=3Dtoken+cookie response_type=3Dfoo+bar Would all be syntactically valid responses from the perspective of OAuth2.0= Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow e= xtensions to define what do with 'code+token' or with any other values or c= ombinations of values. -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4583P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a = few issues/comments:

 

1.  &= nbsp;    The value = 216;cookie’ is way to generic. What is the content of such cookie and= what is the client supposed to do with it?

2.       <= /span>Example 3 does not belong on the End user aut= horization endpoint as it does not produce a code or token (or any other gr= ant type to be exchanged for a token). Is the user involved in this refresh= ?

3.  &n= bsp;    Are you going = to have cookie versions in the future? Is this an extensible format?

 

Overall, this feels like ‘BTW, while we’= ;re at it, also give me a cookie’ which belongs in another extension = request parameter. Just because we have a parameter called ‘response_= type’ does not mean anything that impacts the response should be requ= ested using it. Adding a new request parameter such as ‘openid_cookie= =3D1.0’ to request version 1.0 of the cookie used by OpenID connect i= s one example.

 =

My main objection to allowing = response_type to be extensible is that it requires defining a registry for = new values, a syntax for multiple values to combine them in one request, er= ror codes to deal with unknown or unsupported response types (combined with= supported ones), and defining other restrictions to make sure the endpoint= remains an OAuth endpoint (i.e. results in a grant type exchanged for an a= ccess token or an access token).

=  

By leaving r= esponse_type unchanged and adding another request parameter, all these issu= es are avoided when the cost to the OpenID Connect protocol is nothing more= than a different way to add a cookie to the request.

=

 

EHL

 

 

From: Breno [mailto:breno.demedeiros@gm= ail.com]
Sent: Friday, February 18, 2011 2:03 PM
To: E= ran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH= -WG] Freedom of assembly for response_type

 

Example 1:<= o:p>

 

OpenIDConnect End User Authorization Request for '<oth= er required OAuth2 parameters>&response_type=3Dtoken+cookie'

OpenIDConnect End User Authorization= Response  '<other required OAuth2 parameters>&access_token= =3Dfoo&cookie=3Dbar'

 

Example 2:

<= /div>

 

OpenIDConnect End User Authorization Request for '<other requir= ed OAuth2 parameters>&response_type=3Dcode+cookie'

OpenIDConnect End User Authorization Response = '<other required OAuth2 parameters>&code=3Dfoo'

 

OpenIDConnect outcome of grant redemption ... '<other required OA= uth2 parameters>[&refresh_token=3Dfoo]&access_token=3Dbar&co= okie=3Dbaz'

 =

Example 3 (specific syntax still to be = agreed upon):

 

OpenIDConnect End User Cookie Refresh= Request '<other required OAuth2 parameters>&response_type=3Dcook= ie&cookie=3D... '

OpenIDC= onnect End User Cookie Refresh Response '<other required OAuth2 paramete= rs>&cookie=3Dfoo'

 

Example 4 (specific syntax= still in the work):

OpenIDCo= nnect End User Logout Request '&access_token=3Dbar' (to new endpoint)

OpenIDConnect End User Logout = Response '<something to mean ok>'

 

On Thu, Feb 17,= 2011 at 10:48 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Can you send an example wire int= eraction?

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, = February 17, 2011 10:07 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUT= H-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:=

Ok.

 

So you want to request a cookie from both endpoints: the aut= horization endpoint and the token endpoint? How would that work? There is n= o response_type on the token endpoint.

 

There is no need to. The gr= ant carries the information.

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thu= rsday, February 17, 2011 9:30 PM


= To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fr= eedom of assembly for response_type

<= div>

 

 

On T= hu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

So a= n implicit grant can produce just a cookie or both cookie and token, but no= t code?

 

<= /div>

Yes, cookies would be returned in the same context of acce= ss_tokens, either as the result of an implicit grant or resulting from an e= xplicit exchange from a code-type grant.

&= nbsp;

 

 <= /span>

= EHL

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 1= 7, 2011 5:10 PM


To: Eran= Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assemb= ly for response_type

 

 

On Thu, Feb 17, 201= 1 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is cookie exchanged= for an access token? Authorization grants are not meant to be useful by th= emselves, only exchanged for an access token.

 

In this scenario, g= rants are exchanged for access tokens and/or cookies.

<= div>

 

 

Can you request only a cook= ie? Or is it always with either a token or code?

 

The = idea is that a grant can be exchanged for only a cookie in some cases.=

 

<= div>

 

EHL=

 =

 

 

From: = Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, = 2011 4:50 PM


To: Eran Hamm= er-Lahav
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly fo= r response_type

&nbs= p;

 

On Thu, Feb 17, 2011 at = 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I am not questioning the= use case, only how it fits within the OAuth framework.

 <= /o:p>

I don’= t understand how such an extension is expected to work with the existing gr= ant types. The response_type parameter is used to identify if the flow bein= g used is for an implicit grant or authorization code. Are you suggesting a= new grant type? Are you suggesting additional response parameters/headers = (in the case of a cookie) with both grant types?

 

It's a separate g= rant type that can be combined with either of the previous types.

 

 

 

Without full requirements we can’t design an = extension point. Asking to make this parameter a free text field is not hel= pful.

 =

The requirement is to allow another grant type,= cookie.

 

- cookie can be used separately or in combination with code or token.<= o:p>

 

- if= specified by itself or in combination with token, it's returned in the End= User Authorization Response, in analogy/in addition to the access_token

 

- If s= pecified in combination with code, it's returned in exchange for the code, = in analogy with the access_token

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent:= Thursday, February 17, 2011 4:22 PM

=
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG= ] Freedom of assembly for response_type

 

The use case is very straig= htforward:

 

- SAML provides session management. Facebook Connect provides session mana= gement. Both use cookies. These are authentication protocols but common usa= ges of both SAML and FB Connect imply authorization grants.

<= /div>

- OpenID2.0 does not provide session management. This has = proven to reduce the value of OpenID and make it unsuitable for many scenar= ios.

 

We would like federation protocols based on OAuth2 to be high-value. We wo= uld rather that they not be be hacks built on top of OAuth2. That means tha= t we need a first-order concept of cookie. A cookie can be refreshed indepe= ndent of the grant associated with it. A cookie is something the client hol= ds on to that identifies the user (i.e., it's for user-client authenticatio= n), but that the client is happy to outsource the management of security/cr= ypto/logged-in/logged-out state to the server.

 

The cookie is produced and retur= ned by the server, in combination with a grant, but it can be refreshed ind= ependently.

 

This is a solid and proven use case, and is of fundamental value to= many planned OAuth2 implementations.

=  

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hamm= er-Lahav <eran@= hueniverse.com> wrote:

You need to define how this proposed exten= sion works with the overall architecture.

 

This is not just an endpoi= nt people can bastardize (I am not suggesting *you* are) as they see= fit. It must fit with the overall model which is that this endpoint return= s either an access token or an authorization grant. An authorization grant = has to be exchanged for an access token.

 

If you are going to return = something else, instead or in addition to the token/code options, you need = to explain how it fits within the model. I am opposed to an open-ended exte= nsion point that is not consistent (and restricted) to the model we spent a= year to define and refine. The token+code response type was well defined (= it was the use case that wasn’t).

 

= To move this forward, you ne= ed to come up with specific requirements, not just making something extensi= ble without understanding what it is you are trying to extend. That’s= like the OAuth 1.0 utterly broken oauth_version parameter and the long con= fusion it created later on.

 

EHL

 

=

From: Breno [mailto:breno.demedeiros@gmail.com] <= o:p>

Sent: Thursday, February 17, 2011 1:58 PM<= br>To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Sub= ject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

<= div>

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com&g= t; wrote:

The best approach (at this point) is to leave the spec unchang= ed. However, another spec can update the definition of the response_type pa= rameter, including defining a registry or other methods for extensibility.<= /span>

=  

We can define this now, and it will not have any impact on existing = code, but I am leery of adding yet another extensibility vector without suf= ficient requirement. I also think that adding extension parameters can hand= le this cleanly.

 

The spec, as currently written does not imply tha= t the only possible values are 'code' and 'token'. The only concern is that= libraries may implement such restriction and make extending this behavior = different.

 

=

I do not think that extension parameters can handle this cleanly. In= particular, if the response_type is neither code nor token. 

 

=

 

EHL

 

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces= @ietf.org] On Behalf Of Breno
Sent: Thursday, February= 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of ass= embly for response_type

&= nbsp;

- Problem 1: Se= veral WG participants are working on deploying a federated signon protocol = based on OAuth2 (aka OpenIDConnect) and would like to return an additional = 'session cookie' together with the auth_token. Or sometimes return only a c= ookie as the result of authorization, since cookies will likely have shorte= r lifetimes than access tokens, for security and usability reasons, and req= uire more frequent refresh requirements. In any case, there aremultiple rea= sons for making the cookie separate from the auth_token, including both sec= urity and flexibility of deployment. However, there is no way to express th= is except adding an arbitrary extension parameter (to effectively express a= different response type).

 

- Problem 2: = Codification of code_and_token created controversy as there was not enough = traction among participants to put it in the core. However, it is entirely = possible that deployment experience will lead players to revisit this topic= .

 

<= span style=3D'font-size:10.0pt'> 

- Proposed solution:<= /p>

 

1. Allow response= _type to be a space separated list of arbitrary strings

 

E.g.:<= /o:p>

 

response_ty= pe=3Dcode

response_type=3Dtoken

response_type=3Dcode+token

<= /div>

response_type=3Dcookie

respo= nse_type=3Dcode+cookie

response_type=3Dtoken+cookie

response_type=3Dfoo+bar

 =

Wo= uld all be syntactically valid responses from the perspective of OAuth2.0 C= ore response_type values.

 

 

<= span style=3D'font-size:10.0pt'>2. Define behaviors in the core only for va= lues 'code' and 'token'. Allow extensions to define what do with 'code+toke= n' or with any other values or combinations of values. 


--
Breno de Medeiros

=




--
= Breno de Medeiros



--
Breno de Medeiros

=




--
= Breno de Medeiros

=




--
Breno de Medeiros




-- Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D4583P3PW5EX1MB01E_-- From phil.hunt@oracle.com Mon Feb 21 16:48:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F323A67B2 for ; Mon, 21 Feb 2011 16:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMAD0VG-PZIx for ; Mon, 21 Feb 2011 16:48:20 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E9ED43A67AA for ; Mon, 21 Feb 2011 16:48:19 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1M0n1lE024494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2011 00:49:02 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1LL6o0C029630 for ; Tue, 22 Feb 2011 00:48:59 GMT Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 1074167111298335660; Mon, 21 Feb 2011 16:47:40 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Feb 2011 16:47:39 -0800 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2011 16:45:49 -0800 Message-Id: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4D6307FD.000B:SCFMA4539814,ss=1,fgs=0 Subject: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:48:20 -0000 FYI. I published a blog post with a flow-chart explaining the legs of = OAuth. = http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html Please let me know if any corrections should be made, or for that = matter, any improvements! Phil phil.hunt@oracle.com From phil.hunt@oracle.com Mon Feb 21 16:48:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E5F3A67AB for ; Mon, 21 Feb 2011 16:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVlg804tqfTv for ; Mon, 21 Feb 2011 16:48:41 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4B6193A67AA for ; Mon, 21 Feb 2011 16:48:41 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1M0nMb5025464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2011 00:49:24 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1LLCFR1002750 for ; Tue, 22 Feb 2011 00:49:22 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 1025907941298335762; Mon, 21 Feb 2011 16:49:22 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Feb 2011 16:49:21 -0800 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2011 16:49:20 -0800 Message-Id: <40798DAC-8F44-480E-8677-F765F2C1871B@oracle.com> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D630812.00A2:SCFMA4539814,ss=1,fgs=0 Subject: [OAUTH-WG] Draft13: What are the possible OAuth related access errors for section 7? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:48:42 -0000 When accessing a protected resource with what a client believes to be an = valid token, what errors are possible/valid? Is this specifically out = of scope? Section 7 doesn't seem to cover possible error conditions. = E.g. the one that hit me just now, is how is an expired token indicated = if at all (vs. invalid authorization). Obviously in some cases, most sites won't give details. But still I = found the issue of an expired token causing someone to try a refresh = (section 6) to be a little unclear in draft 13. Also, would/should more specific errors be defined in the various = Bearer, Mac, etc specifications? Phil phil.hunt@oracle.com From beaton@google.com Mon Feb 21 21:35:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEBE3A681D for ; Mon, 21 Feb 2011 21:35:36 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRWZSsZH63WA for ; Mon, 21 Feb 2011 21:35:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D78FE3A6820 for ; Mon, 21 Feb 2011 21:35:32 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p1M5aFE6009471 for ; Mon, 21 Feb 2011 21:36:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298352976; bh=vS082YcgeiBNwsSMlTCvxIiSJQA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GkymJtl+VlvQN54D5OFpypAd6ry6ZVq9toGk/EHcTKUHY3UF59MYfjAkXm5OE+Bsd n3o3nXSnCRWF8YzjS7oRA== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by hpaq12.eem.corp.google.com with ESMTP id p1M5aCK0009673 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 21 Feb 2011 21:36:13 -0800 Received: by pxi11 with SMTP id 11so394559pxi.7 for ; Mon, 21 Feb 2011 21:36:12 -0800 (PST) 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=0mq7fmSceyHOkaMupFK91gXJGzel2tmz3ud1qn1Yq1Y=; b=AtPfrA3yEYpjWQrrtj1INULzlkiT2LOpuRirdSPJd3Z0lm8XpJZKTjeAdXADMEVDzw eecNVe+oBOyuGNtlWhwQ== 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=Osoqb7bu5U+5OlFm5tjAzVTE5Fcht0iz8Fu65P7E5ZvSlU4rlPvScHwa2DCWh5W/DX Re6ojhcSBR7ygrZDXi+w== MIME-Version: 1.0 Received: by 10.143.8.2 with SMTP id l2mr1877599wfi.214.1298352971988; Mon, 21 Feb 2011 21:36:11 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 21 Feb 2011 21:36:11 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D6165F1.6010401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 21 Feb 2011 21:36:11 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636e0a7b9b03e1a049cd85bfc X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 05:35:36 -0000 --001636e0a7b9b03e1a049cd85bfc Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav wrote: > How do you envision this being incorporated into v2? Just section 5 or the > entire document? > My two cents: rather than dedicating a single section of the core doc to security considerations, smaller sections should be added to individual profiles. I think the following sections would be useful: User-agent and web-server flow: mostly the same security considerations for these two flows. I think there are subsections here. 1) Authorization server implementation 2) Client implementation Token design: Design and implementation recommendations for refresh tokens and access tokens. Client id, client secret, and assertions: when and how to use client secrets, when and how to use assertions, how to store, etc... Other flows: each of the other flows has separate security considerations. In some cases they are brief, but they pretty much always need to be there. Cheers, Brian --001636e0a7b9b03e1a049cd85bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te:
<= p class=3D"MsoNormal">How do you envision this being incorporate= d into v2? Just section 5 or the entire document?


My two cents: rather than dedi= cating a single section of the core doc to security considerations, smaller= sections should be added to individual profiles. =A0I think the following = sections would be useful:

User-agent and web-server flow: mostly the same securit= y considerations for these two flows. =A0I think there are subsections here= . =A0
=A0=A0 1) Authorization server implementation
=A0= =A0 2) Client implementation

Token design: Design and implementation recommendations= for refresh tokens and access tokens.

Client id, = client secret, and assertions: when and how to use client secrets, when and= how to use assertions, how to store, etc...

Other flows: each of the other flows has separate secur= ity considerations. =A0In some cases they are brief, but they pretty much a= lways need to be there.

Cheers,
Brian

--001636e0a7b9b03e1a049cd85bfc-- From fcorella@pomcor.com Mon Feb 21 21:56:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A733A6836 for ; Mon, 21 Feb 2011 21:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXAxlb7c-zzM for ; Mon, 21 Feb 2011 21:56:40 -0800 (PST) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by core3.amsl.com (Postfix) with SMTP id 5116C3A6835 for ; Mon, 21 Feb 2011 21:56:40 -0800 (PST) Received: from [98.139.212.152] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Feb 2011 05:57:20 -0000 Received: from [98.139.212.217] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 22 Feb 2011 05:57:20 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 22 Feb 2011 05:57:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93418.61310.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 51734 invoked by uid 60001); 22 Feb 2011 05:57:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298354239; bh=lkJKqR7rZ89hGT+PVgqEcvyAl6GZ2JwWCvRuUmnaBrM=; 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=Oni82ELdqsdy9TgI0CpUliQ/4LdB7fIs4JEs+amS7FhP6hZNrzKb0SIozfy25a2E4Fr2s+ckcgls9Pmy+mhcG6wBpsCEwIb8Cc/Ptkk7L1btbvogDxzV/gkla9U3t53JxqxzkVlA64wn2Xl6AV2T3+CAA+IxzxzCE0ESsE8vRuY= Message-ID: <862855.47753.qm@web55808.mail.re3.yahoo.com> X-YMail-OSG: ZsKFA0IVM1mg1pxiFEGFpt4CXjlO.2cvArFuYLXfNdQcC5n H5hYe.RL0RMFjotTLlPMlXxyCiizLdBsHjWaFFjbYgjObCHQq1Jv6SYjZlWW .VYQATGgkebuVlFsQrvQ9qHb1Akqby90FMyaiCesM69i.YRNxdh5rIOOpBRD Hfm4xUMA5FPpxKWxtRkWxA9GktfeKZMPKAH6Lli1PxFf.xpqi5EX3DIQJNQM _owWUa6ZVFN_oedNn0c5BaMG83Bvl8MIk60qG9bmZ3X85NyVC2nS_X4R.lgY GIvww9QlwMBQt5o96H4rplzIHzmYJza6_ZsaCnEBJyL4GtgThZRIviVUxm12 PE.lF Received: from [174.65.103.16] by web55808.mail.re3.yahoo.com via HTTP; Mon, 21 Feb 2011 21:57:19 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 21 Feb 2011 21:57:19 -0800 (PST) From: Francisco Corella To: OAuth WG , Torsten Lodderstedt In-Reply-To: <4D6165F1.6010401@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-750971263-1298354239=:47753" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 22 Feb 2011 05:56:42 -0000 --0-750971263-1298354239=:47753 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Torsten, > 4.4.1.2.=A0 Threat: Eavesdropping authorization codes >=20 > The OAuth specification does not describe any mechanism for > protecting authorization codes from eavesdroppers when they are > transmitted from the Service Provider to the Client and where the > Service Provider Grants an Access Token. >=20 > Note: A description of a similar attack on the SAML protocol can be > found at http://www.oasis-open.org/committees/download.php/3405/ > oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1). >=20 > Countermeasures: >=20 > o=A0 The authorization server SHOULD enforce a one time usage >=A0=A0=A0 restriction (see Section 5.1.5.4).=A0 Authorization server as we= ll >=A0=A0=A0 as Resource server MUST ensure that these transmissions are >=A0=A0=A0 protected using transport-layer mechanisms such as TLS or SSL >=A0=A0=A0 (see Section 5.1.1). You are talking here about eavesdropping to obtain the authorization code.=A0 The authorization code is not sent to the resource servers.=A0 I agree that the authorization code must be protected by TLS when it is sent by the client to the authorization server.=A0 But it must ALSO be protected when it is sent by the browser to the client.=A0 (The connection from the browser to the client is easier to eavesdrop on than the connection from the client to the authorization server!)=A0 (It must also be protected when sent from the authorization server to the browser in the redirection response, which is probably the case anyway, since that's the response portion of the HTTP request that authenticates the user.) > ... > > 4.4.1.6.=A0 Threat: Authorization code phishing >=20 > A hostile party could act as the client web server and get access to > the authorization code.=A0 This could be achieved using DNS or ARP > spoofing.=A0=20 Yes. > Impact: This affects web applications and may lead to a > disclosure of authorization codes and, potentially, the corresponding > access and refresh tokens. The attacker will not get the access and refresh tokens without the client_id, but doesn't need to.=A0 The attacker can impersonate the user, log in to the client if the protocol is used for social login as in "log in with Facebook", and use the client to obtain protected resources of the legitimate user and deliver them to the attacker. The attacker never sees an access token, but the client gets the access token and uses it for the benefit of the attacker. > Countermeasures: >=20 > o=A0 The client shall authenticate the server using server >=A0=A0=A0 authentication - Section 5.1.2 Really?????????=A0 The browser is sending the authorization code to the client, and the attacker is using DNS or ARP spoofing to receive it instead of the client.=A0 To prevent this, what's needed is obviously authentication of the client by the browser, not authentication of the server by the client! > o=A0 The authorization server shall require the client to authenticate >=A0=A0=A0 with a secret, so the binding of the authorization code to a >=A0=A0=A0 certain client can be validated in a reliable way (see >=A0=A0=A0 Section 5.2.4.4). Client authentication to the server does not prevent the attack. The authorization code is a credential that provides access to the user's protected resources (via the client) and allows the user to log in to the client (in a social-login scenario).=A0 Sending it without TLS protection, as OAuth 2.0 does, is tantamount to sending a user password without TLS protection.=A0=20 If you are not convinced please read the message I sent you a few weeks ago, available at http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and section 3.5.3 of the security analysis paper I announced earlier, available at http://www.pomcor.com/techreports/DoubleRedirection.pdf. (Section 3.5.3 refers to section 2; if you don't want to read the whole section 2, the relevant portion is the last three paragraphs of page 4.) Francisco --0-750971263-1298354239=:47753 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =
Hi Torsten,

> 4.4.1.2.  Threat= : Eavesdropping authorization codes
>
> The OAuth specificatio= n does not describe any mechanism for
> protecting authorization code= s from eavesdroppers when they are
> transmitted from the Service Pro= vider to the Client and where the
> Service Provider Grants an Access= Token.
>
> Note: A description of a similar attack on the SAM= L protocol can be
> found at http://www.oasis-open.org/committees/dow= nload.php/3405/
> oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1).
= >
> Countermeasures:
>
> o  The authorization s= erver SHOULD enforce a one time usage
>    restriction= (see Section 5.1.5.4).  Authorization server as well
> &nb= sp;  as Resource server MUST ensure that these transmissions are
>    protected using transport-layer mechanisms s= uch as TLS or SSL
>    (see Section 5.1.1).

You= are talking here about eavesdropping to obtain the authorization
code.&= nbsp; The authorization code is not sent to the resource servers.  Iagree that the authorization code must be protected by TLS when it is
= sent by the client to the authorization server.  But it must ALSO beprotected when it is sent by the browser to the client.  (The
con= nection from the browser to the client is easier to eavesdrop on
than th= e connection from the client to the authorization server!)  (It
mus= t also be protected when sent from the authorization server to the
brows= er in the redirection response, which is probably the case
anyway, since= that's the response portion of the HTTP request that
authenticates the = user.)

> ...
>
> 4.4.1.6.  Threat: Authorization code phishing
>
> A hostile party could act as = the client web server and get access to
> the authorization code.&nbs= p; This could be achieved using DNS or ARP
> spoofing. 

= Yes.

> Impact: This affects web applications and may lead to a> disclosure of authorization codes and, potentially, the corresponding=
> access and refresh tokens.

The attacker will not get the ac= cess and refresh tokens without the
client_id, but doesn't need to. = ; The attacker can impersonate the
user, log in to the client if the pro= tocol is used for social login
as in "log in with Facebook", and use the= client to obtain protected
resources of the legitimate user and deliver= them to the attacker.
The attacker never sees an access token, but the = client gets the
access token and uses it for the benefit of the attacker= .

> Countermeasures:
>
> o  The client shall authenticate the server using server
>    authe= ntication - Section 5.1.2

Really?????????  The browser is sendi= ng the authorization code to the
client, and the attacker is using DNS o= r ARP spoofing to receive it
instead of the client.  To prevent thi= s, what's needed is obviously
authentication of the client by the browse= r, not authentication of the
server by the client!

> o  T= he authorization server shall require the client to authenticate
>&nb= sp;   with a secret, so the binding of the authorization code to = a
>    certain client can be validated in a reliable w= ay (see
>    Section 5.2.4.4).

Client authentic= ation to the server does not prevent the attack.

The authorization c= ode is a credential that provides access to the
user's protected resourc= es (via the client) and allows the user to log in
to the client (in a social-login scenario).  Sending it without TLS
protection, = as OAuth 2.0 does, is tantamount to sending a user
password without TLS = protection. 

If you are not convinced please read the message = I sent you a few
weeks ago, available at
http://www.ietf.org/mail-a= rchive/web/oauth/current/msg04900.html, and
section 3.5.3 of the sec= urity analysis paper I announced earlier,
available at http://www.pomcor.com/te= chreports/DoubleRedirection.pdf.
(Section 3.5.3 refers to section 2;= if you don't want to read the
whole section 2, the relevant portion is = the last three paragraphs of
page 4.)

Francisco

--0-750971263-1298354239=:47753-- From tonynad@microsoft.com Tue Feb 22 08:43:44 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEF83A6940 for ; Tue, 22 Feb 2011 08:43:44 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfRWl9JRKSMb for ; Tue, 22 Feb 2011 08:43:43 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7E1783A693F for ; Tue, 22 Feb 2011 08:43:43 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Feb 2011 08:44:28 -0800 Received: from DB3EHSOBE004.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 22 Feb 2011 08:44:26 -0800 Received: from mail105-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.8; Tue, 22 Feb 2011 16:44:25 +0000 Received: from mail105-db3 (localhost.localdomain [127.0.0.1]) by mail105-db3-R.bigfish.com (Postfix) with ESMTP id C233F1980489 for ; Tue, 22 Feb 2011 16:44:25 +0000 (UTC) X-SpamScore: -41 X-BigFish: PS-41(zz1b0bM542N9371PzzdafM1202h1082kzz8275bh8275dh1033ILz31h2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail105-db3 (localhost.localdomain [127.0.0.1]) by mail105-db3 (MessageSwitch) id 1298393056822873_16830; Tue, 22 Feb 2011 16:44:16 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.253]) by mail105-db3.bigfish.com (Postfix) with ESMTP id 496971AC8056; Tue, 22 Feb 2011 16:43:24 +0000 (UTC) Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 22 Feb 2011 16:43:11 +0000 Received: from SN1PRD0302MB097.namprd03.prod.outlook.com ([169.254.8.45]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.027; Tue, 22 Feb 2011 16:43:09 +0000 From: Anthony Nadalin To: Phil Hunt , OAuth WG Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth Thread-Index: AQHL0ipTtjZaSpjXs0eFEWU3KTMxjpQNusfw Date: Tue, 22 Feb 2011 16:43:08 +0000 Message-ID: References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> In-Reply-To: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.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: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:43:44 -0000 Nice job Phil -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, February 21, 2011 4:46 PM To: OAuth WG Subject: [OAUTH-WG] Flowchart for legs of OAuth FYI. I published a blog post with a flow-chart explaining the legs of OAuth= . http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html Please let me know if any corrections should be made, or for that matter, a= ny improvements! Phil phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Feb 22 10:39:59 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BCC3A6966 for ; Tue, 22 Feb 2011 10:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms7BJNrHajNv for ; Tue, 22 Feb 2011 10:39:54 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E41FA3A695D for ; Tue, 22 Feb 2011 10:39:49 -0800 (PST) Received: (qmail 22155 invoked from network); 22 Feb 2011 18:40:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Feb 2011 18:40:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Feb 2011 11:40:28 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 22 Feb 2011 11:40:12 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 Thread-Index: AcvSUmxeu8ZLGiUAR0yfeSjRDfnrIQAbUL8g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A91D47FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D6165F1.6010401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A91D47FFP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:39:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D47FFP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF rules require a security considerations section. That doesn't mean we = can't also incorporate additional security text into each grant section. Bu= t having one comprehensive security section makes the other parts easier to= read. EHL From: Brian Eaton [mailto:beaton@google.com] Sent: Monday, February 21, 2011 9:36 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt= -oauth-security-00 On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav > wrote: How do you envision this being incorporated into v2? Just section 5 or the = entire document? My two cents: rather than dedicating a single section of the core doc to se= curity considerations, smaller sections should be added to individual profi= les. I think the following sections would be useful: User-agent and web-server flow: mostly the same security considerations for= these two flows. I think there are subsections here. 1) Authorization server implementation 2) Client implementation Token design: Design and implementation recommendations for refresh tokens = and access tokens. Client id, client secret, and assertions: when and how to use client secret= s, when and how to use assertions, how to store, etc... Other flows: each of the other flows has separate security considerations. = In some cases they are brief, but they pretty much always need to be there= . Cheers, Brian --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D47FFP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IETF rule= s require a security considerations section. That doesn’t mean we can= ’t also incorporate additional security text into each grant section.= But having one comprehensive security section makes the other parts easier= to read.

 

EHL

 

From: Brian Eaton [mailto:beaton@google.com]
Sent: = Monday, February 21, 2011 9:36 PM
To: Eran Hammer-Lahav
Cc:= Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: N= ew Version Notification for draft-lodderstedt-oauth-security-00<= /span>

 

On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:<= /p>

How do you envision this being incorporated into v2? Just section 5 or= the entire document?

=

 

My two cents: rather than dedicating a single section of the core doc t= o security considerations, smaller sections should be added to individual p= rofiles.  I think the following sections would be useful:

 

User-agent and web-server flow: mostly the same security consi= derations for these two flows.  I think there are subsections here. &n= bsp;

   1) Authoriz= ation server implementation

&= nbsp;  2) Client implementation

 

Token design: = Design and implementation recommendations for refresh tokens and access tok= ens.

 

Client id, client secret, and assertions: when= and how to use client secrets, when and how to use assertions, how to stor= e, etc...

 

Other flows: each of the other flows has = separate security considerations.  In some cases they are brief, but t= hey pretty much always need to be there.

 

Cheers,

Brian

 

<= /html>= --_000_90C41DD21FB7C64BB94121FBBC2E723445A91D47FFP3PW5EX1MB01E_-- From torsten@lodderstedt.net Wed Feb 23 11:13:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEEC3A6940 for ; Wed, 23 Feb 2011 11:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L2KUkFP-iAp for ; Wed, 23 Feb 2011 11:13:09 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id E0B4C3A695A for ; Wed, 23 Feb 2011 11:13:08 -0800 (PST) Received: from [79.253.48.94] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PsK9q-0001P6-89; Wed, 23 Feb 2011 20:13:54 +0100 Message-ID: <4D655C74.4090209@lodderstedt.net> Date: Wed, 23 Feb 2011 20:13:56 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4D6165F1.6010401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A91D4581@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D47FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A91D47FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------060205020400020507030404" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:13:14 -0000 This is a multi-part message in MIME format. --------------060205020400020507030404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I would tend to add section 5 as security considerations section to the core draft expanded by descriptions of relevant (generic) threats. We could also add parts of the flow-specific threat model descriptions into to flow-specific sections of the core draft and link them to the security considerations sections. @Brian: where would you place the discussion of the design alternatives? Our document has them before the threat model. regards, Torsten. Am 22.02.2011 19:40, schrieb Eran Hammer-Lahav: > > IETF rules require a security considerations section. That doesn't > mean we can't also incorporate additional security text into each > grant section. But having one comprehensive security section makes the > other parts easier to read > > EHL > > *From:*Brian Eaton [mailto:beaton@google.com] > *Sent:* Monday, February 21, 2011 9:36 PM > *To:* Eran Hammer-Lahav > *Cc:* Torsten Lodderstedt; OAuth WG > *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for > draft-lodderstedt-oauth-security-00 > > On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav > > wrote: > > How do you envision this being incorporated into v2? Just section > 5 or the entire document? > > My two cents: rather than dedicating a single section of the core doc > to security considerations, smaller sections should be added to > individual profiles. I think the following sections would be useful: > > User-agent and web-server flow: mostly the same security > considerations for these two flows. I think there are subsections here. > > 1) Authorization server implementation > > 2) Client implementation > > Token design: Design and implementation recommendations for refresh > tokens and access tokens. > > Client id, client secret, and assertions: when and how to use client > secrets, when and how to use assertions, how to store, etc... > > Other flows: each of the other flows has separate security > considerations. In some cases they are brief, but they pretty much > always need to be there. > > Cheers, > > Brian > --------------060205020400020507030404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would tend to add section 5 as security considerations section to the core draft expanded by descriptions of relevant (generic) threats.

We could also add parts of the flow-specific threat model descriptions into to flow-specific sections of the core draft and link them to the security considerations sections.

@Brian: where would you place the discussion of the design alternatives? Our document has them before the threat model.

regards,
Torsten.

Am 22.02.2011 19:40, schrieb Eran Hammer-Lahav:

IETF rules require a security considerations section. That doesn’t mean we can’t also incorporate additional security text into each grant section. But having one comprehensive security section makes the other parts easier to read

 

EHL

 

From: Brian Eaton [mailto:beaton@google.com]
Sent: Monday, February 21, 2011 9:36 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00

 

On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

How do you envision this being incorporated into v2? Just section 5 or the entire document?

 

My two cents: rather than dedicating a single section of the core doc to security considerations, smaller sections should be added to individual profiles.  I think the following sections would be useful:

 

User-agent and web-server flow: mostly the same security considerations for these two flows.  I think there are subsections here.  

   1) Authorization server implementation

   2) Client implementation

 

Token design: Design and implementation recommendations for refresh tokens and access tokens.

 

Client id, client secret, and assertions: when and how to use client secrets, when and how to use assertions, how to store, etc...

 

Other flows: each of the other flows has separate security considerations.  In some cases they are brief, but they pretty much always need to be there.

 

Cheers,

Brian

 

--------------060205020400020507030404-- From torsten@lodderstedt.net Wed Feb 23 11:43:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4DF3A67F9 for ; Wed, 23 Feb 2011 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nM7FdrvxqmS for ; Wed, 23 Feb 2011 11:43:50 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 94CFF3A67ED for ; Wed, 23 Feb 2011 11:43:49 -0800 (PST) Received: from [79.253.48.94] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PsKdW-0002bu-Sm; Wed, 23 Feb 2011 20:44:34 +0100 Message-ID: <4D6563A5.7000402@lodderstedt.net> Date: Wed, 23 Feb 2011 20:44:37 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fcorella@pomcor.com References: <862855.47753.qm@web55808.mail.re3.yahoo.com> In-Reply-To: <862855.47753.qm@web55808.mail.re3.yahoo.com> Content-Type: multipart/alternative; boundary="------------020100040404090801040500" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:43:51 -0000 This is a multi-part message in MIME format. --------------020100040404090801040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Francisco, Am 22.02.2011 06:57, schrieb Francisco Corella: > Hi Torsten, > > > 4.4.1.2. Threat: Eavesdropping authorization codes > > > > The OAuth specification does not describe any mechanism for > > protecting authorization codes from eavesdroppers when they are > > transmitted from the Service Provider to the Client and where the > > Service Provider Grants an Access Token. > > > > Note: A description of a similar attack on the SAML protocol can be > > found at http://www.oasis-open.org/committees/download.php/3405/ > > oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1). > > > > Countermeasures: > > > > o The authorization server SHOULD enforce a one time usage > > restriction (see Section 5.1.5.4). Authorization server as well > > as Resource server MUST ensure that these transmissions are > > protected using transport-layer mechanisms such as TLS or SSL > > (see Section 5.1.1). > > You are talking here about eavesdropping to obtain the authorization > code. The authorization code is not sent to the resource servers. I > true, this was a mistake. > agree that the authorization code must be protected by TLS when it is > sent by the client to the authorization server. But it must ALSO be > protected when it is sent by the browser to the client. (The > connection from the browser to the client is easier to eavesdrop on > than the connection from the client to the authorization server!) (It > must also be protected when sent from the authorization server to the > browser in the redirection response, which is probably the case > anyway, since that's the response portion of the HTTP request that > authenticates the user.) > That's correct. I changed resource server to client. > > > ... > > > > 4.4.1.6. Threat: Authorization code phishing > > > > A hostile party could act as the client web server and get access to > > the authorization code. This could be achieved using DNS or ARP > > spoofing. > > Yes. > > > Impact: This affects web applications and may lead to a > > disclosure of authorization codes and, potentially, the corresponding > > access and refresh tokens. > > The attacker will not get the access and refresh tokens without the > client_id, but doesn't need to. > whether this is an obstacle mainly depends on whether a client secret is associated with this client_id. > The attacker can impersonate the > user, log in to the client if the protocol is used for social login > as in "log in with Facebook", and use the client to obtain protected > resources of the legitimate user and deliver them to the attacker. > The attacker never sees an access token, but the client gets the > access token and uses it for the benefit of the attacker. > You describe the potential impact of a spoofing attack on the client web site, correct? Is this specific to OAuth? I ask because the focus of the document is on OAuth specific threats. > > > Countermeasures: > > > > o The client shall authenticate the server using server > > authentication - Section 5.1.2 > > Really????????? The browser is sending the authorization code to the > client, and the attacker is using DNS or ARP spoofing to receive it > instead of the client. To prevent this, what's needed is obviously > authentication of the client by the browser, not authentication of the > server by the client! > You are right. Things are getting less obvious after 6 month of work on a document :-) I corrected that. > > > o The authorization server shall require the client to authenticate > > with a secret, so the binding of the authorization code to a > > certain client can be validated in a reliable way (see > > Section 5.2.4.4). > > Client authentication to the server does not prevent the attack. > > The authorization code is a credential that provides access to the > user's protected resources (via the client) and allows the user to log in > to the client (in a social-login scenario). Sending it without TLS > protection, as OAuth 2.0 does, is tantamount to sending a user > password without TLS protection. > Hmmh, OAuth 2.0 is just a protocol. Implementations decide to send/receive authorization codes with or without TLS protection. Having the security threat model now, the OAuth 2.0 spec could declare TLS protection a MUST for the redirect back to the clients. I think that's what you would like to see? regards, Torsten. > > If you are not convinced please read the message I sent you a few > weeks ago, available at > http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and > section 3.5.3 of the security analysis paper I announced earlier, > available at http://www.pomcor.com/techreports/DoubleRedirection.pdf. > (Section 3.5.3 refers to section 2; if you don't want to read the > whole section 2, the relevant portion is the last three paragraphs of > page 4.) > > Francisco > --------------020100040404090801040500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Francisco,

Am 22.02.2011 06:57, schrieb Francisco Corella:
Hi Torsten,

> 4.4.1.2.  Threat: Eavesdropping authorization codes
>
> The OAuth specification does not describe any mechanism for
> protecting authorization codes from eavesdroppers when they are
> transmitted from the Service Provider to the Client and where the
> Service Provider Grants an Access Token.
>
> Note: A description of a similar attack on the SAML protocol can be
> found at http://www.oasis-open.org/committees/download.php/3405/
> oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1).
>
> Countermeasures:
>
> o  The authorization server SHOULD enforce a one time usage
>    restriction (see Section 5.1.5.4).  Authorization server as well
>    as Resource server MUST ensure that these transmissions are
>    protected using transport-layer mechanisms such as TLS or SSL
>    (see Section 5.1.1).

You are talking here about eavesdropping to obtain the authorization
code.  The authorization code is not sent to the resource servers.  I

true, this was a mistake.

agree that the authorization code must be protected by TLS when it is
sent by the client to the authorization server.  But it must ALSO be
protected when it is sent by the browser to the client.  (The
connection from the browser to the client is easier to eavesdrop on
than the connection from the client to the authorization server!)  (It
must also be protected when sent from the authorization server to the
browser in the redirection response, which is probably the case
anyway, since that's the response portion of the HTTP request that
authenticates the user.)

That's correct. I changed resource server to client.


> ...
>
> 4.4.1.6.  Threat: Authorization code phishing
>
> A hostile party could act as the client web server and get access to
> the authorization code.  This could be achieved using DNS or ARP
> spoofing. 

Yes.

> Impact: This affects web applications and may lead to a
> disclosure of authorization codes and, potentially, the corresponding
> access and refresh tokens.

The attacker will not get the access and refresh tokens without the
client_id, but doesn't need to. 

whether this is an obstacle mainly depends on whether a client secret is associated with this client_id.

The attacker can impersonate the
user, log in to the client if the protocol is used for social login
as in "log in with Facebook", and use the client to obtain protected
resources of the legitimate user and deliver them to the attacker.
The attacker never sees an access token, but the client gets the
access token and uses it for the benefit of the attacker.

You describe the potential impact of a spoofing attack on the client web site, correct? Is this specific to OAuth? I ask because the focus of the document is on OAuth specific threats.


> Countermeasures:
>
> o  The client shall authenticate the server using server
>    authentication - Section 5.1.2

Really?????????  The browser is sending the authorization code to the
client, and the attacker is using DNS or ARP spoofing to receive it
instead of the client.  To prevent this, what's needed is obviously
authentication of the client by the browser, not authentication of the
server by the client!

You are right. Things are getting less obvious after 6 month of work on a document :-) I corrected that.


> o  The authorization server shall require the client to authenticate
>    with a secret, so the binding of the authorization code to a
>    certain client can be validated in a reliable way (see
>    Section 5.2.4.4).

Client authentication to the server does not prevent the attack.

The authorization code is a credential that provides access to the
user's protected resources (via the client) and allows the user to log in
to the client (in a social-login scenario).  Sending it without TLS
protection, as OAuth 2.0 does, is tantamount to sending a user
password without TLS protection. 

Hmmh, OAuth 2.0 is just a protocol. Implementations decide to send/receive authorization codes with or without TLS protection. Having the security threat model now, the OAuth 2.0 spec could declare TLS protection a MUST for the redirect back to the clients. I think that's what you would like to see?

regards,
Torsten.


If you are not convinced please read the message I sent you a few
weeks ago, available at
http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, and
section 3.5.3 of the security analysis paper I announced earlier,
available at http://www.pomcor.com/techreports/DoubleRedirection.pdf.
(Section 3.5.3 refers to section 2; if you don't want to read the
whole section 2, the relevant portion is the last three paragraphs of
page 4.)

Francisco
--------------020100040404090801040500-- From progrium@twilio.com Wed Feb 23 14:35:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D513A6955 for ; Wed, 23 Feb 2011 14:35:14 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiCdkhEnCcmJ for ; Wed, 23 Feb 2011 14:35:13 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 169FD3A693D for ; Wed, 23 Feb 2011 14:35:13 -0800 (PST) Received: by vws6 with SMTP id 6so2644828vws.31 for ; Wed, 23 Feb 2011 14:36:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.166.226 with SMTP id zj2mr182589vdb.80.1298500560549; Wed, 23 Feb 2011 14:36:00 -0800 (PST) Received: by 10.52.160.201 with HTTP; Wed, 23 Feb 2011 14:36:00 -0800 (PST) Date: Wed, 23 Feb 2011 14:36:00 -0800 Message-ID: From: Jeff Lindsay To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=bcaec53f962ba6f8c1049cfab881 Subject: [OAUTH-WG] Ruby JWT implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 22:35:14 -0000 --bcaec53f962ba6f8c1049cfab881 Content-Type: text/plain; charset=ISO-8859-1 We're adopting JWT at Twilio and building out a bunch of libraries for it. We have them for Python, PHP, and Ruby and now we're starting to package them up for public use. First one released is Ruby: https://github.com/progrium/ruby-jwt --bcaec53f962ba6f8c1049cfab881 Content-Type: text/html; charset=ISO-8859-1
We're adopting JWT at Twilio and building out a bunch of libraries for it. We have them for Python, PHP, and Ruby and now we're starting to package them up for public use. First one released is Ruby:

https://github.com/progrium/ruby-jwt --bcaec53f962ba6f8c1049cfab881-- From fcorella@pomcor.com Wed Feb 23 14:44:35 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B713A692D for ; Wed, 23 Feb 2011 14:44:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffEEtVRGeTUg for ; Wed, 23 Feb 2011 14:44:34 -0800 (PST) Received: from nm14-vm0.bullet.mail.ac4.yahoo.com (nm14-vm0.bullet.mail.ac4.yahoo.com [98.139.52.234]) by core3.amsl.com (Postfix) with SMTP id E51B03A68EE for ; Wed, 23 Feb 2011 14:44:33 -0800 (PST) Received: from [98.139.52.193] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 22:45:21 -0000 Received: from [98.139.52.178] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 22:45:21 -0000 Received: from [127.0.0.1] by omp1061.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 22:45:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 743399.75450.bm@omp1061.mail.ac4.yahoo.com Received: (qmail 15214 invoked by uid 60001); 23 Feb 2011 22:45:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298501121; bh=fj53kP+zZ+o9Pv6QOuKR+M+dAxlOQWbJNuiX2AoJxCc=; 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=q7iajeNiH+3GNmWZewBiJ1g4beedTE0X30k0kh3NPTDpmV39JouVe7qen9vjoa7BiIYgZtdSsQwDlfnUB4tgjjygT1pNarV2Qs+zcigEQyQGejG5swL9IIv7F0qX1NmwU436gGF0NKDh5k4O7qhl2J0X0G0LXEcLbnMGDUX4K8U= Message-ID: <622228.13669.qm@web55803.mail.re3.yahoo.com> X-YMail-OSG: .Tg8uwEVM1kw63no3RoT0Zvj23Eo6219PCK932D2tI5050F _3O7Kq3QNlTtbNr0IVftu250ShAXEM4GpRLbJWCAVF_eYbr7K13uny6ixNfp Ot5WKS6nmjHkCiRtfn8MWJbkGXO5oF70u_jCDQfUanGzkpROKXKAXKsTyZKJ zB_msyh1aHYXq9beeowVOt9cdptntSuHoV9hVKIHZxm43DFihyaOUDX41erC F6laUkMXNaguCsin5lMBoCFtONzUOfaMtONWmcmQeHYNH.sShL3C0h2GFmTG sVl4hwc3c3pO13F0p2H0UAbdmUZiXi.ym8pkdlNXDsve.Us3Db6Pe9xekP6k 417oaq8ZDaNkm2YYKu4lWuSlbS8lOxz9CwtiJ1ac7s8ef8aV274wcPJYaYk4 KVd0- Received: from [67.91.91.101] by web55803.mail.re3.yahoo.com via HTTP; Wed, 23 Feb 2011 14:45:21 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Wed, 23 Feb 2011 14:45:21 -0800 (PST) From: Francisco Corella To: Torsten Lodderstedt In-Reply-To: <4D6563A5.7000402@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1462562034-1298501121=:13669" Cc: OAuth WG , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 23 Feb 2011 22:44:35 -0000 --0-1462562034-1298501121=:13669 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Torsten, > > The attacker will not get the access and refresh tokens > > without the client_id, but doesn't need to. >=20 > whether this is an obstacle mainly depends on whether a > client secret is associated with this client_id. You're right, I meant to say client_secret, not client_id. > ... > > > The attacker can impersonate the user, log in to the > > client if the protocol is used for social login as in > > "log in with Facebook", and use the client to obtain > > protected resources of the legitimate user and deliver > > them to the attacker.=A0 The attacker never sees an access > > token, but the client gets the access token and uses it > > for the benefit of the attacker. >=20 > You describe the potential impact of a spoofing attack on > the client web site, correct? Is this specific to OAuth? I > ask because the focus of the document is on OAuth specific > threats. I was talking about your scenario where an attacker uses DNS spoofing or ARP spoofing to get the authorization code, and more generally about an attacker obtaining the authorization code by any means.=A0 It's definitely specific to OAuth. > ... > > > The authorization code is a credential that provides > > access to the user's protected resources (via the > > client) and allows the user to log in to the client (in > > a social-login scenario).=A0 Sending it without TLS > > protection, as OAuth 2.0 does, is tantamount to sending > > a user password without TLS protection. >=20 > Hmmh, OAuth 2.0 is just a protocol. Implementations decide > to send/receive authorization codes with or without TLS > protection. Having the security threat model now, the > OAuth 2.0 spec could declare TLS protection a MUST for the > redirect back to the clients. I think that's what you > would like to see? Yes, I'm saying that transmission of the authorization code to the client must be protected by TLS, just like you say that transmission of the authorization code to the authorization server must be protected by TLS (section 4.4.1.2) and all transmissions of the access token must be protected by TLS (section 4.1.3), and just like the bearer token specification says that transmission of the token to a resource server must be protected by TLS (section 3.2). The thing to keep in mind is that the authorization code deserves as much protection as the access token because an attacker can use the authorization code to cause the client to obtain the access token and use it for the attacker's benefit.=A0 Plus, the attacker can use the authorization code to log in to the client in a social login scenario, so the authorization code is arguably more valuable than the access token to the attacker. Francisco --0-1462562034-1298501121=:13669 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Torsten,

> > The attacker wil= l not get the access and refresh tokens
> > without the client_id,= but doesn't need to.
>
> whether this is an obstacle mainly d= epends on whether a
> client secret is associated with this client_id= .

You're right, I meant to say client_secret, not client_id.

= > ...
>
> > The attacker can impersonate the user, log in= to the
> > client if the protocol is used for social login as in<= br>> > "log in with Facebook", and use the client to obtain
> &= gt; protected resources of the legitimate user and deliver
> > the= m to the attacker.  The attacker never sees an access
> > tok= en, but the client gets the access token and uses it
> > for the b= enefit of the attacker.
>
> You describe the potential impact = of a spoofing attack on
> the client web site, correct? Is this specifi= c to OAuth? I
> ask because the focus of the document is on OAuth spe= cific
> threats.

I was talking about your scenario where an at= tacker uses DNS
spoofing or ARP spoofing to get the authorization code, = and
more generally about an attacker obtaining the authorization
code= by any means.  It's definitely specific to OAuth.

> ...
= >
> > The authorization code is a credential that provides
&= gt; > access to the user's protected resources (via the
> > cli= ent) and allows the user to log in to the client (in
> > a social-= login scenario).  Sending it without TLS
> > protection, as O= Auth 2.0 does, is tantamount to sending
> > a user password withou= t TLS protection.
>
> Hmmh, OAuth 2.0 is just a protocol. Impl= ementations decide
> to send/receive authorization codes with or without TLS
> protection. Having the security threat model now, t= he
> OAuth 2.0 spec could declare TLS protection a MUST for the
&g= t; redirect back to the clients. I think that's what you
> would like= to see?

Yes, I'm saying that transmission of the authorization code=
to the client must be protected by TLS, just like you say
that trans= mission of the authorization code to the
authorization server must be pr= otected by TLS (section
4.4.1.2) and all transmissions of the access tok= en must be
protected by TLS (section 4.1.3), and just like the bearertoken specification says that transmission of the token to a
resource s= erver must be protected by TLS (section 3.2).

The thing to keep in m= ind is that the authorization code
deserves as much protection as the ac= cess token because an
attacker can use the authorization code to cause t= he client
to obtain the access token and use it for the attacker's
benefit.  Plus, the attacker can use the authorization = code
to log in to the client in a social login scenario, so the
autho= rization code is arguably more valuable than the access
token to the att= acker.

Francisco

--0-1462562034-1298501121=:13669-- From hannes.tschofenig@gmx.net Thu Feb 24 05:16:22 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9383A6ADE for ; Thu, 24 Feb 2011 05:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot3x1S0rYcJb for ; Thu, 24 Feb 2011 05:16:22 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id B098C3A6B12 for ; Thu, 24 Feb 2011 05:16:21 -0800 (PST) Received: (qmail invoked by alias); 24 Feb 2011 13:17:09 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp064) with SMTP; 24 Feb 2011 14:17:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1854oNt+HE5Jo0+yqJ3B6g7lm9+96Wjf8SHdqcv6G Q1Zh4zjZg7z5w+ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2011 15:17:09 +0200 Message-Id: To: Axel Nennker , progrium@twilio.com Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: [OAUTH-WG] JWT Implementation Question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 13:16:23 -0000 Hey Axel, Hi Jeff,=20 looking at your post regarding the JWT implementation I was wondering = about one aspect: You are providing an implementation in Java, Python, = PHP, and Ruby.=20 Why didn't you implement a sub-set of the CMS implementation for signing = instead? Maybe you could have used existing libraries already. Ciao Hannes From Axel.Nennker@telekom.de Thu Feb 24 06:10:55 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109DE3A6B2B; Thu, 24 Feb 2011 06:10:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSWsKUH7ymxX; Thu, 24 Feb 2011 06:10:54 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 7AF0E3A6B26; Thu, 24 Feb 2011 06:10:51 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail71.telekom.de with ESMTP; 24 Feb 2011 15:11:33 +0100 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Feb 2011 15:11:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2011 15:11:32 +0100 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA305B5BB2B@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] JWT Implementation Question Thread-Index: AcvUJUZzj1rpSRZxQAOvPPY5Tl/6ZQAAFv9A References: From: To: X-OriginalArrivalTime: 24 Feb 2011 14:11:33.0262 (UTC) FILETIME=[BD7852E0:01CBD42C] Cc: woes@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Implementation Question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 14:10:55 -0000 I had all the java crypto routines (using Bouncycastle and lightcrypto libraries) in the xmldap library already and only needed to re-package.=20 The jwt signature stuff is super simple. Although I use ASN.1 in the xmldap library too (to extract icons from X509 certificates) I think that ASN.1 is unneeded to sign some bytes. In that regard CMS is simply too complicated. Probably it can do much more than jwt... In their latest version Bouncycastle just fixed the ASN.1 routines ... When you look at the xmldap WebTokenTest JUNIT test cases =20 https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x mldap/json/WebTokenTest.java You'll see that generating and validating jwt signatures is very easy. And the implementation for all three specified algorithms in all specified keysizes and additionally RSAOAEP+AESCBC encryption is done in 455 lines.=20 Even less when I would clean that up. https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmlda p/json/WebToken.java Although I am sure there is room for improvement in this implementation. -Axel CMS http://tools.ietf.org/html/rfc5652 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Thursday, February 24, 2011 2:17 PM > To: Nennker, Axel; progrium@twilio.com > Cc: OAuth WG > Subject: [OAUTH-WG] JWT Implementation Question >=20 > Hey Axel, Hi Jeff,=20 >=20 > looking at your post regarding the JWT implementation I was=20 > wondering about one aspect: You are providing an=20 > implementation in Java, Python, PHP, and Ruby.=20 >=20 > Why didn't you implement a sub-set of the CMS implementation=20 > for signing instead? Maybe you could have used existing=20 > libraries already. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From progrium@twilio.com Thu Feb 24 10:59:42 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62893A67DF for ; Thu, 24 Feb 2011 10:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG5aOxN34Q5X for ; Thu, 24 Feb 2011 10:59:42 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id E93763A67EA for ; Thu, 24 Feb 2011 10:59:41 -0800 (PST) Received: by vxg33 with SMTP id 33so727554vxg.31 for ; Thu, 24 Feb 2011 11:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.155.1 with SMTP id vs1mr1975228vdb.266.1298573690028; Thu, 24 Feb 2011 10:54:50 -0800 (PST) Received: by 10.52.160.201 with HTTP; Thu, 24 Feb 2011 10:54:49 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Feb 2011 10:54:49 -0800 Message-ID: From: Jeff Lindsay To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=bcaec53f9699834728049d0bbfc7 Cc: OAuth WG , Axel Nennker Subject: Re: [OAUTH-WG] JWT Implementation Question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 18:59:42 -0000 --bcaec53f9699834728049d0bbfc7 Content-Type: text/plain; charset=ISO-8859-1 Hannes, Twilio's API is our product. Whatever we chose for cryptographic signing and message serialization would have to be something that our users can understand quickly and easily. In many cases, these users will have little to no experience with some of these technologies. JWT is the closest thing to satisfying our test of simplicity. -jeff On Thu, Feb 24, 2011 at 5:17 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hey Axel, Hi Jeff, > > looking at your post regarding the JWT implementation I was wondering about > one aspect: You are providing an implementation in Java, Python, PHP, and > Ruby. > > Why didn't you implement a sub-set of the CMS implementation for signing > instead? Maybe you could have used existing libraries already. > > Ciao > Hannes > > --bcaec53f9699834728049d0bbfc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hannes,

Twilio's API is our product. Whatever we cho= se for cryptographic signing and message serialization would have to be som= ething that our users can understand quickly and easily. In many cases, the= se users will have little to no experience with some of these technologies.= JWT is the closest thing to satisfying our test of simplicity.

-jeff

On Thu, Feb 24,= 2011 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:=
Hey Axel, Hi Jeff,

looking at your post regarding the JWT implementation I was wondering about= one aspect: You are providing an implementation in Java, Python, PHP, and = Ruby.

Why didn't you implement a sub-set of the CMS implementation for signin= g instead? Maybe you could have used existing libraries already.

Ciao
Hannes


--bcaec53f9699834728049d0bbfc7-- From progrium@twilio.com Thu Feb 24 12:58:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED81B3A6848 for ; Thu, 24 Feb 2011 12:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.250, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S35dJgkYt0Bj for ; Thu, 24 Feb 2011 12:58:13 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E2A323A6802 for ; Thu, 24 Feb 2011 12:58:12 -0800 (PST) Received: by vws6 with SMTP id 6so911911vws.31 for ; Thu, 24 Feb 2011 12:59:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.158.229 with SMTP id wx5mr2641828vdb.40.1298581109040; Thu, 24 Feb 2011 12:58:29 -0800 (PST) Received: by 10.52.160.201 with HTTP; Thu, 24 Feb 2011 12:58:29 -0800 (PST) Date: Thu, 24 Feb 2011 12:58:29 -0800 Message-ID: From: Jeff Lindsay To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=bcaec53f9691b76d46049d0d7987 Subject: [OAUTH-WG] Python JWT implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 20:58:14 -0000 --bcaec53f9691b76d46049d0d7987 Content-Type: text/plain; charset=ISO-8859-1 Here's our Python implementation, ready to use. Any feedback welcome. (Patches, too!) https://github.com/progrium/pyjwt --bcaec53f9691b76d46049d0d7987 Content-Type: text/html; charset=ISO-8859-1 Here's our Python implementation, ready to use. Any feedback welcome. (Patches, too!)

--bcaec53f9691b76d46049d0d7987-- From James.H.Manger@team.telstra.com Thu Feb 24 16:07:53 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7D53A688A; Thu, 24 Feb 2011 16:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY1GMoJ0BdAe; Thu, 24 Feb 2011 16:07:48 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 367033A635F; Thu, 24 Feb 2011 16:07:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,221,1296997200"; d="scan'208,217";a="29521350" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 25 Feb 2011 11:08:35 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6267"; a="20255544" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdni.tcif.telstra.com.au with ESMTP; 25 Feb 2011 11:08:35 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 25 Feb 2011 11:08:34 +1100 From: "Manger, James H" To: OAuth Mailing List , "websec@ietf.org" Date: Fri, 25 Feb 2011 11:08:33 +1100 Thread-Topic: Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvUgCPYCfnEh2l8Tj+BafbhN2rcIQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 00:07:53 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Q. Should an OAuth client app list the authorization server in the Origin h= eader of requests to resource servers? In OAuth (delegation) flows a server dynamically issues credentials (such a= s a bearer token) to a client app to use in subsequent HTTP requests to oth= er servers. To combat login cross-site request forgery (CSRF) attacks [1] (= where an attacker's server issues the attacker's credentials to a client ap= p to use on behalf of a victim at a legitimate server) the client app needs= to indicate where the credentials came from. The Origin header [2] looks l= ike the right place to indicate this. [For the OAuth list: The Origin HTTP request header "indicates the origin(s= ) that caused the user agent to issue the request" [http://tools.ietf.org/h= tml/draft-ietf-websec-origin-00#section-6.2].] [For the WebSec list: An OAuth credential from an authorization server is a= bit like a cookie, but not restricted to the same origin.] Example: Client to (malicious) authorization server: -> POST /token HTTP/1.1 Host: login.example.com ... <- HTTP/1.1 200 OK ... { "access_token": "SlAV32hkKG", ...} Client to resource server: -> POST /uploadData HTTP/1.1 Host: api.exampledata.com Authorization: BEARER SlAV32hkKG Origin: https://login.example.com ... There can be other servers that contribute to a client app making a request= . For instance, one server can redirect to another. A Origin request header= can list multiple origins. The server will not be able to distinguish whic= h origin issued OAuth credentials from which issued a redirect etc. That mi= ght not matter if a server has to trust all the values listed in the Origin= header. Q. Is it the group's expectation that servers checking the Origin header wi= ll require all the listed origins to be trusted? [1] Robust Defenses for Cross Site Request Forgery, http://www.adambarth.co= m/papers/2008/barth-jackson-mitchell-b.pdf [2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-or= igin [3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-= abarth-principles-of-origin -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Q. Should an OAuth client app list the authorization= server in the Origin header of requests to resource servers?

 

In OAuth (delegation) flows a server dynamically iss= ues credentials (such as a bearer token) to a client app to use in subseque= nt HTTP requests to other servers. To combat login cross-site request forge= ry (CSRF) attacks [1] (where an attacker’s server issues the attacker’s credentials to a client app to use on b= ehalf of a victim at a legitimate server) the client app needs to indicate = where the credentials came from. The Origin header [2] looks like the right= place to indicate this.

 

[For the OAuth list: The Origin HTTP request header = “indicates the origin(s) that caused the user agent to issue the requ= est” [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-= 6.2].]

 

[For the WebSec list: An OAuth credential from an au= thorization server is a bit like a cookie, but not restricted to the same o= rigin.]

 

 

Example:

 

  Client to (malicious) authorization server: -= >

    POST /token HTTP/1.1

    Host: login.example.com

    …

  <-

    HTTP/1.1 200 OK

    …

    { "access_token": "= ;SlAV32hkKG", …}

 

  Client to resource server: ->

    POST /uploadData HTTP/1.1

    Host: api.exampledata.com

    Authorization: BEARER SlAV32hkKG<= o:p>

    Origin: https://login.example.com=

    …

 

 

There can be other servers that contribute to a clie= nt app making a request. For instance, one server can redirect to another. = A Origin request header can list multiple origins. The server will not be a= ble to distinguish which origin issued OAuth credentials from which issued a redirect etc. That might not matter = if a server has to trust all the values listed in the Origin header.

Q. Is it the group’s expectation that servers = checking the Origin header will require all the listed origins to be truste= d?

 

[1] Robust Defenses for Cross Site Request Forgery, = http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf<= /o:p>

[2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-origin

[3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-abarth-principles-of-origin=

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E1127DCD2142WSMSG3153Vsrv_-- From Hannes.Tschofenig@gmx.net Thu Feb 24 23:36:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C5A3A691E for ; Thu, 24 Feb 2011 23:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad8bkgzbYMH0 for ; Thu, 24 Feb 2011 23:36:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 073253A6828 for ; Thu, 24 Feb 2011 23:36:22 -0800 (PST) Received: (qmail invoked by alias); 25 Feb 2011 07:37:13 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp065) with SMTP; 25 Feb 2011 08:37:13 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/LjMI83GzLyMdB5uu7zs9iz3Gw7TcsERYvMABdAl TP5qMqDVJKi4zq Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Hannes Tschofenig Date: Fri, 25 Feb 2011 09:37:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110224233440.05A3A3A6876@core3.amsl.com> To: OAuth WG X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [OAUTH-WG] Fwd: OAUTH - Requested session has been scheduled for IETF 80 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 07:36:24 -0000 FYI: Our WG session got scheduled.=20 Begin forwarded message: > From: IETF Secretariat > Date: February 25, 2011 1:34:40 AM GMT+02:00 > To: Hannes.Tschofenig@gmx.net > Cc: romeda@gmail.com, presnick@qualcomm.com, = alexey.melnikov@isode.com, stpeter@stpeter.im, session-request@ietf.org > Subject: OAUTH - Requested session has been scheduled for IETF 80=20 >=20 > Dear Hannes Tschofenig, >=20 > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by=20 > the information of sessions that you have requested. >=20 > OAUTH Session 1 (2.5 hours) > Friday, Morning Session I 0900-1130 > Room Name: Roma > ---------------------------------------------- >=20 >=20 >=20 > Requested Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: oauth > Area Name: Applications Area > Session Requester: Hannes Tschofenig >=20 > Number of Sessions: 1 > Length of Session(s): 2.5 hours >=20 >=20 > Number of Attendees: 50 > Conflicts to Avoid: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 From phil.hunt@oracle.com Fri Feb 25 11:39:28 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649223A6831 for ; Fri, 25 Feb 2011 11:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0HjZkIpoqWB for ; Fri, 25 Feb 2011 11:39:27 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 86F753A67FB for ; Fri, 25 Feb 2011 11:39:27 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1PJeIhc009449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Feb 2011 19:40:20 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1PDRgfT026926 for ; Fri, 25 Feb 2011 19:40:18 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 1088213901298662707; Fri, 25 Feb 2011 11:38:27 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Feb 2011 11:38:26 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-4-380440985 Date: Fri, 25 Feb 2011 11:38:24 -0800 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D6805A2.017C:SCFMA4539814,ss=1,fgs=0 Subject: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:39:28 -0000 --Apple-Mail-4-380440985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There was some discussion on the type for the authorization header being = OAUTH / MAC / BEARER etc. Did we have a resolution? As for section 2.2 and 2.3, should we not have a more neutral solution = as well and use "authorization_token" instead of oauth_token. The idea = is that the parameter corresponds to the authorization header and NOT = the value of it. The value of such a parameter an be an encoded value = that corresponds to the authorization header. For example: GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: = server.example.com instead of=20 GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com The concern is that if for some reason you switch to "MAC" tokens, then = you have to change parameter names. Why not keep them consistent? Apologies if this was already resolved. Phil phil.hunt@oracle.com --Apple-Mail-4-380440985 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
GET = /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com
instead ofGET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 = Host: server.example.com
=

The concern is = that if for some reason you switch to "MAC" tokens, then you have to = change parameter names. Why not keep them = consistent?

Apologies if this was already = resolved.


= --Apple-Mail-4-380440985-- From beaton@google.com Fri Feb 25 11:48:15 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613653A6A19 for ; Fri, 25 Feb 2011 11:48:15 -0800 (PST) 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=[AWL=0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJuL7n1HL2NI for ; Fri, 25 Feb 2011 11:48:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8168F3A6831 for ; Fri, 25 Feb 2011 11:48:14 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p1PJn76n025416 for ; Fri, 25 Feb 2011 11:49:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298663347; bh=LekhYrgjtxhbCxciD5C9o38Zo1g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=IgluUwNiwSa3QnCQq0jbWcUYOC0sgqhSFdgJbXYVFwlsPlqAP6qiXQc3dSAV5fXJ4 1u5N0qWl9Cen9eeoK3w4w== Received: from pzk36 (pzk36.prod.google.com [10.243.19.164]) by wpaz17.hot.corp.google.com with ESMTP id p1PJmAmf031176 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Feb 2011 11:49:06 -0800 Received: by pzk36 with SMTP id 36so423460pzk.11 for ; Fri, 25 Feb 2011 11:49:05 -0800 (PST) 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=OmcXzxAhRujU+FFhE1XvnK++bmmkKlW7O40VoUW/qF0=; b=m24h5NMQIqoMKnKmTqdBHiFrQx9W9Jke6AK4WP/o6NvHykmcLKScQvqN1MCQOu9nKn KmYY+dN0sBW0EtUcGaxg== 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=mK8UuAkeQKB5qWPpcvTyBrhL5vTIf84cMCrgCMQ8k7JJ/bg8nnGGC52JE+BANX4aA2 1CkccuoTj+aeKkp0JQMw== MIME-Version: 1.0 Received: by 10.142.164.9 with SMTP id m9mr1933244wfe.442.1298663345512; Fri, 25 Feb 2011 11:49:05 -0800 (PST) Received: by 10.142.213.7 with HTTP; Fri, 25 Feb 2011 11:49:05 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Feb 2011 11:49:05 -0800 Message-ID: From: Brian Eaton To: Phil Hunt 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] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:48:15 -0000 My two cents: We've already taken three user visible outages because the OAuth2 spec reused the "oauth_token" parameter in a way that was not compatible with the OAuth1 spec. Luckily they were all caught before they caused serious damage. Generic parameter names are not useful. They lead to confused developers and confused code. If code needs to treat the values differently, the names should be different as well. Cheers, Brian On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt wrote: > There was some discussion on the type for the authorization header being > OAUTH / MAC / BEARER etc. Did we have a resolution? > As for section 2.2 and 2.3, should we not have a more neutral solution as > well and use "authorization_token" instead of oauth_token. The idea is th= at > the parameter corresponds to the authorization header and NOT the value o= f > it. The value of such a parameter an be an encoded value that corresponds= to > the authorization header. =A0For example: > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: > server.example.com > instead of > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com > The concern is that if for some reason you switch to "MAC" tokens, then y= ou > have to change parameter names. Why not keep them consistent? > Apologies if this was already resolved. > Phil > phil.hunt@oracle.com > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From Internet-Drafts@ietf.org Fri Feb 25 14:15:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F143A6A5B; Fri, 25 Feb 2011 14:15:02 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFQ-LZhMOk92; Fri, 25 Feb 2011 14:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854143A6A62; Fri, 25 Feb 2011 14:15:01 -0800 (PST) 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.12 Message-ID: <20110225221501.2618.12245.idtracker@localhost> Date: Fri, 25 Feb 2011 14:15:01 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:15: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 Protocol: Bearer Tokens Author(s) : M. Jones, et al. Filename : draft-ietf-oauth-v2-bearer-03.txt Pages : 18 Date : 2011-02-25 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-03.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-bearer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25141358.I-D@ietf.org> --NextPart-- From Michael.Jones@microsoft.com Fri Feb 25 14:16:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427D13A6A5C for ; Fri, 25 Feb 2011 14:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCHV25ah8U6O for ; Fri, 25 Feb 2011 14:16:25 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 309E53A68BC for ; Fri, 25 Feb 2011 14:16:23 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Feb 2011 14:17:13 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Fri, 25 Feb 2011 14:17:13 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification draft -03 Thread-Index: AcvVOcHRRuhphUQFTzOtEWI8xlMzhg== Date: Fri, 25 Feb 2011 22:17:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432527199A@TK5EX14MBXC207.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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739432527199ATK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:16:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739432527199ATK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've published draft 03 of the OAuth Bearer Token Specification. It contains one breaking change = relative to draft 02 that was voted on by the working group: changing the "OAuth2" O= Auth access token type name to "Bearer". The full set of changes in this d= raft is: * Restored the WWW-Authenticate response header functionality delet= ed from the framework specification in draft 12 based upon the specificatio= n text from draft 11. * Augmented the OAuth Parameters registry by adding two additional = parameter usage locations: "resource request" and "resource response". * Registered the "oauth_token" OAuth parameter with usage location = "resource request". * Registered the "error" OAuth parameter. * Created the OAuth Error registry and registered errors. * Changed the "OAuth2" OAuth access token type name to "Bearer". The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-03= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-03= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (wil= l point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.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, txt, and html versions available) Your feedback is solicited. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739432527199ATK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I&= #8217;ve published draft 03 of the OA= uth Bearer Token Specification.  It contains one breaking change r= elative to draft 02 that was voted on by the working group:  changing the &q= uot;OAuth2" OAuth access token type name to "Bearer".  = The full set of changes in this draft is:

·         Restored the WWW-Authenticate response heade= r functionality deleted from the framework specification in draft 12 based = upon the specification text from draft 11.

·         Augmented the OAuth Parameters registry by a= dding two additional parameter usage locations: "resource request"= ; and "resource response".

·         Registered the "oauth_token" OAuth= parameter with usage location "resource request".

·         Registered the "error" OAuth param= eter.

·         Created the OAuth Error registry and registe= red errors.

·         Changed the "OAuth2" OAuth access = token type name to "Bearer".

 

Th= e draft is available at these locations:

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

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

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

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

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-03.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.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, txt, and html versions available)

 

Yo= ur feedback is solicited.

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739432527199ATK5EX14MBXC207r_-- From Michael.Jones@microsoft.com Fri Feb 25 14:17:08 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7A13A6A5B for ; Fri, 25 Feb 2011 14:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aa6OflGzr2x for ; Fri, 25 Feb 2011 14:17:08 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D7ED93A6A53 for ; Fri, 25 Feb 2011 14:17:07 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Feb 2011 14:18:00 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Fri, 25 Feb 2011 14:18:00 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Errors Registry and OAuth Parameters Registry Thread-Index: AcvVOd2wYTGFwYrpSUWpVhYYW1jFew== Date: Fri, 25 Feb 2011 22:17:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252719B2@TK5EX14MBXC207.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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252719B2TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:17:08 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252719B2TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wanted to explicitly call out that draft -03 of the Bearer Token Specific= ation establishes the OAuth Errors registry to increase interoperability am= ong the related OAuth specifications. Eran, when you produce draft -14 of = the framework specification, please register the errors in the specificatio= n to comply with this new requirement. Errors in other OAuth specification= s should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters regi= stry by adding two additional parameter usage locations: "resource request"= and "resource response". Like parameters for the parameter usage location= s authorization request, authorization response, token request, and token r= esponse, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth regis= try requirements into the framework spec, I would be fine with that. If yo= u do so in your draft -14, I will remove them from my draft -04. Best wishes= , -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943252719B2TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wanted to explicitly call out that draft -03 of th= e Bearer Token Specification establishes the OAuth Errors registry to incre= ase interoperability among the related OAuth specifications.  Eran, wh= en you produce draft -14 of the framework specification, please register the errors in the specification to comply w= ith this new requirement.  Errors in other OAuth specifications should= likewise be registered in updated drafts.

 

I also wanted to call out that draft -03 augments th= e OAuth Parameters registry by adding two additional parameter usage locati= ons: "resource request" and "resource response".  = Like parameters for the parameter usage locations authorization request, authorization response, token request, and token response, parame= ters for these usage locations must also be registered.

 

Eran, if you would prefer, on an editorial basis, to= move these OAuth registry requirements into the framework spec, I would be= fine with that.  If you do so in your draft -14, I will remove them f= rom my draft -04.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Best wishes,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943252719B2TK5EX14MBXC207r_-- From Michael.Jones@microsoft.com Fri Feb 25 14:24:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CF63A6A62 for ; Fri, 25 Feb 2011 14:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeakEmPVSHLx for ; Fri, 25 Feb 2011 14:24:08 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4F30A3A6A5C for ; Fri, 25 Feb 2011 14:24:06 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Feb 2011 14:24:55 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0270.002; Fri, 25 Feb 2011 14:24:56 -0800 From: Mike Jones To: Phil Hunt , OAuth WG Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AQHL1SPffzL8bQ1cOkyjlBw2nes6cZQSygpw Date: Fri, 25 Feb 2011 22:24:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394325271A22TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:24:13 -0000 --_000_4E1F6AAD24975D4BA5B168042967394325271A22TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, Yes, per the working group vote, we decided on the name "Bearer". This nam= e is used in the just-published draft -03. This draft did not change the oauth_token parameter name; as editor, I am n= ot introducing breaking changes at this point unless directed to do so by a= vote of the working group. I agree with your consistency goal among the related specs. One step I too= k in this draft towards that end in the latest draft was establishing the O= Auth Errors registry and extending the scope of the OAuth Parameters regist= ry; the goal is that inconsistencies in error and parameter names among rel= ated specs will be more likely to be identified and corrected at specificat= ion time, rather than at spec usage time. Best wishes= , -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Friday, February 25, 2011 11:38 AM To: OAuth WG Subject: [OAUTH-WG] OAuth Bearer Token draft There was some discussion on the type for the authorization header being OA= UTH / MAC / BEARER etc. Did we have a resolution? As for section 2.2 and 2.3, should we not have a more neutral solution as w= ell and use "authorization_token" instead of oauth_token. The idea is that = the parameter corresponds to the authorization header and NOT the value of = it. The value of such a parameter an be an encoded value that corresponds t= o the authorization header. For example: GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: server= .example.com instead of GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com The concern is that if for some reason you switch to "MAC" tokens, then you= have to change parameter names. Why not keep them consistent? Apologies if this was already resolved. Phil phil.hunt@oracle.com --_000_4E1F6AAD24975D4BA5B168042967394325271A22TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 <= /p>

Yes, per the working grou= p vote, we decided on the name “Bearer”.  This name is use= d in the just-published draft -03.

 <= /p>

This draft did not change= the oauth_token parameter name; as editor, I am not introducing breaking c= hanges at this point unless directed to do so by a vote of the working group.

 <= /p>

I agree with your consist= ency goal among the related specs.  One step I took in this draft towa= rds that end in the latest draft was establishing the OAuth Errors registry and extending the scope of the OAuth Parameters registry; the goa= l is that inconsistencies in error and parameter names among related specs = will be more likely to be identified and corrected at specification time, r= ather than at spec usage time.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Best wishes,

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, February 25, 2011 11:38 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth Bearer Token draft

 

There was some discussion on the type for the author= ization header being OAUTH / MAC / BEARER etc. Did we have a resolution?

 

As for section 2.2 and 2.3, should we not have a mor= e neutral solution as well and use "authorization_token" instead = of oauth_token. The idea is that the parameter corresponds to the authoriza= tion header and NOT the value of it. The value of such a parameter an be an encoded value that corresponds to the authori= zation header.  For example:

= GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com

inst= ead of 

= GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com

 

The concern is that if for some reason you switch to= "MAC" tokens, then you have to change parameter names. Why not k= eep them consistent?

 

Apologies if this was already resolved.

 

 

--_000_4E1F6AAD24975D4BA5B168042967394325271A22TK5EX14MBXC207r_-- From eran@hueniverse.com Fri Feb 25 14:32:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCC33A6A64 for ; Fri, 25 Feb 2011 14:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdu8T5MKziVz for ; Fri, 25 Feb 2011 14:32:32 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EC3713A683F for ; Fri, 25 Feb 2011 14:32:31 -0800 (PST) Received: (qmail 7529 invoked from network); 25 Feb 2011 22:33:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Feb 2011 22:33:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Feb 2011 15:33:24 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Fri, 25 Feb 2011 15:33:02 -0700 Thread-Topic: OAuth Errors Registry and OAuth Parameters Registry Thread-Index: AcvVOd2wYTGFwYrpSUWpVhYYW1jFewAARwXw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C371D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252719B2@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252719B2@TK5EX14MBXC207.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C371DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:32:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C371DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see a point in an error registry (and I find it odd for the Bearer = token specification to impose any requirements of the protocol specificatio= n). Registries are created to prevent namespace collision. I don't see real= problem with collision of error codes, especially not for a while. The OAuth protocol errors are not extensible. To extend them, a specificati= on must be published that updates the OAuth 2.0 RFC. Not making it extensib= le actually helps interoperability. You can't define a "resource request" and "resource response" locations. Th= at's absurd. The resource endpoint is service specific and by definition wi= ll have an unlimited number of parameters. How exactly do you expect this r= egistry to work? Every provider registering every parameter they are going = to use as part of their own API? It's enough that the 'oauth_token' paramet= er invades the provider's space as it is. No changes are needed to the OAuth 2.0 protocol specification and I'd sugge= st you drop all these new additions from the bearer token draft. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, February 25, 2011 2:18 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry I wanted to explicitly call out that draft -03 of the Bearer Token Specific= ation establishes the OAuth Errors registry to increase interoperability am= ong the related OAuth specifications. Eran, when you produce draft -14 of = the framework specification, please register the errors in the specificatio= n to comply with this new requirement. Errors in other OAuth specification= s should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters regi= stry by adding two additional parameter usage locations: "resource request"= and "resource response". Like parameters for the parameter usage location= s authorization request, authorization response, token request, and token r= esponse, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth regis= try requirements into the framework spec, I would be fine with that. If yo= u do so in your draft -14, I will remove them from my draft -04. Best wishes= , -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C371DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see a point in an error registry (and I find it= odd for the Bearer token specification to impose any requirements of the p= rotocol specification). Registries are created to prevent namespace collisi= on. I don’t see real problem with collision of error codes, especiall= y not for a while.

 

The OAuth protocol errors are not extensible. To extend= them, a specification must be published that updates the OAuth 2.0 RFC. No= t making it extensible actually helps interoperability.

 

You can’t de= fine a “resource request” and “resource response” l= ocations. That’s absurd. The resource endpoint is service specific an= d by definition will have an unlimited number of parameters. How exactly do= you expect this registry to work? Every provider registering every paramet= er they are going to use as part of their own API? It’s enough that t= he ‘oauth_token’ parameter invades the provider’s space a= s it is.

 

No changes are needed to the OAuth 2.0 protocol specification and= I’d suggest you drop all these new additions from the bearer token d= raft.

 

EHL

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Friday, February 25, 2011 2:18 = PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Errors = Registry and OAuth Parameters Registry

 

I wanted to exp= licitly call out that draft -03 of the Bearer Token Specification establish= es the OAuth Errors registry to increase interoperability among the related= OAuth specifications.  Eran, when you produce draft -14 of the framew= ork specification, please register the errors in the specification to compl= y with this new requirement.  Errors in other OAuth specifications sho= uld likewise be registered in updated drafts.

 

I also wanted to call out t= hat draft -03 augments the OAuth Parameters registry by adding two addition= al parameter usage locations: "resource request" and "resour= ce response".  Like parameters for the parameter usage locations = authorization request, authorization response, token request, and token res= ponse, parameters for these usage locations must also be registered.

 

Eran= , if you would prefer, on an editorial basis, to move these OAuth registry = requirements into the framework spec, I would be fine with that.  If y= ou do so in your draft -14, I will remove them from my draft -04.

 

 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Bes= t wishes,

     =             &nb= sp;            =             &nb= sp;            =          -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C371DP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Fri Feb 25 14:39:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5B43A6A65 for ; Fri, 25 Feb 2011 14:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXhgtdQJcqMX for ; Fri, 25 Feb 2011 14:39:12 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D2B1C3A6A64 for ; Fri, 25 Feb 2011 14:39:11 -0800 (PST) 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; Fri, 25 Feb 2011 14:40:04 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Fri, 25 Feb 2011 14:40:04 -0800 From: Mike Jones To: Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: OAuth Errors Registry and OAuth Parameters Registry Thread-Index: AcvVOd2wYTGFwYrpSUWpVhYYW1jFewAARwXwAABaNuA= Date: Fri, 25 Feb 2011 22:40:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394325271A68@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252719B2@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C371D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C371D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394325271A68TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:39:18 -0000 --_000_4E1F6AAD24975D4BA5B168042967394325271A68TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see a problem with collision of error codes. I believe that the working = group will likely concur. I agree that it is odd for the bearer token specification to impose require= ments upon the framework specification. Hence my editorial request for you= to incorporate these registry additions into the framework specification. = Nonetheless, if you do not, the requirement remains, as the two specs are = intended to work together as a seamless whole. It is far from absurd to require parameter registrations for the resource r= equest and resource response messages in OAuth specifications. Phil and Br= ian's notes just today point out the value of just such registration. Again, I'll politely repeat my request to update the framework specificatio= n, and other specifications that you are an editor of, to comply with these= requirements. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, February 25, 2011 2:33 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I don't see a point in an error registry (and I find it odd for the Bearer = token specification to impose any requirements of the protocol specificatio= n). Registries are created to prevent namespace collision. I don't see real= problem with collision of error codes, especially not for a while. The OAuth protocol errors are not extensible. To extend them, a specificati= on must be published that updates the OAuth 2.0 RFC. Not making it extensib= le actually helps interoperability. You can't define a "resource request" and "resource response" locations. Th= at's absurd. The resource endpoint is service specific and by definition wi= ll have an unlimited number of parameters. How exactly do you expect this r= egistry to work? Every provider registering every parameter they are going = to use as part of their own API? It's enough that the 'oauth_token' paramet= er invades the provider's space as it is. No changes are needed to the OAuth 2.0 protocol specification and I'd sugge= st you drop all these new additions from the bearer token draft. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, February 25, 2011 2:18 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry I wanted to explicitly call out that draft -03 of the Bearer Token Specific= ation establishes the OAuth Errors registry to increase interoperability am= ong the related OAuth specifications. Eran, when you produce draft -14 of = the framework specification, please register the errors in the specificatio= n to comply with this new requirement. Errors in other OAuth specification= s should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters regi= stry by adding two additional parameter usage locations: "resource request"= and "resource response". Like parameters for the parameter usage location= s authorization request, authorization response, token request, and token r= esponse, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth regis= try requirements into the framework spec, I would be fine with that. If yo= u do so in your draft -14, I will remove them from my draft -04. Best wishes= , -- Mike --_000_4E1F6AAD24975D4BA5B168042967394325271A68TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see a problem with c= ollision of error codes.  I believe that the working group will likely= concur.

 

I agree that it is odd= for the bearer token specification to impose requirements upon the framewo= rk specification.  Hence my editorial request for you to incorporate t= hese registry additions into the framework specification.  Nonetheless, if you do not, the requirement remains, = as the two specs are intended to work together as a seamless whole.

 

It is far from absurd = to require parameter registrations for the resource request and resource re= sponse messages in OAuth specifications.  Phil and Brian’s notes= just today point out the value of just such registration.

 

Again, I’ll poli= tely repeat my request to update the framework specification, and other spe= cifications that you are an editor of, to comply with these requirements.

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, February 25, 2011 2:33 PM
To: Mike Jones; oauth@ietf.org
Subject: RE: OAuth Errors Registry and OAuth Parameters Registry

 

I don’t see a po= int in an error registry (and I find it odd for the Bearer token specificat= ion to impose any requirements of the protocol specification). Registries a= re created to prevent namespace collision. I don’t see real problem with collision of error codes, especially n= ot for a while.

 

The OAuth protocol err= ors are not extensible. To extend them, a specification must be published t= hat updates the OAuth 2.0 RFC. Not making it extensible actually helps inte= roperability.

 

You can’t define= a “resource request” and “resource response” locat= ions. That’s absurd. The resource endpoint is service specific and by= definition will have an unlimited number of parameters. How exactly do you expect this registry to work? Every provider registering every paramet= er they are going to use as part of their own API? It’s enough that t= he ‘oauth_token’ parameter invades the provider’s space a= s it is.

 

No changes are needed = to the OAuth 2.0 protocol specification and I’d suggest you drop all = these new additions from the bearer token draft.

 

EHL<= /p>

 

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 25, 2011 2:18 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Regis= try

 

I wanted to explicitly call out that draft -03 of th= e Bearer Token Specification establishes the OAuth Errors registry to incre= ase interoperability among the related OAuth specifications.  Eran, wh= en you produce draft -14 of the framework specification, please register the errors in the specification to comply w= ith this new requirement.  Errors in other OAuth specifications should= likewise be registered in updated drafts.

 

I also wanted to call out that draft -03 augments th= e OAuth Parameters registry by adding two additional parameter usage locati= ons: "resource request" and "resource response".  = Like parameters for the parameter usage locations authorization request, authorization response, token request, and token response, parame= ters for these usage locations must also be registered.

 

Eran, if you would prefer, on an editorial basis, to= move these OAuth registry requirements into the framework spec, I would be= fine with that.  If you do so in your draft -14, I will remove them f= rom my draft -04.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Best wishes,

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

 

--_000_4E1F6AAD24975D4BA5B168042967394325271A68TK5EX14MBXC207r_-- From phil.hunt@oracle.com Fri Feb 25 14:40:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E481A3A6A62 for ; Fri, 25 Feb 2011 14:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xurvnnmqYyHV for ; Fri, 25 Feb 2011 14:39:59 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A28EC3A6A5B for ; Fri, 25 Feb 2011 14:39:59 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1PMeorZ019319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Feb 2011 22:40:52 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1PJKfqb032012; Fri, 25 Feb 2011 22:40:50 GMT Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 1039441231298673649; Fri, 25 Feb 2011 14:40:49 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Feb 2011 14:40:49 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-5-391384253 From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Fri, 25 Feb 2011 14:40:47 -0800 Message-Id: <6ACD2369-6A7F-48F2-B354-E5FDF5EA4DB6@oracle.com> References: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D682FF2.00E3:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:40:01 -0000 --Apple-Mail-5-391384253 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mike, Thanks, I just noticed you addressed the change to "BEARER" in draft 03 = (just published). I could live with the parameter name oauth_token, provided we can = sub-type (rather then be generic). E.g. GET /resource?oauth_token=3DBEARER+vF9dft4qmT Either way, I suspect this is a breaking change unless we specify that = no prefix (i.e. as with authorization header) refers to the legacy case. = Which I could also live with. If we don't then the value of OAUTH_TOKEN (or authorization_token) = becomes unclear. I think this will cause some major issues that some = will consider bugs in the spec. Phil phil.hunt@oracle.com On 2011-02-25, at 2:24 PM, Mike Jones wrote: > Hi Phil, > =20 > Yes, per the working group vote, we decided on the name =93Bearer=94. = This name is used in the just-published draft -03. > =20 > This draft did not change the oauth_token parameter name; as editor, I = am not introducing breaking changes at this point unless directed to do = so by a vote of the working group. > =20 > I agree with your consistency goal among the related specs. One step = I took in this draft towards that end in the latest draft was = establishing the OAuth Errors registry and extending the scope of the = OAuth Parameters registry; the goal is that inconsistencies in error and = parameter names among related specs will be more likely to be identified = and corrected at specification time, rather than at spec usage time. > =20 > Best = wishes, > -- = Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Friday, February 25, 2011 11:38 AM > To: OAuth WG > Subject: [OAUTH-WG] OAuth Bearer Token draft > =20 > There was some discussion on the type for the authorization header = being OAUTH / MAC / BEARER etc. Did we have a resolution? > =20 > As for section 2.2 and 2.3, should we not have a more neutral solution = as well and use "authorization_token" instead of oauth_token. The idea = is that the parameter corresponds to the authorization header and NOT = the value of it. The value of such a parameter an be an encoded value = that corresponds to the authorization header. For example: > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: = server.example.com > instead of=20 > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: = server.example.com > =20 > The concern is that if for some reason you switch to "MAC" tokens, = then you have to change parameter names. Why not keep them consistent? > =20 > Apologies if this was already resolved. > =20 > Phil > phil.hunt@oracle.com > =20 > =20 >=20 > =20 --Apple-Mail-5-391384253 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I could live with the parameter = name oauth_token, provided we can sub-type (rather then be generic). =  E.g.
GET = /resource?oauth_token=3DBEARER+vF9dft4qmT

=
Either way,  I suspect this is a breaking change unless we = specify that no prefix (i.e. as with authorization header) refers to the = legacy case. Which I could also live with.

If = we don't then the value of OAUTH_TOKEN (or authorization_token) becomes = unclear. I think this will cause some major issues that some will = consider bugs in the spec.


On 2011-02-25, at 2:24 PM, Mike Jones wrote:

Hi = Phil,
Yes, = per the working group vote, we decided on the name =93Bearer=94.  = This name is used in the just-published draft = -03.
This = draft did not change the oauth_token parameter name; as editor, I am not = introducing breaking changes at this point unless directed to do so by a = vote of the working group.
 
I agree with your consistency goal = among the related specs.  One step I took in this draft towards = that end in the latest draft was establishing the OAuth Errors registry = and extending the scope of the OAuth Parameters registry; the goal is = that inconsistencies in error and parameter names among related specs = will be more likely to be identified and corrected at specification = time, rather than at spec usage time.
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Phil = Hunt
Sent: Friday, February 25, 2011 = 11:38 AM
To: OAuth = WG
Subject: [OAUTH-WG] OAuth Bearer = Token draft
There was some discussion = on the type for the authorization header being OAUTH / MAC / BEARER etc. = Did we have a resolution?
 
As for section = 2.2 and 2.3, should we not have a more neutral solution as well and use = "authorization_token" instead of oauth_token. The idea is that the = parameter corresponds to the authorization header and NOT the value of = it. The value of such a parameter an be an encoded value that = corresponds to the authorization header.  For = example:
GET = /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: instead = of 
Date: Fri, 25 Feb 2011 16:02:00 -0700 Thread-Topic: OAuth Errors Registry and OAuth Parameters Registry Thread-Index: AcvVOd2wYTGFwYrpSUWpVhYYW1jFewAARwXwAABaNuAAAJKl8A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3724@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252719B2@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C371D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394325271A68@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394325271A68@TK5EX14MBXC207.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C3724P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:01:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3724P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth 2.0 defines two endpoint, each with a set of error codes. These codes= are not extensible and therefore do not require a registry. If you want to= allow error code extensibility, you need to make the case for that with re= quirements and use cases. I have not seen any. My API uses the 'position' parameter for protected resources. Am I expected= to register it? It has nothing to do with OAuth, but if I supported Bearer= token would be used alongside the 'oauth_token' parameter. The 'oauth_toke= n' parameter is an nasty hack to make it easy for developers to access prot= ected resources without using the Authorization header (based on browser li= mitations from 4 years ago). Defining a registry for this parameter is just= adding insult to injury. The bearer token draft can define whatever registries it want for those usi= ng *bearer* tokens. It has no say on anything else. Period. If you want to = make changed to other drafts, you need to make a case and build consensus. = By definition, your drafts cannot change any requirement in other drafts un= less you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new = proposals? EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 25, 2011 2:40 PM To: Eran Hammer-Lahav; oauth@ietf.org Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I see a problem with collision of error codes. I believe that the working = group will likely concur. I agree that it is odd for the bearer token specification to impose require= ments upon the framework specification. Hence my editorial request for you= to incorporate these registry additions into the framework specification. = Nonetheless, if you do not, the requirement remains, as the two specs are = intended to work together as a seamless whole. It is far from absurd to require parameter registrations for the resource r= equest and resource response messages in OAuth specifications. Phil and Br= ian's notes just today point out the value of just such registration. Again, I'll politely repeat my request to update the framework specificatio= n, and other specifications that you are an editor of, to comply with these= requirements. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, February 25, 2011 2:33 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth Errors Registry and OAuth Parameters Registry I don't see a point in an error registry (and I find it odd for the Bearer = token specification to impose any requirements of the protocol specificatio= n). Registries are created to prevent namespace collision. I don't see real= problem with collision of error codes, especially not for a while. The OAuth protocol errors are not extensible. To extend them, a specificati= on must be published that updates the OAuth 2.0 RFC. Not making it extensib= le actually helps interoperability. You can't define a "resource request" and "resource response" locations. Th= at's absurd. The resource endpoint is service specific and by definition wi= ll have an unlimited number of parameters. How exactly do you expect this r= egistry to work? Every provider registering every parameter they are going = to use as part of their own API? It's enough that the 'oauth_token' paramet= er invades the provider's space as it is. No changes are needed to the OAuth 2.0 protocol specification and I'd sugge= st you drop all these new additions from the bearer token draft. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, February 25, 2011 2:18 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry I wanted to explicitly call out that draft -03 of the Bearer Token Specific= ation establishes the OAuth Errors registry to increase interoperability am= ong the related OAuth specifications. Eran, when you produce draft -14 of = the framework specification, please register the errors in the specificatio= n to comply with this new requirement. Errors in other OAuth specification= s should likewise be registered in updated drafts. I also wanted to call out that draft -03 augments the OAuth Parameters regi= stry by adding two additional parameter usage locations: "resource request"= and "resource response". Like parameters for the parameter usage location= s authorization request, authorization response, token request, and token r= esponse, parameters for these usage locations must also be registered. Eran, if you would prefer, on an editorial basis, to move these OAuth regis= try requirements into the framework spec, I would be fine with that. If yo= u do so in your draft -14, I will remove them from my draft -04. Best wishes= , -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3724P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OAuth 2.0 defines two endpoint, each with a set of error code= s. These codes are not extensible and therefore do not require a registry. = If you want to allow error code extensibility, you need to make the case fo= r that with requirements and use cases. I have not seen any.

 =

My API uses t= he ‘position’ parameter for protected resources. Am I expected = to register it? It has nothing to do with OAuth, but if I supported Bearer = token would be used alongside the ‘oauth_token’ parameter. The = ‘oauth_token’ parameter is an nasty hack to make it easy for de= velopers to access protected resources without using the Authorization head= er (based on browser limitations from 4 years ago). Defining a registry for= this parameter is just adding insult to injury.

 

<= p class=3DMsoNormal>The bearer token draft ca= n define whatever registries it want for those using *bearer* tokens= . It has no say on anything else. Period. If you want to make changed to ot= her drafts, you need to make a case and build consensus. By definition, you= r drafts cannot change any requirement in other drafts unless you update th= em (this is an IETF process rule).

 

Can you provide use cases, requirements= , and examples for each of your new proposals?

 

EHL

 

 

 <= /span>

 

From: Mike Jones [mai= lto:Michael.Jones@microsoft.com]
Sent: Friday, February 25, 2011= 2:40 PM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject:= RE: OAuth Errors Registry and OAuth Parameters Registry<= /p>

 

I see a problem with collision of error co= des.  I believe that the working group will likely concur.<= /span>

 

I agree th= at it is odd for the bearer token specification to impose requirements upon= the framework specification.  Hence my editorial request for you to i= ncorporate these registry additions into the framework specification. = Nonetheless, if you do not, the requirement remains, as the two specs are = intended to work together as a seamless whole.

 

It is far from absurd to re= quire parameter registrations for the resource request and resource respons= e messages in OAuth specifications.  Phil and Brian’s notes just= today point out the value of just such registration.

=

 =

Again, I’ll po= litely repeat my request to update the framework specification, and other s= pecifications that you are an editor of, to comply with these requirements.=

 

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

 

<= b>From:<= /span> Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, = February 25, 2011 2:33 PM
To: Mike Jones; oauth@ietf.org
Su= bject: RE: OAuth Errors Registry and OAuth Parameters Registry

 

I don’t see a point in an = error registry (and I find it odd for the Bearer token specification to imp= ose any requirements of the protocol specification). Registries are created= to prevent namespace collision. I don’t see real problem with collis= ion of error codes, especially not for a while.

 

The OAuth protocol errors = are not extensible. To extend them, a specification must be published that = updates the OAuth 2.0 RFC. Not making it extensible actually helps interope= rability.

 

You can’t define a “resource request” and R= 20;resource response” locations. That’s absurd. The resource en= dpoint is service specific and by definition will have an unlimited number = of parameters. How exactly do you expect this registry to work? Every provi= der registering every parameter they are going to use as part of their own = API? It’s enough that the ‘oauth_token’ parameter invades= the provider’s space as it is.

 

No changes are needed to the OAuth 2= .0 protocol specification and I’d suggest you drop all these new addi= tions from the bearer token draft.

 

EHL

 

 

 

=

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Fr= iday, February 25, 2011 2:18 PM
To: oauth@ietf.org
Subject:= [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry

 

I wanted to explicitly call out that draft -03 of the Bearer = Token Specification establishes the OAuth Errors registry to increase inter= operability among the related OAuth specifications.  Eran, when you pr= oduce draft -14 of the framework specification, please register the errors = in the specification to comply with this new requirement.  Errors in o= ther OAuth specifications should likewise be registered in updated drafts.<= o:p>

 

I also wanted to call out that draft -03 augments the OAuth Parameters re= gistry by adding two additional parameter usage locations: "resource r= equest" and "resource response".  Like parameters for t= he parameter usage locations authorization request, authorization response,= token request, and token response, parameters for these usage locations mu= st also be registered.

 =

Eran, if you would prefer, on an editorial basis, = to move these OAuth registry requirements into the framework spec, I would = be fine with that.  If you do so in your draft -14, I will remove them= from my draft -04.

 

         = ;            &n= bsp;            = ;            &n= bsp;            = ;     Best wishes,

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3724P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Feb 25 15:03:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320E53A6A71 for ; Fri, 25 Feb 2011 15:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2AD-xeutsen for ; Fri, 25 Feb 2011 15:03:08 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 044483A6A6F for ; Fri, 25 Feb 2011 15:03:07 -0800 (PST) Received: (qmail 18648 invoked from network); 25 Feb 2011 23:04:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Feb 2011 23:04:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Feb 2011 16:03:49 -0700 From: Eran Hammer-Lahav To: Phil Hunt , Mike Jones Date: Fri, 25 Feb 2011 16:03:26 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcvVPRJwSWL59wwDR2WDTLbu4M19rwAAvrcg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3725@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.redmond.corp.microsoft.com> <6ACD2369-6A7F-48F2-B354-E5FDF5EA4DB6@oracle.com> In-Reply-To: <6ACD2369-6A7F-48F2-B354-E5FDF5EA4DB6@oracle.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C3725P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:03:14 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3725P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 'oauth_token' is limited to bearer tokens only. It is not suitable for anyt= hing else. It is a hack and should be treated as such. The right (extensibl= e) solution is to use the HTTP Authorization header, which comes with its o= wn extensibility model. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Friday, February 25, 2011 2:41 PM To: Mike Jones Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft Mike, Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (ju= st published). I could live with the parameter name oauth_token, provided we can sub-type = (rather then be generic). E.g. GET /resource?oauth_token=3DBEARER+vF9dft4qmT Either way, I suspect this is a breaking change unless we specify that no = prefix (i.e. as with authorization header) refers to the legacy case. Which= I could also live with. If we don't then the value of OAUTH_TOKEN (or authorization_token) becomes = unclear. I think this will cause some major issues that some will consider = bugs in the spec. Phil phil.hunt@oracle.com On 2011-02-25, at 2:24 PM, Mike Jones wrote: Hi Phil, Yes, per the working group vote, we decided on the name "Bearer". This nam= e is used in the just-published draft -03. This draft did not change the oauth_token parameter name; as editor, I am n= ot introducing breaking changes at this point unless directed to do so by a= vote of the working group. I agree with your consistency goal among the related specs. One step I too= k in this draft towards that end in the latest draft was establishing the O= Auth Errors registry and extending the scope of the OAuth Parameters regist= ry; the goal is that inconsistencies in error and parameter names among rel= ated specs will be more likely to be identified and corrected at specificat= ion time, rather than at spec usage time. Best wishes= , -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, February 25, 2011 11:38 AM To: OAuth WG Subject: [OAUTH-WG] OAuth Bearer Token draft There was some discussion on the type for the authorization header being OA= UTH / MAC / BEARER etc. Did we have a resolution? As for section 2.2 and 2.3, should we not have a more neutral solution as w= ell and use "authorization_token" instead of oauth_token. The idea is that = the parameter corresponds to the authorization header and NOT the value of = it. The value of such a parameter an be an encoded value that corresponds t= o the authorization header. For example: GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: server= .example.com instead of GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com The concern is that if for some reason you switch to "MAC" tokens, then you= have to change parameter names. Why not keep them consistent? Apologies if this was already resolved. Phil phil.hunt@oracle.com --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3725P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

‘oa= uth_token’ is limited to bearer tokens only. It is not suitable for a= nything else. It is a hack and should be treated as such. The right (extens= ible) solution is to use the HTTP Authorization header, which comes with it= s own extensibility model.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, Febru= ary 25, 2011 2:41 PM
To: Mike Jones
Cc: OAuth WG
= Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

<= /div>

 

M= ike,

 

Thanks, I just noticed you addressed the change to &= quot;BEARER" in draft 03 (just published).

 

I c= ould live with the parameter name oauth_token, provided we can sub-type (ra= ther then be generic).  E.g.

<= span class=3Dapple-style-span>GET= /resource?oauth_token=3DBEARER+vF9dft4qmT

 

Either way,  I suspect this is a breaking change unless w= e specify that no prefix (i.e. as with authorization header) refers to the = legacy case. Which I could also live with.

 

If we do= n't then the value of OAUTH_TOKEN (or authorization_token) becomes unclear.= I think this will cause some major issues that some will consider bugs in = the spec.

 

Phil

 



 

From:=  oauth-bounces@ietf.org&n= bsp;[mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: = ;Friday, February 25, 2011 11:38 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth Bearer Token draft

 <= /p>

There was some discussion on the ty= pe for the authorization header being OAUTH / MAC / BEARER etc. Did we have= a resolution?

&nb= sp;

As for section= 2.2 and 2.3, should we not have a more neutral solution as well and use &q= uot;authorization_token" instead of oauth_token. The idea is that the = parameter corresponds to the authorization header and NOT the value of it. = The value of such a parameter an be an encoded value that corresponds to th= e authorization header.  For example:

<= div>

GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:=  server.example.com

=

instead of =

GET /resource?oauth_t= oken=3DvF9dft4qmT HTTP/1.1 Host: <= /span>server.example.com<= o:p>

 <= o:p>

The concern is tha= t if for some reason you switch to "MAC" tokens, then you have to= change parameter names. Why not keep them consistent?

=

 

=

Apologies if this was already resolved.

 

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3725P3PW5EX1MB01E_-- From beaton@google.com Fri Feb 25 15:24:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5502F3A6A7B for ; Fri, 25 Feb 2011 15:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOBvi7QSFP7z for ; Fri, 25 Feb 2011 15:24:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5A79C3A6A7A for ; Fri, 25 Feb 2011 15:24:44 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p1PNPaUi015538 for ; Fri, 25 Feb 2011 15:25:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298676336; bh=MZNKdOblAdtFqzTfixTzdxFp/hQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=COeF9vAtFODV3BOgPTOVNvN9FpD1Zy6bftvcaNl72MnS2nhUcNXJBkz6RtGmJTUg2 HlImleMdry+7V/FrxVA7A== Received: from pzk12 (pzk12.prod.google.com [10.243.19.140]) by wpaz37.hot.corp.google.com with ESMTP id p1PNPYkB020882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Feb 2011 15:25:35 -0800 Received: by pzk12 with SMTP id 12so533709pzk.15 for ; Fri, 25 Feb 2011 15:25:34 -0800 (PST) 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=BoB9qcFBv99K+M1OH9J/xgu+QcrROrO6hZdzJ6dAjqA=; b=kziuc8SPRXS3bsHsQiBq2T0w5lHGjIO79atf7rE1VHdUKix9J33f4o/ejpgKh8R12w Gh/dcjr1QO0hueKYagFg== 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=EOpVx9YNJWqz3Iw2VhYXrV3x/5FH8XQ1zh7oto9LXncmLlaRQAkK6zGlNHv1F9D1yW bkvY4rUJwYJiyHOCkwvA== MIME-Version: 1.0 Received: by 10.142.155.9 with SMTP id c9mr2120220wfe.127.1298676334092; Fri, 25 Feb 2011 15:25:34 -0800 (PST) Received: by 10.142.213.7 with HTTP; Fri, 25 Feb 2011 15:25:33 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3725@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.redmond.corp.microsoft.com> <6ACD2369-6A7F-48F2-B354-E5FDF5EA4DB6@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C3725@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 25 Feb 2011 15:25:33 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:24:45 -0000 On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav wr= ote: > =91oauth_token=92 is limited to bearer tokens only. It is not suitable fo= r > anything else. Except that OAuth 1.0 already went out using oauth_token for signed request= s. From fcorella@pomcor.com Fri Feb 25 15:41:11 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237EF3A6A7D for ; Fri, 25 Feb 2011 15:41:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hllowIWoUSnw for ; Fri, 25 Feb 2011 15:41:10 -0800 (PST) Received: from nm14.bullet.mail.ac4.yahoo.com (nm14.bullet.mail.ac4.yahoo.com [98.139.52.211]) by core3.amsl.com (Postfix) with SMTP id 0F92E3A6A7B for ; Fri, 25 Feb 2011 15:41:09 -0800 (PST) Received: from [98.139.52.195] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 Received: from [98.139.52.139] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 Received: from [127.0.0.1] by omp1022.mail.ac4.yahoo.com with NNFMP; 25 Feb 2011 23:42:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 790914.74619.bm@omp1022.mail.ac4.yahoo.com Received: (qmail 25996 invoked by uid 60001); 25 Feb 2011 23:42:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298677320; bh=HSGzYKvQPrpXOIEWR1Uw6+e4x3sCVRqsJUXMdE+Q0l4=; 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=ygJYzq8Wc818Fy2UHLEQK76ZbDOtY8go8ALTfNVBVVJSTp1LS82a60e8vvxKhTbx4QCGY+1JjOGKBxHorO7ls/E0WeF6LKhbRGQfNHFVvNv/IbI76jiryFFA4u7Ru+/FB78/BBWgjQ4utVo5aQCMILgDxdPuGxaaBAVJH3Bv2uw= Message-ID: <593793.24331.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: UvntHMIVM1nHs6wx6O5UHJAT9M2R3MUj8Jljl0PyS7W0SvF U6WxZeQnCho5yduN73.gc08bxMzCr06x5D8AloKd1NfMp1oMbYkvDFWsFI8i 5sw5.N9YlTl4BmAYpZHyWAXAdsCGf27kBIMdMC5eyVglDIdMmfk8J0Ul2LS_ mj5oSGpffbkITpk5bQ.r62rLhLnvV3ifytfzfBQseKLViYBMgive6FNymn7. kxZ6mPGan8TwZyXPw_QWBUsaOt5BzsylisF6tJtnmJJpss3PZxqHX6OcevGv _dZSujNuvJeL52bDxbvcAZ_4nvYLVPQE3DleSo_pcC73K_S8XNM4f0tyCXRb OWYkK4WnuEIqD9lvYgGLuBmKmhIfKOSJP9v0WNYkR5WC2jqq8mOtNVs9m4zC st6U- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Fri, 25 Feb 2011 15:42:00 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Fri, 25 Feb 2011 15:42:00 -0800 (PST) From: Francisco Corella To: OAuth Mailing List , "websec@ietf.org" , James HManger In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1990049981-1298677320=:24331" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 23:41:11 -0000 --0-1990049981-1298677320=:24331 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi James, You raise an interesting point.=C2=A0 I hadn't thought about the threat of Login CSRF. > Q. Should an OAuth client app list the authorization server > in the Origin header of requests to resource servers? >=20 > In OAuth (delegation) flows a server dynamically issues > credentials (such as a bearer token) to a client app to use > in subsequent HTTP requests to other servers. To combat > login cross-site request forgery (CSRF) attacks [1] (where > an attacker=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A=C3= =84=C3=B4s credentials to a > client app ... But how will the client app get the "credentials" (bearer token) from the wrong authorization server? Even though the particular attack you describe may not work, OAuth is wide open to Login CSRF in a different way.=C2=A0 An attacker can legitimately obtain an authorization code, and then cause the victim's browser to submit it to the client application, thus logging the victim in to the client application as the attacker (in a social login scenario such as "log in with Facebook").=C2=A0 I bet all applications that use OAuth to delegate authentication (to Facebook, Twitter, Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. One solution I would propose is to have the client set a pre-session cookie in the user's browser before the first redirection and include the value of the cookie in the local state parameter that it sends to the authorization server. The authorization server later returns the local state together with the authorization code, and the browser adds the cookie, so the client can prevent the attack by checking that the value of the cookie agrees with the value it included in the local state. Francisco --0-1990049981-1298677320=:24331 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi James,

You raise an interesting poi= nt.  I hadn't thought about the
threat of Login CSRF.

> Q= . Should an OAuth client app list the authorization server
> in the O= rigin header of requests to resource servers?
>
> In OAuth (de= legation) flows a server dynamically issues
> credentials (such as a = bearer token) to a client app to use
> in subsequent HTTP requests to= other servers. To combat
> login cross-site request forgery (CSRF) a= ttacks [1] (where
> an attacker=E2=80=9A=C3=84=C3=B4s server issues t= he attacker=E2=80=9A=C3=84=C3=B4s credentials to a
> client app ...
But how will the client app get the "credentials" (bearer token)
f= rom the wrong authorization server?

Even though the particular attac= k you describe may not work,
OAuth is wide open to Login CSRF in a diffe= rent way.  An
attacker can legitimately obtain an authorization code, and
then cause the victi= m's browser to submit it to the client
application, thus logging the vic= tim in to the client
application as the attacker (in a social login scen= ario such
as "log in with Facebook").  I bet all applications that = use
OAuth to delegate authentication (to Facebook, Twitter,
Google, L= inkedIn, Yahoo, etc.) are vulnerable to this now.

One solution I wou= ld propose is to have the client set a
pre-session cookie in the user's = browser before the first
redirection and include the value of the cookie= in the local
state parameter that it sends to the authorization server.=
The authorization server later returns the local state
together with= the authorization code, and the browser adds
the cookie, so the client = can prevent the attack by checking
that the value of the cookie agrees w= ith the value it
included in the local state.

Francisco

--0-1990049981-1298677320=:24331-- From eran@hueniverse.com Fri Feb 25 15:46:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B8B3A6A7E for ; Fri, 25 Feb 2011 15:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9yjGyx87DUN for ; Fri, 25 Feb 2011 15:45:59 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 364C43A6A7C for ; Fri, 25 Feb 2011 15:45:59 -0800 (PST) Received: (qmail 8202 invoked from network); 25 Feb 2011 23:46:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Feb 2011 23:46:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 25 Feb 2011 16:46:22 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 25 Feb 2011 16:46:00 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcvVQ0+T+lmUl4WuSGGPzV8MW69EGgAAoFbQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C372F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B168042967394325271A22@TK5EX14MBXC207.redmond.corp.microsoft.com> <6ACD2369-6A7F-48F2-B354-E5FDF5EA4DB6@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C3725@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] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 23:46:00 -0000 2.0 does not use this parameter. Only the bearer token draft uses it. If yo= u have an issue with that, feel free to change that parameter name for bear= er token requests. The MAC draft does not support protected resources reque= sts via the query or post parameters, only the header. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, February 25, 2011 3:26 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >=20 > On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav > wrote: > > 'oauth_token' is limited to bearer tokens only. It is not suitable for > > anything else. >=20 > Except that OAuth 1.0 already went out using oauth_token for signed > requests. From fcorella@pomcor.com Fri Feb 25 16:09:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9923A6A8B for ; Fri, 25 Feb 2011 16:09:25 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWgNaPlGNlAs for ; Fri, 25 Feb 2011 16:09:24 -0800 (PST) Received: from nm9-vm0.bullet.mail.ac4.yahoo.com (nm9-vm0.bullet.mail.ac4.yahoo.com [98.139.53.192]) by core3.amsl.com (Postfix) with SMTP id 926E53A6A8A for ; Fri, 25 Feb 2011 16:09:23 -0800 (PST) Received: from [98.139.52.196] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 00:10:16 -0000 Received: from [98.139.52.178] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 00:10:16 -0000 Received: from [127.0.0.1] by omp1061.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 00:10:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 834103.2445.bm@omp1061.mail.ac4.yahoo.com Received: (qmail 7066 invoked by uid 60001); 26 Feb 2011 00:10:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298679016; bh=HGRXc7CbVQIcfArc7WCjAWUWHlP4rDPweRyG9bn6vUA=; 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=bEFnCd6/HI0J/xKl1OipZUz97Pe18AUwmcetKpIH1HYxvbnuYbct/iZf4Dn5kxoAMQH/mIOk+tMK4rfQPTeedGaQe4SfHH9Jzu5PkUMQejCj/UyBw0IH978fUjhx3jfxW3uaRGCF1W7o0zheVPUF8xLaOHQwa0QoVJesOsdNtvo= Message-ID: <656127.6263.qm@web55808.mail.re3.yahoo.com> X-YMail-OSG: 6tAS4e4VM1kOMcZCR81TgFTfRISHBlq1HmblVeAz36YwjQ4 zFJmLcsdfuNJUru7_suBSSPKWqaFbj4x6uHXKE86zTAHNNUED9ahkl5PzBGD PGJbS4XF7i206KJEnALfz3VbuKIWC8bn6zGia2UsrjXBr3p1plLbGv9t1LtU W_v44eddue9TYAp_3VZTR4FXv6nRV2FanCqKTyLBU6YXdFpS6TCaOLrOe5XW i7W_HT7ngDHqKp364iNsp9AZDUn19PRbq3lSwXN2HdVvpAUTzOq7n4wl6fp2 xP4kAunckFrkv55HTd6owEG5aIjll8XbCwjg6Mt2_nPtTw6qNJB5Rjnybr6V PjRthscTLgX4NRb1Nfo46EX7He2VWvUxSfzaEB1p4ZzMasg7oqXIV9f4dyUi .LzVmbIiHAA1A Received: from [67.91.91.101] by web55808.mail.re3.yahoo.com via HTTP; Fri, 25 Feb 2011 16:10:16 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Fri, 25 Feb 2011 16:10:16 -0800 (PST) From: Francisco Corella To: "oauth@ietf.org" , Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432527199A@TK5EX14MBXC207.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1055676122-1298679016=:6263" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 26 Feb 2011 00:09:25 -0000 --0-1055676122-1298679016=:6263 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, In section 3.2 you say: > To deal with token redirect, it is important for the > authorization server to include the identity of the intended > recipients, namely a single resource server (or a list of > resource servers). You should add that each resource server must verify that it is the intended recipient of the token.=C2=A0 (This prevents a malicious resource server from using a token that it has legitimately received to obtain resources from a target resource server; the target resource server will foil the attack by noticing that it is not the intended recipient of the token.)=C2=A0 Perhaps it goes without saying, but it doesn't hurt to be explicit. Francisco --- On Fri, 2/25/11, Mike Jones wrote: From: Mike Jones Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03 To: "oauth@ietf.org" Date: Friday, February 25, 2011, 10:17 PM =0A=0A =0A =0A=0A=0AI=E2=80=99ve published=0Adraft 03 of the=0AOAuth Bearer= Token Specification.=C2=A0 It contains one breaking change relative to=0Ad= raft 02 that was voted on by the working group:=C2=A0 changing the "OAuth2"= OAuth access token type name to "Bearer".=C2=A0 The full set of changes in= this draft is: =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=0ARestored the WWW-Authenticate response header functionality deleted f= rom the framework specification in draft 12 based upon the specification te= xt from draft 11.=0A =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=0AAugmented the OAuth Parameters registry by adding two additional p= arameter usage locations: "resource request" and "resource response".=0A = =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0ARegistered t= he "oauth_token" OAuth parameter with usage location "resource request".=0A= =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0ARegistered = the "error" OAuth parameter. =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=0ACreated the OAuth Error registry and registered errors.= =0A =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0AChanged = the "OAuth2" OAuth access token type name to "Bearer". =0A =C2=A0 =0AThe dr= aft is available at these locations: =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-o= auth-v2-bearer-03.txt =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-= 03.xml =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0Ahttp:= //self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.html =0A=0A=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0Ahttp://self-issued.info/doc= s/draft-ietf-oauth-v2-bearer-03.txt =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=0Ahttp://self-issued.info/docs/draft-ietf-oauth-v2-be= arer-03.xml =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0A= http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to= new versions as they are posted) =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=0Ahttp://self-issued.info/docs/draft-ietf-oauth-v2-be= arer.txt (will point to new versions as they are posted) =0A=0A=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0Ahttp://self-issued.info/docs/d= raft-ietf-oauth-v2-bearer.xml (will point to new versions as they are poste= d) =0A=0A=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0Ahttp://sv= n.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with h= tml, txt, and html versions available) =0A =C2=A0 =0AYour feedback is solic= ited. =0A =C2=A0 =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike =0A =C2=A0 =0A=0A =0A -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-1055676122-1298679016=:6263 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

In section 3.2 you say:
> To deal with token redirect, it is important for the
> authori= zation server to include the identity of the intended
> recipients, n= amely a single resource server (or a list of
> resource servers).
=
You should add that each resource server must verify that it
is the = intended recipient of the token.  (This prevents a
malicious resour= ce server from using a token that it has
legitimately received to obtain= resources from a target
resource server; the target resource server wil= l foil the
attack by noticing that it is not the intended recipient ofthe token.)  Perhaps it goes without saying, but it doesn't
hurt = to be explicit.

Francisco

--- On Fri, 2/25/11, Mike Jones = <Michael.Jones@microsoft.com> wrote:

From: Mike Jones <Michael.Jones@microsoft.com>
S= ubject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03
To: "o= auth@ietf.org" <oauth@ietf.org>
Date: Friday, February 25, 2011, 1= 0:17 PM

=0A=0A =0A =0A=0A
= =0A

I= =E2=80=99ve published=0Adraft 03 of= the=0AOAuth Bearer Token Specification.  It contains one breaking change relative to=0Adraft 02 that was voted on by the working group:  = changing the "OAuth2" OAuth access token type name to "Bearer".  The f= ull set of changes in this draft is:

=0A

=0A=C2=B7  &n= bsp;     =0ARestored the WWW-= Authenticate response header functionality deleted from the framework speci= fication in draft 12 based upon the specification text from draft 11.=0A =0A

=0A= =C2=B7        =0A<= /span>Augmented the OAuth Parameters registry by adding two a= dditional parameter usage locations: "resource request" and "resource respo= nse".=0A

=0A

=0A=C2=B7      &nbs= p; =0ARegistered the "oauth_token" OAuth paramete= r with usage location "resource request".=0A

=0A

=0A=C2=B7 = ;       =0ARegister= ed the "error" OAuth parameter.

=0A

=0A=C2=B7   = ;     =0ACreated the OAuth Er= ror registry and registered errors.=0A

=0A

=0A=C2=B7  &= nbsp;     =0AChanged the "OAu= th2" OAuth access token type name to "Bearer".

=0A

 

=0A

The draft is= available at these locations:

=0A

=0A=C2=B7   &n= bsp;    =0Ahttp://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-= bearer-03.txt

=0A

=0A=C2=B7     &n= bsp;  =0Ahttp://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-03.xm= l

=0A

=0A=C2=B7       &n= bsp;=0Ahttp://self= -issued.info/docs/draft-ietf-oauth-v2-bearer-03.html

=0A

=C2=B7        =0Ahttp://self-issued.info/docs/draft-i= etf-oauth-v2-bearer-03.txt

=0A

=0A=C2=B7   &= nbsp;    =0Ahttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-03.xml=

=0A

=0A=C2=B7       &nb= sp;=0Ahttp://self-iss= ued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versio= ns as they are posted)

=0A

=0A=C2=B7    &nb= sp;   =0Ahttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will poi= nt to new versions as they are posted)

=0A

=0A=C2=B7 &nb= sp;      =0Ahttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer= .xml (will point to new versions as they are posted)

=0A

= =0A=C2=B7        =0Ahttp://svn.openid.net/repos/specifications/oau= th/2.0/ (Subversion repository, with html, txt, and html versions avail= able)

=0A

 

=0A

Your feedback is solicited.

=0A

 

=0A

  =             &nb= sp;            =             &nb= sp;            =             -- Mike<= /p> =0A

 

=0A
=0A =0A

-----Inline Attachment Follows----= -

_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
--0-1055676122-1298679016=:6263-- From beaton@google.com Fri Feb 25 16:35:26 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F233A6A98 for ; Fri, 25 Feb 2011 16:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.227 X-Spam-Level: X-Spam-Status: No, score=-105.227 tagged_above=-999 required=5 tests=[AWL=0.750, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cppj36vzxAJA for ; Fri, 25 Feb 2011 16:35:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id B120E3A6A95 for ; Fri, 25 Feb 2011 16:35:20 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p1Q0aCZt008291 for ; Fri, 25 Feb 2011 16:36:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298680573; bh=9Mx3R7YzqV+mP/Mf46ko+Oq171w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=QbW+PNEUGLW3MJ7JO6/62kHo9bw0YRI6GB+E20sfOxTWHNPjr1u231Vo6Qinnjr5P GvoHogcOx8oDgHsVHRdzw== Received: from pwj6 (pwj6.prod.google.com [10.241.219.70]) by kpbe15.cbf.corp.google.com with ESMTP id p1Q0aAGW022370 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Feb 2011 16:36:11 -0800 Received: by pwj6 with SMTP id 6so484001pwj.32 for ; Fri, 25 Feb 2011 16:36:10 -0800 (PST) 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=qtf/+9Pb3KC1/hW8j56qymTmxi5yKBjaDnnL1EUcexc=; b=P+szSLsCvMrZen2NueaUnmNXmQHETZDX3919GAPK4rvAf8b1J3OL4OWB6bI6s+sO7w XMa6MKVFABJmUZ0phPJA== 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=YCwbm3G9obgAK+fQP43wonYY1UTeZusb/5rSJt19DaDQzW+0o6uOUpqE7Cfca1UbZx uQUryNcUXBWqKTC4ISxQ== MIME-Version: 1.0 Received: by 10.142.212.10 with SMTP id k10mr2163661wfg.70.1298680570369; Fri, 25 Feb 2011 16:36:10 -0800 (PST) Received: by 10.142.213.7 with HTTP; Fri, 25 Feb 2011 16:36:10 -0800 (PST) In-Reply-To: <593793.24331.qm@web55801.mail.re3.yahoo.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <593793.24331.qm@web55801.mail.re3.yahoo.com> Date: Fri, 25 Feb 2011 16:36:10 -0800 Message-ID: From: Brian Eaton To: fcorella@pomcor.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "websec@ietf.org" , OAuth Mailing List , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 00:35:26 -0000 I don't think the advice from the OAuth 1.0a spec is wrong: http://oauth.net/core/1.0a/#anchor38 "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. Service Providers SHOULD strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the User at the Consumer site intended to complete the OAuth negotiation with the Service Provider." This is the purpose of the "state" parameter during the approval flows. Cheers, Brian On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella wr= ote: > > Hi James, > > You raise an interesting point.=A0 I hadn't thought about the > threat of Login CSRF. > > > Q. Should an OAuth client app list the authorization server > > in the Origin header of requests to resource servers? > > > > In OAuth (delegation) flows a server dynamically issues > > credentials (such as a bearer token) to a client app to use > > in subsequent HTTP requests to other servers. To combat > > login cross-site request forgery (CSRF) attacks [1] (where > > an attacker=82=C4=F4s server issues the attacker=82=C4=F4s credentials = to a > > client app ... > > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? > > Even though the particular attack you describe may not work, > OAuth is wide open to Login CSRF in a different way.=A0 An > attacker can legitimately obtain an authorization code, and > then cause the victim's browser to submit it to the client > application, thus logging the victim in to the client > application as the attacker (in a social login scenario such > as "log in with Facebook").=A0 I bet all applications that use > OAuth to delegate authentication (to Facebook, Twitter, > Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. > > One solution I would propose is to have the client set a > pre-session cookie in the user's browser before the first > redirection and include the value of the cookie in the local > state parameter that it sends to the authorization server. > The authorization server later returns the local state > together with the authorization code, and the browser adds > the cookie, so the client can prevent the attack by checking > that the value of the cookie agrees with the value it > included in the local state. > > Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From fcorella@pomcor.com Fri Feb 25 17:53:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7293A6A48 for ; Fri, 25 Feb 2011 17:53:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTxSd6CWh2gh for ; Fri, 25 Feb 2011 17:53:52 -0800 (PST) Received: from nm8.bullet.mail.ac4.yahoo.com (nm8.bullet.mail.ac4.yahoo.com [98.139.52.205]) by core3.amsl.com (Postfix) with SMTP id D20873A6A0B for ; Fri, 25 Feb 2011 17:53:51 -0800 (PST) Received: from [98.139.52.196] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 Received: from [98.139.52.170] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 01:54:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 917922.87507.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 19488 invoked by uid 60001); 26 Feb 2011 01:54:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298685279; bh=Y6DYoZRHXkUi8maM5KEp5EmrARL7CQJR8g2mVPGmS4E=; 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=Xw52HcGYD5fvshaZyUS4rKGpYItcFTtY8ogIsyCSX1wfNeKRwmQRhZkTWf3w4zbgDcc1KLoh5tfVaKlZDI0XNAdNQmGofeufXpKmXZkA53NRaZuDL2y2geaMdke2W4z1PICbJDakEHooPXg7WzWOgT0STSGfEfowJ2ElNh7c15g= Message-ID: <805657.18502.qm@web55805.mail.re3.yahoo.com> X-YMail-OSG: a_bnh0oVM1mQ27523OXTyJQJXFC0R4dgh5XBMQ2hpDrsTsW JV9fKrNlW2DAar.WfxyFSG.86.xFiFfPm2rw0p0E1baSIMhl_QeNGq1RTKXk 3BNgk59EU7.v.Od96t0odNNbJXS6qHFBi7Oy6rZuSkBwlG9SJcr6j1IzK59i pH9_lBFckEx5nQq4aFgwD2m3SaCm9kH07jmi6vjHV1k7lOFeUd474F5g1.wZ .SNetsAknrrRO5uRNHrftT38K8U.kXjNhcgdxVA1MLcuCtYJtq.pjv.HK4xD sLLV5X9B5uoqjHFbb76FCujk_WDrKc7NVgiaX0_zjKtRmpZOTo9Qe_eVUj3w kzBRizS0- Received: from [67.91.91.101] by web55805.mail.re3.yahoo.com via HTTP; Fri, 25 Feb 2011 17:54:39 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Fri, 25 Feb 2011 17:54:39 -0800 (PST) From: Francisco Corella To: Brian Eaton In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1828664380-1298685279=:18502" Cc: "websec@ietf.org" , OAuth Mailing List , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 26 Feb 2011 01:53:52 -0000 --0-1828664380-1298685279=:18502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There is nothing wrong with telling people that they should prevent CSRF at= tacks :-) But there is no explicit state parameter in OAuth 1.0a.=C2=A0 Do you think = that implementors of 1.0a, just by reading section 11.14, are aware of the = danger of Login CSRF and can figure out how to prevent it, using a pre-sess= ion cookie and implementing a state parameter that is not even mentioned in= the specification? Francisco --- On Sat, 2/26/11, Brian Eaton wrote: From: Brian Eaton Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat lo= gin CSRF To: fcorella@pomcor.com Cc: "OAuth Mailing List" , "websec@ietf.org" , "James HManger" , "Karen P. Lewison" = Date: Saturday, February 26, 2011, 12:36 AM I don't think the advice from the OAuth 1.0a spec is wrong: http://oauth.net/core/1.0a/#anchor38 "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. Service Providers SHOULD strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the User at the Consumer site intended to complete the OAuth negotiation with the Service Provider." This is the purpose of the "state" parameter during the approval flows. Cheers, Brian On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella wr= ote: > > Hi James, > > You raise an interesting point.=C2=A0 I hadn't thought about the > threat of Login CSRF. > > > Q. Should an OAuth client app list the authorization server > > in the Origin header of requests to resource servers? > > > > In OAuth (delegation) flows a server dynamically issues > > credentials (such as a bearer token) to a client app to use > > in subsequent HTTP requests to other servers. To combat > > login cross-site request forgery (CSRF) attacks [1] (where > > an attacker=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A= =C3=84=C3=B4s credentials to a > > client app ... > > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? > > Even though the particular attack you describe may not work, > OAuth is wide open to Login CSRF in a different way.=C2=A0 An > attacker can legitimately obtain an authorization code, and > then cause the victim's browser to submit it to the client > application, thus logging the victim in to the client > application as the attacker (in a social login scenario such > as "log in with Facebook").=C2=A0 I bet all applications that use > OAuth to delegate authentication (to Facebook, Twitter, > Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. > > One solution I would propose is to have the client set a > pre-session cookie in the user's browser before the first > redirection and include the value of the cookie in the local > state parameter that it sends to the authorization server. > The authorization server later returns the local state > together with the authorization code, and the browser adds > the cookie, so the client can prevent the attack by checking > that the value of the cookie agrees with the value it > included in the local state. > > Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0-1828664380-1298685279=:18502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There is nothing wrong with telling people th= at they should prevent CSRF attacks :-)

But there is no explicit sta= te parameter in OAuth 1.0a.  Do you think that implementors of 1.0a, j= ust by reading section 11.14, are aware of the danger of Login CSRF and can= figure out how to prevent it, using a pre-session cookie and implementing = a state parameter that is not even mentioned in the specification?

F= rancisco

--- On Sat, 2/26/11, Brian Eaton <beaton@google.co= m> wrote:

From: Brian Eaton <= beaton@google.com>
Subject: Re: [OAUTH-WG] Indicating origin of OAuth= credentials to combat login CSRF
To: fcorella@pomcor.com
Cc: "OAuth = Mailing List" <oauth@ietf.org>, "websec@ietf.org" <websec@ietf.org= >, "James HManger" <James.H.Manger@team.telstra.com>, "Karen P. Lewison= " <kplewison@pomcor.com>
Date: Saturday, February 26, 2011, 12:36 = AM

I don't think the advice from the OAuth = 1.0a spec is wrong:

http://oauth.net/core/1.0a/#anchor38

"Cross-S= ite Request Forgery (CSRF) is a web-based attack whereby HTTP
requests a= re transmitted from a user that the website trusts or has
authenticated.= CSRF attacks on OAuth approvals can allow an attacker
to obtain authori= zation to OAuth Protected Resources without the
consent of the User. Ser= vice Providers SHOULD strongly consider best
practices in CSRF preventio= n at all OAuth endpoints.

CSRF attacks on OAuth callback URLs hosted= by Consumers are also
possible. Consumers should prevent CSRF attacks o= n OAuth callback URLs
by verifying that the User at the Consumer site intended to complete
the OAuth negotiation with the Service Provider."<= br>
This is the purpose of the "state" parameter during the approval flo= ws.

Cheers,
Brian

On Fri, Feb 25, 2011 at 3:42 PM, Francis= co Corella <fcorella@pomcor.com> wrote:
>
&= gt; Hi James,
>
> You raise an interesting point.  I hadn'= t thought about the
> threat of Login CSRF.
>
> > Q. S= hould an OAuth client app list the authorization server
> > in the= Origin header of requests to resource servers?
> >
> > I= n OAuth (delegation) flows a server dynamically issues
> > credent= ials (such as a bearer token) to a client app to use
> > in subseq= uent HTTP requests to other servers. To combat
> > login cross-sit= e request forgery (CSRF) attacks [1] (where
> > an attacker=E2=80=9A=C3=84=C3=B4s server issues the attacker=E2=80=9A=C3=84= =C3=B4s credentials to a
> > client app ...
>
> But ho= w will the client app get the "credentials" (bearer token)
> from the= wrong authorization server?
>
> Even though the particular att= ack you describe may not work,
> OAuth is wide open to Login CSRF in = a different way.  An
> attacker can legitimately obtain an autho= rization code, and
> then cause the victim's browser to submit it to = the client
> application, thus logging the victim in to the client> application as the attacker (in a social login scenario such
> = as "log in with Facebook").  I bet all applications that use
> O= Auth to delegate authentication (to Facebook, Twitter,
> Google, Link= edIn, Yahoo, etc.) are vulnerable to this now.
>
> One solution= I would propose is to have the client set a
> pre-session cookie in = the user's browser before the first
> redirection and include the value of the cookie i= n the local
> state parameter that it sends to the authorization serv= er.
> The authorization server later returns the local state
> = together with the authorization code, and the browser adds
> the cook= ie, so the client can prevent the attack by checking
> that the value= of the cookie agrees with the value it
> included in the local state= .
>
> Francisco
>
>
> _______________________= ________________________
> OAuth mailing list
> OAuth@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/oauth
>
--0-1828664380-1298685279=:18502-- From torsten@lodderstedt.net Sat Feb 26 04:26:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA783A67D7; Sat, 26 Feb 2011 04:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyaoEd1LIfVu; Sat, 26 Feb 2011 04:26:16 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 560DF3A67B6; Sat, 26 Feb 2011 04:26:15 -0800 (PST) Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtJEl-0006uH-QM; Sat, 26 Feb 2011 13:27:03 +0100 Message-ID: <4D68F197.7040707@lodderstedt.net> Date: Sat, 26 Feb 2011 13:27:03 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------030004040703060504060508" X-Df-Sender: torsten@lodderstedt-online.de Cc: "websec@ietf.org" , OAuth Mailing List Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:26:21 -0000 This is a multi-part message in MIME format. --------------030004040703060504060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi James, I would expect the token to carry information about its issuer. Would this be sufficient in order to detect CSRF? regards, Torsten. Am 25.02.2011 01:08, schrieb Manger, James H: > > Q. Should an OAuth client app list the authorization server in the > Origin header of requests to resource servers? > > In OAuth (delegation) flows a server dynamically issues credentials > (such as a bearer token) to a client app to use in subsequent HTTP > requests to other servers. To combat login cross-site request forgery > (CSRF) attacks [1] (where an attacker's server issues the attacker's > credentials to a client app to use on behalf of a victim at a > legitimate server) the client app needs to indicate where the > credentials came from. The Origin header [2] looks like the right > place to indicate this. > > [For the OAuth list: The Origin HTTP request header "indicates the > origin(s) that caused the user agent to issue the request" > [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2].] > > [For the WebSec list: An OAuth credential from an authorization server > is a bit like a cookie, but not restricted to the same origin.] > > Example: > > Client to (malicious) authorization server: -> > > POST /token HTTP/1.1 > > Host: login.example.com > > ... > > <- > > HTTP/1.1 200 OK > > ... > > { "access_token": "SlAV32hkKG", ...} > > Client to resource server: -> > > POST /uploadData HTTP/1.1 > > Host: api.exampledata.com > > Authorization: BEARER SlAV32hkKG > > Origin: https://login.example.com > > ... > > There can be other servers that contribute to a client app making a > request. For instance, one server can redirect to another. A Origin > request header can list multiple origins. The server will not be able > to distinguish which origin issued OAuth credentials from which issued > a redirect etc. That might not matter if a server has to trust all the > values listed in the Origin header. > > Q. Is it the group's expectation that servers checking the Origin > header will require all the listed origins to be trusted? > > [1] Robust Defenses for Cross Site Request Forgery, > http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf > > [2] The Web Origin Concept, > http://tools.ietf.org/html/draft-ietf-websec-origin > > [3] Principles of the Same Origin Policy, > http://tools.ietf.org/html/draft-abarth-principles-of-origin > > -- > > James Manger > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030004040703060504060508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi James,

I would expect the token to carry information about its issuer. Would this be sufficient in order to detect CSRF?

regards,
Torsten.

Am 25.02.2011 01:08, schrieb Manger, James H:

Q. Should an OAuth client app list the authorization server in the Origin header of requests to resource servers?

 

In OAuth (delegation) flows a server dynamically issues credentials (such as a bearer token) to a client app to use in subsequent HTTP requests to other servers. To combat login cross-site request forgery (CSRF) attacks [1] (where an attacker’s server issues the attacker’s credentials to a client app to use on behalf of a victim at a legitimate server) the client app needs to indicate where the credentials came from. The Origin header [2] looks like the right place to indicate this.

 

[For the OAuth list: The Origin HTTP request header “indicates the origin(s) that caused the user agent to issue the request” [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2].]

 

[For the WebSec list: An OAuth credential from an authorization server is a bit like a cookie, but not restricted to the same origin.]

 

 

Example:

 

  Client to (malicious) authorization server: ->

    POST /token HTTP/1.1

    Host: login.example.com

    …

  <-

    HTTP/1.1 200 OK

    …

    { "access_token": "SlAV32hkKG", …}

 

  Client to resource server: ->

    POST /uploadData HTTP/1.1

    Host: api.exampledata.com

    Authorization: BEARER SlAV32hkKG

    Origin: https://login.example.com

    …

 

 

There can be other servers that contribute to a client app making a request. For instance, one server can redirect to another. A Origin request header can list multiple origins. The server will not be able to distinguish which origin issued OAuth credentials from which issued a redirect etc. That might not matter if a server has to trust all the values listed in the Origin header.

Q. Is it the group’s expectation that servers checking the Origin header will require all the listed origins to be trusted?

 

[1] Robust Defenses for Cross Site Request Forgery, http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

[2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-origin

[3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-abarth-principles-of-origin

 

--

James Manger

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030004040703060504060508-- From torsten@lodderstedt.net Sat Feb 26 04:30:05 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621963A6800 for ; Sat, 26 Feb 2011 04:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qyy+6dC2djs for ; Sat, 26 Feb 2011 04:30:04 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 0409D3A6864 for ; Sat, 26 Feb 2011 04:30:03 -0800 (PST) Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtJIW-00020J-Tj; Sat, 26 Feb 2011 13:30:56 +0100 Message-ID: <4D68F281.9080904@lodderstedt.net> Date: Sat, 26 Feb 2011 13:30:57 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:30:05 -0000 I agree with your point of view. Consequentely, the parameter name should be something like "bearer_token"? regards, Torsten. Am 25.02.2011 20:49, schrieb Brian Eaton: > My two cents: > > We've already taken three user visible outages because the OAuth2 spec > reused the "oauth_token" parameter in a way that was not compatible > with the OAuth1 spec. > > Luckily they were all caught before they caused serious damage. > > Generic parameter names are not useful. They lead to confused > developers and confused code. If code needs to treat the values > differently, the names should be different as well. > > Cheers, > Brian > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt wrote: >> There was some discussion on the type for the authorization header being >> OAUTH / MAC / BEARER etc. Did we have a resolution? >> As for section 2.2 and 2.3, should we not have a more neutral solution as >> well and use "authorization_token" instead of oauth_token. The idea is that >> the parameter corresponds to the authorization header and NOT the value of >> it. The value of such a parameter an be an encoded value that corresponds to >> the authorization header. For example: >> GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: >> server.example.com >> instead of >> GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com >> The concern is that if for some reason you switch to "MAC" tokens, then you >> have to change parameter names. Why not keep them consistent? >> Apologies if this was already resolved. >> Phil >> phil.hunt@oracle.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 torsten@lodderstedt.net Sat Feb 26 04:38:20 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42D23A683C; Sat, 26 Feb 2011 04:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XQ5pregnxHP; Sat, 26 Feb 2011 04:38:19 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 6F5CB3A6800; Sat, 26 Feb 2011 04:38:19 -0800 (PST) Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtJQX-00016N-Fw; Sat, 26 Feb 2011 13:39:13 +0100 Message-ID: <4D68F471.3090204@lodderstedt.net> Date: Sat, 26 Feb 2011 13:39:13 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marius Scurtescu References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:38:21 -0000 Am 18.02.2011 18:40, schrieb Marius Scurtescu: > On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin wrote: >> Marius >> >> Isn't the risk of the refresh token leaking the same as the risk of the >> access token leaking, i.e. why not provide both? > Sure, but refresh tokens never die. One can replace the refresh token with every refresh request, so the impact of a refresh token leakage could be reduced to that of a leaked access token. I'm in favour to add the refresh token parameter to the implicit grant flow as it would make it more useable for native apps. On the other hand, requirements of the authorization code flow could be strengthened to require client authentication. regards, Torsten. > >> IMO, the refresh token >> just provides a server side mechanism for revoking access, where resource >> servers are distributed, through having short lived access tokens >> >> Of course, the refresh access token flow currently requires a secret so >> would need to be changed or alternative flow introduced. Will wait for >> details of how auth code flow can be used > The flow is not changing. For native apps the client secret can either > be declared optional, or a "well known secret" can be issued for > native apps. > > The authorization server can also insist that each native app has a > unique secret and it must guard it, that may or may not make sense. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sat Feb 26 05:01:58 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A813A683C for ; Sat, 26 Feb 2011 05:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUjM38siEvZx for ; Sat, 26 Feb 2011 05:01:57 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 8D3063A6800 for ; Sat, 26 Feb 2011 05:01:57 -0800 (PST) Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtJnP-0002SJ-F9 for oauth@ietf.org; Sat, 26 Feb 2011 14:02:51 +0100 Message-ID: <4D68F9FB.3070802@lodderstedt.net> Date: Sat, 26 Feb 2011 14:02:51 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Breaking change for authorization code flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 13:01:58 -0000 Hi all, I just noticed a change between draft 11 and 13 I would like to bring to your attention. Until draft 11, the spec left open whether the client of the authz code grant type had to present a secret or not. It had been a decision of the authz server and I assume some deployments already work that way (at least our's does). Accordingly the text for the request to change a code for token is: "Validate the client credentials (if present) and ensure they match the authorization code." In drafts 12/13, the text has been changed to: "Validate the client credentials and ensure they match the authorization code." Given the assumption that, w/o a dynamic client registration feature, native application cannot securely manage secrets, this means native apps cannot use the authorization code flow any longer. The only interactive flows left would be "implicit grant", which is not capable of issuing refresh tokens. Which in turn means, native app would be forced to acquire access tokens interactively in every session. Am I right? Or do I just misinterpret the text? I would suggest to stick to the -11s semantics of the authorization code flow. regards, Torsten. From torsten@lodderstedt.net Sat Feb 26 05:15:17 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E663A692E for ; Sat, 26 Feb 2011 05:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ15KAZiKm7v for ; Sat, 26 Feb 2011 05:15:16 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 997BA3A6929 for ; Sat, 26 Feb 2011 05:15:16 -0800 (PST) Received: from [79.253.40.1] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtK0I-000569-Cn; Sat, 26 Feb 2011 14:16:10 +0100 Message-ID: <4D68FD1A.9020205@lodderstedt.net> Date: Sat, 26 Feb 2011 14:16:10 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marius Scurtescu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Revocation (was: Re-Chartering: What Items to work on?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 13:15:17 -0000 thank you for your feedback. Am 03.02.2011 02:01, schrieb Marius Scurtescu: > Following up on the Token Revocation extension proposed at: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > I am suggesting three changes to this extension: > > 1. Either drop client authentication or make it optional. If clients > want to revoke tokens, more power to them. If it is a malicious > client, why would the authorization server deny revoking tokens? The impact of an unauthorized revocation is merely inconvenience since the client has the go through the authorization process again. Nevertheless, I would like to add some protection here. My suggestion: the authorization server should require authentication for clients having such credentials. > 2. Can we drop the "token_type" parameter, as suggested before? yes, we can. I will modify this in the next revision of the I-D. > 3. "authorization server MUST also invalidate all access tokens issued > for that refresh token." can we change this MUST to a SHOULD? Why? The server is only required to revoke the access tokens if it is capable to do so. > > In case of success, why is the server supposed to return 204 instead > of 200? Just worried that this will confuse clients. because there is no response body (required). I'm open to change it to 200 but what data shall be contained in the response? regards, Torsten. > Thanks, > Marius > > > > On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu wrote: >> On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt >> wrote: >>> Am 12.01.2011 22:19, schrieb Richer, Justin P.: >>>> Yes, let the server do the work. In practice, it's going to be looking up >>>> the token based on the token value anyway (for bearer tokens, at least). All >>>> the client really cares about is asking to "revoke this token that I am >>>> sending you". If the client credentials and token are correct and >>>> verifiable, then the revoke should go through. >>> What do others think? >> I agree with Justin's suggestion, let the server figure the token >> type. The server should be able to do that anyhow. >> >> >>>> A client wanting to revoke both a request token and an access token will >>>> have to make several calls to this, unless you want to put in a way to put >>>> multiple token values in. I don't recommend that though, as it seems to me >>>> an optimization for a problem nobody has yet. >>> the token_type does not control whether the server deletes all access tokens >>> associated with a refresh token. >>> >>> This depends on the authorization servers policy. >> There are cases when the server cannot revoke the access tokens >> associated with a refresh token (static access tokens for example). >> That being said, I think the server SHOULD revoke all access tokens if >> possible. >> >> >> Marius >> From eran@hueniverse.com Sat Feb 26 08:48:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1883A67C2 for ; Sat, 26 Feb 2011 08:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax6JfpauVHkG for ; Sat, 26 Feb 2011 08:48:45 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2BA213A672F for ; Sat, 26 Feb 2011 08:48:44 -0800 (PST) Received: (qmail 9827 invoked from network); 26 Feb 2011 16:49:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Feb 2011 16:49:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 26 Feb 2011 09:49:39 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Sat, 26 Feb 2011 09:49:15 -0700 Thread-Topic: [OAUTH-WG] Breaking change for authorization code flow? Thread-Index: AcvVtX1CepHPdBwnSSKoFnMtR0GPvAAHzUOQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3771@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D68F9FB.3070802@lodderstedt.net> In-Reply-To: <4D68F9FB.3070802@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Breaking change for authorization code flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 16:48:46 -0000 I think you are making too much of this. Section 3.2 clearly states: In addition, the authorization server MAY allow unauthenticated access to= ken requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means. Which covers everything. However, I want the rest of the document to clearl= y express the expectation that the client is authenticated and lack of such= is an exception. This will also make the security consideration section si= mpler by assuming the client is authenticated. I don't mind putting this back in if others feel strongly about it, and wil= l take it in as part of the LC review process. I consider this purely edito= rial. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Saturday, February 26, 2011 5:03 AM > To: OAuth WG > Subject: [OAUTH-WG] Breaking change for authorization code flow? >=20 > Hi all, >=20 > I just noticed a change between draft 11 and 13 I would like to bring to = your > attention. >=20 > Until draft 11, the spec left open whether the client of the authz code g= rant > type had to present a secret or not. It had been a decision of the authz > server and I assume some deployments already work that way (at least our'= s > does). >=20 > Accordingly the text for the request to change a code for token is: > "Validate the client credentials (if present) and ensure they match the > authorization code." >=20 > In drafts 12/13, the text has been changed to: > "Validate the client credentials and ensure they match the authorization > code." >=20 > Given the assumption that, w/o a dynamic client registration feature, nat= ive > application cannot securely manage secrets, this means native apps cannot > use the authorization code flow any longer. >=20 > The only interactive flows left would be "implicit grant", which is not c= apable > of issuing refresh tokens. Which in turn means, native app would be force= d > to acquire access tokens interactively in every session. >=20 > Am I right? Or do I just misinterpret the text? >=20 > I would suggest to stick to the -11s semantics of the authorization code = flow. >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sun Feb 27 04:44:45 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0913A68F6 for ; Sun, 27 Feb 2011 04:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe9tJlTIDqJZ for ; Sun, 27 Feb 2011 04:44:44 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 112063A6809 for ; Sun, 27 Feb 2011 04:44:43 -0800 (PST) Received: from [79.253.41.153] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ptg0J-0006kr-OR; Sun, 27 Feb 2011 13:45:39 +0100 Message-ID: <4D6A4773.3010603@lodderstedt.net> Date: Sun, 27 Feb 2011 13:45:39 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4D68F9FB.3070802@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234464F0C3771@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3771@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Breaking change for authorization code flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 12:44:45 -0000 Am 26.02.2011 17:49, schrieb Eran Hammer-Lahav: > I think you are making too much of this. glad to hear :-) I just want to make sure native apps are OAuth 1st class citizens. The aibility to issue refresh tokens to such clients is a key feature, which is by no meaning an exception. Even if they cannot be authenticated. regards, Torsten. > Section 3.2 clearly states: > > In addition, the authorization server MAY allow unauthenticated access token requests > when the client identity does not matter (e.g. anonymous client) or > when the client identity is established via other means. > > Which covers everything. However, I want the rest of the document to clearly express the expectation that the client is authenticated and lack of such is an exception. This will also make the security consideration section simpler by assuming the client is authenticated. > > I don't mind putting this back in if others feel strongly about it, and will take it in as part of the LC review process. I consider this purely editorial. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Saturday, February 26, 2011 5:03 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Breaking change for authorization code flow? >> >> Hi all, >> >> I just noticed a change between draft 11 and 13 I would like to bring to your >> attention. >> >> Until draft 11, the spec left open whether the client of the authz code grant >> type had to present a secret or not. It had been a decision of the authz >> server and I assume some deployments already work that way (at least our's >> does). >> >> Accordingly the text for the request to change a code for token is: >> "Validate the client credentials (if present) and ensure they match the >> authorization code." >> >> In drafts 12/13, the text has been changed to: >> "Validate the client credentials and ensure they match the authorization >> code." >> >> Given the assumption that, w/o a dynamic client registration feature, native >> application cannot securely manage secrets, this means native apps cannot >> use the authorization code flow any longer. >> >> The only interactive flows left would be "implicit grant", which is not capable >> of issuing refresh tokens. Which in turn means, native app would be forced >> to acquire access tokens interactively in every session. >> >> Am I right? Or do I just misinterpret the text? >> >> I would suggest to stick to the -11s semantics of the authorization code flow. >> >> regards, >> Torsten. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sun Feb 27 05:04:02 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933713A68F6 for ; Sun, 27 Feb 2011 05:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP1uIjjnrmJU for ; Sun, 27 Feb 2011 05:04:00 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by core3.amsl.com (Postfix) with ESMTP id BED0C3A69A3 for ; Sun, 27 Feb 2011 05:03:58 -0800 (PST) Received: from [79.253.41.153] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PtgIw-0002WH-KM; Sun, 27 Feb 2011 14:04:54 +0100 Message-ID: <4D6A4BF6.9030602@lodderstedt.net> Date: Sun, 27 Feb 2011 14:04:54 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Breno References: <90C41DD21FB7C64BB94121FBBC2E723445A91D4299@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42A5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D42F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020500080107020603050100" X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Freedom of assembly for response_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 13:04:02 -0000 This is a multi-part message in MIME format. --------------020500080107020603050100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Breno, what is the difference between your cookie and any access token? I'm asking because I'm under the impression the cookie is "just" another token for the purpose of securely communicating between the OpenIDConnect client and the OpenIdConnect server. If so, you could obtain this token using the standard response type. regards, Torsten. Am 18.02.2011 23:03, schrieb Breno: > Example 1: > > OpenIDConnect End User Authorization Request for ' OAuth2 parameters>&response_type=token+cookie' > OpenIDConnect End User Authorization Response ' parameters>&access_token=foo&cookie=bar' > > Example 2: > > OpenIDConnect End User Authorization Request for ' OAuth2 parameters>&response_type=code+cookie' > OpenIDConnect End User Authorization Response ' parameters>&code=foo' > > OpenIDConnect outcome of grant redemption ... ' parameters>[&refresh_token=foo]&access_token=bar&cookie=baz' > > Example 3 (specific syntax still to be agreed upon): > > OpenIDConnect End User Cookie Refresh Request ' parameters>&response_type=cookie&cookie=... ' > OpenIDConnect End User Cookie Refresh Response ' parameters>&cookie=foo' > > Example 4 (specific syntax still in the work): > OpenIDConnect End User Logout Request '&access_token=bar' (to new > endpoint) > OpenIDConnect End User Logout Response '' > > On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav > > wrote: > > Can you send an example wire interaction? > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, February 17, 2011 10:07 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav > > wrote: > > Ok. > > So you want to request a cookie from both endpoints: the > authorization endpoint and the token endpoint? How would that > work? There is no response_type on the token endpoint. > > There is no need to. The grant carries the information. > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, February 17, 2011 9:30 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type > > On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav > > wrote: > > So an implicit grant can produce just a cookie or both cookie > and token, but not code? > > Yes, cookies would be returned in the same context of > access_tokens, either as the result of an implicit grant or > resulting from an explicit exchange from a code-type grant. > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, February 17, 2011 5:10 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for > response_type > > On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav > > wrote: > > Is cookie exchanged for an access token? Authorization > grants are not meant to be useful by themselves, only > exchanged for an access token. > > In this scenario, grants are exchanged for access tokens > and/or cookies. > > Can you request only a cookie? Or is it always with > either a token or code? > > The idea is that a grant can be exchanged for only a > cookie in some cases. > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, February 17, 2011 4:50 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for > response_type > > On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav > > wrote: > > I am not questioning the use case, only how it fits > within the OAuth framework. > > I don’t understand how such an extension is expected > to work with the existing grant types. The > response_type parameter is used to identify if the > flow being used is for an implicit grant or > authorization code. Are you suggesting a new grant > type? Are you suggesting additional response > parameters/headers (in the case of a cookie) with both > grant types? > > It's a separate grant type that can be combined with > either of the previous types. > > Without full requirements we can’t design an > extension point. Asking to make this parameter a > free text field is not helpful. > > The requirement is to allow another grant type, cookie. > > - cookie can be used separately or in combination with > code or token. > > - if specified by itself or in combination with token, > it's returned in the End User Authorization Response, > in analogy/in addition to the access_token > > - If specified in combination with code, it's returned > in exchange for the code, in analogy with the access_token > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, February 17, 2011 4:22 PM > > > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Freedom of assembly for > response_type > > The use case is very straightforward: > > - SAML provides session management. Facebook > Connect provides session management. Both use > cookies. These are authentication protocols but > common usages of both SAML and FB Connect imply > authorization grants. > > - OpenID2.0 does not provide session management. > This has proven to reduce the value of OpenID and > make it unsuitable for many scenarios. > > We would like federation protocols based on OAuth2 > to be high-value. We would rather that they not be > be hacks built on top of OAuth2. That means that > we need a first-order concept of cookie. A cookie > can be refreshed independent of the grant > associated with it. A cookie is something the > client holds on to that identifies the user (i.e., > it's for user-client authentication), but that the > client is happy to outsource the management of > security/crypto/logged-in/logged-out state to the > server. > > The cookie is produced and returned by the server, > in combination with a grant, but it can be > refreshed independently. > > This is a solid and proven use case, and is of > fundamental value to many planned OAuth2 > implementations. > > On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav > > > wrote: > > You need to define how this proposed extension > works with the overall architecture. > > This is not just an endpoint people can bastardize > (I am not suggesting **you** are) as they see fit. > It must fit with the overall model which is that > this endpoint returns either an access token or an > authorization grant. An authorization grant has to > be exchanged for an access token. > > If you are going to return something else, instead > or in addition to the token/code options, you need > to explain how it fits within the model. I am > opposed to an open-ended extension point that is > not consistent (and restricted) to the model we > spent a year to define and refine. The token+code > response type was well defined (it was the use > case that wasn’t). > > To move this forward, you need to come up with > specific requirements, not just making something > extensible without understanding what it is you > are trying to extend. That’s like the OAuth 1.0 > utterly broken oauth_version parameter and the > long confusion it created later on. > > EHL > > *From:*Breno [mailto:breno.demedeiros@gmail.com > ] > > *Sent:* Thursday, February 17, 2011 1:58 PM > *To:* Eran Hammer-Lahav > *Cc:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Freedom of assembly for > response_type > > On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav > > > wrote: > > The best approach (at this point) is to leave the > spec unchanged. However, another spec can update > the definition of the response_type parameter, > including defining a registry or other methods for > extensibility. > > We can define this now, and it will not have any > impact on existing code, but I am leery of adding > yet another extensibility vector without > sufficient requirement. I also think that adding > extension parameters can handle this cleanly. > > The spec, as currently written does not imply that > the only possible values are 'code' and 'token'. > The only concern is that libraries may implement > such restriction and make extending this behavior > different. > > I do not think that extension parameters can > handle this cleanly. In particular, if the > response_type is neither code nor token. > > EHL > > *From:*oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org > ] *On Behalf Of > *Breno > *Sent:* Thursday, February 17, 2011 10:30 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Freedom of assembly for > response_type > > - Problem 1: Several WG participants are > working on deploying a federated signon > protocol based on OAuth2 (aka OpenIDConnect) > and would like to return an additional > 'session cookie' together with the auth_token. > Or sometimes return only a cookie as the > result of authorization, since cookies will > likely have shorter lifetimes than access > tokens, for security and usability reasons, > and require more frequent refresh > requirements. In any case, there aremultiple > reasons for making the cookie separate from > the auth_token, including both security and > flexibility of deployment. However, there is > no way to express this except adding an > arbitrary extension parameter (to effectively > express a different response type). > > - Problem 2: Codification of code_and_token > created controversy as there was not enough > traction among participants to put it in the > core. However, it is entirely possible that > deployment experience will lead players to > revisit this topic. > > - Proposed solution: > > 1. Allow response_type to be a space separated > list of arbitrary strings > > E.g.: > > response_type=code > > response_type=token > > response_type=code+token > > response_type=cookie > > response_type=code+cookie > > response_type=token+cookie > > response_type=foo+bar > > Would all be syntactically valid responses > from the perspective of OAuth2.0 Core > response_type values. > > 2. Define behaviors in the core only for > values 'code' and 'token'. Allow extensions to > define what do with 'code+token' or with any > other values or combinations of values. > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020500080107020603050100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Breno,

what is the difference between your cookie and any access token?

I'm asking because I'm under the impression the cookie is "just" another token for the purpose of securely communicating between the OpenIDConnect client and the OpenIdConnect server. If so, you could obtain this token using the standard response type.

regards,
Torsten.

Am 18.02.2011 23:03, schrieb Breno:
Example 1:

OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=token+cookie'
OpenIDConnect End User Authorization Response  '<other required OAuth2 parameters>&access_token=foo&cookie=bar'

Example 2:

OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=code+cookie'
OpenIDConnect End User Authorization Response '<other required OAuth2 parameters>&code=foo'

OpenIDConnect outcome of grant redemption ... '<other required OAuth2 parameters>[&refresh_token=foo]&access_token=bar&cookie=baz'

Example 3 (specific syntax still to be agreed upon):

OpenIDConnect End User Cookie Refresh Request '<other required OAuth2 parameters>&response_type=cookie&cookie=... '
OpenIDConnect End User Cookie Refresh Response '<other required OAuth2 parameters>&cookie=foo'

Example 4 (specific syntax still in the work):
OpenIDConnect End User Logout Request '&access_token=bar' (to new endpoint)
OpenIDConnect End User Logout Response '<something to mean ok>'

On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Can you send an example wire interaction?

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 10:07 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Ok.

 

So you want to request a cookie from both endpoints: the authorization endpoint and the token endpoint? How would that work? There is no response_type on the token endpoint.

 

There is no need to. The grant carries the information.

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 9:30 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

So an implicit grant can produce just a cookie or both cookie and token, but not code?

 

Yes, cookies would be returned in the same context of access_tokens, either as the result of an implicit grant or resulting from an explicit exchange from a code-type grant.

 

 

 

EHL

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 5:10 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is cookie exchanged for an access token? Authorization grants are not meant to be useful by themselves, only exchanged for an access token.

 

In this scenario, grants are exchanged for access tokens and/or cookies.

 

 

Can you request only a cookie? Or is it always with either a token or code?

 

The idea is that a grant can be exchanged for only a cookie in some cases.

 

 

EHL

 

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 4:50 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I am not questioning the use case, only how it fits within the OAuth framework.

 

I don’t understand how such an extension is expected to work with the existing grant types. The response_type parameter is used to identify if the flow being used is for an implicit grant or authorization code. Are you suggesting a new grant type? Are you suggesting additional response parameters/headers (in the case of a cookie) with both grant types?

 

It's a separate grant type that can be combined with either of the previous types.

 

 

 

Without full requirements we can’t design an extension point. Asking to make this parameter a free text field is not helpful.

 

The requirement is to allow another grant type, cookie.

 

- cookie can be used separately or in combination with code or token.

 

- if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token

 

- If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token

 

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, February 17, 2011 4:22 PM


To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

The use case is very straightforward:

 

- SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants.

- OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios.

 

We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server.

 

The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently.

 

This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations.

 

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You need to define how this proposed extension works with the overall architecture.

 

This is not just an endpoint people can bastardize (I am not suggesting *you* are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token.

 

If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t).

 

To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]

Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

 

 

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility.

 

We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly.

 

The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different.

 

I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. 

 

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Freedom of assembly for response_type

 

- Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type).

 

- Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic.

 

 

- Proposed solution:

 

1. Allow response_type to be a space separated list of arbitrary strings

 

E.g.:

 

response_type=code

response_type=token

response_type=code+token

response_type=cookie

response_type=code+cookie

response_type=token+cookie

response_type=foo+bar

 

Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values.

 

 

2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. 


--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros




--
Breno de Medeiros


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------020500080107020603050100-- From peter.wolanin@acquia.com Sun Feb 27 06:58:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0082E3A6945 for ; Sun, 27 Feb 2011 06:58:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 182nVaFGzI2z for ; Sun, 27 Feb 2011 06:58:11 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id 92C153A6943 for ; Sun, 27 Feb 2011 06:58:11 -0800 (PST) Received: from source ([209.85.216.176]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTWpmvNODYTgGCjDWHukq3jiKkGGNSiZF@postini.com; Sun, 27 Feb 2011 06:59:09 PST Received: by qyk30 with SMTP id 30so2800955qyk.0 for ; Sun, 27 Feb 2011 06:59:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.73.133 with SMTP id q5mr3756114qaj.234.1298818747992; Sun, 27 Feb 2011 06:59:07 -0800 (PST) Received: by 10.224.136.74 with HTTP; Sun, 27 Feb 2011 06:59:07 -0800 (PST) Date: Sun, 27 Feb 2011 09:59:07 -0500 Message-ID: From: Peter Wolanin To: eran@hueniverse.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth v2 Mac token spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 15:00:16 -0000 Dear Mr. Hammer-Lahav regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 I was quite happy to find this, since I had overlooked it before and it define the sort of robust HMAC-based auth we have been using for our APIs in various forms, but has the advantage of being a standard that if implemented would make our future implementations much more standardized. 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. 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=C2=A0 some discussion that suggests I'm mistaken? 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. -Peter -- 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" From peter.wolanin@acquia.com Sun Feb 27 07:54:14 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553803A6A10 for ; Sun, 27 Feb 2011 07:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDSNljpC0Hlr for ; Sun, 27 Feb 2011 07:54:13 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with SMTP id 9419F3A6A0F for ; Sun, 27 Feb 2011 07:54:12 -0800 (PST) Received: from source ([209.85.216.44]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTWpz3ecgBXjFAFX6PXYgVmsc+ck8mTYB@postini.com; Sun, 27 Feb 2011 07:55:11 PST Received: by qwh6 with SMTP id 6so2558567qwh.31 for ; Sun, 27 Feb 2011 07:55:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.196.66 with SMTP id ef2mr1971425qab.134.1298822108101; Sun, 27 Feb 2011 07:55:08 -0800 (PST) Received: by 10.224.136.74 with HTTP; Sun, 27 Feb 2011 07:55:08 -0800 (PST) In-Reply-To: References: Date: Sun, 27 Feb 2011 10:55:08 -0500 Message-ID: From: Peter Wolanin To: eran@hueniverse.com 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.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 15:54:14 -0000 To clarify a bit in terms of of the flexibility I mention being gained by keeping a body hash filed in the headers and for constructing the signature - I'm imagining myself implementing 2 layers of servers for handling the upload and processing of large files. The public facing server (e.g. a load balancer and auth server where SSL terminates) could hold all the secrets and verify the signature based on just the headers including the body hash. Then, a back-end sever could take the request body and verify the body hash (returning a 403 if it doesn't match) without needing to have access to the client secrets. I agree with your comments at http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-w= eb/ that the core spec should be based on HMAC signatures. I was previously very disappointed when looking at the main Oauth2 spec and seeing only the bearer token approach or the approach of sending the secret in the request. Seems like barely an improvement over http basic auth. Perhaps a bearer token is suitable for use cases of just reading public or semi-public data, but even then I'm astounded that the operation of getting a refreshed token would not use an HMAC based signature instead of sending the secret. Best, -Peter Wolanin On Sun, Feb 27, 2011 at 9:59 AM, Peter Wolanin w= rote: > Dear Mr. Hammer-Lahav > > regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > > I was quite happy to find this, since I had overlooked it before and > it define the sort of robust HMAC-based auth we have been using for > our APIs in various forms, but has the advantage of being a standard > that if implemented would make our future implementations much more > standardized. > > 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 clearly 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 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. > > 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 so= me > discussion that suggests I'm mistaken? > > 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. =C2=A0Obviously 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. > > -Peter > > -- > 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" > --=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 James.H.Manger@team.telstra.com Sun Feb 27 14:40:01 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D553A68BD for ; Sun, 27 Feb 2011 14:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUTTnVZJzUUh for ; Sun, 27 Feb 2011 14:39:55 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 215883A6835 for ; Sun, 27 Feb 2011 14:39:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,235,1296997200"; d="scan'208,217";a="27985235" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Feb 2011 09:40:51 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6270"; a="20119172" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 28 Feb 2011 09:40:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 28 Feb 2011 09:40:50 +1100 From: "Manger, James H" To: Torsten Lodderstedt , OAuth Mailing List Date: Mon, 28 Feb 2011 09:40:49 +1100 Thread-Topic: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvVsIFieUlfK0igRZG6JSYaLFLD1QBHUs8w Message-ID: <255B9BB34FB7D647A506DC292726F6E1127ECCCBD4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <4D68F197.7040707@lodderstedt.net> In-Reply-To: <4D68F197.7040707@lodderstedt.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127ECCCBD4WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 22:40:01 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127ECCCBD4WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Torsten Lodderstedt said: "I would expect the token to carry information ab= out its issuer. Would this be sufficient in order to detect CSRF?" No. A Login CSRF attack involves a legitimate token (listing the legitimate iss= uer) that an attacker received being given to a victim client. The client g= ets a legitimate token - but they got it from the wrong party so they canno= t be sure it was a token meant for them. If the client tells the resource server where they got the token from then = the resource server can confirm that there wasn't an attacker between the l= egitimate authorization server and client. -- James Manger Am 25.02.2011 01:08, schrieb Manger, James H: Q. Should an OAuth client app list the authorization server in the Origin h= eader of requests to resource servers? In OAuth (delegation) flows a server dynamically issues credentials (such a= s a bearer token) to a client app to use in subsequent HTTP requests to oth= er servers. To combat login cross-site request forgery (CSRF) attacks [1] (= where an attacker's server issues the attacker's credentials to a client ap= p to use on behalf of a victim at a legitimate server) the client app needs= to indicate where the credentials came from. The Origin header [2] looks l= ike the right place to indicate this. [For the OAuth list: The Origin HTTP request header "indicates the origin(s= ) that caused the user agent to issue the request" [http://tools.ietf.org/h= tml/draft-ietf-websec-origin-00#section-6.2].] [For the WebSec list: An OAuth credential from an authorization server is a= bit like a cookie, but not restricted to the same origin.] Example: Client to (malicious) authorization server: -> POST /token HTTP/1.1 Host: login.example.com ... <- HTTP/1.1 200 OK ... { "access_token": "SlAV32hkKG", ...} Client to resource server: -> POST /uploadData HTTP/1.1 Host: api.exampledata.com Authorization: BEARER SlAV32hkKG Origin: https://login.example.com ... There can be other servers that contribute to a client app making a request= . For instance, one server can redirect to another. A Origin request header= can list multiple origins. The server will not be able to distinguish whic= h origin issued OAuth credentials from which issued a redirect etc. That mi= ght not matter if a server has to trust all the values listed in the Origin= header. Q. Is it the group's expectation that servers checking the Origin header wi= ll require all the listed origins to be trusted? [1] Robust Defenses for Cross Site Request Forgery, http://www.adambarth.co= m/papers/2008/barth-jackson-mitchell-b.pdf [2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-or= igin [3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-= abarth-principles-of-origin -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127ECCCBD4WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Torsten Lodderstedt said: “I would expect the token= to carry information about its issuer. Would this be sufficient in order t= o detect CSRF?”

No.

A Login CSRF attack in= volves a legitimate token (listing the legitimate issuer) that an attacker = received being given to a victim client. The client gets a legitimate token= – but they got it from the wrong party so they cannot be sure it was a token meant for them.

If the client tells th= e resource server where they got the token from then the resource server ca= n confirm that there wasn’t an attacker between the legitimate author= ization server and client.

 

--

James Manger

 

 

 

Am 25.02.2011 01:08, schrieb Manger, James H:

Q. Should an OAuth client app list the authorization= server in the Origin header of requests to resource servers?

 

In OAuth (delegation) flows a server dynamically iss= ues credentials (such as a bearer token) to a client app to use in subseque= nt HTTP requests to other servers. To combat login cross-site request forge= ry (CSRF) attacks [1] (where an attacker’s server issues the attacker’s credentials to a client app to use on b= ehalf of a victim at a legitimate server) the client app needs to indicate = where the credentials came from. The Origin header [2] looks like the right= place to indicate this.

 

[For the OAuth list: The Origin HTTP request header = “indicates the origin(s) that caused the user agent to issue the requ= est” [http://tools.ietf.org/html/draft-ietf-websec-origin-00#sect= ion-6.2].]

 

[For the WebSec list: An OAuth credential from an au= thorization server is a bit like a cookie, but not restricted to the same o= rigin.]

 

 

Example:

 

  Client to (malicious) authorization server: -= >

    POST /token HTTP/1.1

    Host: login.example.com

    …

  <-

    HTTP/1.1 200 OK

    …

    { "access_token": "= ;SlAV32hkKG", …}

 

  Client to resource server: ->

    POST /uploadData HTTP/1.1

    Host: api.exampledata.com

    Authorization: BEARER SlAV32hkKG<= o:p>

    Origin: https://login.example.com

    …

 

 

There can be other servers that contribute to a clie= nt app making a request. For instance, one server can redirect to another. = A Origin request header can list multiple origins. The server will not be a= ble to distinguish which origin issued OAuth credentials from which issued a redirect etc. That might not matter = if a server has to trust all the values listed in the Origin header.

Q. Is it the group’s expectation that servers = checking the Origin header will require all the listed origins to be truste= d?

 

[1] Robust Defenses for Cross Site Request Forgery, = http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf<= /o:p>

[2] The Web Origin Concept, http://tools.ietf.org/html/draft-ietf-websec-origin

[3] Principles of the Same Origin Policy, http://tools.ietf.org/html/draft-abarth-principles-of-origin=

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E1127ECCCBD4WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sun Feb 27 19:26:30 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12DD3A6998 for ; Sun, 27 Feb 2011 19:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op1HuVM3IvEu for ; Sun, 27 Feb 2011 19:26:29 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 7C8A93A694A for ; Sun, 27 Feb 2011 19:26:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,237,1296997200"; d="scan'208,217";a="26134872" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 28 Feb 2011 14:27:26 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6270"; a="20654793" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 28 Feb 2011 14:27:26 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 28 Feb 2011 14:27:25 +1100 From: "Manger, James H" To: "fcorella@pomcor.com" , OAuth Mailing List Date: Mon, 28 Feb 2011 14:27:25 +1100 Thread-Topic: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvVRZy6W6JRVC5DR6KxS2nohGdi4wBqHlBg Message-ID: <255B9BB34FB7D647A506DC292726F6E1127ECCD50E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> <593793.24331.qm@web55801.mail.re3.yahoo.com> In-Reply-To: <593793.24331.qm@web55801.mail.re3.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127ECCD50EWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 03:26:30 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127ECCD50EWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRnJhbmNpc2NvLA0KDQoNCg0KPj4gUS4gU2hvdWxkIGFuIE9BdXRoIGNsaWVudCBhcHAgbGlz dCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCg0KPj4gaW4gdGhlIE9yaWdpbiBoZWFkZXIgb2Yg cmVxdWVzdHMgdG8gcmVzb3VyY2Ugc2VydmVycz8NCg0KPj4NCg0KPj4gSW4gT0F1dGggKGRlbGVn YXRpb24pIGZsb3dzIGEgc2VydmVyIGR5bmFtaWNhbGx5IGlzc3Vlcw0KDQo+PiBjcmVkZW50aWFs cyAoc3VjaCBhcyBhIGJlYXJlciB0b2tlbikgdG8gYSBjbGllbnQgYXBwIHRvIHVzZQ0KDQo+PiBp biBzdWJzZXF1ZW50IEhUVFAgcmVxdWVzdHMgdG8gb3RoZXIgc2VydmVycy4gVG8gY29tYmF0DQoN Cj4+IGxvZ2luIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBhdHRhY2tzIFsxXSAo d2hlcmUNCg0KPj4gYW4gYXR0YWNrZXLigJlzIHNlcnZlciBpc3N1ZXMgdGhlIGF0dGFja2Vy4oCZ cyBjcmVkZW50aWFscyB0byBhDQoNCj4+IGNsaWVudCBhcHAgLi4uDQoNCg0KDQo+IEJ1dCBob3cg d2lsbCB0aGUgY2xpZW50IGFwcCBnZXQgdGhlICJjcmVkZW50aWFscyIgKGJlYXJlciB0b2tlbikN Cg0KPiBmcm9tIHRoZSB3cm9uZyBhdXRob3JpemF0aW9uIHNlcnZlcj8NCg0KDQoNCg0KDQpBIGNs aWVudCBhcHAgaGFyZHdpcmVkIHRvIHVzZSBhIHNwZWNpZmljIHNpbmdsZSBzZXJ2aWNlIGNhbm5v dCBnZXQgYSB0b2tlbiBmcm9tIHRoZSB3cm9uZyBzZXJ2ZXIuIElmIHRoZSBjbGllbnQgYXBwIGFk ZGl0aW9uYWxseSBuZXZlciBmb2xsb3dzIHJlZGlyZWN0cyBvciBhbnkgb3RoZXIgaW5zdHJ1Y3Rp b25zIGZyb20gdGhlIHNlcnZlciB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0byBhbm90aGVyIHNl cnZpY2UuIFN1Y2ggYW4gYXBwIGlzIHNhZmUgZnJvbSBsb2dpbiBDU1JGIGF0dGFja3MsIGJ1dCBo YXJkbHkgbmVlZHMgYSBpbnRlcm9wZXJhYmxlIHdlYiBzcGVjLg0KDQoNCg0KQSBjbGllbnQgYXBw IHRoYXQgZ29lcyB0byB3aGljaGV2ZXIgc2VydmljZSBhIHVzZXIgcG9pbnRzIGl0IGF0IGNvdWxk IGdldCBhIHRva2VuIGZyb20gYW55IGF1dGhvcml6YXRpb24gc2VydmVyLiBGb3IgaW5zdGFuY2Us IGEgcGhvdG8gZnJhbWluZyBhcHAgdGhhdCBhc2tzIGZvciB0aGUgVVJMIG9mIHlvdXIgb25saW5l IHBob3RvIHN0b3JlLg0KDQoNCg0KQSBjbGllbnQgdGhhdCBmb2xsb3dzIEhUVFAgcmVkaXJlY3Rz IChvciBMaW5rOiBoZWFkZXIgb3IgYW55IG90aGVyIHZhcmlldHkgb2YgaHlwZXJ0ZXh0KSBtaWdo dCBnZXQgZGlyZWN0ZWQgdG8gYW4gMm5kIHNlcnZpY2Ugd2hpbGUgc3RpbGwgdXNpbmcgdGhlIHRv a2VuIGZyb20gdGhlIDFzdCBzZXJ2aWNlLg0KDQoNCg0KSSBkb27igJl0IHNlZSBhbnkgd2F5IGZv ciBhIGNsaWVudCB0byBrbm93IHRoZSBib3VuZGFyaWVzIG9mIGFuIE9BdXRoMiBzZXJ2aWNlIOKA kyBvdGhlciB0aGFuIHByZWNvbmZpZ3VyZWQgc2VydmljZS1zcGVjaWZpYyBrbm93bGVkZ2UuIE9B dXRoMiBkcmFmdCAxMCBzYWlkIGNsaWVudHMg4oCcTVVTVCBOT1QgbWFrZSBhdXRoZW50aWNhdGVk IHJlcXVlc3RzIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIHVuZmFtaWxpYXIgcmVzb3VyY2Ugc2Vy dmVyc+KAnS4gQ2xpZW50cyB3ZXJlIGFzc3VtZWQgdG8gYmUg4oCcZmFtaWxpYXLigJ0gd2l0aCBl dmVyeSBzZXJ2ZXIgdGhleSBjb250YWN0ZWQg4oCTIHRoZSBhbnRpdGhlc2lzIG9mIHdlYiBhcmNo aXRlY3R1cmUuIExhdGVyIGRyYWZ0cyBkb27igJl0IGV2ZW4gaGF2ZSB0aGF0IGxhbmd1YWdlIChp dCBwcm9iYWJseSBnb3QgbG9zdCBpbiB0aGUgZG9jIHNwbGl0KS4gSSBoYXZlIHByZXZpb3VzbHkg YXJndWVkIGZvciBhIOKAmHNpdGVz4oCZIGZpZWxkIGluIGEgdG9rZW4gcmVzcG9uc2UgdG8gaW5k aWNhdGUgd2hlcmUgdGhlIHRva2VuIGNhbiBiZSB1c2VkLiBBIGNsaWVudCB3b3VsZCBzdGlsbCBu ZWVkIHRvIHVzZSB0aGUg4oCcT3JpZ2lu4oCdIGhlYWRlciBhcyBwcm90ZWN0aW9uIGFnYWluc3Qg YSBtYWxpY2lvdXMg4oCYc2l0ZXPigJkgdmFsdWUuIFsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDI1ODcuaHRtbCBTcGVjIHRleHQgZm9yIOKA nHNpdGVz4oCdIGZpZWxkXQ0KDQoNCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0K --_000_255B9BB34FB7D647A506DC292726F6E1127ECCD50EWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxl IERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhpIEZyYW5jaXNjbyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBRLiBTaG91bGQgYW4gT0F1dGggY2xpZW50IGFwcCBsaXN0 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PiZndDsmZ3Q7IGluIHRoZSBPcmlnaW4gaGVhZGVyIG9mIHJlcXVlc3RzIHRvIHJlc291cmNlIHNl cnZlcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmd0OyZndDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IEluIE9BdXRoIChkZWxlZ2F0aW9uKSBm bG93cyBhIHNlcnZlciBkeW5hbWljYWxseSBpc3N1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj4mZ3Q7Jmd0OyBjcmVkZW50aWFscyAoc3VjaCBhcyBhIGJlYXJlciB0b2tlbikgdG8g YSBjbGllbnQgYXBwIHRvIHVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDsm Z3Q7IGluIHN1YnNlcXVlbnQgSFRUUCByZXF1ZXN0cyB0byBvdGhlciBzZXJ2ZXJzLiBUbyBjb21i YXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBsb2dpbiBjcm9zcy1z aXRlIHJlcXVlc3QgZm9yZ2VyeSAoQ1NSRikgYXR0YWNrcyBbMV0gKHdoZXJlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgYW4gYXR0YWNrZXLigJlzIHNlcnZlciBpc3N1 ZXMgdGhlIGF0dGFja2Vy4oCZcyBjcmVkZW50aWFscyB0byBhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+Jmd0OyZndDsgY2xpZW50IGFwcCAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mZ3Q7IEJ1 dCBob3cgd2lsbCB0aGUgY2xpZW50IGFwcCBnZXQgdGhlICZxdW90O2NyZWRlbnRpYWxzJnF1b3Q7 IChiZWFyZXIgdG9rZW4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmd0OyBmcm9t IHRoZSB3cm9uZyBhdXRob3JpemF0aW9uIHNlcnZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5BIGNsaWVudCBhcHAgaGFyZHdpcmVkIHRvIHVz ZSBhIHNwZWNpZmljIHNpbmdsZSBzZXJ2aWNlIGNhbm5vdCBnZXQgYSB0b2tlbiBmcm9tIHRoZSB3 cm9uZyBzZXJ2ZXIuIElmIHRoZSBjbGllbnQgYXBwIGFkZGl0aW9uYWxseSBuZXZlciBmb2xsb3dz IHJlZGlyZWN0cyBvcg0KIGFueSBvdGhlciBpbnN0cnVjdGlvbnMgZnJvbSB0aGUgc2VydmVyIHdp bGwgbm90IHNlbmQgdGhlIHRva2VuIHRvIGFub3RoZXIgc2VydmljZS4gU3VjaCBhbiBhcHAgaXMg c2FmZSBmcm9tIGxvZ2luIENTUkYgYXR0YWNrcywgYnV0IGhhcmRseSBuZWVkcyBhIGludGVyb3Bl cmFibGUgd2ViIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QSBjbGllbnQgYXBwIHRoYXQgZ29lcyB0byB3 aGljaGV2ZXIgc2VydmljZSBhIHVzZXIgcG9pbnRzIGl0IGF0IGNvdWxkIGdldCBhIHRva2VuIGZy b20gYW55IGF1dGhvcml6YXRpb24gc2VydmVyLiBGb3IgaW5zdGFuY2UsIGEgcGhvdG8gZnJhbWlu ZyBhcHAgdGhhdCBhc2tzDQogZm9yIHRoZSBVUkwgb2YgeW91ciBvbmxpbmUgcGhvdG8gc3RvcmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+QSBjbGllbnQgdGhhdCBmb2xsb3dzIEhUVFAgcmVkaXJlY3RzIChvciBM aW5rOiBoZWFkZXIgb3IgYW55IG90aGVyIHZhcmlldHkgb2YgaHlwZXJ0ZXh0KSBtaWdodCBnZXQg ZGlyZWN0ZWQgdG8gYW4gMjxzdXA+bmQ8L3N1cD4gc2VydmljZSB3aGlsZSBzdGlsbCB1c2luZw0K IHRoZSB0b2tlbiBmcm9tIHRoZSAxPHN1cD5zdDwvc3VwPiBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkkgZG9u4oCZdCBzZWUgYW55IHdheSBmb3IgYSBjbGllbnQgdG8ga25vdyB0aGUgYm91bmRhcmll cyBvZiBhbiBPQXV0aDIgc2VydmljZSDigJMgb3RoZXIgdGhhbiBwcmVjb25maWd1cmVkIHNlcnZp Y2Utc3BlY2lmaWMga25vd2xlZGdlLiBPQXV0aDIgZHJhZnQgMTAgc2FpZCBjbGllbnRzDQog4oCc TVVTVCBOT1QgbWFrZSBhdXRoZW50aWNhdGVkIHJlcXVlc3RzIHdpdGggYW4gYWNjZXNzIHRva2Vu IHRvIHVuZmFtaWxpYXIgcmVzb3VyY2Ugc2VydmVyc+KAnS4gQ2xpZW50cyB3ZXJlIGFzc3VtZWQg dG8gYmUg4oCcZmFtaWxpYXLigJ0gd2l0aCBldmVyeSBzZXJ2ZXIgdGhleSBjb250YWN0ZWQg4oCT IHRoZSBhbnRpdGhlc2lzIG9mIHdlYiBhcmNoaXRlY3R1cmUuIExhdGVyIGRyYWZ0cyBkb27igJl0 IGV2ZW4gaGF2ZSB0aGF0IGxhbmd1YWdlIChpdCBwcm9iYWJseQ0KIGdvdCBsb3N0IGluIHRoZSBk b2Mgc3BsaXQpLiBJIGhhdmUgcHJldmlvdXNseSBhcmd1ZWQgZm9yIGEg4oCYc2l0ZXPigJkgZmll bGQgaW4gYSB0b2tlbiByZXNwb25zZSB0byBpbmRpY2F0ZSB3aGVyZSB0aGUgdG9rZW4gY2FuIGJl IHVzZWQuIEEgY2xpZW50IHdvdWxkIHN0aWxsIG5lZWQgdG8gdXNlIHRoZSDigJxPcmlnaW7igJ0g aGVhZGVyIGFzIHByb3RlY3Rpb24gYWdhaW5zdCBhIG1hbGljaW91cyDigJhzaXRlc+KAmSB2YWx1 ZS4gWw0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMDI1ODcuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMDI1ODcuaHRtbDwvYT4gU3BlYyB0ZXh0IGZvciDigJxzaXRl c+KAnSBmaWVsZF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E1127ECCD50EWSMSG3153Vsrv_-- From fcorella@pomcor.com Mon Feb 28 10:21:37 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282E63A6C1B for ; Mon, 28 Feb 2011 10:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0G01NjAlVmU for ; Mon, 28 Feb 2011 10:21:34 -0800 (PST) Received: from nm11-vm0.bullet.mail.ac4.yahoo.com (nm11-vm0.bullet.mail.ac4.yahoo.com [98.139.53.196]) by core3.amsl.com (Postfix) with SMTP id BF7D53A6AA4 for ; Mon, 28 Feb 2011 10:21:34 -0800 (PST) Received: from [98.139.52.196] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 28 Feb 2011 18:22:32 -0000 Received: from [98.139.52.179] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 28 Feb 2011 18:22:32 -0000 Received: from [127.0.0.1] by omp1062.mail.ac4.yahoo.com with NNFMP; 28 Feb 2011 18:22:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 938914.91692.bm@omp1062.mail.ac4.yahoo.com Received: (qmail 21562 invoked by uid 60001); 28 Feb 2011 18:22:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298917352; bh=gnMjXcSwcpQ3Xz10AJnlhPD4pxJ5Kzg3CZZZYHy/4Go=; 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=v1Hn9SSo86Ckt5hQLs+bvnrEK9bcd9BaLsLvtXdBk7tCRmGF2WDgUOOHuw/5QC7y31FpLQ8fYwhGTLNsGK2BpsvbleyKI7WhuTfxZzfGcmrEt+wX7P0lm1KvQPW3ZA9nR5pCGxYeDF4JPBYZl3xT3ilickHYzP0rrTyOFc/yYXM= Message-ID: <807184.4713.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: nNrOa5cVM1n6q4j5Fj3tZFt8GC3I3C47W9cKDdMRn7lzHrd 6C7uMFL9P5nPYu6O3impATBjYKpCcTV0oEUmnjmAnuKaAlDSk3J0coAkaEKy qt7qCTWtLa4ot5Wr1bh1SP3U8DIbAO8JlL2f.CZrukJnffu3.Axtdi3S_GVZ OsUv_nzYI_2W0wbU7DS0vhQPeqRgUNlQ.wlU4O5FTjl0rpmbQLwDB.SB11B8 EokXQDGn47y_lEVjY3GG8JvwCyaph1jHHqwArEcYKe0yPGOLrBIYEsdQfQC6 .bz.wTxLyif7WHsnDcxaQYkj1QzE7pFu6ONjw6qsX31RYErVuU1Mz5oGnVC1 wfc.kQS86iNp4TwMn_l5CqLrhSwRATQCLK5pXRAGNsPKcSV0A1mUvYF_EoTt bhuo- Received: from [67.91.91.101] by web55806.mail.re3.yahoo.com via HTTP; Mon, 28 Feb 2011 10:22:32 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 28 Feb 2011 10:22:32 -0800 (PST) From: Francisco Corella To: OAuth Mailing List , James HManger In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127ECCD50E@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1856858788-1298917352=:4713" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 28 Feb 2011 18:21:37 -0000 --0-1856858788-1298917352=:4713 Content-Type: text/plain; charset=us-ascii Hi James, > A client that follows HTTP redirects (or Link: header or any > other variety of hypertext) might get directed to an 2nd > service while still using the token from the 1st service. But why would a legitimate authorization server redirect the client to an attacker's server? Francisco --0-1856858788-1298917352=:4713 Content-Type: text/html; charset=us-ascii
Hi James,

> A client that follows HTTP redirects (or Link: header or any
> other variety of hypertext) might get directed to an 2nd
> service while still using the token from the 1st service.

But why would a legitimate authorization server redirect the
client to an attacker's server?

Francisco

--0-1856858788-1298917352=:4713-- From mscurtescu@google.com Mon Feb 28 10:34:56 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F463A6C43 for ; Mon, 28 Feb 2011 10:34:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-XFuRyLNsk1 for ; Mon, 28 Feb 2011 10:34:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E11183A6C1D for ; Mon, 28 Feb 2011 10:34:55 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p1SIZtF7027040 for ; Mon, 28 Feb 2011 10:35:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298918156; bh=Qa/wwBAB7/6oS3vJ/vJC63FUoB8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Q9FXkcK28mjmdzpR34rfsAYgXHzwLG99CDV7B6hqW1mEw2mtRB+ZSdliFrie+tSL2 ZUFoyzMCXcC2fwgXkmUrA== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by hpaq11.eem.corp.google.com with ESMTP id p1SIZGnk027100 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Feb 2011 10:35:54 -0800 Received: by gxk3 with SMTP id 3so1531094gxk.12 for ; Mon, 28 Feb 2011 10:35:54 -0800 (PST) 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=pULncJKp8PqCjPk/1KgC4zJUgH7s9HumGVjAv+8gOyQ=; b=BDVlu+zZMi782CC/FpCs/hw8otYiUKF8C/MLH4WYqA+zvcF4Cw+gYfPrSzsUXsgW7G b1XRH43DaEuaktgLr+7w== 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=X91uiz+vpSixgZ2bodVcs0JMjGyTINpak4WmTMKXjD3jKtIh8+BUl4NpuSzJcSSzAB wltgtGqQKlthz71TeRNw== Received: by 10.100.178.5 with SMTP id a5mr2376815anf.184.1298918152095; Mon, 28 Feb 2011 10:35:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.38.13 with HTTP; Mon, 28 Feb 2011 10:35:32 -0800 (PST) In-Reply-To: <4D68FD1A.9020205@lodderstedt.net> References: <4D68FD1A.9020205@lodderstedt.net> From: Marius Scurtescu Date: Mon, 28 Feb 2011 10:35:32 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Revocation (was: Re-Chartering: What Items to work on?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 18:34:57 -0000 On Sat, Feb 26, 2011 at 5:16 AM, Torsten Lodderstedt wrote: > thank you for your feedback. > > Am 03.02.2011 02:01, schrieb Marius Scurtescu: >> >> Following up on the Token Revocation extension proposed at: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> I am suggesting three changes to this extension: >> >> 1. Either drop client authentication or make it optional. If clients >> want to revoke tokens, more power to them. If it is a malicious >> client, why would the authorization server deny revoking tokens? > > The impact of an unauthorized revocation is merely inconvenience since the > client has the go through the authorization process again. Nevertheless, I > would like to add some protection here. If this inconvenience is done on purpose then the token is in the wrong hands. In which case you really want this token revoked, why would you make that more difficult? If the inconvenience is some error, then it will happen with or without credentials. I think client authentication should be optional at best. > My suggestion: the authorization server should require authentication for > clients having such credentials. > >> 2. Can we drop the "token_type" parameter, as suggested before? > > yes, we can. I will modify this in the next revision of the I-D. Great, thanks. >> 3. "authorization server MUST also invalidate all access tokens issued >> for that refresh token." can we change this MUST to a SHOULD? > > Why? The server is only required to revoke the access tokens if it is > capable to do so. Because it could be expensive, or impossible, for the authorization server to track down all access tokens associated with a refresh token. >> In case of success, why is the server supposed to return 204 instead >> of 200? Just worried that this will confuse clients. > > because there is no response body (required). I'm open to change it to 200 > but what data shall be contained in the response? An empty response body with 200 is illegal? A couple more suggestions: 1. Allow GET requests as well. This helps JavaScript clients. 2. Allow JSONP requests, for JavaScript clients as well. Marius From igor.faynberg@alcatel-lucent.com Mon Feb 28 12:15:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248BF3A6C5B; Mon, 28 Feb 2011 12:15:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tASW9pkS+WVy; Mon, 28 Feb 2011 12:15:17 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 4394C3A67D9; Mon, 28 Feb 2011 12:15:17 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1SKGALS021683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 14:16:11 -0600 (CST) Received: from [135.244.20.152] (faynberg.lra.lucent.com [135.244.20.152]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p1SKG8B7006113; Mon, 28 Feb 2011 14:16:09 -0600 (CST) Message-ID: <4D6C0289.3030300@alcatel-lucent.com> Date: Mon, 28 Feb 2011 15:16:09 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> In-Reply-To: <4D68F471.3090204@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: oauth-bounces@ietf.org, OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 20:15:18 -0000 +1 Igor Torsten Lodderstedt wrote: > ... > > I'm in favour to add the refresh token parameter to the implicit grant > flow as it would make it more useable for native apps. > .... From Michael.Jones@microsoft.com Mon Feb 28 12:50:00 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986F43A6C79 for ; Mon, 28 Feb 2011 12:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOW1BGGBGa1i for ; Mon, 28 Feb 2011 12:49:58 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C18A03A6C58 for ; Mon, 28 Feb 2011 12:49:58 -0800 (PST) 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; Mon, 28 Feb 2011 12:51:00 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 12:50:59 -0800 From: Mike Jones To: Hannes Tschofenig , Blaine Cook Thread-Topic: OAuth bearer token draft ready for working group last call Thread-Index: AcvXiTP4gGWtRe3/QY6bpvAE0i97+Q== Date: Mon, 28 Feb 2011 20:50:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.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.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252777D5TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:50:00 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252777D5TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943252777D5TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As editor, having received no comments on the normat= ive content of draft-ietf-oauth-v2-bearer-03, and having made no breaking c= hanges since draft -01, other than one change voted upon by the working gro= up, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call.

 

I’ll note that this draft requires editorial u= pdates to the IANA Considerations section framework specification to regist= er its errors.  This should happen in draft -14 at the same time that = the security considerations are added.  At that point, hopefully we can go to working group last call on the framework spe= cification as well.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943252777D5TK5EX14MBXC207r_-- From eran@hueniverse.com Mon Feb 28 13:12:46 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FF73A6842 for ; Mon, 28 Feb 2011 13:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf98ijsPtEtL for ; Mon, 28 Feb 2011 13:12:42 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id ABB1C3A6828 for ; Mon, 28 Feb 2011 13:12:42 -0800 (PST) Received: (qmail 12456 invoked from network); 28 Feb 2011 21:13:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Feb 2011 21:13:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 28 Feb 2011 14:13:37 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , Blaine Cook Date: Mon, 28 Feb 2011 14:13:33 -0700 Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AcvXiTP4gGWtRe3/QY6bpvAE0i97+QAAoAPg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C39CDP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:12:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39CDP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39CDP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am opposed to all the new registration changes and requirem= ents which have any impact on draft-ietf-oauth-v2. This request seems a bit= odd given my feedback (which you have, again, ignored).<= /p>

 

EHL

 

 <= /o:p>

&nb= sp;

 

From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hann= es Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: = [OAUTH-WG] OAuth bearer token draft ready for working group last call<= /o:p>

 

As editor, having received no comments on the normative con= tent of draft-ietf-oauth-v2-bearer-03, and having made no breaking changes = since draft -01, other than one change voted upon by the working group, I b= elieve that draft-ietf-oauth-v2-bearer-03 is ready for working group last c= all.

 

I’ll note that this draft requires editorial updates to the IA= NA Considerations section framework specification to register its errors.&n= bsp; This should happen in draft -14 at the same time that the security con= siderations are added.  At that point, hopefully we can go to working = group last call on the framework specification as well.

 

   = ;            &n= bsp;            = ;            &n= bsp;            = ;           -- Mike<= /o:p>

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39CDP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Mon Feb 28 13:23:36 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E1E3A6C68 for ; Mon, 28 Feb 2011 13:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OeZIfFKfxds for ; Mon, 28 Feb 2011 13:23:32 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C0CDB3A6A25 for ; Mon, 28 Feb 2011 13:23:31 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Feb 2011 13:24:33 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 13:24:32 -0800 From: Mike Jones To: Eran Hammer-Lahav , Hannes Tschofenig , Blaine Cook Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AQHL14xivmrkF7m4/UenV2yInOLCE5QXbI8Q Date: Mon, 28 Feb 2011 21:24:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394325277998@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394325277998TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:23:36 -0000 --_000_4E1F6AAD24975D4BA5B168042967394325277998TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did not ignore your feedback. I replied to it, pointing out why I believ= e your position is incorrect. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_4E1F6AAD24975D4BA5B168042967394325277998TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did not ignore your = feedback.  I replied to it, pointing out why I believe your position i= s incorrect.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, February 28, 2011 1:14 PM
To: Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working g= roup last call

 

I am opposed to all th= e new registration changes and requirements which have any impact on draft-= ietf-oauth-v2. This request seems a bit odd given my feedback (which you ha= ve, again, ignored).

 

EHL<= /p>

 

 

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: [OAUTH-WG] OAuth bearer token draft ready for working group= last call

 

As editor, having received no comments on the normat= ive content of draft-ietf-oauth-v2-bearer-03, and having made no breaking c= hanges since draft -01, other than one change voted upon by the working gro= up, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call.

 

I’ll note that this draft requires editorial u= pdates to the IANA Considerations section framework specification to regist= er its errors.  This should happen in draft -14 at the same time that = the security considerations are added.  At that point, hopefully we can go to working group last call on the framework spe= cification as well.

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394325277998TK5EX14MBXC207r_-- From eran@hueniverse.com Mon Feb 28 13:26:31 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954ED3A6C6F for ; Mon, 28 Feb 2011 13:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHrXj6A-XK7K for ; Mon, 28 Feb 2011 13:26:25 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 75D763A6A25 for ; Mon, 28 Feb 2011 13:26:25 -0800 (PST) Received: (qmail 18691 invoked from network); 28 Feb 2011 21:27:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Feb 2011 21:27:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Feb 2011 14:27:17 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Mon, 28 Feb 2011 14:27:14 -0700 Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AQHL14xivmrkF7m4/UenV2yInOLCE5QXbI8QgAAAhFA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39DB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394325277998@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394325277998@TK5EX14MBXC207.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C39DBP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:26:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39DBP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My last note on this was: --- OAuth 2.0 defines two endpoint, each with a set of error codes. These codes= are not extensible and therefore do not require a registry. If you want to= allow error code extensibility, you need to make the case for that with re= quirements and use cases. I have not seen any. My API uses the 'position' parameter for protected resources. Am I expected= to register it? It has nothing to do with OAuth, but if I supported Bearer= token would be used alongside the 'oauth_token' parameter. The 'oauth_toke= n' parameter is an nasty hack to make it easy for developers to access prot= ected resources without using the Authorization header (based on browser li= mitations from 4 years ago). Defining a registry for this parameter is just= adding insult to injury. The bearer token draft can define whatever registries it want for those usi= ng *bearer* tokens. It has no say on anything else. Period. If you want to = make changed to other drafts, you need to make a case and build consensus. = By definition, your drafts cannot change any requirement in other drafts un= less you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new = proposals? --- Did I miss a reply? EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 28, 2011 1:25 PM To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I did not ignore your feedback. I replied to it, pointing out why I believ= e your position is incorrect. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39DBP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My last note on this was:

 

---

OAuth 2.0 defines two endpoint,= each with a set of error codes. These codes are not extensible and therefo= re do not require a registry. If you want to allow error code extensibility= , you need to make the case for that with requirements and use cases. I hav= e not seen any.

 

My API uses the ‘position’ parameter for pro= tected resources. Am I expected to register it? It has nothing to do with O= Auth, but if I supported Bearer token would be used alongside the ‘oa= uth_token’ parameter. The ‘oauth_token’ parameter is an n= asty hack to make it easy for developers to access protected resources with= out using the Authorization header (based on browser limitations from 4 yea= rs ago). Defining a registry for this parameter is just adding insult to in= jury.

 

The bearer token draft can define whatever registries it want for th= ose using *bearer* tokens. It has no say on anything else. Period. I= f you want to make changed to other drafts, you need to make a case and bui= ld consensus. By definition, your drafts cannot change any requirement in o= ther drafts unless you update them (this is an IETF process rule).

 =

Can you= provide use cases, requirements, and examples for each of your new proposa= ls?

---

 

Did I miss a reply?

EHL

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com] <= br>Sent: Monday, February 28, 2011 1:25 PM
To: Eran Hammer= -Lahav; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
S= ubject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group= last call

 = ;

I did not ign= ore your feedback.  I replied to it, pointing out why I believe your p= osition is incorrect.

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: = Monday, February 28, 2011 1:14 PM
To: Mike Jones; Hannes Tschofen= ig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-= WG] OAuth bearer token draft ready for working group last call

 

I am opposed to all the new registra= tion changes and requirements which have any impact on draft-ietf-oauth-v2.= This request seems a bit odd given my feedback (which you have, again, ign= ored).

 

EHL

 

 

 

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Mike Jones
Sent: Monday, February 28, 201= 1 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth= @ietf.org
Subject: [OAUTH-WG] OAuth bearer token draft ready for = working group last call

 

As editor, having received no = comments on the normative content of draft-ietf-oauth-v2-bearer-03, and hav= ing made no breaking changes since draft -01, other than one change voted u= pon by the working group, I believe that draft-ietf-oauth-v2-bearer-03 is r= eady for working group last call.

&= nbsp;

I’ll note that this draft require= s editorial updates to the IANA Considerations section framework specificat= ion to register its errors.  This should happen in draft -14 at the sa= me time that the security considerations are added.  At that point, ho= pefully we can go to working group last call on the framework specification= as well.

 

          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39DBP3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Mon Feb 28 13:33:13 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F653A6C2A for ; Mon, 28 Feb 2011 13:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjHer1vGteyM for ; Mon, 28 Feb 2011 13:33:07 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 198793A67D9 for ; Mon, 28 Feb 2011 13:33:06 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Feb 2011 13:34:08 -0800 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 13:34:08 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AQHL14xivmrkF7m4/UenV2yInOLCE5QXbI8QgAAAhFCAAADUoA== Date: Mon, 28 Feb 2011 21:34:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252779C5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394325277998@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39DB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39DB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252779C5TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:33:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252779C5TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I realize that we disagree. Unless you change your position, it seems that= the working group will need to decide whether registering error codes aids= interoperability. I believe that it does. (You also appeared to agree as well in draft 11, in which you included the = text "[[ Add mechanism for extending error codes ]".) -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:27 PM To: Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call My last note on this was: --- OAuth 2.0 defines two endpoint, each with a set of error codes. These codes= are not extensible and therefore do not require a registry. If you want to= allow error code extensibility, you need to make the case for that with re= quirements and use cases. I have not seen any. My API uses the 'position' parameter for protected resources. Am I expected= to register it? It has nothing to do with OAuth, but if I supported Bearer= token would be used alongside the 'oauth_token' parameter. The 'oauth_toke= n' parameter is an nasty hack to make it easy for developers to access prot= ected resources without using the Authorization header (based on browser li= mitations from 4 years ago). Defining a registry for this parameter is just= adding insult to injury. The bearer token draft can define whatever registries it want for those usi= ng *bearer* tokens. It has no say on anything else. Period. If you want to = make changed to other drafts, you need to make a case and build consensus. = By definition, your drafts cannot change any requirement in other drafts un= less you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new = proposals? --- Did I miss a reply? EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 28, 2011 1:25 PM To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I did not ignore your feedback. I replied to it, pointing out why I believ= e your position is incorrect. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943252779C5TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I realize that we disa= gree.  Unless you change your position, it seems that the working grou= p will need to decide whether registering error codes aids interoperability= .  I believe that it does.

 

(You also appeared to = agree as well in draft 11, in which you included the text “[[ Add mec= hanism for extending error codes ]”.)

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, February 28, 2011 1:27 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working g= roup last call

 

My last note on this w= as:

 

---<= /p>

OAuth 2.0 defines two = endpoint, each with a set of error codes. These codes are not extensible an= d therefore do not require a registry. If you want to allow error code exte= nsibility, you need to make the case for that with requirements and use cases. I have not seen any.<= /span>

 

My API uses the ‘= ;position’ parameter for protected resources. Am I expected to regist= er it? It has nothing to do with OAuth, but if I supported Bearer token wou= ld be used alongside the ‘oauth_token’ parameter. The ‘oauth_token’ parameter is an nasty hack to make it easy f= or developers to access protected resources without using the Authorization= header (based on browser limitations from 4 years ago). Defining a registr= y for this parameter is just adding insult to injury.

 

The bearer token draft= can define whatever registries it want for those using *bearer* tok= ens. It has no say on anything else. Period. If you want to make changed to= other drafts, you need to make a case and build consensus. By definition, your drafts cannot change any requirem= ent in other drafts unless you update them (this is an IETF process rule).<= o:p>

 

Can you provide use ca= ses, requirements, and examples for each of your new proposals?<= /span>

---<= /p>

 

Did I miss a reply?

 

EHL<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Monday, February 28, 2011 1:25 PM
To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working g= roup last call

 

I did not ignore your = feedback.  I replied to it, pointing out why I believe your position i= s incorrect.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, February 28, 2011 1:14 PM
To: Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working g= roup last call

 

I am opposed to all th= e new registration changes and requirements which have any impact on draft-= ietf-oauth-v2. This request seems a bit odd given my feedback (which you ha= ve, again, ignored).

 

EHL<= /p>

 

 

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: [OAUTH-WG] OAuth bearer token draft ready for working group= last call

 

As editor, having received no comments on the normat= ive content of draft-ietf-oauth-v2-bearer-03, and having made no breaking c= hanges since draft -01, other than one change voted upon by the working gro= up, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call.

 

I’ll note that this draft requires editorial u= pdates to the IANA Considerations section framework specification to regist= er its errors.  This should happen in draft -14 at the same time that = the security considerations are added.  At that point, hopefully we can go to working group last call on the framework spe= cification as well.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943252779C5TK5EX14MBXC207r_-- From eran@hueniverse.com Mon Feb 28 14:04:59 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5C73A6C89 for ; Mon, 28 Feb 2011 14:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNLttGz-D3+h for ; Mon, 28 Feb 2011 14:04:50 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 048503A6BEC for ; Mon, 28 Feb 2011 14:04:49 -0800 (PST) Received: (qmail 23754 invoked from network); 28 Feb 2011 22:05:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Feb 2011 22:05:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Feb 2011 15:05:45 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Mon, 28 Feb 2011 15:05:42 -0700 Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AQHL14xivmrkF7m4/UenV2yInOLCE5QXbI8QgAAAhFCAAADUoIAABhXQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39F9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B168042967394325277998@TK5EX14MBXC207.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E7234464F0C39DB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943252779C5@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252779C5@TK5EX14MBXC207.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_90C41DD21FB7C64BB94121FBBC2E7234464F0C39F9P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:04:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39F9P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text in -11 was from the initial extensibility draft and was removed wh= en I revisited the issue and could not come up with any requirements for ex= tending error codes. You made a claim that an error code registry aids inte= roperability but offered no use cases or requirements showing how this new = registry solves an actual problem. As most people who ever interacted with an IANA registry know, very few act= ually help interoperability. Most just frustrate developers for no good rea= son to the point where the registry is the least useful reference. If you n= otice the new extensibility language in -13, it makes the registry less str= ict in its requirements for vendor-specific parameters. IOW, it defines the= bare minimum needed to help avoid parameter name collision. But the error code registry is only one issue. Your proposal goes further a= nd defines two new locations for which you have provided no requirements an= d use cases to show how your solution solves a problem. We can add plenty of registries: an endpoint registry for future new endpoi= nts like a device endpoint, a client authentication registry, a grant type = registry for extension URI types, a registry for non-URI callback values, e= tc. The bottom line, a registry is meant to reduce the likelihood of namesp= ace collisions where such a collision will *actually* cause interoperabilit= y problems. If you want to add an error code registry, you MUST provide at least one ex= ample of an error code you plan to introduce that will require registration= or interoperability will fail. 'Aids interoperability' is not a justification if you don't actually show h= ow your solution accomplishes it (and what problem is this solution trying = to solve). EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 28, 2011 1:34 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I realize that we disagree. Unless you change your position, it seems that= the working group will need to decide whether registering error codes aids= interoperability. I believe that it does. (You also appeared to agree as well in draft 11, in which you included the = text "[[ Add mechanism for extending error codes ]".) -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:27 PM To: Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call My last note on this was: --- OAuth 2.0 defines two endpoint, each with a set of error codes. These codes= are not extensible and therefore do not require a registry. If you want to= allow error code extensibility, you need to make the case for that with re= quirements and use cases. I have not seen any. My API uses the 'position' parameter for protected resources. Am I expected= to register it? It has nothing to do with OAuth, but if I supported Bearer= token would be used alongside the 'oauth_token' parameter. The 'oauth_toke= n' parameter is an nasty hack to make it easy for developers to access prot= ected resources without using the Authorization header (based on browser li= mitations from 4 years ago). Defining a registry for this parameter is just= adding insult to injury. The bearer token draft can define whatever registries it want for those usi= ng *bearer* tokens. It has no say on anything else. Period. If you want to = make changed to other drafts, you need to make a case and build consensus. = By definition, your drafts cannot change any requirement in other drafts un= less you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new = proposals? --- Did I miss a reply? EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, February 28, 2011 1:25 PM To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I did not ignore your feedback. I replied to it, pointing out why I believ= e your position is incorrect. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerat= ions section framework specification to register its errors. This should h= appen in draft -14 at the same time that the security considerations are ad= ded. At that point, hopefully we can go to working group last call on the = framework specification as well. -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39F9P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The text in -11 was from the initial extensibility draft and = was removed when I revisited the issue and could not come up with any requi= rements for extending error codes. You made a claim that an error code regi= stry aids interoperability but offered no use cases or requirements showing= how this new registry solves an actual problem.

 

=

As most people who ever = interacted with an IANA registry know, very few actually help interoperabil= ity. Most just frustrate developers for no good reason to the point where t= he registry is the least useful reference. If you notice the new extensibil= ity language in -13, it makes the registry less strict in its requirements = for vendor-specific parameters. IOW, it defines the bare minimum needed to = help avoid parameter name collision.

 

But the error code registry is only o= ne issue. Your proposal goes further and defines two new locations for whic= h you have provided no requirements and use cases to show how your solution= solves a problem.

 

We can add plenty of registries: an endpoint registry f= or future new endpoints like a device endpoint, a client authentication reg= istry, a grant type registry for extension URI types, a registry for non-UR= I callback values, etc. The bottom line, a registry is meant to reduce the = likelihood of namespace collisions where such a collision will *actually= * cause interoperability problems.

 

If you want to add an error code re= gistry, you MUST provide at least one example of an error code you plan to = introduce that will require registration or interoperability will fail.

&= nbsp;

&#= 8216;Aids interoperability’ is not a justification if you don’t= actually show how your solution accomplishes it (and what problem is this = solution trying to solve).

 

EHL

<= span style=3D'color:#1F497D'> 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]=
Sent: Monday, February 28, 2011 1:34 PM
To: Eran Hamm= er-Lahav
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAu= th bearer token draft ready for working group last call

 

I realize that we disagree.  Unless yo= u change your position, it seems that the working group will need to decide= whether registering error codes aids interoperability.  I believe tha= t it does.

 

(You also appeared to agree as well in draft 11, in which you i= ncluded the text “[[ Add mechanism for extending error codes ]”= .)

=  

            = ;            &n= bsp;            = ;            &n= bsp;            = ;  -- Mike

 

From= : Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday= , February 28, 2011 1:27 PM
To: Mike Jones
Cc: oauth@ie= tf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for= working group last call

 

My last note on this was:

 

---

<= span style=3D'color:#1F497D'>OAuth 2.0 defines two endpoint, each with a se= t of error codes. These codes are not extensible and therefore do not requi= re a registry. If you want to allow error code extensibility, you need to m= ake the case for that with requirements and use cases. I have not seen any.=

 

My API uses the ‘position’ parameter for protected resources.= Am I expected to register it? It has nothing to do with OAuth, but if I su= pported Bearer token would be used alongside the ‘oauth_token’ = parameter. The ‘oauth_token’ parameter is an nasty hack to make= it easy for developers to access protected resources without using the Aut= horization header (based on browser limitations from 4 years ago). Defining= a registry for this parameter is just adding insult to injury.<= /span>

 

The bearer= token draft can define whatever registries it want for those using *bea= rer* tokens. It has no say on anything else. Period. If you want to mak= e changed to other drafts, you need to make a case and build consensus. By = definition, your drafts cannot change any requirement in other drafts unles= s you update them (this is an IETF process rule).

 

=

Can you provide use case= s, requirements, and examples for each of your new proposals?

---

 

Did I miss = a reply?

 

EHL

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent:<= /b> Monday, February 28, 2011 1:25 PM
To: Eran Hammer-Lahav; Hann= es Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: = RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call

 

<= p class=3DMsoNormal>I did not ignore your fee= dback.  I replied to it, pointing out why I believe your position is i= ncorrect.

 

From: E= ran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, Febr= uary 28, 2011 1:14 PM
To: Mike Jones; Hannes Tschofenig; Blaine C= ook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth be= arer token draft ready for working group last call

 

I am opposed to all the new registration changes= and requirements which have any impact on draft-ietf-oauth-v2. This reques= t seems a bit odd given my feedback (which you have, again, ignored).<= /o:p>

&nb= sp;

EHL<= o:p>

 

 

 

 

F= rom: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of Mike Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
= Subject: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call

 

As editor, having received no comments on the = normative content of draft-ietf-oauth-v2-bearer-03, and having made no brea= king changes since draft -01, other than one change voted upon by the worki= ng group, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working= group last call.

 

<= p class=3DMsoNormal>I’ll note that this draft requires editorial upda= tes to the IANA Considerations section framework specification to register = its errors.  This should happen in draft -14 at the same time that the= security considerations are added.  At that point, hopefully we can g= o to working group last call on the framework specification as well.

 

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C39F9P3PW5EX1MB01E_-- From jricher@mitre.org Mon Feb 28 14:29:50 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A173A6C97 for ; Mon, 28 Feb 2011 14:29:50 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsi-6IBIuGSb for ; Mon, 28 Feb 2011 14:29:49 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 1841C3A67E2 for ; Mon, 28 Feb 2011 14:29:48 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 266F321B0DAF; Mon, 28 Feb 2011 17:30:50 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1CCA921B01AB; Mon, 28 Feb 2011 17:30:50 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 28 Feb 2011 17:30:50 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , Mike Jones , Hannes Tschofenig , Blaine Cook Date: Mon, 28 Feb 2011 17:28:46 -0500 Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AcvXiTP4gGWtRe3/QY6bpvAE0i97+QAAoAPgAALKUx0= Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com>, <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:29:50 -0000 I personally think the error code registry is a good idea, and the resourse= parameter registry is a very very bad idea. I also didn't see anything app= roaching consensus on these changes in the wg, but heres my vote. - justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Monday, February 28, 2011 4:13 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group la= st call I am opposed to all the new registration changes and requirements which hav= e any impact on draft-ietf-oauth-v2. This request seems a bit odd given my = feedback (which you have, again, ignored). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last c= all As editor, having received no comments on the normative content of draft-ie= tf-oauth-v2-bearer-03, and having made no breaking changes since draft -01,= other than one change voted upon by the working group, I believe that draf= t-ietf-oauth-v2-bearer-03 is ready for working group last call. I=92ll note that this draft requires editorial updates to the IANA Consider= ations section framework specification to register its errors. This should= happen in draft -14 at the same time that the security considerations are = added. At that point, hopefully we can go to working group last call on th= e framework specification as well. -- Mike From mscurtescu@google.com Mon Feb 28 14:57:24 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85333A6C8E for ; Mon, 28 Feb 2011 14:57:24 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YESfSpk8thWc for ; Mon, 28 Feb 2011 14:57:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 626253A6CAF for ; Mon, 28 Feb 2011 14:57:24 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p1SMwPvq028072 for ; Mon, 28 Feb 2011 14:58:25 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298933905; bh=4r6Bo716SLwZkPSuMdAMlJTs1Hc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pmSqM+OCCa4VtrydCqg/9DuHdlx5BDbr1fkcbUMgbfQAOUG9j7O/e1IO8vM2QvK1a md2mcGn6QYsvtRU5U3iOg== Received: from yxn22 (yxn22.prod.google.com [10.190.4.86]) by hpaq7.eem.corp.google.com with ESMTP id p1SMvuWn028515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 28 Feb 2011 14:58:23 -0800 Received: by yxn22 with SMTP id 22so2066854yxn.34 for ; Mon, 28 Feb 2011 14:58:23 -0800 (PST) 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=4H4vF2ZMUDPkhqljQSh2YMzLD0jg1cSZaQTe5UYvIKo=; b=I3Ucq64f150qcVrVQWy+3BmNeE9vHsEuEvA971rB97OhAJhKvmDRI1zknoYp+3fQ9Y p8dEzOceg3YEzpaDoyAQ== 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=dKj8HbsNdEPSLlxw5OtMW7J8qGfj93er7O6ezpkiX79P7zy4CdwJwxoaKu1s/yLFq3 wrYqaAPa63ebDUKddd8A== Received: by 10.100.17.26 with SMTP id 26mr2568573anq.14.1298933903201; Mon, 28 Feb 2011 14:58:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.38.13 with HTTP; Mon, 28 Feb 2011 14:58:03 -0800 (PST) In-Reply-To: <4D6C0289.3030300@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> From: Marius Scurtescu Date: Mon, 28 Feb 2011 14:58:03 -0800 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:57:24 -0000 On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg wrote: > +1 > > Igor > > Torsten Lodderstedt wrote: >> >> ... >> >> I'm in favour to add the refresh token parameter to the implicit grant >> flow as it would make it more useable for native apps. I think it is much safer to go with refresh tokens only sent indirectly through an authorization code swap. Implicit grant with refresh token also has no client secret swap and makes things worse by passing the refresh token through the browser. Marius From phil.hunt@oracle.com Mon Feb 28 15:18:27 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBAB3A6A4C for ; Mon, 28 Feb 2011 15:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPEvMW1pY6d6 for ; Mon, 28 Feb 2011 15:18:26 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9A1663A6836 for ; Mon, 28 Feb 2011 15:18:26 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1SNJLRt003890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 23:19:24 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1SNJJUF004724; Mon, 28 Feb 2011 23:19:20 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 1094729781298935094; Mon, 28 Feb 2011 15:18:14 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Feb 2011 15:18:13 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 28 Feb 2011 15:18:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> ! To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4D6C2D79.006E:SCFMA4539814,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:18:27 -0000 Given these questions, I am wondering, why does the Implicit Grant flow = NOT have an authorization code step? Having one, would keep = architecture of AS and TS clearly separate. One down side is that issuing of access/refresh token would now have to = be opened to SHOULD authenticate the client from MUST. What was the original case for this flow? That should point us as to = why the separate flow and whether refresh makes sense given the higher = risks of the implicit flow. Phil phil.hunt@oracle.com On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote: > On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg > wrote: >> +1 >>=20 >> Igor >>=20 >> Torsten Lodderstedt wrote: >>>=20 >>> ... >>>=20 >>> I'm in favour to add the refresh token parameter to the implicit = grant >>> flow as it would make it more useable for native apps. >=20 > I think it is much safer to go with refresh tokens only sent > indirectly through an authorization code swap. >=20 > Implicit grant with refresh token also has no client secret swap and > makes things worse by passing the refresh token through the browser. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Mon Feb 28 15:26:52 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3833A6CCA for ; Mon, 28 Feb 2011 15:26:52 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY-WU5do30SW for ; Mon, 28 Feb 2011 15:26:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DF27D3A6CC9 for ; Mon, 28 Feb 2011 15:26:51 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1SNRnm3010461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 17:27:49 -0600 (CST) Received: from [135.244.20.152] (faynberg.lra.lucent.com [135.244.20.152]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p1SNRn0f029229; Mon, 28 Feb 2011 17:27:49 -0600 (CST) Message-ID: <4D6C2F74.30301@alcatel-lucent.com> Date: Mon, 28 Feb 2011 18:27:48 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Phil Hunt References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> ! In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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, 28 Feb 2011 23:26:52 -0000 Cannot help harping... It is exactly this type of a question that Phil asked that makes a document on the use cases necessary! Igor Phil Hunt wrote: > ... > > What was the original case for this flow? That should point us as to why the separate flow and whether refresh makes sense given the higher risks of the implicit flow. > > > From James.H.Manger@team.telstra.com Mon Feb 28 16:42:25 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C613A6D07 for ; Mon, 28 Feb 2011 16:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftQT02BxrPno for ; Mon, 28 Feb 2011 16:42:21 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id C37123A6D02 for ; Mon, 28 Feb 2011 16:42:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,244,1296997200"; d="scan'208,217";a="26517621" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 01 Mar 2011 11:43:20 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6271"; a="20264582" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccvi.tcif.telstra.com.au with ESMTP; 01 Mar 2011 11:43:20 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 1 Mar 2011 11:43:20 +1100 From: "Manger, James H" To: "fcorella@pomcor.com" , OAuth Mailing List Date: Tue, 1 Mar 2011 11:43:17 +1100 Thread-Topic: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvXdHpAohhIqq73QiChvRgm6lnM5QALUlGw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127F342542@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127ECCD50E@WSMSG3153V.srv.dir.telstra.com> <807184.4713.qm@web55806.mail.re3.yahoo.com> In-Reply-To: <807184.4713.qm@web55806.mail.re3.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127F342542WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:42:26 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127F342542WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Francisco, >> A client that follows HTTP redirects (or Link: header or any >> other variety of hypertext) might get directed to an 2nd >> service while still using the token from the 1st service. > But why would a legitimate authorization server redirect the > client to an attacker's server? It can happen the other way around. The 1st service acts maliciously, forwa= rding a token that was actually obtained from the 2nd service. The client t= hen uses that token to make requests to the 2nd service - because it thinks= it is part of the 1st service. The core issue is that a client gets a opaque token from one service and wi= ll use it to access other resources. The token is opaque to the client: 1. The client cannot check that the token was originally issued by th= is service (as opposed to this service forwarding a token from elsewhere); 2. The client cannot check that the token was meant for itself (as op= posed to being forwarded from another client); 3. The client isn't told by the token issuer where it should & should= n't be used (ie the boundary of the services); 4. The client isn't told by a resource server which sources of tokens= are legitimate. One way to avoid some of these issues is to hardwire clients to a specific = service - which is very limiting. Another way is to have a standard token format - which is limiting, and a b= ig burden on clients. A better way is to accept points 1 & 2; address 3 by listing resource sites= in token responses; and address 4 obliquely by listing the authorization s= erver in the "Origin" HTTP request header. Then it doesn't matter if a clie= nt unwittingly connects with an attacker's service (just as it shouldn't ma= tter to a legitimate web site if their web browser clients unwittingly visi= t malicious or compromised web sites). -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127F342542WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Francisco,

 

>> A client that follows HTTP redirects (or Li= nk: header or any
>> other variety of hypertext) might get directed to an 2nd
>> service while still using the token from the 1st service.

> But why would a legitimate authorization server redirect the
> client to an attacker's server?

 

It can happen the other way around. The 1st servi= ce acts maliciously, forwarding a token that was actually obtained from the= 2nd service. The client then uses that token to make requests to the 2nd ser= vice – because it thinks it is part of the 1st service.

 

The core issue is that a client gets a opaque token from one= service and will use it to access other resources. The token is opaque to = the client:

1.&nbs= p;      The client cannot check that the token was originally issued= by this service (as opposed to this service forwarding a token from elsewh= ere);

2.&nbs= p;      The client cannot check that the token was meant for itself = (as opposed to being forwarded from another client);

3.&nbs= p;      The client isn’t told by the token issuer where it sho= uld & shouldn’t be used (ie the boundary of the services);

4.&nbs= p;      The client isn’t told by a resource server which sourc= es of tokens are legitimate.

 

One way to avoid some of these issues is to hardwire clients= to a specific service – which is very limiting.

Another way is to have a standard token format – which= is limiting, and a big burden on clients.

A better way is to accept points 1 & 2; address 3 by lis= ting resource sites in token responses; and address 4 obliquely by listing = the authorization server in the “Origin” HTTP request header. Then it doesn’t mat= ter if a client unwittingly connects with an attacker’s service (just= as it shouldn’t matter to a legitimate web site if their web browser= clients unwittingly visit malicious or compromised web sites).<= /span>

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E1127F342542WSMSG3153Vsrv_-- From eran@hueniverse.com Mon Feb 28 17:23:23 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03B93A6D53 for ; Mon, 28 Feb 2011 17:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovikqGKa1uvd for ; Mon, 28 Feb 2011 17:23:22 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 895C93A6D51 for ; Mon, 28 Feb 2011 17:23:22 -0800 (PST) Received: (qmail 19093 invoked from network); 1 Mar 2011 01:24:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Mar 2011 01:24:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 28 Feb 2011 18:24:12 -0700 From: Eran Hammer-Lahav To: Phil Hunt , Marius Scurtescu Date: Mon, 28 Feb 2011 18:24:07 -0700 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: AcvXnfQ0BoerfLsxQ6GhgJz0rgd60wAEV7bw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3A56@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> ! In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:23:23 -0000 One more round trip is often too slow. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Monday, February 28, 2011 3:18 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >=20 > Given these questions, I am wondering, why does the Implicit Grant flow > NOT have an authorization code step? Having one, would keep architecture > of AS and TS clearly separate. >=20 > One down side is that issuing of access/refresh token would now have to b= e > opened to SHOULD authenticate the client from MUST. >=20 > What was the original case for this flow? That should point us as to why= the > separate flow and whether refresh makes sense given the higher risks of t= he > implicit flow. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote: >=20 > > On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg > > wrote: > >> +1 > >> > >> Igor > >> > >> Torsten Lodderstedt wrote: > >>> > >>> ... > >>> > >>> I'm in favour to add the refresh token parameter to the implicit > >>> grant flow as it would make it more useable for native apps. > > > > I think it is much safer to go with refresh tokens only sent > > indirectly through an authorization code swap. > > > > Implicit grant with refresh token also has no client secret swap and > > makes things worse by passing the refresh token through the browser. > > > > Marius > > _______________________________________________ > > 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 eran@hueniverse.com Mon Feb 28 17:24:04 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8B93A6D58 for ; Mon, 28 Feb 2011 17:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N5Lm+JFygHB for ; Mon, 28 Feb 2011 17:24:04 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E89093A6D57 for ; Mon, 28 Feb 2011 17:24:03 -0800 (PST) Received: (qmail 19804 invoked from network); 1 Mar 2011 01:25:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Mar 2011 01:25:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 28 Feb 2011 18:25:05 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." Date: Mon, 28 Feb 2011 18:25:02 -0700 Thread-Topic: [OAUTH-WG] OAuth bearer token draft ready for working group last call Thread-Index: AcvXiTP4gGWtRe3/QY6bpvAE0i97+QAAoAPgAALKUx0ABiJIQA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3A57@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943252777D5@TK5EX14MBXC207.redmond.corp.microsoft.com>, <90C41DD21FB7C64BB94121FBBC2E7234464F0C39CD@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@ietf.org" Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:24:05 -0000 Hey Justin, Can you provide some examples, use cases or requirements? EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Monday, February 28, 2011 2:29 PM > To: Eran Hammer-Lahav; Mike Jones; Hannes Tschofenig; Blaine Cook > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group > last call >=20 > I personally think the error code registry is a good idea, and the resour= se > parameter registry is a very very bad idea. I also didn't see anything > approaching consensus on these changes in the wg, but heres my vote. >=20 > - justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > Sent: Monday, February 28, 2011 4:13 PM > To: Mike Jones; Hannes Tschofenig; Blaine Cook > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group > last call >=20 > I am opposed to all the new registration changes and requirements which > have any impact on draft-ietf-oauth-v2. This request seems a bit odd give= n > my feedback (which you have, again, ignored). >=20 > EHL >=20 >=20 >=20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Monday, February 28, 2011 12:51 PM > To: Hannes Tschofenig; Blaine Cook > Cc: oauth@ietf.org > Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last > call >=20 > As editor, having received no comments on the normative content of draft- > ietf-oauth-v2-bearer-03, and having made no breaking changes since draft = - > 01, other than one change voted upon by the working group, I believe that > draft-ietf-oauth-v2-bearer-03 is ready for working group last call. >=20 > I'll note that this draft requires editorial updates to the IANA Consider= ations > section framework specification to register its errors. This should happ= en in > draft -14 at the same time that the security considerations are added. A= t that > point, hopefully we can go to working group last call on the framework > specification as well. >=20 > -- Mike From skylar@kiva.org Mon Feb 28 18:27:18 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265863A6C90 for ; Mon, 28 Feb 2011 18:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5wKiFUU0Z2v for ; Mon, 28 Feb 2011 18:27:12 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by core3.amsl.com (Postfix) with SMTP id CBC5A3A6C48 for ; Mon, 28 Feb 2011 18:27:11 -0800 (PST) Received: from source ([74.125.82.176]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKTWxZvF2O5+iAcM0LaP8/ldyVLQcKzV4l@postini.com; Mon, 28 Feb 2011 18:28:14 PST Received: by wya21 with SMTP id 21so4825287wya.21 for ; Mon, 28 Feb 2011 18:28:11 -0800 (PST) Received: by 10.227.72.147 with SMTP id m19mr5559566wbj.131.1298946489897; Mon, 28 Feb 2011 18:28:09 -0800 (PST) Received: from [192.168.0.10] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id o6sm3834718wbo.15.2011.02.28.18.28.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Feb 2011 18:28:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3A56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 1 Mar 2011 03:28:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B9EA296-F846-4C03-8291-C1D8A21EDB74@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> ! <90C41DD21FB7C64BB94121FBBC2E7234464F0C3A56@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:27:18 -0000 I had assumed a use case for this was an entirely browser-based client. = Such a client would be limited to same-host requests. Providing a proxy = to make token requests just opens the possibility of abuse of client = proxies with poor security practices - and for no added value. If a = client can't secure credentials, there's no point in a second round = trip. As such, simplify the model and, in the process, emphasize the = loss of of a layer of security in the flow. In principle, I favor reserving separate flows for credential vs. = credential-less apps. However, in practice, I see providers evangelizing = one flow when there are a mix of apps with credentials and those without = (eg, mix of device & hosted apps in the ecosystem) and thus no need to = restrict the code flow only to clients with secrets. One flow is enough = complication when there is provider-specific complexity to explain as = well. The implicit flow, then, seems appropriate for providers who never = issue secret client credentials. Better use cases anyone? On Mar 1, 2011, at 2:24 AM, Eran Hammer-Lahav wrote: > One more round trip is often too slow. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Phil Hunt >> Sent: Monday, February 28, 2011 3:18 PM >> To: Marius Scurtescu >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>=20 >> Given these questions, I am wondering, why does the Implicit Grant = flow >> NOT have an authorization code step? Having one, would keep = architecture >> of AS and TS clearly separate. >>=20 >> One down side is that issuing of access/refresh token would now have = to be >> opened to SHOULD authenticate the client from MUST. >>=20 >> What was the original case for this flow? That should point us as to = why the >> separate flow and whether refresh makes sense given the higher risks = of the >> implicit flow. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote: >>=20 >>> On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg >>> wrote: >>>> +1 >>>>=20 >>>> Igor >>>>=20 >>>> Torsten Lodderstedt wrote: >>>>>=20 >>>>> ... >>>>>=20 >>>>> I'm in favour to add the refresh token parameter to the implicit >>>>> grant flow as it would make it more useable for native apps. >>>=20 >>> I think it is much safer to go with refresh tokens only sent >>> indirectly through an authorization code swap. >>>=20 >>> Implicit grant with refresh token also has no client secret swap and >>> makes things worse by passing the refresh token through the browser. >>>=20 >>> Marius >>> _______________________________________________ >>> 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 fcorella@pomcor.com Mon Feb 28 21:15:51 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E2F3A6CC0 for ; Mon, 28 Feb 2011 21:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pXf1JQ6SGib for ; Mon, 28 Feb 2011 21:15:48 -0800 (PST) Received: from nm5.bullet.mail.ac4.yahoo.com (nm5.bullet.mail.ac4.yahoo.com [98.139.52.202]) by core3.amsl.com (Postfix) with SMTP id EF2FE3A68D2 for ; Mon, 28 Feb 2011 21:15:47 -0800 (PST) Received: from [98.139.52.195] by nm5.bullet.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 05:16:49 -0000 Received: from [98.139.52.157] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 05:16:49 -0000 Received: from [127.0.0.1] by omp1040.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 05:16:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 824937.12458.bm@omp1040.mail.ac4.yahoo.com Received: (qmail 89552 invoked by uid 60001); 1 Mar 2011 05:16:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298956609; bh=D2IKQE3Uvj3lsnH3Jo0Fo2Ltot6N//+3U1x+vCo5chA=; 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=giMeARe7BqIgFSKjz99K1XIomuaA1BfxmvitfZgIFzKWkHFfShzP2dYeV6jJf2cNQP9x1csYoFEr4m4c1+RCbiVpAPnZhVXDP+u/OZG74jV5kmC563DDFQigoZKpzSMQy+3nwOAsREhaN777PdSI8TG33FuQgVX3jirLKSQoSqo= Message-ID: <573957.85970.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: BBgl.ogVM1lyifrUAPt.cZdZZIMSOUQzbH3pCZo8E6ztS5z HdXQpuxdVwo1Os0gMuKRHCOuIyRwnD._Tmz8fi43oHIsJITZ0c9c6S5PP__u RdUkC9EB.qn0_rX2SnZUrGPMBOnV.qfCmiNee40JApeujKfQXDnth_rxFnid o8mFUFQV7SXnZt4AOne5qIwXrVQ.5sOvz7T54Rp5e8xD8FqQHVyp_Rpp7_Ke grlA1ttFRViPbtg02ScdhqXkpPm8G62f5ddzJpbdEnZIxj96FQpiWMvUG1Gv erbI9VvvK01_rfWucjNRh5ypFxOM7ZQq16IW9Wd4xkPxEtwLXwHwHJHChalZ xZqZJ_JmknsBgKTVhTuiNoDjbZkW1EEYBQKvC_cL4qZE7LM70gQTXprao9e0 kIm1XKHWbpw-- Received: from [174.65.103.16] by web55804.mail.re3.yahoo.com via HTTP; Mon, 28 Feb 2011 21:16:49 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 28 Feb 2011 21:16:49 -0800 (PST) From: Francisco Corella To: OAuth Mailing List , James HManger In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127F342542@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-517188337-1298956609=:85970" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 01 Mar 2011 05:15:51 -0000 --0-517188337-1298956609=:85970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi James, I think I got it now.=C2=A0 Thanks for explaining it so patiently. The attack is only possible if there are multiple independent authorization= servers that don't trust each other.=C2=A0 But the OAuth specification tal= ks about multiple resource servers but only one authorization server.=C2=A0= I think there is an implicit assumption that the multiple resource servers= will only accept tokens from the one authorization server.=C2=A0 By far th= e most widespread deployment of OAuth is for social login, as in "log in wi= th Facebook".=C2=A0 In that case the authorization server is a Facebook end= point, the resource servers are Facebook endpoints, and the attack is not p= ossible. Francisco --- On Tue, 3/1/11, Manger, James H wrote= : From: Manger, James H Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat lo= gin CSRF To: "fcorella@pomcor.com" , "OAuth Mailing List" Cc: "Karen P. Lewison" Date: Tuesday, March 1, 2011, 12:43 AM =0A=0A =0A =0A=0A=0A=0A=0AFrancisco, =0A =C2=A0 =0A>> A client that follows= HTTP redirects (or Link: header or any =0A>> other variety of hypertext) might get directed to an 2nd =0A>> service while still using the token from the 1st service. =0A =0A> But why would a legitimate authorization server redirect the =0A> client to an attacker's server? =0A =0A =0A =C2=A0 =0AIt can happen the other way around. The 1st service acts = maliciously, forwarding a token that was actually obtained from the 2nd ser= vice.=0A The client then uses that token to make requests to the 2nd servic= e =E2=80=93 because it thinks it is part of the 1st service. =0A =C2=A0 =0A= The core issue is that a client gets a opaque token from one service and wi= ll use it to access other resources. The token is opaque to the client: =0A= 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0AThe client cannot check that the t= oken was originally issued by this service (as opposed to this service forw= arding a token from elsewhere); =0A2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =0AThe client cannot check that the token was meant for itself (as opposed = to being forwarded from another client); =0A3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=0AThe client isn=E2=80=99t told by the token issuer where it shou= ld & shouldn=E2=80=99t be used (ie the boundary of the services); =0A4.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0AThe client isn=E2=80=99t told by a reso= urce server which sources of tokens are legitimate. =0A =C2=A0 =0AOne way t= o avoid some of these issues is to hardwire clients to a specific service = =E2=80=93 which is very limiting. =0AAnother way is to have a standard toke= n format =E2=80=93 which is limiting, and a big burden on clients. =0AA bet= ter way is to accept points 1 & 2; address 3 by listing resource sites in t= oken responses; and address 4 obliquely by listing the authorization server= =0A in the =E2=80=9COrigin=E2=80=9D HTTP request header. Then it doesn=E2= =80=99t matter if a client unwittingly connects with an attacker=E2=80=99s = service (just as it shouldn=E2=80=99t matter to a legitimate web site if th= eir web browser clients unwittingly visit malicious or compromised web site= s). =0A =C2=A0 =0A-- =0AJames Manger =0A=0A =0A --0-517188337-1298956609=:85970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi James,

I think I got it now.  = Thanks for explaining it so patiently.

The attack is only possible i= f there are multiple independent authorization servers that don't trust eac= h other.  But the OAuth specification talks about multiple resource se= rvers but only one authorization server.  I think there is an implicit= assumption that the multiple resource servers will only accept tokens from= the one authorization server.  By far the most widespread deployment = of OAuth is for social login, as in "log in with Facebook".  In that c= ase the authorization server is a Facebook endpoint, the resource servers a= re Facebook endpoints, and the attack is not possible.

Francisco
=
--- On Tue, 3/1/11, Manger, James H <James.H.Manger@team.telst= ra.com> wrote:

From: Manger, James H = <James.H.Manger@team.telstra.com>
Subject: RE: [OAUTH-WG] Indicati= ng origin of OAuth credentials to combat login CSRF
To: "fcorella@pomcor= .com" <fcorella@pomcor.com>, "OAuth Mailing List" <oauth@ietf.org&= gt;
Cc: "Karen P. Lewison" <kplewison@pomcor.com>
Date: Tuesday= , March 1, 2011, 12:43 AM

=0A=0A =0A =0A=0A=0A=0A<= div class=3D"yiv1900283487WordSection1">=0A

Francisco,

=0A

 

=0A>> A client that follows HTTP redir= ects (or Link: header or any
=0A>> other variety of hypertext) mig= ht get directed to an 2nd
=0A>> service while still using the toke= n from the 1st service.
=0A
=0A> But why would a legitimate author= ization server redirect the
=0A> client to an attacker's server?
= =0A
=0A=

=0A

 

=0A

It can = happen the other way around. The 1st service acts maliciously, f= orwarding a token that was actually obtained from the 2nd servic= e.=0A The client then uses that token to make requests to the 2nd service =E2=80=93 because it thinks it is part of the 1st serv= ice.

=0A

 

=0A

The core issue is that a client gets a opaque token from one service an= d will use it to access other resources. The token is opaque to the client:=

=0A

1.      =0AThe client cannot c= heck that the token was originally issued by this service (as opposed to th= is service forwarding a token from elsewhere);

=0A

2.  &nbs= p;   =0AThe client cannot check that the token was meant= for itself (as opposed to being forwarded from another client);

= =0A

3.      =0AThe client isn=E2=80=99t tol= d by the token issuer where it should & shouldn=E2=80=99t be used (ie t= he boundary of the services);

=0A

4.     &nb= sp;=0AThe client isn=E2=80=99t told by a resource server which sources = of tokens are legitimate.

=0A

  =0A

One way to avoid some of these issues is to hardwi= re clients to a specific service =E2=80=93 which is very limiting. =0A

Another way is to have a standard token format =E2= =80=93 which is limiting, and a big burden on clients.

=0A

A better way is to accept points 1 & 2; address 3 by listi= ng resource sites in token responses; and address 4 obliquely by listing th= e authorization server=0A in the =E2=80=9COrigin=E2=80=9D HTTP request head= er. Then it doesn=E2=80=99t matter if a client unwittingly connects with an= attacker=E2=80=99s service (just as it shouldn=E2=80=99t matter to a legit= imate web site if their web browser clients unwittingly visit malicious or = compromised web sites).

=0A

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">  

= =0A

--

=0A

James Manger

=0A
=0A =0A
--0-517188337-1298956609=:85970-- From James.H.Manger@team.telstra.com Mon Feb 28 22:58:21 2011 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A9C3A6A20 for ; Mon, 28 Feb 2011 22:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGPzGDHDMhR7 for ; Mon, 28 Feb 2011 22:58:17 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 2AB783A6D7A for ; Mon, 28 Feb 2011 22:58:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,245,1296997200"; d="scan'208,217";a="25986112" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 01 Mar 2011 17:59:14 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6271"; a="20278280" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 01 Mar 2011 17:59:14 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 1 Mar 2011 17:59:13 +1100 From: "Manger, James H" To: "fcorella@pomcor.com" , OAuth Mailing List Date: Tue, 1 Mar 2011 17:59:06 +1100 Thread-Topic: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Thread-Index: AcvXz+C/ukFEjDDdQQ6znWt8VOt7TAACvQAA Message-ID: <255B9BB34FB7D647A506DC292726F6E1127F4DAE9D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127F342542@WSMSG3153V.srv.dir.telstra.com> <573957.85970.qm@web55804.mail.re3.yahoo.com> In-Reply-To: <573957.85970.qm@web55804.mail.re3.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127F4DAE9DWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 06:58:21 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127F4DAE9DWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgYXR0YWNrIGlzIG9ubHkgcG9zc2libGUgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGluZGVw ZW5kZW50IGF1dGhvcml6YXRpb24gc2VydmVycyB0aGF0IGRvbid0IHRydXN0IGVhY2ggb3RoZXIu DQoNCg0KDQpBbmQgdGhlcmUgYXJlLiBGYWNlYm9vaywgVHdpdHRlciwgUGhvdG9zLWFyZS11cywg WHl64oCmIGNhbiBvcGVyYXRlIGF1dGhvcml6YXRpb24gc2VydmVyczsgdGhleSBhcmUgYWxsIGlu ZGVwZW5kZW50OyBhbmQgZG9u4oCZdCBwYXJ0aWN1bGFybHkgdHJ1c3QgZWFjaCBvdGhlci4gVGhl IGF0dGFjayBkb2VzbuKAmXQgcmVxdWlyZSBhIHNpbmdsZSByZXNvdXJjZSBzZXJ2ZXIgdG8gdHJ1 c3QgYWxsIHRoZXNlIGluZGVwZW5kZW50IGF1dGhvcml6YXRpb24gc2VydmVycy4NCg0KDQoNCj4g QnkgZmFyIHRoZSBtb3N0IHdpZGVzcHJlYWQgZGVwbG95bWVudCBvZiBPQXV0aCBpcyBmb3Igc29j aWFsIGxvZ2luLCBhcyBpbiAibG9nIGluIHdpdGggRmFjZWJvb2siLiAgSW4gdGhhdCBjYXNlIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBhIEZhY2Vib29rIGVuZHBvaW50LCB0aGUgcmVzb3Vy Y2Ugc2VydmVycyBhcmUgRmFjZWJvb2sgZW5kcG9pbnRzLCBhbmQgdGhlIGF0dGFjayBpcyBub3Qg cG9zc2libGUNCg0KDQoNCg0KDQpZb3UgYXJlIHByb2JhYmx5IHJpZ2h0IHRoYXQgdGhpcyBhdHRh Y2sgaXMgbm90IHBvc3NpYmxlIGFnYWluc3QgYSBjbGllbnQgYXBwIG9mZmVyaW5nIGEg4oCcbG9n aW4gd2l0aCBmYWNlYm9va+KAnSBidXR0b24uIFN1Y2ggYSBjbGllbnQgaXMgaGFyZHdpcmVkIHRv IHdvcmsgd2l0aCBhIHNpbmdsZSBzZXJ2aWNlIOKAkyB3aGljaCBpcyBvbmUgKHZlcnkgbGltaXRp bmcpIHdheSB0byBhdm9pZCB0aGVzZSBhdHRhY2tzLg0KDQoNCg0KQSBjbGllbnQgYWNjZXB0aW5n IGxvZ2luIGZyb20gYW55IHNvY2lhbCBuZXR3b3JrIChldmVuIG9uZXMgdGhlIGNsaWVudCBoYXNu 4oCZdCBoZWFyZCBvZikgY291bGQgYmUgc3VzY2VwdGlibGUgdGhpcyBhdHRhY2suIFRoZSDigJxv dGhlcuKAnSBzb2NpYWwgbmV0d29yayByZXR1cm5zIGEgdG9rZW4gdGhhdCBpdCBhY3R1YWxseSBn b3QgZnJvbSBGYWNlYm9vayBhbmQgZ2V0cyB0aGUgY2xpZW50IGFwcCB0byB1c2UgaXQgYXQgRmFj ZWJvb2suDQoNCg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2VyDQoNCg0KDQoNCg0KRnJvbTogRnJh bmNpc2NvIENvcmVsbGEgW21haWx0bzpmY29yZWxsYUBwb21jb3IuY29tXQ0KU2VudDogVHVlc2Rh eSwgMSBNYXJjaCAyMDExIDQ6MTcgUE0NClRvOiBPQXV0aCBNYWlsaW5nIExpc3Q7IE1hbmdlciwg SmFtZXMgSA0KQ2M6IEthcmVuIFAuIExld2lzb24NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIElu ZGljYXRpbmcgb3JpZ2luIG9mIE9BdXRoIGNyZWRlbnRpYWxzIHRvIGNvbWJhdCBsb2dpbiBDU1JG DQoNCg0KDQpIaSBKYW1lcywNCg0KSSB0aGluayBJIGdvdCBpdCBub3cuICBUaGFua3MgZm9yIGV4 cGxhaW5pbmcgaXQgc28gcGF0aWVudGx5Lg0KDQpUaGUgYXR0YWNrIGlzIG9ubHkgcG9zc2libGUg aWYgdGhlcmUgYXJlIG11bHRpcGxlIGluZGVwZW5kZW50IGF1dGhvcml6YXRpb24gc2VydmVycyB0 aGF0IGRvbid0IHRydXN0IGVhY2ggb3RoZXIuICBCdXQgdGhlIE9BdXRoIHNwZWNpZmljYXRpb24g dGFsa3MgYWJvdXQgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycyBidXQgb25seSBvbmUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuICBJIHRoaW5rIHRoZXJlIGlzIGFuIGltcGxpY2l0IGFzc3VtcHRpb24g dGhhdCB0aGUgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycyB3aWxsIG9ubHkgYWNjZXB0IHRva2Vu cyBmcm9tIHRoZSBvbmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBCeSBmYXIgdGhlIG1vc3Qgd2lk ZXNwcmVhZCBkZXBsb3ltZW50IG9mIE9BdXRoIGlzIGZvciBzb2NpYWwgbG9naW4sIGFzIGluICJs b2cgaW4gd2l0aCBGYWNlYm9vayIuICBJbiB0aGF0IGNhc2UgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGlzIGEgRmFjZWJvb2sgZW5kcG9pbnQsIHRoZSByZXNvdXJjZSBzZXJ2ZXJzIGFyZSBGYWNl Ym9vayBlbmRwb2ludHMsIGFuZCB0aGUgYXR0YWNrIGlzIG5vdCBwb3NzaWJsZS4NCg0KRnJhbmNp c2NvDQoNCi0tLSBPbiBUdWUsIDMvMS8xMSwgTWFuZ2VyLCBKYW1lcyBIIDxKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90ZToNCg0KDQoNCg0KRnJvbTogTWFuZ2VyLCBKYW1lcyBI IDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPg0KU3ViamVjdDogUkU6IFtPQVVUSC1X R10gSW5kaWNhdGluZyBvcmlnaW4gb2YgT0F1dGggY3JlZGVudGlhbHMgdG8gY29tYmF0IGxvZ2lu IENTUkYNClRvOiAiZmNvcmVsbGFAcG9tY29yLmNvbSIgPGZjb3JlbGxhQHBvbWNvci5jb20+LCAi T0F1dGggTWFpbGluZyBMaXN0IiA8b2F1dGhAaWV0Zi5vcmc+DQpDYzogIkthcmVuIFAuIExld2lz b24iIDxrcGxld2lzb25AcG9tY29yLmNvbT4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDEsIDIwMTEs IDEyOjQzIEFNDQoNCkZyYW5jaXNjbywNCg0KDQoNCj4+IEEgY2xpZW50IHRoYXQgZm9sbG93cyBI VFRQIHJlZGlyZWN0cyAob3IgTGluazogaGVhZGVyIG9yIGFueQ0KPj4gb3RoZXIgdmFyaWV0eSBv ZiBoeXBlcnRleHQpIG1pZ2h0IGdldCBkaXJlY3RlZCB0byBhbiAybmQNCj4+IHNlcnZpY2Ugd2hp bGUgc3RpbGwgdXNpbmcgdGhlIHRva2VuIGZyb20gdGhlIDFzdCBzZXJ2aWNlLg0KDQo+IEJ1dCB3 aHkgd291bGQgYSBsZWdpdGltYXRlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0IHRoZQ0K PiBjbGllbnQgdG8gYW4gYXR0YWNrZXIncyBzZXJ2ZXI/DQoNCg0KDQpJdCBjYW4gaGFwcGVuIHRo ZSBvdGhlciB3YXkgYXJvdW5kLiBUaGUgMXN0IHNlcnZpY2UgYWN0cyBtYWxpY2lvdXNseSwgZm9y d2FyZGluZyBhIHRva2VuIHRoYXQgd2FzIGFjdHVhbGx5IG9idGFpbmVkIGZyb20gdGhlIDJuZCBz ZXJ2aWNlLiBUaGUgY2xpZW50IHRoZW4gdXNlcyB0aGF0IHRva2VuIHRvIG1ha2UgcmVxdWVzdHMg dG8gdGhlIDJuZCBzZXJ2aWNlIOKAkyBiZWNhdXNlIGl0IHRoaW5rcyBpdCBpcyBwYXJ0IG9mIHRo ZSAxc3Qgc2VydmljZS4NCg0KDQoNClRoZSBjb3JlIGlzc3VlIGlzIHRoYXQgYSBjbGllbnQgZ2V0 cyBhIG9wYXF1ZSB0b2tlbiBmcm9tIG9uZSBzZXJ2aWNlIGFuZCB3aWxsIHVzZSBpdCB0byBhY2Nl c3Mgb3RoZXIgcmVzb3VyY2VzLiBUaGUgdG9rZW4gaXMgb3BhcXVlIHRvIHRoZSBjbGllbnQ6DQoN CjEuICAgICAgIFRoZSBjbGllbnQgY2Fubm90IGNoZWNrIHRoYXQgdGhlIHRva2VuIHdhcyBvcmln aW5hbGx5IGlzc3VlZCBieSB0aGlzIHNlcnZpY2UgKGFzIG9wcG9zZWQgdG8gdGhpcyBzZXJ2aWNl IGZvcndhcmRpbmcgYSB0b2tlbiBmcm9tIGVsc2V3aGVyZSk7DQoNCjIuICAgICAgIFRoZSBjbGll bnQgY2Fubm90IGNoZWNrIHRoYXQgdGhlIHRva2VuIHdhcyBtZWFudCBmb3IgaXRzZWxmIChhcyBv cHBvc2VkIHRvIGJlaW5nIGZvcndhcmRlZCBmcm9tIGFub3RoZXIgY2xpZW50KTsNCg0KMy4gICAg ICAgVGhlIGNsaWVudCBpc27igJl0IHRvbGQgYnkgdGhlIHRva2VuIGlzc3VlciB3aGVyZSBpdCBz aG91bGQgJiBzaG91bGRu4oCZdCBiZSB1c2VkIChpZSB0aGUgYm91bmRhcnkgb2YgdGhlIHNlcnZp Y2VzKTsNCg0KNC4gICAgICAgVGhlIGNsaWVudCBpc27igJl0IHRvbGQgYnkgYSByZXNvdXJjZSBz ZXJ2ZXIgd2hpY2ggc291cmNlcyBvZiB0b2tlbnMgYXJlIGxlZ2l0aW1hdGUuDQoNCg0KDQpPbmUg d2F5IHRvIGF2b2lkIHNvbWUgb2YgdGhlc2UgaXNzdWVzIGlzIHRvIGhhcmR3aXJlIGNsaWVudHMg dG8gYSBzcGVjaWZpYyBzZXJ2aWNlIOKAkyB3aGljaCBpcyB2ZXJ5IGxpbWl0aW5nLg0KDQpBbm90 aGVyIHdheSBpcyB0byBoYXZlIGEgc3RhbmRhcmQgdG9rZW4gZm9ybWF0IOKAkyB3aGljaCBpcyBs aW1pdGluZywgYW5kIGEgYmlnIGJ1cmRlbiBvbiBjbGllbnRzLg0KDQpBIGJldHRlciB3YXkgaXMg dG8gYWNjZXB0IHBvaW50cyAxICYgMjsgYWRkcmVzcyAzIGJ5IGxpc3RpbmcgcmVzb3VyY2Ugc2l0 ZXMgaW4gdG9rZW4gcmVzcG9uc2VzOyBhbmQgYWRkcmVzcyA0IG9ibGlxdWVseSBieSBsaXN0aW5n IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbiB0aGUg4oCcT3JpZ2lu4oCdIEhUVFAgcmVxdWVz dCBoZWFkZXIuIFRoZW4gaXQgZG9lc27igJl0IG1hdHRlciBpZiBhIGNsaWVudCB1bndpdHRpbmds eSBjb25uZWN0cyB3aXRoIGFuIGF0dGFja2Vy4oCZcyBzZXJ2aWNlIChqdXN0IGFzIGl0IHNob3Vs ZG7igJl0IG1hdHRlciB0byBhIGxlZ2l0aW1hdGUgd2ViIHNpdGUgaWYgdGhlaXIgd2ViIGJyb3dz ZXIgY2xpZW50cyB1bndpdHRpbmdseSB2aXNpdCBtYWxpY2lvdXMgb3IgY29tcHJvbWlzZWQgd2Vi IHNpdGVzKS4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0K --_000_255B9BB34FB7D647A506DC292726F6E1127F4DAE9DWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTkwMDI4MzQ4N21zb2xpc3RwYXJhZ3JhcGgsIGxpLnlp djE5MDAyODM0ODdtc29saXN0cGFyYWdyYXBoLCBkaXYueWl2MTkwMDI4MzQ4N21zb2xpc3RwYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTkwMDI4MzQ4N21zb2xpc3RwYXJhZ3JhcGg7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTkwMDI4MzQ4 N21zb25vcm1hbCwgbGkueWl2MTkwMDI4MzQ4N21zb25vcm1hbCwgZGl2LnlpdjE5MDAyODM0ODdt c29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTkwMDI4MzQ4N21zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxOTAwMjgzNDg3 bXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjE5MDAyODM0ODdtc29oeXBlcmxpbms7 fQ0Kc3Bhbi55aXYxOTAwMjgzNDg3bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTkwMDI4MzQ4N21zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MTkwMDI4MzQ4 N2VtYWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTp5aXYxOTAwMjgzNDg3ZW1haWxzdHlsZTE3 O30NCnAueWl2MTkwMDI4MzQ4N21zb25vcm1hbDEsIGxpLnlpdjE5MDAyODM0ODdtc29ub3JtYWwx LCBkaXYueWl2MTkwMDI4MzQ4N21zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTkwMDI4 MzQ4N21zb25vcm1hbDE7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4ueWl2MTkwMDI4MzQ4N21zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MTkwMDI4MzQ4N21zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4ueWl2MTkwMDI4MzQ4N21zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXtt c28tc3R5bGUtbmFtZTp5aXYxOTAwMjgzNDg3bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2MTkwMDI4MzQ4N21z b2xpc3RwYXJhZ3JhcGgxLCBsaS55aXYxOTAwMjgzNDg3bXNvbGlzdHBhcmFncmFwaDEsIGRpdi55 aXYxOTAwMjgzNDg3bXNvbGlzdHBhcmFncmFwaDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTkwMDI4 MzQ4N21zb2xpc3RwYXJhZ3JhcGgxOw0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxOTAwMjgzNDg3ZW1haWxzdHlsZTE3MQ0KCXtt c28tc3R5bGUtbmFtZTp5aXYxOTAwMjgzNDg3ZW1haWxzdHlsZTE3MTsNCglmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQog PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGUgYXR0YWNrIGlz IG9ubHkgcG9zc2libGUgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGluZGVwZW5kZW50IGF1dGhvcml6 YXRpb24gc2VydmVycyB0aGF0IGRvbid0IHRydXN0IGVhY2ggb3RoZXIuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFuZCB0aGVyZSBhcmUuIEZhY2Vib29rLCBUd2l0dGVyLCBQaG90b3MtYXJlLXVz LCBYeXrigKYgY2FuIG9wZXJhdGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzOyB0aGV5IGFyZSBhbGwg aW5kZXBlbmRlbnQ7IGFuZCBkb27igJl0IHBhcnRpY3VsYXJseSB0cnVzdCBlYWNoIG90aGVyLiBU aGUgYXR0YWNrIGRvZXNu4oCZdCByZXF1aXJlIGEgc2luZ2xlIHJlc291cmNlIHNlcnZlciB0byB0 cnVzdCBhbGwgdGhlc2UgaW5kZXBlbmRlbnQNCiBhdXRob3JpemF0aW9uIHNlcnZlcnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgQnkgZmFyIHRoZSBtb3N0IHdpZGVzcHJlYWQgZGVwbG95 bWVudCBvZiBPQXV0aCBpcyBmb3Igc29jaWFsIGxvZ2luLCBhcyBpbiAmcXVvdDtsb2cgaW4gd2l0 aCBGYWNlYm9vayZxdW90Oy4mbmJzcDsgSW4gdGhhdCBjYXNlIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBpcyBhIEZhY2Vib29rIGVuZHBvaW50LCB0aGUgcmVzb3VyY2Ugc2VydmVycyBhcmUgRmFj ZWJvb2sgZW5kcG9pbnRzLCBhbmQgdGhlIGF0dGFjayBpcyBub3QgcG9zc2libGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Zb3UgYXJlIHByb2JhYmx5IHJpZ2h0IHRoYXQgdGhpcyBhdHRhY2sgaXMgbm90IHBvc3NpYmxl IGFnYWluc3QgYSBjbGllbnQgYXBwIG9mZmVyaW5nIGEg4oCcbG9naW4gd2l0aCBmYWNlYm9va+KA nSBidXR0b24uIFN1Y2ggYSBjbGllbnQgaXMgaGFyZHdpcmVkIHRvIHdvcmsgd2l0aCBhIHNpbmds ZSBzZXJ2aWNlIOKAkyB3aGljaCBpcyBvbmUgKHZlcnkgbGltaXRpbmcpIHdheSB0byBhdm9pZCB0 aGVzZSBhdHRhY2tzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNsaWVudCBhY2NlcHRpbmcg bG9naW4gZnJvbSBhbnkgc29jaWFsIG5ldHdvcmsgKGV2ZW4gb25lcyB0aGUgY2xpZW50IGhhc27i gJl0IGhlYXJkIG9mKSBjb3VsZCBiZSBzdXNjZXB0aWJsZSB0aGlzIGF0dGFjay4gVGhlIOKAnG90 aGVy4oCdIHNvY2lhbCBuZXR3b3JrIHJldHVybnMgYSB0b2tlbiB0aGF0IGl0IGFjdHVhbGx5IGdv dCBmcm9tIEZhY2Vib29rIGFuZCBnZXRzIHRoZSBjbGllbnQgYXBwIHRvIHVzZSBpdCBhdA0KIEZh Y2Vib29rLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBGcmFuY2lzY28gQ29yZWxsYSBbbWFpbHRvOmZjb3JlbGxhQHBv bWNvci5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgMSBNYXJjaCAyMDExIDQ6MTcg UE08YnI+DQo8Yj5Ubzo8L2I+IE9BdXRoIE1haWxpbmcgTGlzdDsgTWFuZ2VyLCBKYW1lcyBIPGJy Pg0KPGI+Q2M6PC9iPiBLYXJlbiBQLiBMZXdpc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb T0FVVEgtV0ddIEluZGljYXRpbmcgb3JpZ2luIG9mIE9BdXRoIGNyZWRlbnRpYWxzIHRvIGNvbWJh dCBsb2dpbiBDU1JGPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEphbWVzLDxicj4NCjxicj4NCkkgdGhpbmsgSSBnb3Qg aXQgbm93LiZuYnNwOyBUaGFua3MgZm9yIGV4cGxhaW5pbmcgaXQgc28gcGF0aWVudGx5Ljxicj4N Cjxicj4NClRoZSBhdHRhY2sgaXMgb25seSBwb3NzaWJsZSBpZiB0aGVyZSBhcmUgbXVsdGlwbGUg aW5kZXBlbmRlbnQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHRoYXQgZG9uJ3QgdHJ1c3QgZWFjaCBv dGhlci4mbmJzcDsgQnV0IHRoZSBPQXV0aCBzcGVjaWZpY2F0aW9uIHRhbGtzIGFib3V0IG11bHRp cGxlIHJlc291cmNlIHNlcnZlcnMgYnV0IG9ubHkgb25lIGF1dGhvcml6YXRpb24gc2VydmVyLiZu YnNwOyBJIHRoaW5rIHRoZXJlIGlzIGFuIGltcGxpY2l0IGFzc3VtcHRpb24gdGhhdA0KIHRoZSBt dWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgb25seSBhY2NlcHQgdG9rZW5zIGZyb20gdGhl IG9uZSBhdXRob3JpemF0aW9uIHNlcnZlci4mbmJzcDsgQnkgZmFyIHRoZSBtb3N0IHdpZGVzcHJl YWQgZGVwbG95bWVudCBvZiBPQXV0aCBpcyBmb3Igc29jaWFsIGxvZ2luLCBhcyBpbiAmcXVvdDts b2cgaW4gd2l0aCBGYWNlYm9vayZxdW90Oy4mbmJzcDsgSW4gdGhhdCBjYXNlIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBpcyBhIEZhY2Vib29rIGVuZHBvaW50LCB0aGUgcmVzb3VyY2UNCiBzZXJ2 ZXJzIGFyZSBGYWNlYm9vayBlbmRwb2ludHMsIGFuZCB0aGUgYXR0YWNrIGlzIG5vdCBwb3NzaWJs ZS48YnI+DQo8YnI+DQpGcmFuY2lzY288YnI+DQo8YnI+DQotLS0gT24gPGI+VHVlLCAzLzEvMTEs IE1hbmdlciwgSmFtZXMgSCA8aT4mbHQ7SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSZn dDs8L2k+PC9iPiB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KRnJvbTogTWFuZ2Vy LCBKYW1lcyBIICZsdDtKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tJmd0Ozxicj4NClN1 YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEluZGljYXRpbmcgb3JpZ2luIG9mIE9BdXRoIGNyZWRlbnRp YWxzIHRvIGNvbWJhdCBsb2dpbiBDU1JGPGJyPg0KVG86ICZxdW90O2Zjb3JlbGxhQHBvbWNvci5j b20mcXVvdDsgJmx0O2Zjb3JlbGxhQHBvbWNvci5jb20mZ3Q7LCAmcXVvdDtPQXV0aCBNYWlsaW5n IExpc3QmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCkNjOiAmcXVvdDtLYXJlbiBQ LiBMZXdpc29uJnF1b3Q7ICZsdDtrcGxld2lzb25AcG9tY29yLmNvbSZndDs8YnI+DQpEYXRlOiBU dWVzZGF5LCBNYXJjaCAxLCAyMDExLCAxMjo0MyBBTTxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0i eWl2MTkwMDI4MzQ4NyI+DQo8ZGl2Pg0KPHAgY2xhc3M9InlpdjE5MDAyODM0ODdtc29ub3JtYWwi PkZyYW5jaXNjbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYxOTAwMjgzNDg3bXNvbm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYxOTAwMjgzNDg3bXNvbm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsmZ3Q7IEEgY2xpZW50IHRoYXQg Zm9sbG93cyBIVFRQIHJlZGlyZWN0cyAob3IgTGluazogaGVhZGVyIG9yIGFueTxicj4NCiZndDsm Z3Q7IG90aGVyIHZhcmlldHkgb2YgaHlwZXJ0ZXh0KSBtaWdodCBnZXQgZGlyZWN0ZWQgdG8gYW4g Mm5kPGJyPg0KJmd0OyZndDsgc2VydmljZSB3aGlsZSBzdGlsbCB1c2luZyB0aGUgdG9rZW4gZnJv bSB0aGUgMXN0IHNlcnZpY2UuPGJyPg0KPGJyPg0KJmd0OyBCdXQgd2h5IHdvdWxkIGEgbGVnaXRp bWF0ZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdCB0aGU8YnI+DQomZ3Q7IGNsaWVudCB0 byBhbiBhdHRhY2tlcidzIHNlcnZlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYxOTAw MjgzNDg3bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieWl2MTkwMDI4MzQ4 N21zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ SXQgY2FuIGhhcHBlbiB0aGUgb3RoZXIgd2F5IGFyb3VuZC4gVGhlIDE8c3VwPnN0PC9zdXA+IHNl cnZpY2UgYWN0cyBtYWxpY2lvdXNseSwgZm9yd2FyZGluZyBhIHRva2VuIHRoYXQgd2FzIGFjdHVh bGx5IG9idGFpbmVkIGZyb20gdGhlIDI8c3VwPm5kPC9zdXA+IHNlcnZpY2UuIFRoZSBjbGllbnQg dGhlbiB1c2VzDQogdGhhdCB0b2tlbiB0byBtYWtlIHJlcXVlc3RzIHRvIHRoZSAyPHN1cD5uZDwv c3VwPiBzZXJ2aWNlIOKAkyBiZWNhdXNlIGl0IHRoaW5rcyBpdCBpcyBwYXJ0IG9mIHRoZSAxPHN1 cD5zdDwvc3VwPiBzZXJ2aWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYx OTAwMjgzNDg3bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieWl2MTkwMDI4 MzQ4N21zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+VGhlIGNvcmUgaXNzdWUgaXMgdGhhdCBhIGNsaWVudCBnZXRzIGEgb3BhcXVlIHRva2VuIGZy b20gb25lIHNlcnZpY2UgYW5kIHdpbGwgdXNlIGl0IHRvIGFjY2VzcyBvdGhlciByZXNvdXJjZXMu IFRoZSB0b2tlbiBpcyBvcGFxdWUgdG8gdGhlIGNsaWVudDo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ieWl2MTkwMDI4MzQ4N21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ow0KICBjb2xvcjojMUY0OTdEIj4xLiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaGUgY2xpZW50IGNhbm5vdCBjaGVjayB0aGF0IHRoZSB0b2tlbiB3 YXMgb3JpZ2luYWxseSBpc3N1ZWQgYnkgdGhpcyBzZXJ2aWNlIChhcyBvcHBvc2VkIHRvIHRoaXMg c2VydmljZSBmb3J3YXJkaW5nIGEgdG9rZW4gZnJvbSBlbHNld2hlcmUpOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYxOTAwMjgzNDg3bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQogIGNvbG9yOiMxRjQ5N0QiPjIuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBjbGllbnQgY2Fubm90IGNoZWNrIHRoYXQgdGhl IHRva2VuIHdhcyBtZWFudCBmb3IgaXRzZWxmIChhcyBvcHBvc2VkIHRvIGJlaW5nIGZvcndhcmRl ZCBmcm9tIGFub3RoZXIgY2xpZW50KTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i eWl2MTkwMDI4MzQ4N21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ow0KICBjb2xvcjojMUY0OTdEIj4zLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgY2xpZW50IGlzbuKAmXQgdG9sZCBieSB0aGUgdG9rZW4gaXNzdWVyIHdoZXJlIGl0 IHNob3VsZCAmYW1wOyBzaG91bGRu4oCZdCBiZSB1c2VkIChpZSB0aGUgYm91bmRhcnkgb2YgdGhl IHNlcnZpY2VzKTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieWl2MTkwMDI4MzQ4 N21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ow0KICBjb2xv cjojMUY0OTdEIj40LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgY2xp ZW50IGlzbuKAmXQgdG9sZCBieSBhIHJlc291cmNlIHNlcnZlciB3aGljaCBzb3VyY2VzIG9mIHRv a2VucyBhcmUgbGVnaXRpbWF0ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieWl2 MTkwMDI4MzQ4N21zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InlpdjE5MDAy ODM0ODdtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPk9uZSB3YXkgdG8gYXZvaWQgc29tZSBvZiB0aGVzZSBpc3N1ZXMgaXMgdG8gaGFyZHdpcmUg Y2xpZW50cyB0byBhIHNwZWNpZmljIHNlcnZpY2Ug4oCTIHdoaWNoIGlzIHZlcnkgbGltaXRpbmcu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InlpdjE5MDAyODM0ODdtc29ub3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkFub3RoZXIgd2F5 IGlzIHRvIGhhdmUgYSBzdGFuZGFyZCB0b2tlbiBmb3JtYXQg4oCTIHdoaWNoIGlzIGxpbWl0aW5n LCBhbmQgYSBiaWcgYnVyZGVuIG9uIGNsaWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9InlpdjE5MDAyODM0ODdtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPkEgYmV0dGVyIHdheSBpcyB0byBhY2NlcHQgcG9pbnRzIDEgJmFt cDsgMjsgYWRkcmVzcyAzIGJ5IGxpc3RpbmcgcmVzb3VyY2Ugc2l0ZXMgaW4gdG9rZW4gcmVzcG9u c2VzOyBhbmQgYWRkcmVzcyA0IG9ibGlxdWVseSBieSBsaXN0aW5nIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBpbiB0aGUg4oCcT3JpZ2lu4oCdIEhUVFAgcmVxdWVzdA0KIGhlYWRlci4gVGhlbiBp dCBkb2VzbuKAmXQgbWF0dGVyIGlmIGEgY2xpZW50IHVud2l0dGluZ2x5IGNvbm5lY3RzIHdpdGgg YW4gYXR0YWNrZXLigJlzIHNlcnZpY2UgKGp1c3QgYXMgaXQgc2hvdWxkbuKAmXQgbWF0dGVyIHRv IGEgbGVnaXRpbWF0ZSB3ZWIgc2l0ZSBpZiB0aGVpciB3ZWIgYnJvd3NlciBjbGllbnRzIHVud2l0 dGluZ2x5IHZpc2l0IG1hbGljaW91cyBvciBjb21wcm9taXNlZCB3ZWIgc2l0ZXMpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ5aXYxOTAwMjgzNDg3bXNvbm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ieWl2MTkwMDI4MzQ4N21zb25vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+LS08L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ieWl2MTkwMDI4MzQ4N21zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E1127F4DAE9DWSMSG3153Vsrv_--