From hannes.tschofenig@nsn.com Tue Apr 7 06:34:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B99E3A6991 for ; Tue, 7 Apr 2009 06:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=-0.960, 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 sBJwXPjPbtMj for ; Tue, 7 Apr 2009 06:34:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 122523A6983 for ; Tue, 7 Apr 2009 06:34:16 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n37DZM0c002885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Apr 2009 15:35:22 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n37DZLrF015861 for ; Tue, 7 Apr 2009 15:35:21 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 15:35:21 +0200 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: Tue, 7 Apr 2009 16:36:44 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45013E8068@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes - IETF#74 OAuth Thread-Index: Acm3heR9UTPeujbpRpOMo3DyrJN01g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 07 Apr 2009 13:35:21.0751 (UTC) FILETIME=[B2F20A70:01C9B785] Subject: [oauth] Meeting Minutes - IETF#74 OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:34:21 -0000 Here are the meeting minutes from the IETF#74 meeting:=20 http://www.ietf.org/proceedings/09mar/minutes/oauth.txt Thanks to Jeff for taking the notes.=20 Ciao Hannes From hannes.tschofenig@nsn.com Tue Apr 7 07:11:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7916B3A6886 for ; Tue, 7 Apr 2009 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=1.081, 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 BhwHsxFGwQ1F for ; Tue, 7 Apr 2009 07:11:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1C9063A69E1 for ; Tue, 7 Apr 2009 07:11:20 -0700 (PDT) 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 n37ECP1D013967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Apr 2009 16:12:25 +0200 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 n37ECO15030342 for ; Tue, 7 Apr 2009 16:12:25 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 16:11:21 +0200 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: Tue, 7 Apr 2009 17:12:44 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated OAuth Charter Text Thread-Index: Acm3iuu/KyXNBFprRzuHqVrG4Cx7EA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 07 Apr 2009 14:11:21.0454 (UTC) FILETIME=[BA3A90E0:01C9B78A] Subject: [oauth] Updated OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:11:22 -0000 Based on the discussions during the IETF meeting we have updated the charter text.=20 There are two changes worth mentioning:=20 ** Backwards Compatibility **=20 I tried to clarify the term backwards compatibility based on text provided by Peter Saint-Andre. Peter had some experience with this topic already in the context of XMPP and I believe that the text they have used in their original charter fits quite well.=20 ** 2-Legged Scenario ** Initially, the 2-legged scenario was out-of-scope. The opinion changed and folks are now interested to also work on this use case within this group.=20 Here is the new version: --------------------------- Open Authentication Protocol (oauth) Last Modified: 2009-04-06 Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault =20 Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm l. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ 2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora-farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones.=20 The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism=20 Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard=20 Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard=20 From stpeter@stpeter.im Tue Apr 7 08:32:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE383A67DF for ; Tue, 7 Apr 2009 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXz866ObLyJf for ; Tue, 7 Apr 2009 08:32:41 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 4FE253A67A6 for ; Tue, 7 Apr 2009 08:32:41 -0700 (PDT) Received: from wrk165.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id BB9A2E800D; Tue, 7 Apr 2009 09:33:47 -0600 (MDT) Message-ID: <49DB725A.9000102@stpeter.im> Date: Tue, 07 Apr 2009 09:33:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030905070308040601010602" Cc: oauth@ietf.org Subject: Re: [oauth] Updated OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:32:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030905070308040601010602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Nits inline. On 4/7/09 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Based on the discussions during the IETF meeting we have updated the > charter text. > > There are two changes worth mentioning: > > ** Backwards Compatibility ** > > I tried to clarify the term backwards compatibility based on text > provided by Peter Saint-Andre. Peter had some experience with this topic > already in the context of XMPP and I believe that the text they have > used in their original charter fits quite well. > > ** 2-Legged Scenario ** > > Initially, the 2-legged scenario was out-of-scope. The opinion changed > and folks are now interested to also work on this use case within this > group. > > > > Here is the new version: > > --------------------------- > > > Open Authentication Protocol (oauth) > > Last Modified: 2009-04-06 > > Chair(s): > > TBD > > Applications Area Director(s): > > Alexey Melnikov > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without necessarily revealing their > credentials, or even their identity. For example, a photo-sharing site > that supports OAuth would allow its users to use a third-party printing > Web site to access their private pictures, without gaining full control > of the user account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair which can be used by a third party to access resources on their > behalf. For clarity, I would change "their" to "the user's". > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard that will: > * Improve the terminology used. > * Embody good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. I would change "the gap" to "those gaps". > * Promote interoperability. Is this an actionable guideline? > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the > original OAuth specification in IETF draft format, is used and the > available extension points are going to be utilized. That's a somewhat long and confusing sentence. :) I'd be happy to suggest something that might be a bit more readable. We seem to be assuming that the result of the WG activity will be "OAuth 1.1", which further assumes that versioning is well-defined in OAuth. Is that the case, or is definition of versioning in scope for the group? Could we specify a bit more clearly what we mean by "the available extension points"? Are those other documents, or places in OAuth 1.0 where extensibility can occur? > In completing its > work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to > retain backwards compatibility with the OAuth 1.0 specification. > However, changes that are not backwards compatible might be accepted if > the group determines that the changes are required to meet the group's > technical objectives and the group clearly documents the reasons for > making them. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods Why? Because HMAC-SHA1 and RSA-SHA1 have known vulnerabilities, or because agility is desiable here? > and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. > > The Working Group should consider: > * Implementer experience. > * The end-user experience, including internationalization. > * Existing uses of OAuth. > * Ability to achieve broad implementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > > After delivering OAuth 1.1, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration, e.g., > http://oauth.net/discovery/1.0. > * Comprehensive message integrity, e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm > l. > * Recommendations regarding the structure of the token. > * Localization, e.g., > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ > 2/spec.html. > * Session-oriented tokens, e.g., > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. > * Alternate token exchange profiles, e.g., > draft-dehora-farrell-oauth-accesstoken-creds-00. I'm leery of this long list, which is only a list of *possible* work items ("for example, but not limited to"). Perhaps it makes more sense to not mention extensions until "OAuth 1.1" is complete? At time it might be appropriate to recharter the group and work on new features and extensions. > The work on extensions is within the scope of the working group charter > and requires consensus within the group to add new milestones. But which extensions are in scope? IMHO it's best to tightly define the charter, especially the initial charter. The group can always be rechartered later. > The Working Group will also define a generally applicable HTTP > authentication mechanism (i.e., browser-based "2-leg" scenerio). Is there a draft to refer to here? What is the 2-leg scenario? This might be a term of art, but it is undefined in the charter. > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) No need to say this here, since we said it above. > Jul 2009 Submit a document as a working group item providing the > functionality of the 2-legged HTTP authentication mechanism Undefined (see above). And now it is referred to as authentication. This might lead some to think that work on authentication is being smuggled in the back door ("doesn't the IETF already have some authentication protocols defined in both HTTP and SASL?"). > Jul 2009 Start of discussion about OAuth extensions the group should > work on > Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Start Working Group Last Call on the 2-legged HTTP > authentication mechanism document > Nov 2009 Prepare milestone update to start new work within the scope > of the charter Is that perhaps better as a recharter? > Dec 2009 Submit 2-legged HTTP authentication mechanism document to > the IESG for consideration as a Proposed Standard See above. Thanks for the text! Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030905070308040601010602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/ +Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6 JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0 YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS +GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0 dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3 l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK /kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9 bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5 zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9 gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1 Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa 16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06 8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ 9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA0MDcxNTMzNDZaMCMGCSqGSIb3DQEJBDEWBBS+rDeErOGw92JhEfgtFHUT D32WZzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAe5cp6SZQwEsopodv3FdaDQucYMcXWS6pKZ86sVgkPLRZslu2S1z4tGGZvJRs UIvjCkQh2p8rMmhDGqHCNKnWlBvMdMubjWnsma+mfPovLOCh6/JJHyCcpF1ieR2+n8GYZzKy zMWqAalcuVlYgzLQyeyCMyiY982HZdxZbZ+W/e6lRKOylchYhGFFLpZpPPVfOlCj4R1f7rUJ 5u2z5qprlQVPhBz0zCRznxPa/dk8kYvxgizwToCWHPiOwXg5DU1bQpJZKfVkxnXDWz+9CKgX jiM8XZYPKIs0UoN8IOkhgIKZ8h1rvW3z3v0/6KHPnhL67iZOijsMzehOSft48AtGBgAAAAAA AA== --------------ms030905070308040601010602-- From stephen.farrell@cs.tcd.ie Tue Apr 7 08:56:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984A53A6D66 for ; Tue, 7 Apr 2009 08:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, 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 7XgKFJMp8eEy for ; Tue, 7 Apr 2009 08:56:02 -0700 (PDT) Received: from SG2EHSOBE003.bigfish.com (outbound-sin.frontbridge.com [207.46.51.80]) by core3.amsl.com (Postfix) with ESMTP id 8C8563A67F5 for ; Tue, 7 Apr 2009 08:56:01 -0700 (PDT) Received: from mail193-sin-R.bigfish.com (10.3.40.3) by SG2EHSOBE003.bigfish.com (10.3.40.23) with Microsoft SMTP Server id 8.1.340.0; Tue, 7 Apr 2009 15:57:06 +0000 Received: from mail193-sin (localhost.localdomain [127.0.0.1]) by mail193-sin-R.bigfish.com (Postfix) with ESMTP id 355B01CA00A9; Tue, 7 Apr 2009 15:57:06 +0000 (UTC) X-BigFish: VPS8(z5edJz98dRzz1202hzzz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail193-sin (MessageSwitch) id 1239119824823359_19142; Tue, 7 Apr 2009 15:57:04 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail193-sin.bigfish.com (Postfix) with ESMTP id 724E910A8055; Tue, 7 Apr 2009 15:57:04 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 33D8B68002; Tue, 7 Apr 2009 16:57:03 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A017EF2FAC1; Tue, 07 Apr 2009 16:57:03 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 22DB168002; Tue, 7 Apr 2009 16:57:03 +0100 (IST) Message-ID: <49DB7820.7000703@cs.tcd.ie> Date: Tue, 7 Apr 2009 16:58:24 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Peter Saint-Andre References: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> <49DB725A.9000102@stpeter.im> In-Reply-To: <49DB725A.9000102@stpeter.im> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A117EF2FAC1 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.102.35) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [oauth] Updated OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:56:02 -0000 Peter Saint-Andre wrote: > But which extensions are in scope? IMHO it's best to tightly define the > charter, especially the initial charter. The group can always be > rechartered later. There was a longish thread on this a month or two ago so I'd be leery of going back and re-doing all that discussion. I think the current text is ok as-is on this point. Stephen. From stpeter@stpeter.im Tue Apr 7 09:24:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE883A67A6 for ; Tue, 7 Apr 2009 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 snR20h4pqZt4 for ; Tue, 7 Apr 2009 09:24:59 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 012C33A63EB for ; Tue, 7 Apr 2009 09:24:58 -0700 (PDT) Received: from wrk165.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id F1F22E800D; Tue, 7 Apr 2009 10:18:08 -0600 (MDT) Message-ID: <49DB7CC0.8060305@stpeter.im> Date: Tue, 07 Apr 2009 10:18:08 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Stephen Farrell References: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> <49DB725A.9000102@stpeter.im> <49DB7820.7000703@cs.tcd.ie> In-Reply-To: <49DB7820.7000703@cs.tcd.ie> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509010208050704080501" Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [oauth] Updated OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 16:25:00 -0000 This is a cryptographically signed message in MIME format. --------------ms080509010208050704080501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/7/09 9:58 AM, Stephen Farrell wrote: > > Peter Saint-Andre wrote: > >> But which extensions are in scope? IMHO it's best to tightly define the >> charter, especially the initial charter. The group can always be >> rechartered later. > > There was a longish thread on this a month or two ago so I'd be leery > of going back and re-doing all that discussion. I think the current > text is ok as-is on this point. I defer to the list consensus, then. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080509010208050704080501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/ +Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6 JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0 YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS +GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0 aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0 dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3 l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK /kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9 bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5 zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9 gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1 Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa 16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06 8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ 9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA0MDcxNjE4MDhaMCMGCSqGSIb3DQEJBDEWBBSzeLswdF826b85ME9EG/bS SJHRiDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN AQEBBQAEggEAWj1MJ01X50fnKYAeYytI7edmQCsYtyaVKUDU4JzuHzgtnjo85KGUDhcrg+31 WPsQbg9JUTygYaMK0TgwbC6yJurjV2BP+73LaV2Ezm4U9lw6Z2MiFyiThi+janjmDKOIt5BZ J1liaH/G1LMkSWY8ReR/9/iYTBiBPwXD/iS+/aGxmVYck6xOiDXYzyzlmDxo3d78G/iFVlGP BsBXSLA0Fw6IAdxE/PyltWsO5Q7NWb8UcT5NVVjDvQLE/UC4QvtALCHgagmGrmr3UpELhbty M0D06SlPMUto6vDLvlUuZDNTef5FhPnhcO6hAdeg2hyfwT4MHZjmJ4yWqWwY5cf3HQAAAAAA AA== --------------ms080509010208050704080501-- From eran@hueniverse.com Tue Apr 7 19:52:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FBE3A6829 for ; Tue, 7 Apr 2009 19:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 kIDxrGwRCYrv for ; Tue, 7 Apr 2009 19:52:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 05F1A28C0E8 for ; Tue, 7 Apr 2009 19:50:43 -0700 (PDT) Received: (qmail 760 invoked from network); 8 Apr 2009 02:51:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Apr 2009 02:51:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 7 Apr 2009 19:51:42 -0700 From: Eran Hammer-Lahav To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "oauth@ietf.org" Date: Tue, 7 Apr 2009 19:51:46 -0700 Thread-Topic: [oauth] Updated OAuth Charter Text Thread-Index: Acm3iuu/KyXNBFprRzuHqVrG4Cx7EAAagjVq Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45013E80AA@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6015F5215A3Feranhueniversecom_" MIME-Version: 1.0 Subject: Re: [oauth] Updated OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 02:52:52 -0000 --_000_C6015F5215A3Feranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please change '1.1' with 'future version'. EHL On 4/7/09 7:12 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: Based on the discussions during the IETF meeting we have updated the charter text. There are two changes worth mentioning: ** Backwards Compatibility ** I tried to clarify the term backwards compatibility based on text provided by Peter Saint-Andre. Peter had some experience with this topic already in the context of XMPP and I believe that the text they have used in their original charter fits quite well. ** 2-Legged Scenario ** Initially, the 2-legged scenario was out-of-scope. The opinion changed and folks are now interested to also work on this use case within this group. Here is the new version: --------------------------- Open Authentication Protocol (oauth) Last Modified: 2009-04-06 Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm l. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ 2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora-farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C6015F5215A3Feranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] Updated OAuth Charter Text Please change ‘1.1’ with ‘future version’.
EHL


On 4/7/09 7:12 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:<= BR>
Based on the discussions during the IETF me= eting we have updated the
charter text.

There are two changes worth mentioning:

** Backwards Compatibility **

I tried to clarify the term backwards compatibility based on text
provided by Peter Saint-Andre. Peter had some experience with this topic already in the context of XMPP and I believe that the text they have
used in their original charter fits quite well.

** 2-Legged Scenario **

Initially, the 2-legged scenario was out-of-scope. The opinion changed
and folks are now interested to also work on this use case within this
group.



Here is the new version:

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


Open Authentication Protocol (oauth)

Last Modified: 2009-04-06

Chair(s):

TBD

Applications Area Director(s):

Alexey Melnikov <alexey.melnikov@i= sode.com>
Lisa Dusseault <lisa@osafoundation.or= g>

Applications Area Advisor:

TBD

Mailing Lists:

https://www.ietf.or= g/mailman/listinfo/oauth

Description of Working Group:

OAuth allows a user to grant a third-party Web site or application
access to their resources, without necessarily revealing their
credentials, or even their identity. For example, a photo-sharing site
that supports OAuth would allow its users to use a third-party printing
Web site to access their private pictures, without gaining full control
of the user account.

OAuth consists of:
  * A mechanism for exchanging a user's credentials for a token-s= ecret
pair which can be used by a third party to access resources on their
behalf.
  * A mechanism for signing HTTP requests with the token-secret p= air.

The Working Group will produce one or more documents suitable for
consideration as Proposed Standard that will:
  * Improve the terminology used.
  * Embody good security practice, or document gaps in its capabi= lities,
and propose a path forward for addressing the gap.
  * Promote interoperability.
  * Provide guidelines for extensibility.

This specifically means that as a starting point for the working group
OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the
original OAuth specification in IETF draft format, is used and the
available extension points are going to be utilized. In completing its
work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to
retain backwards compatibility with the OAuth 1.0 specification.
However, changes that are not backwards compatible might be accepted if
the group determines that the changes are required to meet the group's
technical objectives and the group clearly documents the reasons for
making them.

Furthermore, OAuth 1.0 defines three signature methods used to protect
requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new
security requirements justify their usage. Existing signature methods
will not be modified but may be dropped as part of the backwards
compatible profiling activity. The applicability of existing and new
signature methods to protocols other than HTTP will be investigated.

The Working Group should consider:
  * Implementer experience.
  * The end-user experience, including internationalization.
  * Existing uses of OAuth.
  * Ability to achieve broad implementation.
  * Ability to address broader use cases than may be contemplated= by the
original authors.

After delivering OAuth 1.1, the Working Group may consider defining
additional functions and/or extensions, for example (but not limited
to):
 * Discovery of OAuth configuration, e.g.,
http://oauth.net/discovery/1.0.
 * Comprehensive message integrity, e.g.,
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/s= pec.htm
l.
 * Recommendations regarding the structure of the token.
 * Localization, e.g.,
http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/= drafts/
2/spec.html.
 * Session-oriented tokens, e.g.,
http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec= .html.
 * Alternate token exchange profiles, e.g.,
draft-dehora-farrell-oauth-accesstoken-creds-00.

The work on extensions is within the scope of the working group charter
and requires consensus within the group to add new milestones.

The Working Group will also define a generally applicable HTTP
authentication mechanism (i.e., browser-based "2-leg" scenerio).<= BR>
Goals and Milestones:

Apr 2009    Submit 'OAuth: HTTP Authorization Delegation Pro= tocol' as
working group item
            (dr= aft-hammer-oauth will be used as a starting point for
further work.)
Jul 2009    Submit a document as a working group item provid= ing the
functionality of the 2-legged HTTP authentication mechanism
Jul 2009    Start of discussion about OAuth extensions the g= roup should
work on
Oct 2009    Start Working Group Last Call on 'OAuth: HTTP Au= thorization
Delegation Protocol'
Nov 2009    Submit 'OAuth: HTTP Authorization Delegation Pro= tocol' to
the IESG for consideration as a Proposed Standard
Nov 2009    Start Working Group Last Call on the 2-legged HT= TP
authentication mechanism document
Nov 2009    Prepare milestone update to start new work withi= n the scope
of the charter
Dec 2009    Submit 2-legged HTTP authentication mechanism do= cument to
the IESG for consideration as a Proposed Standard
_______________________________________________
oauth mailing list
oauth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C6015F5215A3Feranhueniversecom_-- From eran@hueniverse.com Sat Apr 11 18:33:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26623A6A48 for ; Sat, 11 Apr 2009 18:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.815, 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 6cpD8QpjMDTJ for ; Sat, 11 Apr 2009 18:33:10 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 085A63A6857 for ; Sat, 11 Apr 2009 18:33:10 -0700 (PDT) Received: (qmail 2685 invoked from network); 12 Apr 2009 01:34:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Apr 2009 01:34:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 11 Apr 2009 18:34:19 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Sat, 11 Apr 2009 18:34:14 -0700 Thread-Topic: I-D Action:draft-eaton-oauth-bodyhash-00.txt Thread-Index: Acm7DnGv6tA2YOH6SH6zLTuQr34gBwAAFe+3 Message-ID: In-Reply-To: <20090412013002.20F923A6B6A@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_C606932815E72eranhueniversecom_" MIME-Version: 1.0 Subject: [oauth] FW: I-D Action:draft-eaton-oauth-bodyhash-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 01:33:10 -0000 --_004_C606932815E72eranhueniversecom_ Content-Type: multipart/alternative; boundary="_000_C606932815E72eranhueniversecom_" --_000_C606932815E72eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a new Core 1.0 extension for consideration by the upcoming WG. EHL ------ Forwarded Message From: Reply-To: Date: Sat, 11 Apr 2009 18:30:02 -0700 To: Subject: I-D Action:draft-eaton-oauth-bodyhash-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : OAuth Request Body Hash Author(s) : B. Eaton, E. Hammer-Lahav Filename : draft-eaton-oauth-bodyhash-00.txt Pages : 11 Date : 2009-04-11 This specification extends the OAuth signature to include integrity checks on HTTP request bodies with content types other than "application/x-www-form-urlencoded". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eaton-oauth-bodyhash-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --_000_C606932815E72eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D Action:draft-eaton-oauth-bodyhash-00.txt This is a new Core 1.0 extension for consideration by the upcoming WG= .

EHL

------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@i= etf.org>
Date: Sat, 11 Apr 2009 18:30:02 -0700
To: <i-d-announce@ietf.org&= gt;
Subject: I-D Action:draft-eaton-oauth-bodyhash-00.txt

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

        Title    &nb= sp;      : OAuth Request Body Hash
        Author(s)    = ;   : B. Eaton, E. Hammer-Lahav
        Filename    =     : draft-eaton-oauth-bodyhash-00.txt
        Pages    &nb= sp;      : 11
        Date    &nbs= p;       : 2009-04-11

This specification extends the OAuth signature to include integrity
checks on HTTP request bodies with content types other than
"application/x-www-form-urlencoded".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eaton-oauth-bodyhash-00.tx= t

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.

 X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2E53A6A65 for ; Wed, 15 Apr 2009 00:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4mtCk5uAjEa for ; Wed, 15 Apr 2009 00:50:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4B7BA3A6A06 for ; Wed, 15 Apr 2009 00:50:00 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2009 07:51:11 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp043) with SMTP; 15 Apr 2009 09:51:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yMwBx2tkyP8C2Hy9/wAleZ7FQ0FGd969ehXR77o MMPsgWytmNyRup From: "Hannes Tschofenig" To: Date: Wed, 15 Apr 2009 10:52:36 +0300 Message-ID: <010e01c9bd9f$26743710$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm65a7RhhoyCCO5TCqyz9HkG7yebQCuGqWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 Cc: oauth@ietf.org Subject: [oauth] FW: OAUTH charter for consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 07:50:04 -0000 Hi Adrian, thanks for your feedback to the charter. I have addressed most of your comments in the updated charter text. A few minor comments inline (search for [hannes]). I will distribute the updated charter text with a subsequent mail. Ciao Hannes ________________________________ From: Lisa Dusseault [mailto:Lisa.Dusseault@messagingarchitects.com] Sent: 11 April, 2009 23:39 To: Blaine Cook; Hannes Tschofenig Subject: Fwd: OAUTH charter for consideration FYI Begin forwarded message: From: Adrian Farrel Date: April 10, 2009 1:08:27 PM PDT To: Lisa Dusseault Cc: iesg@ietf.org Subject: Re: OAUTH charter for consideration Reply-To: Adrian Farrel Hi Lisa, Nits, but mainly that the third person has become confused. Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. "their resources" == the user's resources? "their credentials" == the third party's credentials? "their identity" == the third party's identity? Would be neat to clean that up. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. Even in this example... "thier private pictures" == each user's private pictures? OAuth consists of: * A mechanism for exchanging a user's credentials for a token- secret pair which can be used by a third party to access resources on their behalf. On the user's behalf or on behalf of the third party? * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. s/gap/gaps/ * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted s/backwards/backward/ x2 if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the s/modified/modified,/ backwards compatible profiling activity. The applicability of existing s/backwards/backward/ and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0 . * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html . * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp ec.html . * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. I find it a bit odd to see URLs in the charter like this given that we don't feel very comfortable with URLs in RFCs. [hannes] We put them in there since folks want to have a few examples of possible extensions listed. The name of the extension, however, does not really provide enough useful content and hence we added the pointers. * Alternate token exchange profiles, e.g., draft-dehora-farrell- oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. s/and/, but/ ??? The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). s/i.e./e.g./ ??? [hannes] "i.e." is correct here since 2-legged scenario is the terminology we are using for this type of exchange. Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard Cheers, Adrian --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. From Hannes.Tschofenig@gmx.net Wed Apr 15 00:50:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B863A6986 for ; Wed, 15 Apr 2009 00:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 57ue3VRcfRXX for ; Wed, 15 Apr 2009 00:50:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD98E3A6A69 for ; Wed, 15 Apr 2009 00:50:04 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2009 07:51:16 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp035) with SMTP; 15 Apr 2009 09:51:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+n5fR+Y4mnwYJfSgOgl0NZqmxRiu7Yys262zAoJs 3qj9mKsX40UyI+ From: "Hannes Tschofenig" To: Date: Wed, 15 Apr 2009 10:52:43 +0300 Message-ID: <010f01c9bd9f$290653a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm9nyhoDPiyix7qRrGaHaXXdIB9rQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: Adrian.Farrel@huawei.com Subject: [oauth] OAuth Charter Text (15th April 2009) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 07:50:06 -0000 Open Authentication Protocol (oauth) Last Modified: 2009-04-15 Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to the user's resources, without necessarily revealing the user's credentials, or even the user's identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access the user's private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair, which can be used by a third party to access resources on the user's behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gaps. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backward compatibility with the OAuth 1.0 specification. However, changes that are not backward compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified, but may be dropped as part of the backward compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp ec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora-farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter, but requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenario). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard From hardjono@MIT.EDU Wed Apr 15 06:04:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C823A6B0A for ; Wed, 15 Apr 2009 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkIse-jvvrzu for ; Wed, 15 Apr 2009 06:04:27 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 787B33A6A8B for ; Wed, 15 Apr 2009 06:04:27 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n3FD5ERJ028616; Wed, 15 Apr 2009 09:05:15 -0400 (EDT) Received: from thomasvnf1ekrv (dhcp-18-111-63-76.dyn.mit.edu [18.111.63.76]) (authenticated bits=0) (User authenticated as hardjono@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n3FD5DDP014760 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Apr 2009 09:05:13 -0400 (EDT) From: "Thomas Hardjono" To: "'Hannes Tschofenig'" , References: <010e01c9bd9f$26743710$0201a8c0@nsnintra.net> In-Reply-To: <010e01c9bd9f$26743710$0201a8c0@nsnintra.net> Date: Wed, 15 Apr 2009 09:05:14 -0400 Message-ID: <003201c9bdca$d152d580$73f88080$@edu> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: Acm65a7RhhoyCCO5TCqyz9HkG7yebQCuGqWQAAsM2dA= Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002D_01C9BDA9.49769280" X-Scanned-By: MIMEDefang 2.42 Cc: oauth@ietf.org Subject: Re: [oauth] FW: OAUTH charter for consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:04:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01C9BDA9.49769280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I just had a short question/suggestion. In the past every time a new WG is to be proposed or created, the IETF usually insists that the new WG make-use of existing protocols and/or mechanisms, which already exists in the IETF or other Standards organization. (ie. don't re-invent the wheel). Will this mandate also be observed in this new WG? Thanks. /thomas/ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, April 15, 2009 3:53 AM > To: Adrian.Farrel@huawei.com > Cc: oauth@ietf.org > Subject: [oauth] FW: OAUTH charter for consideration > > Hi Adrian, > > thanks for your feedback to the charter. I have addressed most of your > comments in the updated charter text. A few minor comments inline > (search > for [hannes]). > > I will distribute the updated charter text with a subsequent mail. > > Ciao > Hannes > > > > ________________________________ > > From: Lisa Dusseault > [mailto:Lisa.Dusseault@messagingarchitects.com] > > Sent: 11 April, 2009 23:39 > To: Blaine Cook; Hannes Tschofenig > Subject: Fwd: OAUTH charter for consideration > > > FYI > > > Begin forwarded message: > > > From: Adrian Farrel > Date: April 10, 2009 1:08:27 PM PDT > To: Lisa Dusseault > Cc: iesg@ietf.org > Subject: Re: OAUTH charter for consideration > Reply-To: Adrian Farrel > > Hi Lisa, > > Nits, but mainly that the third person has become confused. > > > > Description of Working Group: > > > > OAuth allows a user to grant a third-party Web site > or application access to their resources, without necessarily revealing > their credentials, or even their identity. > > > > "their resources" == the user's resources? > "their credentials" == the third party's credentials? > "their identity" == the third party's identity? > > Would be neat to clean that up. > > > > For example, a photo-sharing site that supports > OAuth would allow its users to use a third-party printing Web site to > access their private pictures, without gaining full control of the user > account. > > > > Even in this example... > "thier private pictures" == each user's private pictures? > > > > OAuth consists of: > > > * A mechanism for exchanging a user's credentials > for a token- secret pair which can be used by a third party to access > resources on their behalf. > > > > On the user's behalf or on behalf of the third party? > > > > * A mechanism for signing HTTP requests with the > token-secret pair. > > > > The Working Group will produce one or more documents > suitable for consideration as Proposed Standard that will: > > > * Improve the terminology used. > > > * Embody good security practice, or document gaps > in its capabilities, and propose a path forward for addressing the gap. > > > > s/gap/gaps/ > > > > * Promote interoperability. > > > * Provide guidelines for extensibility. > > > > This specifically means that as a starting point for > the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is > a > copy of the original OAuth specification in IETF draft format, is used > and > the available extension points are going to be utilized. In completing > its > work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to > retain backwards compatibility with the OAuth 1.0 specification. > However, > changes that are not backwards compatible might be accepted > > > > s/backwards/backward/ x2 > > > > if the group determines that the changes are > required to meet the group's technical objectives and the group clearly > documents the reasons for making them. > > > > Furthermore, OAuth 1.0 defines three signature > methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- > SHA1. > The group will work on new signature methods and will describe the > environments where new security requirements justify their usage. > Existing > signature methods will not be modified but may be dropped as part of > the > > > > s/modified/modified,/ > > > > backwards compatible profiling activity. The > applicability of existing > > > > s/backwards/backward/ > > > > and new signature methods to protocols other than > HTTP will be investigated. > > > > The Working Group should consider: > > > * Implementer experience. > > > * The end-user experience, including > internationalization. > > > * Existing uses of OAuth. > > > * Ability to achieve broad implementation. > > > * Ability to address broader use cases than may be > contemplated by the original authors. > > > > After delivering OAuth 1.1, the Working Group may > consider defining additional functions and/or extensions, for example > (but > not limited > > > to): > > > * Discovery of OAuth configuration, e.g., > http://oauth.net/discovery/1.0 . > > > * Comprehensive message integrity, e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm > l . > > > * Recommendations regarding the structure of the > token. > > > * Localization, e.g., > > > > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ > 2/sp > ec.html . > > > * Session-oriented tokens, e.g., > > > > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. > > > > I find it a bit odd to see URLs in the charter like this > given that we don't feel very comfortable with URLs in RFCs. > > > [hannes] We put them in there since folks want to have a few examples of > possible extensions listed. The name of the extension, however, does not > really provide enough useful content and hence we added the pointers. > > > > * Alternate token exchange profiles, e.g., > draft-dehora-farrell- oauth-accesstoken-creds-00. > > > > The work on extensions is within the scope of the > working group charter and requires consensus within the group to add > new > milestones. > > > > s/and/, but/ ??? > > > > The Working Group will also define a generally > applicable HTTP authentication mechanism (i.e., browser-based "2-leg" > scenerio). > > > > s/i.e./e.g./ ??? > > > [hannes] "i.e." is correct here since 2-legged scenario is the > terminology > we are using for this type of exchange. > > > Goals and Milestones: > > > > Apr 2009 Submit 'OAuth: HTTP Authorization > Delegation Protocol' as working group item > > > (draft-hammer-oauth will be used as a > starting point for further work.) > > > Jul 2009 Submit a document as a working group > item providing the functionality of the 2-legged HTTP authentication > mechanism > > > Jul 2009 Start of discussion about OAuth > extensions the group should work on > > > Oct 2009 Start Working Group Last Call on 'OAuth: > HTTP Authorization Delegation Protocol' > > > Nov 2009 Submit 'OAuth: HTTP Authorization > Delegation Protocol' to the IESG for consideration as a Proposed > Standard > > > Nov 2009 Start Working Group Last Call on the > 2-legged HTTP authentication mechanism document > > > Nov 2009 Prepare milestone update to start new > work within the scope of the charter > > > Dec 2009 Submit 2-legged HTTP authentication > mechanism document to the IESG for consideration as a Proposed Standard > > > > Cheers, > Adrian > > > > --- Scanned by M+ Guardian Messaging Firewall --- Messaging > Architects sponsors The Spamhaus Project. > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_002D_01C9BDA9.49769280 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2zCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTGMIIDrqADAgECAhB9eEvuJn8dJd9a0XpZB2odMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkwMzA2MDAw MDAwWhcNMTAwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0GCSqGSIb3DQEJARYQaGFy ZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtMQMYVUaf9hf4paIPmIi 2MQtsJ1OXqzHTaGGrFcapR2DypnEylOwu8ED05xBQCN6tRhqP09/Z2wuYbhIDLlukHlbW5fbVlyM jtUGv1XgylCijK5NC31IlWBi2XGfJxqVFS7T1yF4LhfiuRX4NW7UAW06vWar3qDwymIR86kuSX8C AwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0 YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOC AQEAW9PkC8JHUEASjQMBtXPoEmiNLc1kFptdd+q1yfXTy4uCjxyqODT52yaC/mM+WQDCUpsjTMKz zUU19J5z7cElBQEIAze7ClxD6guUXUJuQbtIhce9Kl8aqbmwIrYWv/6MGuUV+Ofi2V3ja79DfHHC LKEanzzUFT/b9WNHlaWM6R+fFkuNXGJ+Hj3/kgBOEiH6EHsfbhCUNOgveoGHYRqOf/2vjPqzcvv8 WiYmtC1yFhD8JRzqK2oGSd8NrMOdKJKqmvodQzGrV7M5G2eozsobJlPeIcNHTPKudH/5n8jWdUIO 7RIIpYAAYKNsVwiFaQORI9MBOGotFbcQcDOZyUwhrzCCBMwwggQ1oAMCAQICEByunWua9OYvIoqj 2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdH R0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhe jVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyr zROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOCAYQwggGAMBIGA1UdEwEB /wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYw LgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDMtMjA0OC0xNTUwHQYDVR0OBBYE FBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0GCSqGSIb3DQEBBQUAA4GBALEv2Zbh kqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Yo9K/HOzWGZ9KTUP4yru+E4BJBd0h czNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqSKTw6rlTaphJRsY/IytNHeObbpR6H BuPRFMDCIfa6MYIEczCCBG8CAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTAJBgUrDgMCGgUAoIIC1jAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUxMzA1MTNaMCMGCSqG SIb3DQEJBDEWBBSxeBfrMOqrVHMWFuUmagIVvnltKTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhB9eEvuJn8dJd9a0XpZB2od MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTANBgkqhkiG9w0BAQEFAASBgA8G /W3+eNmU+9Pdzl0Y1yAcPqT3eBm2NPLvn6EmxIFa+xyWfGVZonqoXkngEFEEJQZaIUox97tDvBhC cvF9ytQTlBliEhleTBsP+9aRx28GhRb0nKIeA9wMhDWMm7m2CpAXUZ9miRTmgunU93Gh4haSvS9G szVUVx/Bz4v1tBmLAAAAAAAA ------=_NextPart_000_002D_01C9BDA9.49769280-- From hannes.tschofenig@nsn.com Wed Apr 15 06:14:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F077F28C17F for ; Wed, 15 Apr 2009 06:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.541 X-Spam-Level: X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[AWL=1.058, 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 LjR6ht8wqQWC for ; Wed, 15 Apr 2009 06:14:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4409828C150 for ; Wed, 15 Apr 2009 06:14:38 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3FDFWr3028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Apr 2009 15:15:32 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3FDFWPp023088; Wed, 15 Apr 2009 15:15:32 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 15:15:31 +0200 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: Wed, 15 Apr 2009 16:16:58 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501448D52@FIESEXC015.nsn-intra.net> In-Reply-To: <003201c9bdca$d152d580$73f88080$@edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] FW: OAUTH charter for consideration Thread-Index: Acm65a7RhhoyCCO5TCqyz9HkG7yebQCuGqWQAAsM2dAAAF6pMA== References: <010e01c9bd9f$26743710$0201a8c0@nsnintra.net> <003201c9bdca$d152d580$73f88080$@edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Thomas Hardjono" , "Hannes Tschofenig" , X-OriginalArrivalTime: 15 Apr 2009 13:15:31.0965 (UTC) FILETIME=[41151AD0:01C9BDCC] Cc: oauth@ietf.org Subject: Re: [oauth] FW: OAUTH charter for consideration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:14:41 -0000 Hi Thomas,=20 >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of ext Thomas Hardjono >Sent: 15 April, 2009 16:05 >To: 'Hannes Tschofenig'; Adrian.Farrel@huawei.com >Cc: oauth@ietf.org >Subject: Re: [oauth] FW: OAUTH charter for consideration > >Hi, > >I just had a short question/suggestion. In the past every time=20 >a new WG is to be proposed or created, the IETF usually=20 >insists that the new WG make-use of existing protocols and/or=20 >mechanisms, which already exists in the IETF or other=20 >Standards organization. (ie. don't re-invent the wheel). We re-use something that is already out there and try to improve security (and other things). The stuff that is being re-used is the OAuth protocol, see http://oauth.net/ (with code available here http://oauth.net/code).=20 Ciao Hannes=20 > >Will this mandate also be observed in this new WG? > >Thanks. > >/thomas/ > > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf=20 >> Of Hannes Tschofenig >> Sent: Wednesday, April 15, 2009 3:53 AM >> To: Adrian.Farrel@huawei.com >> Cc: oauth@ietf.org >> Subject: [oauth] FW: OAUTH charter for consideration >>=20 >> Hi Adrian, >>=20 >> thanks for your feedback to the charter. I have addressed=20 >most of your=20 >> comments in the updated charter text. A few minor comments inline=20 >> (search for [hannes]). >>=20 >> I will distribute the updated charter text with a subsequent mail. >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> From: Lisa Dusseault >> [mailto:Lisa.Dusseault@messagingarchitects.com] >>=20 >> Sent: 11 April, 2009 23:39 >> To: Blaine Cook; Hannes Tschofenig >> Subject: Fwd: OAUTH charter for consideration >>=20 >>=20 >> FYI >>=20 >>=20 >> Begin forwarded message: >>=20 >>=20 >> From: Adrian Farrel >> Date: April 10, 2009 1:08:27 PM PDT >> To: Lisa Dusseault=20 > >> Cc: iesg@ietf.org >> Subject: Re: OAUTH charter for consideration >> Reply-To: Adrian Farrel >>=20 >> Hi Lisa, >>=20 >> Nits, but mainly that the third person has=20 >become confused. >>=20 >>=20 >>=20 >> Description of Working Group: >>=20 >>=20 >>=20 >> OAuth allows a user to grant a=20 >third-party Web site or application =20 >> access to their resources, without necessarily revealing their =20 >> credentials, or even their identity. >>=20 >>=20 >>=20 >> "their resources" =3D=3D the user's resources? >> "their credentials" =3D=3D the third party's credentials? >> "their identity" =3D=3D the third party's identity? >>=20 >> Would be neat to clean that up. >>=20 >>=20 >>=20 >> For example, a photo-sharing site that=20 >supports OAuth would allow=20 >> its users to use a third-party printing Web site to access their=20 >> private pictures, without gaining full control of the user account. >>=20 >>=20 >>=20 >> Even in this example... >> "thier private pictures" =3D=3D each user's private=20 >pictures? >>=20 >>=20 >>=20 >> OAuth consists of: >>=20 >>=20 >> * A mechanism for exchanging a user's=20 >credentials for a token-=20 >> secret pair which can be used by a third party to access=20 >resources on =20 >> their behalf. >>=20 >>=20 >>=20 >> On the user's behalf or on behalf of the third party? >>=20 >>=20 >>=20 >> * A mechanism for signing HTTP=20 >requests with the token-secret=20 >> pair. >>=20 >>=20 >>=20 >> The Working Group will produce one or=20 >more documents suitable for=20 >> consideration as Proposed Standard that will: >>=20 >>=20 >> * Improve the terminology used. >>=20 >>=20 >> * Embody good security practice, or=20 >document gaps in its =20 >> capabilities, and propose a path forward for addressing the gap. >>=20 >>=20 >>=20 >> s/gap/gaps/ >>=20 >>=20 >>=20 >> * Promote interoperability. >>=20 >>=20 >> * Provide guidelines for extensibility. >>=20 >>=20 >>=20 >> This specifically means that as a=20 >starting point for the working=20 >> group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is=20 >a copy of=20 >> the original OAuth specification in IETF draft format, is=20 >used and the=20 >> available extension points are going to be utilized. In=20 >completing its=20 >> work to profile OAuth 1.0 to become OAuth 1.1, the group=20 >will strive =20 >> to retain backwards compatibility with the OAuth 1.0 specification. >> However, >> changes that are not backwards compatible might be accepted >>=20 >>=20 >>=20 >> s/backwards/backward/ x2 >>=20 >>=20 >>=20 >> if the group determines that the=20 >changes are required to meet the =20 >> group's technical objectives and the group clearly documents the =20 >> reasons for making them. >>=20 >>=20 >>=20 >> Furthermore, OAuth 1.0 defines three=20 >signature methods used to=20 >> protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. >> The group will work on new signature methods and will describe the=20 >> environments where new security requirements justify their usage. >> Existing >> signature methods will not be modified but may be dropped=20 >as part of=20 >> the >>=20 >>=20 >>=20 >> s/modified/modified,/ >>=20 >>=20 >>=20 >> backwards compatible profiling=20 >activity. The applicability of=20 >> existing >>=20 >>=20 >>=20 >> s/backwards/backward/ >>=20 >>=20 >>=20 >> and new signature methods to protocols=20 >other than HTTP will be=20 >> investigated. >>=20 >>=20 >>=20 >> The Working Group should consider: >>=20 >>=20 >> * Implementer experience. >>=20 >>=20 >> * The end-user experience, including=20 >internationalization. >>=20 >>=20 >> * Existing uses of OAuth. >>=20 >>=20 >> * Ability to achieve broad implementation. >>=20 >>=20 >> * Ability to address broader use cases=20 >than may be contemplated by =20 >> the original authors. >>=20 >>=20 >>=20 >> After delivering OAuth 1.1, the Working=20 >Group may consider defining=20 >> additional functions and/or extensions, for example (but not limited >>=20 >>=20 >> to): >>=20 >>=20 >> * Discovery of OAuth configuration, e.g., >> http://oauth.net/discovery/1.0 . >>=20 >>=20 >> * Comprehensive message integrity, e.g., >>=20 >http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1 >/spec.htm >> l . >>=20 >>=20 >> * Recommendations regarding the structure of the >> token. >>=20 >>=20 >> * Localization, e.g., >>=20 >>=20 >>=20 >>=20 >http://oauth.googlecode.com/svn/spec/ext/language_preference/1. >0/drafts/ >> 2/sp >> ec.html . >>=20 >>=20 >> * Session-oriented tokens, e.g., >>=20 >>=20 >>=20 >>=20 >http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/s >pec.html. >>=20 >>=20 >>=20 >> I find it a bit odd to see URLs in the charter like this >> given that we don't feel very comfortable with URLs in RFCs. >>=20 >>=20 >> [hannes] We put them in there since folks want to have a few=20 >examples of >> possible extensions listed. The name of the extension,=20 >however, does not >> really provide enough useful content and hence we added the pointers. >>=20 >>=20 >>=20 >> * Alternate token exchange profiles, e.g., >> draft-dehora-farrell- oauth-accesstoken-creds-00. >>=20 >>=20 >>=20 >> The work on extensions is within the=20 >scope of the >> working group charter and requires consensus within the group to add >> new >> milestones. >>=20 >>=20 >>=20 >> s/and/, but/ ??? >>=20 >>=20 >>=20 >> The Working Group will also define a generally >> applicable HTTP authentication mechanism (i.e., browser-based "2-leg" >> scenerio). >>=20 >>=20 >>=20 >> s/i.e./e.g./ ??? >>=20 >>=20 >> [hannes] "i.e." is correct here since 2-legged scenario is the >> terminology >> we are using for this type of exchange. >>=20 >>=20 >> Goals and Milestones: >>=20 >>=20 >>=20 >> Apr 2009 Submit 'OAuth: HTTP Authorization >> Delegation Protocol' as working group item >>=20 >>=20 >> (draft-hammer-oauth will be used as a >> starting point for further work.) >>=20 >>=20 >> Jul 2009 Submit a document as a working group >> item providing the functionality of the 2-legged HTTP authentication >> mechanism >>=20 >>=20 >> Jul 2009 Start of discussion about OAuth >> extensions the group should work on >>=20 >>=20 >> Oct 2009 Start Working Group Last=20 >Call on 'OAuth: >> HTTP Authorization Delegation Protocol' >>=20 >>=20 >> Nov 2009 Submit 'OAuth: HTTP Authorization >> Delegation Protocol' to the IESG for consideration as a Proposed >> Standard >>=20 >>=20 >> Nov 2009 Start Working Group Last Call on the >> 2-legged HTTP authentication mechanism document >>=20 >>=20 >> Nov 2009 Prepare milestone update to=20 >start new >> work within the scope of the charter >>=20 >>=20 >> Dec 2009 Submit 2-legged HTTP authentication >> mechanism document to the IESG for consideration as a=20 >Proposed Standard >>=20 >>=20 >>=20 >> Cheers, >> Adrian >>=20 >>=20 >>=20 >> --- Scanned by M+ Guardian Messaging Firewall --- Messaging >> Architects sponsors The Spamhaus Project. >>=20 >>=20 >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From rbarnes@bbn.com Wed Apr 15 07:27:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73A43A6979 for ; Wed, 15 Apr 2009 07:27:53 -0700 (PDT) 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 paPrPM5iTGes for ; Wed, 15 Apr 2009 07:27:53 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E903C28C1C4 for ; Wed, 15 Apr 2009 07:27:52 -0700 (PDT) Received: from dhcp89-089-090.bbn.com ([128.89.89.90] helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Lu66o-000362-Ai; Wed, 15 Apr 2009 10:29:02 -0400 Message-ID: <49E5EF2D.20308@bbn.com> Date: Wed, 15 Apr 2009 10:29:01 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hannes Tschofenig , oauth@ietf.org References: <010f01c9bd9f$290653a0$0201a8c0@nsnintra.net> In-Reply-To: <010f01c9bd9f$290653a0$0201a8c0@nsnintra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [oauth] OAuth Charter Text (15th April 2009) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:27:54 -0000 Generally seems in pretty good shape. Some comments below. --Richard > OAuth allows a user to grant a third-party Web site or application > access to the user's resources, without necessarily revealing the > user's credentials, or even the user's identity. ... Which credentials/identity, and to whom? Also, why not align terminology with the draft? Suggested text: " OAuth allows a resource owner to grant a "client" Web site or application access to resources stored at another "server" Web site. OAuth enables this access without requiring the user to reveal to the client site either the identity or credentials used with the server site. " > OAuth consists of: * A mechanism for exchanging a user's credentials > for a token-secret pair, which can be used by a third party to access > resources on the user's behalf. * A mechanism for signing HTTP > requests with the token-secret pair. I would frame this slightly differently: " OAuth consists of: * A mechanism for carrying credentials in HTTP requests and responses * A mechanism for signing an HTTP request URI and request parameters with these credentials * A framework for using these mechanisms to delegate authentication and authorization for access to HTTP resources " (These corresponding roughly to sections 3.4, 3.3, and 4 in draft-hammer-oauth) > The Working Group will also define a generally applicable HTTP > authentication mechanism (i.e., browser-based "2-leg" scenario). Part of this goal should also be to define the applicability and trade-offs of this mechanism vis à vis the current HTTP authentication mechanisms, especially Digest. (Also, I don't find the term 2-leg especially helpful.) > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item (draft-hammer-oauth will be used as a starting > point for further work.) > Jul 2009 Submit a document as a working > group item providing the functionality of the 2-legged HTTP > authentication mechanism > Jul 2009 Start of discussion about OAuth > extensions the group should work on > Oct 2009 Start Working Group > Last Call on 'OAuth: HTTP Authorization Delegation Protocol' > Nov 2009 > Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG > for consideration as a Proposed Standard Nov 2009 Start Working > Group Last Call on the 2-legged HTTP authentication mechanism > document Nov 2009 Prepare milestone update to start new work > within the scope of the charter Dec 2009 Submit 2-legged HTTP > authentication mechanism document to the IESG for consideration as a > Proposed Standard The milestones here seem really sketchy ("Start a discussion?"). It seems like this should be the place to list concrete deliverables that you want to acheive. It looks like there's only really two of these right now: 1. OAuth core 2. 2-legged I don't think there's a need for vague language about extensions in the milestones; just add milestones as the need for extensions becomes clear. From Hannes.Tschofenig@gmx.net Wed Apr 15 08:51:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490ED3A697A for ; Wed, 15 Apr 2009 08:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 7VB9mIi2POM7 for ; Wed, 15 Apr 2009 08:51:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD8253A6936 for ; Wed, 15 Apr 2009 08:51:46 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2009 15:52:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp068) with SMTP; 15 Apr 2009 17:52:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+w7DAKTIewtAxQ6SOZtlElfUfJbr6ocCgzyTulZ2 eBXQlpf4XKnsen From: "Hannes Tschofenig" To: "'Richard Barnes'" , References: <010f01c9bd9f$290653a0$0201a8c0@nsnintra.net> <49E5EF2D.20308@bbn.com> Date: Wed, 15 Apr 2009 18:54:23 +0300 Message-ID: <000001c9bde2$733dd360$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm91onX3ksTarpdSHSQ69lblEj4cwAAx5lQ In-Reply-To: <49E5EF2D.20308@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: Re: [oauth] OAuth Charter Text (15th April 2009) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:51:48 -0000 Hi Richard,=20 we could align the charter with the terminology of the latest OAuth I-D. There is no guarantee that the terminology does not change again. I = thought that the current description is good enough to describe the basic idea = what the group is about. If you want to know more then you will have to read through the latest drafts anyway.=20 More inline: >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of Richard Barnes >Sent: 15 April, 2009 17:29 >To: Hannes Tschofenig; oauth@ietf.org >Subject: Re: [oauth] OAuth Charter Text (15th April 2009) > >Generally seems in pretty good shape. Some comments below. >--Richard > > > >> OAuth allows a user to grant a third-party Web site or application=20 >> access to the user's resources, without necessarily revealing the=20 >> user's credentials, or even the user's identity. ... > >Which credentials/identity, and to whom? Also, why not align=20 >terminology with the draft? Suggested text: >" >OAuth allows a resource owner to grant a "client" Web site or=20 >application access to resources stored at another "server" Web site.=20 >OAuth enables this access without requiring the user to reveal=20 >to the client site either the identity or credentials used=20 >with the server site. >" > > >> OAuth consists of: * A mechanism for exchanging a user's credentials=20 >> for a token-secret pair, which can be used by a third party=20 >to access=20 >> resources on the user's behalf. * A mechanism for signing HTTP=20 >> requests with the token-secret pair. > >I would frame this slightly differently: >" >OAuth consists of: > * A mechanism for carrying credentials in HTTP requests and responses > * A mechanism for signing an HTTP request URI and request=20 >parameters with these credentials > * A framework for using these mechanisms to delegate=20 >authentication and authorization for access to HTTP resources " >(These corresponding roughly to sections 3.4, 3.3, and 4 in >draft-hammer-oauth) > > >> The Working Group will also define a generally applicable HTTP=20 >> authentication mechanism (i.e., browser-based "2-leg" scenario). > >Part of this goal should also be to define the applicability=20 >and trade-offs of this mechanism vis =E0 vis the current HTTP=20 >authentication mechanisms, especially Digest. (Also, I don't=20 >find the term 2-leg especially helpful.) I just used the term that other folks came up with.=20 > > >> Goals and Milestones: >>=20 >> Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as >> working group item (draft-hammer-oauth will be used as a starting=20 >> point for further work.) >> Jul 2009 Submit a document as a working >> group item providing the functionality of the 2-legged HTTP=20 >> authentication mechanism >> Jul 2009 Start of discussion about OAuth >> extensions the group should work on=20 >> Oct 2009 Start Working Group >> Last Call on 'OAuth: HTTP Authorization Delegation Protocol' >> Nov 2009 >> Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG >> for consideration as a Proposed Standard Nov 2009 Start Working >> Group Last Call on the 2-legged HTTP authentication mechanism >> document Nov 2009 Prepare milestone update to start new work >> within the scope of the charter Dec 2009 Submit 2-legged HTTP >> authentication mechanism document to the IESG for consideration as a=20 >> Proposed Standard > >The milestones here seem really sketchy ("Start a=20 >discussion?"). It seems like this should be the place to list=20 >concrete deliverables that you want to acheive. It looks like=20 >there's only really two of these right now: >1. OAuth core >2. 2-legged =09 >I don't think there's a need for vague language about=20 >extensions in the milestones; just add milestones as the need=20 >for extensions becomes clear. Theoretically we can put there whatever we think is useful.=20 Most of the milestones are pretty precise and easy to measure.=20 I also wanted to provide some indications on when to start discussions = about extensions into the charter itself to have some sort of timeplan in the group. In fact, the current GEOPRIV milestones list similar items :-) Ciao Hannes >_______________________________________________ >oauth mailing list >oauth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 23 22:57:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3333A69FA for ; Thu, 23 Apr 2009 22:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=-0.758, 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 hpvTV0OYT33I for ; Thu, 23 Apr 2009 22:57:21 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 92B473A69FF for ; Thu, 23 Apr 2009 22:57:21 -0700 (PDT) Received: (qmail 17790 invoked from network); 24 Apr 2009 05:58:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Apr 2009 05:58:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 23 Apr 2009 22:58:40 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 23 Apr 2009 22:58:39 -0700 Thread-Topic: OAuth Security Advisory Thread-Index: AcnEobbo/uq73bnWRu6pVncF5s3CRw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72342509CCD545@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 9QA= BVat Dp/H D73Y EIKh E0GZ FlPv GnF0 G3AT Hp8j HuYC IVW/ IbW/ JhAp KlPn LOBt; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D2C15CD7-EEDF-471E-BC70-31F8CDA6595C}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Fri, 24 Apr 2009 05:58:39 GMT;TwBBAHUAdABoACAAUwBlAGMAdQByAGkAdAB5ACAAQQBkAHYAaQBzAG8AcgB5AA== x-cr-puzzleid: {D2C15CD7-EEDF-471E-BC70-31F8CDA6595C} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 05:57:22 -0000 Over the past few days a security threat has been identified in the OAuth C= ore 1.0 protocol. While this is not an IETF protocol, it is being chartered= for standardization within the IETF. Before the security threat has been d= isclosed, the community has been working closely with many vendors to coord= inate and help them mitigate the risks involved. The attack cannot be solve= d without a protocol change. The OAuth Security Advisory 2009.1 was posted on the OAuth site: http://oauth.net/advisories/2009-1 For more information on the attack: http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-f= ixation-attack.html I serve as the community coordinator for this issue. Please feel to contact= me in public or private with any concerns. EHL From wwwrun@core3.amsl.com Tue Apr 28 11:05:43 2009 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 733833A7123; Tue, 28 Apr 2009 11:05:43 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090428180543.733833A7123@core3.amsl.com> Date: Tue, 28 Apr 2009 11:05:43 -0700 (PDT) Cc: oauth@ietf.org Subject: [oauth] WG Review: Open Authentication Protocol (oauth) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:05:43 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 5, 2009. Open Authentication Protocol (oauth) ------------------------------------- Last Modified: 2009-04-06 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources ontheir behalf. * A mechanism for signing HTTP requests with the token- secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard From jtrentadams@gmail.com Wed Apr 29 10:57:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9973A68F2 for ; Wed, 29 Apr 2009 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 p4XMloFk24II for ; Wed, 29 Apr 2009 10:57:42 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 299153A67ED for ; Wed, 29 Apr 2009 10:57:42 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1426791yxb.49 for ; Wed, 29 Apr 2009 10:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=725mldrp3y6JOKsYmZuv8HDBRuAWK5tGn+FMXfNn84E=; b=TWUvX+x7bx4tdifntPmlWJaUCPGWCaC+u2t/+r/8hLstBckqdIN4lwPfpeQtFU6Uux Hh0PjWtsuH4nmAss8bThjV0E76QEo0JgTHbvdsRDjUgtWCJzKEIFeb4ras9Hb7L17uOM GOOBdLIOmlWsvKciA9BwioHNTsJNB7FhD5dLE= 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:x-enigmail-version:content-type :content-transfer-encoding; b=c0AEUhH5VgmJg4pYSOjerGuAuyUieu0HxpfBa5KsFmePYq9Knc0WgHPbxCa2Xcxsoa QlV8YJuw9NAPF2Ksb+PMDWfCKJTBF55J9tPEQXnkIp07OLp7ra3BlPStn2IxOjXr4KkX Cgxyn5E/oT4Afql4OEhLI5aK8KeNiZZy5Mqc8= Received: by 10.90.72.3 with SMTP id u3mr472624aga.6.1241027944238; Wed, 29 Apr 2009 10:59:04 -0700 (PDT) Received: from jtrentadams-isoc.local (c-24-91-114-64.hsd1.ma.comcast.net [24.91.114.64]) by mx.google.com with ESMTPS id 32sm2178235aga.44.2009.04.29.10.59.03 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 10:59:03 -0700 (PDT) Message-ID: <49F89567.60407@gmail.com> Date: Wed, 29 Apr 2009 13:59:03 -0400 From: "J. Trent Adams" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72342509CCD545@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72342509CCD545@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:57:44 -0000 Eran - I haven't seen much discussion of proposed protocol changes addressing the recent security advisory on the IETF list. Do you anticipate that the work being done on the Google list will eventually migrate over for review and discussion? In related news, has anyone notified the IETF Security Directorate, yet? It might be a great way to raise the visibility of the issue to the kind of folks you were hoping to attract to the work. - Trent Eran Hammer-Lahav wrote: > Over the past few days a security threat has been identified in the OAuth Core 1.0 protocol. While this is not an IETF protocol, it is being chartered for standardization within the IETF. Before the security threat has been disclosed, the community has been working closely with many vendors to coordinate and help them mitigate the risks involved. The attack cannot be solved without a protocol change. > > The OAuth Security Advisory 2009.1 was posted on the OAuth site: > > http://oauth.net/advisories/2009-1 > > For more information on the attack: > > http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html > > I serve as the community coordinator for this issue. Please feel to contact me in public or private with any concerns. > > EHL > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From eran@hueniverse.com Wed Apr 29 15:02:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A371928C2EE for ; Wed, 29 Apr 2009 15:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-0.734, 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 zEGRmPV7SBo6 for ; Wed, 29 Apr 2009 15:02:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5B70828C312 for ; Wed, 29 Apr 2009 15:02:23 -0700 (PDT) Received: (qmail 17014 invoked from network); 29 Apr 2009 22:03:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Apr 2009 22:03:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 29 Apr 2009 15:03:44 -0700 From: Eran Hammer-Lahav To: "J. Trent Adams" Date: Wed, 29 Apr 2009 15:03:42 -0700 Thread-Topic: [oauth] OAuth Security Advisory Thread-Index: AcnI9C9RFSxeoV6JRZu4d4N+5TyS6wAIixLV Message-ID: In-Reply-To: <49F89567.60407@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C61E1CCE17503eranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:02:56 -0000 --_000_C61E1CCE17503eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This list (IETF) has no "jurisdiction" over the Core 1.0 version which is b= eing addressed on the OAuth public list. Once a solution is proposed, it wi= ll be reflected in the draft-hammer-oauth I-D and will be part of the WG di= scussions. I did notify the security area but since I am not on their list, not sure i= f they discussed it or not. EHL On 4/29/09 10:59 AM, "J. Trent Adams" wrote: Eran - I haven't seen much discussion of proposed protocol changes addressing the recent security advisory on the IETF list. Do you anticipate that the work being done on the Google list will eventually migrate over for review and discussion? In related news, has anyone notified the IETF Security Directorate, yet? It might be a great way to raise the visibility of the issue to the kind of folks you were hoping to attract to the work. - Trent Eran Hammer-Lahav wrote: > Over the past few days a security threat has been identified in the OAuth= Core 1.0 protocol. While this is not an IETF protocol, it is being charter= ed for standardization within the IETF. Before the security threat has been= disclosed, the community has been working closely with many vendors to coo= rdinate and help them mitigate the risks involved. The attack cannot be sol= ved without a protocol change. > > The OAuth Security Advisory 2009.1 was posted on the OAuth site: > > http://oauth.net/advisories/2009-1 > > For more information on the attack: > > http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session= -fixation-attack.html > > I serve as the community coordinator for this issue. Please feel to conta= ct me in public or private with any concerns. > > EHL > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- J. Trent Adams =3Djtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --_000_C61E1CCE17503eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAuth Security Advisory This list (IETF) has no “jurisdiction” over the Core 1.0 = version which is being addressed on the OAuth public list. Once a solution = is proposed, it will be reflected in the draft-hammer-oauth I-D and will be= part of the WG discussions.

I did notify the security area but since I am not on their list, not sure i= f they discussed it or not.

EHL


On 4/29/09 10:59 AM, "J. Trent Adams" <jtrentadams@gmail.com> wrote:

Eran -

I haven't seen much discussion of proposed protocol changes addressing
the recent security advisory on the IETF list.  Do you anticipate that=
the work being done on the Google list will eventually migrate over for
review and discussion?

In related news, has anyone notified the IETF Security Directorate,
yet?  It might be a great way to raise the visibility of the issue to<= BR> the kind of folks you were hoping to attract to the work.

- Trent


Eran Hammer-Lahav wrote:
> Over the past few days a security threat has been identified in the OA= uth Core 1.0 protocol. While this is not an IETF protocol, it is being char= tered for standardization within the IETF. Before the security threat has b= een disclosed, the community has been working closely with many vendors to = coordinate and help them mitigate the risks involved. The attack cannot be = solved without a protocol change.
>
> The OAuth Security Advisory 2009.1 was posted on the OAuth site:
>
> http://oauth.net/adviso= ries/2009-1
>
> For more information on the attack:
>
> http://www.hueniverse.com/hueniverse/2= 009/04/explaining-the-oauth-session-fixation-attack.html
>
> I serve as the community coordinator for this issue. Please feel to co= ntact me in public or private with any concerns.
>
> EHL
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>  

--
J. Trent Adams
=3Djtrentadams

Profile: http://www.medi= aslate.org/jtrentadams/
LinkedIN: http://www.lin= kedin.com/in/jtrentadams
Twitter: http://twitter.com/jtre= ntadams


--_000_C61E1CCE17503eranhueniversecom_-- From nfloyd@fellowshiptech.com Wed Apr 29 19:03:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E5A3A6F03 for ; Wed, 29 Apr 2009 19:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vfXiCtmRDch for ; Wed, 29 Apr 2009 19:03:02 -0700 (PDT) Received: from mail.fellowshiptech.com (mail.fellowshiptech.com [64.244.145.226]) by core3.amsl.com (Postfix) with ESMTP id B01553A6B81 for ; Wed, 29 Apr 2009 19:03:02 -0700 (PDT) Received: from ftmsx01.FT.CORP.LOCAL ([192.168.10.99]) by ftmsx01.FT.CORP.LOCAL ([192.168.10.99]) with mapi; Wed, 29 Apr 2009 21:04:23 -0500 From: "Floyd, Nicholas" To: Eran Hammer-Lahav Date: Wed, 29 Apr 2009 21:04:21 -0500 Thread-Topic: OAuth session fixation attack countermeasures Thread-Index: AcnJN/oypbdUvJHMT/GV5zsn5RDdcQ== 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_B0894194C966004786FA36D8AF5CB74B0901E298A8ftmsx01FTCORP_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [oauth] OAuth session fixation attack countermeasures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:03:03 -0000 --_000_B0894194C966004786FA36D8AF5CB74B0901E298A8ftmsx01FTCORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eran: We have implemented the recommended wording from the Nick Floyd - Integration Architect Fellowship Technologies 817 657 9389 | Mobile nfloyd@fellowshiptech.com Col 3:23 --_000_B0894194C966004786FA36D8AF5CB74B0901E298A8ftmsx01FTCORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eran:

 

We have implemented the recommended wording from the <= o:p>

 

 

Nick Flo= yd - Integration Architect

Fellowsh= ip Technologies

817 657 9389 | Mobile

nfloyd@fellowshiptech.com

Col 3= :23

 

 

--_000_B0894194C966004786FA36D8AF5CB74B0901E298A8ftmsx01FTCORP_-- From nfloyd@fellowshiptech.com Wed Apr 29 19:23:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D003A6CAC for ; Wed, 29 Apr 2009 19:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo0n3wIlA+nL for ; Wed, 29 Apr 2009 19:23:09 -0700 (PDT) Received: from mail.fellowshiptech.com (mail.fellowshiptech.com [64.244.145.226]) by core3.amsl.com (Postfix) with ESMTP id 9BE9E3A6B15 for ; Wed, 29 Apr 2009 19:23:09 -0700 (PDT) Received: from ftmsx01.FT.CORP.LOCAL ([192.168.10.99]) by ftmsx01.FT.CORP.LOCAL ([192.168.10.99]) with mapi; Wed, 29 Apr 2009 21:24:32 -0500 From: "Floyd, Nicholas" To: Eran Hammer-Lahav Date: Wed, 29 Apr 2009 21:24:30 -0500 Thread-Topic: OAuth session fixation attack countermeasures Thread-Index: AcnJN/oypbdUvJHMT/GV5zsn5RDdcQAABcjA 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_B0894194C966004786FA36D8AF5CB74B0901E298BEftmsx01FTCORP_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [oauth] OAuth session fixation attack countermeasures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:23:12 -0000 --_000_B0894194C966004786FA36D8AF5CB74B0901E298BEftmsx01FTCORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eran: We have implemented the recommended wording from the security advisory. We= have also come up with another measure after discussions with you and some= internal collaboration. 1. Consumer requests an unauthorized request token --> The service pr= ovider stores the generated token with the consumers domain (obtained from = the request) 2. Consumer requests authorization from the user --> The service prov= ider verifies the consumers request domain with the domain stored with the = token 3. The Consumer requests an Access token using the authorized request= token --> The service provider verifies the consumers request domain with = the domain stored with the token Given: PASS 1. Consumer Host: www.myconsumersite.com - Request an unauthorized request token 2. Service provider verifies and grants unauthorized request token st= oring "myconsumersite" with the token 3. Consumer Host: www.myconsumersite.com - authorization from the user 4. Service provider verifies token and domain: "myconsumersite" 5. User logs in and allows access 6. Service provider sends back the authorized request token 7. Consumer Host: www.myconsumersite.com - Request an access token using the authorized request token 8. Service provider verifies token and domain: "myconsumersite" and p= asses back an access token FAIL 1. Consumer Host: www.myconsumersite.com - Request an unauthorized request token 2. Service provider verifies and grants unauthorized request token st= oring "myconsumersite" with the token 3. Consumer Host: www.notmyconsumersite.com - authorization from the user 4. Service provider verifies token and domain: "notmyconsumersite" w= ith the domain from the token "myconsumersite" 5. Service provider rejects the request and passes back a 400 or 403 The last two legs of OAuth the Service provider will verify the originating= domain and reject the request if the domain or ip do not match what is sto= red with the request token. We know this binds the consumer to have the end to end OAuth implementation= exist on one domain, however, we feel that this would be an effective way = to stop the fixation attack. Any feedback or thoughts on this approach would be appreciated. Nick Floyd - Integration Architect Fellowship Technologies Twitter : @nickfloyd nfloyd@fellowshiptech.com Col 3:23 --_000_B0894194C966004786FA36D8AF5CB74B0901E298BEftmsx01FTCORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eran:

 

We have implemented the recommended wording from the s= ecurity advisory.=A0 We have also come up with another measure after discussions wi= th you and some internal collaboration.

 

1.&n= bsp;      Consumer requests an unauthorized request token =E0 The service provider stores the = generated token with the consumers domain (obtained from the request)

2.&n= bsp;      Consumer requests authorization from the user =E0 The service provider verifies th= e consumers request domain with the domain stored with the token

3.&n= bsp;      The Consumer requests an Access token using the authorized request token =E0 T= he service provider verifies the consumers request domain with the domain stor= ed with the token

 

Given:

PASS

1.&n= bsp;      Consumer Host: www.myconsumersite.com - Request an unauthorized request token

2.&n= bsp;      Service provider verifies and grants unauthorized request token storing “myconsumersite” with the token

3.&n= bsp;      Consumer Host: www.myconsumersite.com - authorization from the user

4.&n= bsp;      Service provider verifies token and domain: “= myconsumersite”

5.&n= bsp;      User logs in and allows access

6.&n= bsp;      Service provider sends back the authorized request token

7.&n= bsp;      Consumer Host: www.myconsumersite.com - Request an access token using the authori= zed request token

8.&n= bsp;      Service provider verifies token and domain: “= myconsumersite” and passes back an access token

 

FAIL

1.&n= bsp;      Consumer Host: www.myconsumersite.com - Request an unauthorized request token

2.&n= bsp;      Service provider verifies and grants unauthorized request token storing “myconsumersite” with the token

3.&n= bsp;      Consumer Host: www.notmyconsumersite.com - authorization from the user

4.&n= bsp;      Service provider verifies token and domain: “= notmyconsumersite” =A0with the domain from the token “myconsumersite”

5.&n= bsp;      Service provider rejects the request and passes bac= k a 400 or 403

 

The last two legs of OAuth the Service provider will v= erify the originating domain and reject the request if the domain or ip do not ma= tch what is stored with the request token.

 

We know this binds the consumer to have the end to end= OAuth implementation exist on one domain, however, we feel that this would be an effective way to stop the fixation attack.

 

Any feedback or thoughts on this approach would be app= reciated.

 =

Nick Flo= yd - Integration Architect

Fellowship Technologies<= span style=3D'font-size:12.0pt;color:#1F497D'>

Twitter : @nickfloyd

nfloyd@fellowsh= iptech.com

Col 3= :23

 =

 

--_000_B0894194C966004786FA36D8AF5CB74B0901E298BEftmsx01FTCORP_-- From rbarnes@bbn.com Wed Apr 29 20:22:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20E83A6DDF for ; Wed, 29 Apr 2009 20:22:03 -0700 (PDT) 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 j+lI5Q0VAccM for ; Wed, 29 Apr 2009 20:22:02 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 85C883A6889 for ; Wed, 29 Apr 2009 20:22:02 -0700 (PDT) Received: from [128.89.254.123] by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LzMrs-0003aE-Dx; Wed, 29 Apr 2009 23:23:24 -0400 Message-ID: <49F919AB.8020603@bbn.com> Date: Wed, 29 Apr 2009 23:23:23 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 03:22:03 -0000 Sure enough, Eran's message showed up on the SAAG list: There hasn't been any discussion of it on that list so far. --Richard Eran Hammer-Lahav wrote: > This list (IETF) has no “jurisdiction” over the Core 1.0 version which > is being addressed on the OAuth public list. Once a solution is > proposed, it will be reflected in the draft-hammer-oauth I-D and will > be part of the WG discussions. > > I did notify the security area but since I am not on their list, not > sure if they discussed it or not. > > EHL > > > On 4/29/09 10:59 AM, "J. Trent Adams" wrote: > > Eran - > > I haven't seen much discussion of proposed protocol changes addressing > the recent security advisory on the IETF list. Do you anticipate that > the work being done on the Google list will eventually migrate > over for > review and discussion? > > In related news, has anyone notified the IETF Security Directorate, > yet? It might be a great way to raise the visibility of the issue to > the kind of folks you were hoping to attract to the work. > > - Trent > > > Eran Hammer-Lahav wrote: > > Over the past few days a security threat has been identified in > the OAuth Core 1.0 protocol. While this is not an IETF protocol, > it is being chartered for standardization within the IETF. Before > the security threat has been disclosed, the community has been > working closely with many vendors to coordinate and help them > mitigate the risks involved. The attack cannot be solved without a > protocol change. > > > > The OAuth Security Advisory 2009.1 was posted on the OAuth site: > > > > http://oauth.net/advisories/2009-1 > > > > For more information on the attack: > > > > http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html > > > > I serve as the community coordinator for this issue. Please feel > to contact me in public or private with any concerns. > > > > EHL > > _______________________________________________ > > oauth mailing list > > oauth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > J. Trent Adams > =jtrentadams > > Profile: http://www.mediaslate.org/jtrentadams/ > LinkedIN: http://www.linkedin.com/in/jtrentadams > Twitter: http://twitter.com/jtrentadams > > > ------------------------------------------------------------------------ > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hardjono@MIT.EDU Thu Apr 30 06:32:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895503A7223 for ; Thu, 30 Apr 2009 06:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1InmQyTZJshD for ; Thu, 30 Apr 2009 06:32:08 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id EBB8D3A6F27 for ; Thu, 30 Apr 2009 06:32:07 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n3UDXQG6012774; Thu, 30 Apr 2009 09:33:27 -0400 (EDT) Received: from thomasvnf1ekrv (dhcp-18-111-56-67.dyn.mit.edu [18.111.56.67]) (authenticated bits=0) (User authenticated as hardjono@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n3UDXPr8000221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 09:33:26 -0400 (EDT) From: "Thomas Hardjono" To: "'Eran Hammer-Lahav'" References: <49F89567.60407@gmail.com> In-Reply-To: Date: Thu, 30 Apr 2009 09:33:26 -0400 Message-ID: <008c01c9c998$3e699a90$bb3ccfb0$@edu> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: AcnI9C9RFSxeoV6JRZu4d4N+5TyS6wAIixLVACAnq9A= Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0084_01C9C976.B6B83820" X-Scanned-By: MIMEDefang 2.42 Cc: oauth@ietf.org Subject: Re: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:32:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0084_01C9C976.B6B83820 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0085_01C9C976.B6B83820" ------=_NextPart_001_0085_01C9C976.B6B83820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eran, I'm now confused about the OAuth specs being done in the IETF versus the one being done outside the IETF (Core 1.0): - If in the future further flaws are found in either Core 1.0 or the IETF draft (or both), what will be the process to fix/reconcile this. Currently it seems that the real work in being done in the Oauth public list, with the fixes being brought into draft-hammer-oauth. (ps. Just a friendly comment: with this approach its going to be difficult to avoid the impression that the new IETF WG will just be rubber-stamping the work done outside the IETF. I hope this will not be the case). - Are there plans to converge the two (or deprecate one), and at which point does the IETF have so-called "jurisdiction". cheers, /thomas/ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, April 29, 2009 6:04 PM To: J. Trent Adams Cc: oauth@ietf.org Subject: Re: [oauth] OAuth Security Advisory This list (IETF) has no "jurisdiction" over the Core 1.0 version which is being addressed on the OAuth public list. Once a solution is proposed, it will be reflected in the draft-hammer-oauth I-D and will be part of the WG discussions. I did notify the security area but since I am not on their list, not sure if they discussed it or not. EHL On 4/29/09 10:59 AM, "J. Trent Adams" wrote: Eran - I haven't seen much discussion of proposed protocol changes addressing the recent security advisory on the IETF list. Do you anticipate that the work being done on the Google list will eventually migrate over for review and discussion? In related news, has anyone notified the IETF Security Directorate, yet? It might be a great way to raise the visibility of the issue to the kind of folks you were hoping to attract to the work. - Trent Eran Hammer-Lahav wrote: > Over the past few days a security threat has been identified in the OAuth Core 1.0 protocol. While this is not an IETF protocol, it is being chartered for standardization within the IETF. Before the security threat has been disclosed, the community has been working closely with many vendors to coordinate and help them mitigate the risks involved. The attack cannot be solved without a protocol change. > > The OAuth Security Advisory 2009.1 was posted on the OAuth site: > > http://oauth.net/advisories/2009-1 > > For more information on the attack: > > http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fi xation-attack.html > > I serve as the community coordinator for this issue. Please feel to contact me in public or private with any concerns. > > EHL > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams ------=_NextPart_001_0085_01C9C976.B6B83820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAuth Security Advisory

Hi Eran,

 

I’m now confused about the OAuth specs being done in the IETF versus the one being done outside the IETF (Core = 1.0):

 

- If in the future further flaws are found in either Core = 1.0 or the IETF draft (or both), what will be the process to fix/reconcile = this. Currently it seems that the real work in being done in the Oauth public list, with the fixes being brought into draft-hammer-oauth.

 

(ps. Just a friendly comment: with this approach its = going to be difficult to avoid the impression that the new IETF WG will just be rubber-stamping the work done outside the IETF. I hope this will not be = the case).

 

- Are there plans to converge the two (or deprecate one), = and at which point does the IETF have so-called = “jurisdiction”.

 

cheers,

 

/thomas/

 

 

 

From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, April = 29, 2009 6:04 PM
To: J. Trent Adams
Cc: oauth@ietf.org
Subject: Re: [oauth] = OAuth Security Advisory

 

This list (IETF) has no “jurisdiction” = over the Core 1.0 version which is being addressed on the OAuth public list. Once a = solution is proposed, it will be reflected in the draft-hammer-oauth I-D and will be = part of the WG discussions.

I did notify the security area but since I am not on their list, not = sure if they discussed it or not.

EHL


On 4/29/09 10:59 AM, "J. Trent Adams" <jtrentadams@gmail.com> = wrote:

Eran -

I haven't seen much discussion of proposed protocol changes = addressing
the recent security advisory on the IETF list.  Do you anticipate = that
the work being done on the Google list will eventually migrate over = for
review and discussion?

In related news, has anyone notified the IETF Security Directorate,
yet?  It might be a great way to raise the visibility of the issue = to
the kind of folks you were hoping to attract to the work.

- Trent


Eran Hammer-Lahav wrote:
> Over the past few days a security threat has been identified in the = OAuth Core 1.0 protocol. While this is not an IETF protocol, it is being = chartered for standardization within the IETF. Before the security threat has been disclosed, the community has been working closely with many vendors to coordinate and help them mitigate the risks involved. The attack cannot = be solved without a protocol change.
>
> The OAuth Security Advisory 2009.1 was posted on the OAuth = site:
>
> http://oauth.net/advisories/2= 009-1
>
> For more information on the attack:
>
> http://www.hueniverse.com/hueniverse/2009/= 04/explaining-the-oauth-session-fixation-attack.html
>
> I serve as the community coordinator for this issue. Please feel to contact me in public or private with any concerns.
>
> EHL
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ietf.org= /mailman/listinfo/oauth
>  

--
J. Trent Adams
=3Djtrentadams

Profile: http://www.mediaslate.org= /jtrentadams/
LinkedIN: http://www.linkedin.com/i= n/jtrentadams
Twitter: http://twitter.com/jtrentadams

------=_NextPart_001_0085_01C9C976.B6B83820-- ------=_NextPart_000_0084_01C9C976.B6B83820 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2zCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTGMIIDrqADAgECAhB9eEvuJn8dJd9a0XpZB2odMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkwMzA2MDAw MDAwWhcNMTAwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0GCSqGSIb3DQEJARYQaGFy ZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtMQMYVUaf9hf4paIPmIi 2MQtsJ1OXqzHTaGGrFcapR2DypnEylOwu8ED05xBQCN6tRhqP09/Z2wuYbhIDLlukHlbW5fbVlyM jtUGv1XgylCijK5NC31IlWBi2XGfJxqVFS7T1yF4LhfiuRX4NW7UAW06vWar3qDwymIR86kuSX8C AwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0 YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOC AQEAW9PkC8JHUEASjQMBtXPoEmiNLc1kFptdd+q1yfXTy4uCjxyqODT52yaC/mM+WQDCUpsjTMKz zUU19J5z7cElBQEIAze7ClxD6guUXUJuQbtIhce9Kl8aqbmwIrYWv/6MGuUV+Ofi2V3ja79DfHHC LKEanzzUFT/b9WNHlaWM6R+fFkuNXGJ+Hj3/kgBOEiH6EHsfbhCUNOgveoGHYRqOf/2vjPqzcvv8 WiYmtC1yFhD8JRzqK2oGSd8NrMOdKJKqmvodQzGrV7M5G2eozsobJlPeIcNHTPKudH/5n8jWdUIO 7RIIpYAAYKNsVwiFaQORI9MBOGotFbcQcDOZyUwhrzCCBMwwggQ1oAMCAQICEByunWua9OYvIoqj 2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdH R0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhe jVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyr zROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOCAYQwggGAMBIGA1UdEwEB /wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYw LgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDMtMjA0OC0xNTUwHQYDVR0OBBYE FBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0GCSqGSIb3DQEBBQUAA4GBALEv2Zbh kqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Yo9K/HOzWGZ9KTUP4yru+E4BJBd0h czNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqSKTw6rlTaphJRsY/IytNHeObbpR6H BuPRFMDCIfa6MYIEczCCBG8CAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTAJBgUrDgMCGgUAoIIC1jAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MzAxMzMzMjZaMCMGCSqG SIb3DQEJBDEWBBRZCJs7XJkLIxpQfQmLIxJXfCj+vjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhB9eEvuJn8dJd9a0XpZB2od MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTANBgkqhkiG9w0BAQEFAASBgK8H G9hbzw47FmqNxhmDsMfLZPGS7weMc9ceZrp7Pf8/wy03itUg4l+A+RknH19mAVsEUG87zCMysZrT /mrj/BydUvQanFeW37ZukQEoeTJKw5XBP5NI2Ash1n2Q5OKH1Q/XxZxUTX0eRJ96ROkVLsUiO8F4 na7S1M4jE+3Fhe2lAAAAAAAA ------=_NextPart_000_0084_01C9C976.B6B83820-- From romeda@gmail.com Thu Apr 30 06:41:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2158828C293 for ; Thu, 30 Apr 2009 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAnUqaR2bgIy for ; Thu, 30 Apr 2009 06:41:44 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id E04F128C360 for ; Thu, 30 Apr 2009 06:41:34 -0700 (PDT) Received: by bwz7 with SMTP id 7so1809522bwz.37 for ; Thu, 30 Apr 2009 06:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kHLbyXobU8n2iEVStqjCjEJdwL9Pn5fxk6LsnEQ5faU=; b=cyf6/Z2ePYKSmV/90ulIkid1HjbHJyIKrURQPLeJFMLPYwCNCXk1KGTiTbtBR6xGbO redISjhAtby/k+nIsNHVGPY7/onpfwFx++4YooKu0GzHL3ORgXVfB8yQX+KR3A89z4fW 06GSJhrNKz84pzbUpCgXfceVEFJDlsuC0qziQ= 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=QlCkpEO9ai0DIzs4UbrMo7LhEj2fQZiUSxEz80tEhoWNBhu+O21Fp6N2LZMdtHXnDQ aZlKzE9erUZhVF0f3veZdK6i4JytrIOTrbdCsBJxKqQHYhOgFuabxKeztvmrsvD58fXo 3CSoXiwoPd02Mc9GIbsqugjGtRSoQOGzwMzBo= MIME-Version: 1.0 Received: by 10.239.140.212 with SMTP id y20mr85450hby.165.1241098976980; Thu, 30 Apr 2009 06:42:56 -0700 (PDT) In-Reply-To: <008c01c9c998$3e699a90$bb3ccfb0$@edu> References: <49F89567.60407@gmail.com> <008c01c9c998$3e699a90$bb3ccfb0$@edu> Date: Thu, 30 Apr 2009 14:42:56 +0100 Message-ID: From: Blaine Cook To: Thomas Hardjono Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [oauth] OAuth Security Advisory X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:41:45 -0000 On Thu, Apr 30, 2009 at 2:33 PM, Thomas Hardjono wrote: > Hi Eran, > > I=E2=80=99m now confused about the OAuth specs being done in the IETF ver= sus the one > being done outside the IETF (Core 1.0): > > - If in the future further flaws are found in either Core 1.0 or the IETF > draft (or both), what will be the process to fix/reconcile this. Currentl= y > it seems that the real work in being done in the Oauth public list, with = the > fixes being brought into draft-hammer-oauth. > > (ps. Just a friendly comment: with this approach its going to be difficul= t > to avoid the impression that the new IETF WG will just be rubber-stamping > the work done outside the IETF. I hope this will not be the case). > > - Are there plans to converge the two (or deprecate one), and at which po= int > does the IETF have so-called =E2=80=9Cjurisdiction=E2=80=9D. The IETF has not yet formally approved the charter for the OAuth working group. As such, there isn't any protocol work happening within the context of the IETF. We expect this to proceed soon. Once the IETF process starts in earnest, it's hoped that the existing OAuth community will move discussions entirely to the IETF list and process. b.