From oauth-bounces@ietf.org Fri Jan 30 00:26:21 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717DC3A6971; Fri, 30 Jan 2009 00:26:21 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6E13A68C6 for ; Fri, 30 Jan 2009 00:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2jkt5+Cdi-3p for ; Fri, 30 Jan 2009 00:26:18 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id B097D3A6800 for ; Fri, 30 Jan 2009 00:26:15 -0800 (PST) Received: by qyk4 with SMTP id 4so465836qyk.13 for ; Fri, 30 Jan 2009 00:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=WYAst4KocTP4yGr0uKUOkW7gvcyWev81HE1wns5xbps=; b=T6y32+bW10Gj26gnwCkCLEyeWkvdJU4b2F69uYEa0zV0UInPVGe38ma8Z3bo/JoIW3 kdUj+zdJjmkcSdK/TtogLjszOAW4Yaqz7ql6lT33y0Y2W+LxN3c/iWjqIYGya2K+Q/Rb zWO8AddBH8HndhTjd7QhOAqpcb4gj1OoBaT+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IIqQ3l5xLfc4ww4CQcPF3t3LVZOmtVtMZh/fYOyTyvG7lzUrftoR67Cu2Lm8ULt0w7 zYbxJeWYYHZnwIgwiL9U0/fOKNcPWsW4F+NPMnzW6R7Ll98Q88AKTaYF6SweZKRQYx9Y tDjN4dfd+wvNzDqwJwIHDgSYElw8kYe3rZ68M= MIME-Version: 1.0 Received: by 10.214.113.18 with SMTP id l18mr1691156qac.352.1233303956211; Fri, 30 Jan 2009 00:25:56 -0800 (PST) Date: Fri, 30 Jan 2009 09:25:56 +0100 Message-ID: <6c0fd2bc0901300025t32340017w61a2fec958d62b0@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Subject: [oauth] What's next? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hello, This list has been awfully quiet recently. I believe we need to have some closure on the charter front before the WG can be formally formed and work begins. Should we try to list changes (if any) people feel should be made to the charter? One thing I think we could change is to add some text describing (and tightening) the goals around interoperability. For instance: - minimum security requirements, - hold at least one interop event? - etc. Do people think there are over immediate steps? Cheers, Hubert _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Fri Jan 30 09:54:51 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAED928C2DD; Fri, 30 Jan 2009 09:54:51 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69EC28C2D6 for ; Fri, 30 Jan 2009 09:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 pYGk4rettAKk for ; Fri, 30 Jan 2009 09:54:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 730C33A6965 for ; Fri, 30 Jan 2009 09:54:49 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2009 17:54:30 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp066) with SMTP; 30 Jan 2009 18:54:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ypbcYLb1ysWkVazmLRAmniMNeS190vQSslmYpMj pZ7N8ofACzGlRg From: "Hannes Tschofenig" To: Date: Fri, 30 Jan 2009 19:55:13 +0200 Message-ID: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmDA7jrRJJBacfoQoCgXAE1S86VuA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Subject: [oauth] OAUTH Charter Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi all, After a chat with Lisa I got in touch with Eran to slightly revise the charter text that Sam and Mark put together for the last IETF meeting. It should addresses some of the comments provided during the BOF. Your feedback is welcome. Ciao Hannes ------------------------------------- Open Authentication Protocol (oauth) Last Modified: 2009-01-30 Chair(s): TBD Applications Area Director(s): Chris Newman 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 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 consist 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, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology * Assure good security practice, or document gaps in its capabilities * Promote interoperability This specifically means that as a starting point for the working group the OAuth 1.0 specification is used and the available extension points are going to be utilized. It seems desireable to profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAUTH 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability. 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 in case the existing mechanisms do not fulfill the security requirements. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. In doing so, it should consider: * Implementer experience * Existing uses of OAuth * Ability to achieve broad impementation * Ability to address broader use cases than may be contemplated by the original authors * Impact on the Internet and Web The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group MAY consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration * Message integrity * Recommendations regarding the structure of the token Goals and Milestones: 12/2009 Submit document(s) suitable for publication as standards-track RFCs. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Fri Jan 30 11:03:59 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AAF3A6B4A; Fri, 30 Jan 2009 11:03:59 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A9828C132 for ; Fri, 30 Jan 2009 11:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjEiKUB6zId9 for ; Fri, 30 Jan 2009 11:03:56 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 46C643A68E5 for ; Fri, 30 Jan 2009 11:03:56 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so114354eya.31 for ; Fri, 30 Jan 2009 11:03:36 -0800 (PST) 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=47TJt/lbjeH3IGk4z/8Ktbi8jiwG0NUv8N1nguZS4So=; b=O2LrijbF/ERWYv/kEQqXdna8Dcq8iK8DLgOqEotsfEbIUcZg2FBQSwB2vFK5zaSj0Q Uq+3r6AX+6FI6LnLCCzbhchFtmJ745HqSryGL7IDLFpneTamGyfXPbGbJfSaWkAFuQUi j4OG4cfD3e3O40Xo+BPAh1Vy6pejWUo4hOAQM= 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=pNlReXSKaljfJwWJx6i9nwe9Ued+rWNqQVmW9U6k2EK+P0Fy7K4jANMlOq68CyGj+i FMHA9PZxnXBxG/I1+huRfZtt6cwMstwkVyIIj2fEUhtD6J4Khvw3lTMoUtuobnged+U+ U1x0S87io3EnQH4vNG9arIArr/kPBntRviMQ4= MIME-Version: 1.0 Received: by 10.210.105.2 with SMTP id d2mr1738371ebc.67.1233342216026; Fri, 30 Jan 2009 11:03:36 -0800 (PST) In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> Date: Fri, 30 Jan 2009 19:03:35 +0000 Message-ID: From: Blaine Cook To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org +1. This looks awesome, thanks Hannes. What are the next steps? My understanding is that first we need some kind of consensus on this charter, and then ?? b. On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > 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 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 consist 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, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices and > terminology > * Assure good security practice, or document gaps in its capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group the > OAuth 1.0 specification is used and the > available extension points are going to be utilized. It seems desireable to > profile OAuth 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced by > this group must support a basic set of features to guarantee > interoperability. > > 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 in case the existing mechanisms do not fulfill the > security requirements. Existing signature methods will not be modified but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a byproduct, > or such a scenario could be addressed by additional future work, the Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as standards-track > RFCs. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Fri Jan 30 14:32:28 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596DE3A68C0; Fri, 30 Jan 2009 14:32:28 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816093A68C0 for ; Fri, 30 Jan 2009 14:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 xowpsJFlzGnr for ; Fri, 30 Jan 2009 14:32:26 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 15B2E3A6781 for ; Fri, 30 Jan 2009 14:32:25 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2009 22:32:06 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp002) with SMTP; 30 Jan 2009 23:32:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184HpV9fX04pgxh4cRlGzZDd0tnqL5ir7qrQzCVWO z8buLOCqYrvhXh From: "Hannes Tschofenig" To: "'Blaine Cook'" References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> Date: Sat, 31 Jan 2009 00:32:48 +0200 Message-ID: <035301c9832a$ae7d6b90$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmDDXP0PE16PZzvTS2CAgbb7hUV7QADBgvA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org We need a couple of folks agreeing the charter proposals. Next, there is the question whether a meeting slot at the next IETF meeting (in San Francisco) should be requested (e.g., in the form of a BOF). This would give some discussion time for the details of the BOF or if everyone likes the charter till then already one could disuss the technical details instead. The Area Directors are then requested to charter a working group. They discuss it within the IESG and get feedback from the IAB. They also need to find chairs for the group. Ciao Hannes >-----Original Message----- >From: Blaine Cook [mailto:romeda@gmail.com] >Sent: 30 January, 2009 21:04 >To: Hannes Tschofenig >Cc: oauth@ietf.org >Subject: Re: [oauth] OAUTH Charter Proposal > >+1. This looks awesome, thanks Hannes. What are the next steps? My >understanding is that first we need some kind of consensus on >this charter, and then ?? > >b. > >On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig > wrote: >> Hi all, >> >> After a chat with Lisa I got in touch with Eran to slightly >revise the >> charter text that Sam and Mark put together for the last >IETF meeting. >> >> It should addresses some of the comments provided during the >BOF. Your >> feedback is welcome. >> >> Ciao >> Hannes >> >> ------------------------------------- >> >> Open Authentication Protocol (oauth) >> >> Last Modified: 2009-01-30 >> >> Chair(s): >> >> TBD >> >> Applications Area Director(s): >> >> Chris Newman >> 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 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 consist 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, based upon the OAuth >I-D, that will: >> * Align OAuth with the Internet and Web architectures, best >practices >> and terminology >> * Assure good security practice, or document gaps in its >capabilities >> * Promote interoperability >> >> This specifically means that as a starting point for the >working group >> the OAuth 1.0 specification is used and the available >extension points >> are going to be utilized. It seems desireable to profile >OAuth 1.0 in >> a way that produces a specification that is a backwards compatible >> profile, i.e. any OAUTH 1.0 and the specification produced by this >> group must support a basic set of features to guarantee >> interoperability. >> >> 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 in case the existing mechanisms do not >> fulfill the security requirements. Existing signature >methods will not >> be modified but may be dropped as part of the backwards >compatible profiling activity. >> >> In doing so, it should consider: >> * Implementer experience >> * Existing uses of OAuth >> * Ability to achieve broad impementation >> * Ability to address broader use cases than may be contemplated by >> the original authors >> * Impact on the Internet and Web >> >> The Working Group is not tasked with defining a generally applicable >> HTTP Authentication mechanism (i.e., browser-based "2-leg" >scenerio), >> and should consider this work out of scope in its discussions. >> However, if the deliverables are able to be factored in such a way >> that this is a byproduct, or such a scenario could be addressed by >> additional future work, the Working Group may choose to do so. >> >> After delivering OAuth, the Working Group MAY consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration >> * Message integrity >> * Recommendations regarding the structure of the token >> >> Goals and Milestones: >> >> 12/2009 Submit document(s) suitable for publication as >standards-track >> RFCs. >> >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Fri Jan 30 14:35:46 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FD83A6987; Fri, 30 Jan 2009 14:35:46 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AFE3A6987 for ; Fri, 30 Jan 2009 14:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=-1.925, 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 96OofzoCVF5m for ; Fri, 30 Jan 2009 14:35:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5868F3A6975 for ; Fri, 30 Jan 2009 14:35:44 -0800 (PST) Received: (qmail 10034 invoked from network); 30 Jan 2009 22:35:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jan 2009 22:35:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 30 Jan 2009 15:35:21 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , Blaine Cook Date: Fri, 30 Jan 2009 15:35:15 -0700 Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmDDXP0PE16PZzvTS2CAgbb7hUV7QADBgvAAAReQWI= Message-ID: In-Reply-To: <035301c9832a$ae7d6b90$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Type: multipart/mixed; boundary="===============0495164254==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0495164254== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C5A8C0A311CC5eranhueniversecom_" --_000_C5A8C0A311CC5eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like the proposed charter. I think it offers enough flexibility for chang= es while maintaining the spirit and framework of the OAuth Core 1.0 spec. EHL On 1/30/09 2:32 PM, "Hannes Tschofenig" wrote: We need a couple of folks agreeing the charter proposals. Next, there is the question whether a meeting slot at the next IETF meeting (in San Francisco) should be requested (e.g., in the form of a BOF). This would give some discussion time for the details of the BOF or if everyone likes the charter till then already one could disuss the technical details instead. The Area Directors are then requested to charter a working group. They discuss it within the IESG and get feedback from the IAB. They also need to find chairs for the group. Ciao Hannes >-----Original Message----- >From: Blaine Cook [mailto:romeda@gmail.com] >Sent: 30 January, 2009 21:04 >To: Hannes Tschofenig >Cc: oauth@ietf.org >Subject: Re: [oauth] OAUTH Charter Proposal > >+1. This looks awesome, thanks Hannes. What are the next steps? My >understanding is that first we need some kind of consensus on >this charter, and then ?? > >b. > >On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig > wrote: >> Hi all, >> >> After a chat with Lisa I got in touch with Eran to slightly >revise the >> charter text that Sam and Mark put together for the last >IETF meeting. >> >> It should addresses some of the comments provided during the >BOF. Your >> feedback is welcome. >> >> Ciao >> Hannes >> >> ------------------------------------- >> >> Open Authentication Protocol (oauth) >> >> Last Modified: 2009-01-30 >> >> Chair(s): >> >> TBD >> >> Applications Area Director(s): >> >> Chris Newman >> 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 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 consist 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, based upon the OAuth >I-D, that will: >> * Align OAuth with the Internet and Web architectures, best >practices >> and terminology >> * Assure good security practice, or document gaps in its >capabilities >> * Promote interoperability >> >> This specifically means that as a starting point for the >working group >> the OAuth 1.0 specification is used and the available >extension points >> are going to be utilized. It seems desireable to profile >OAuth 1.0 in >> a way that produces a specification that is a backwards compatible >> profile, i.e. any OAUTH 1.0 and the specification produced by this >> group must support a basic set of features to guarantee >> interoperability. >> >> 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 in case the existing mechanisms do not >> fulfill the security requirements. Existing signature >methods will not >> be modified but may be dropped as part of the backwards >compatible profiling activity. >> >> In doing so, it should consider: >> * Implementer experience >> * Existing uses of OAuth >> * Ability to achieve broad impementation >> * Ability to address broader use cases than may be contemplated by >> the original authors >> * Impact on the Internet and Web >> >> The Working Group is not tasked with defining a generally applicable >> HTTP Authentication mechanism (i.e., browser-based "2-leg" >scenerio), >> and should consider this work out of scope in its discussions. >> However, if the deliverables are able to be factored in such a way >> that this is a byproduct, or such a scenario could be addressed by >> additional future work, the Working Group may choose to do so. >> >> After delivering OAuth, the Working Group MAY consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration >> * Message integrity >> * Recommendations regarding the structure of the token >> >> Goals and Milestones: >> >> 12/2009 Submit document(s) suitable for publication as >standards-track >> RFCs. >> >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C5A8C0A311CC5eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAUTH Charter Proposal I like the proposed charter. I think it offers enough flexibility for= changes while maintaining the spirit and framework of the OAuth Core 1.0 s= pec.

EHL


On 1/30/09 2:32 PM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:

We need a couple of folks agreeing the char= ter proposals.

Next, there is the question whether a meeting slot at the next IETF meeting=
(in San Francisco) should be requested (e.g., in the form of a BOF). This would give some discussion time for the details of the BOF or if everyone likes the charter till then already one could disuss the technical details<= BR> instead.

The Area Directors are then requested to charter a working group. They
discuss it within the IESG and get feedback from the IAB. They also need to=
find chairs for the group.

Ciao
Hannes

>-----Original Message-----
>From: Blaine Cook [mailto:romeda@gm= ail.com]
>Sent: 30 January, 2009 21:04
>To: Hannes Tschofenig
>Cc: oauth@ietf.org
>Subject: Re: [oauth] OAUTH Charter Proposal
>
>+1. This looks awesome, thanks Hannes. What are the next steps? My
>understanding is that first we need some kind of consensus on
>this charter, and then ??
>
>b.
>
>On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig
><Hannes.Tschofenig@gmx.net= > wrote:
>> Hi all,
>>
>> After a chat with Lisa I got in touch with Eran to slightly
>revise the
>> charter text that Sam and Mark put together for the last
>IETF meeting.
>>
>> It should addresses some of the comments provided during the
>BOF. Your
>> feedback is welcome.
>>
>> Ciao
>> Hannes
>>
>> -------------------------------------
>>
>> Open Authentication Protocol (oauth)
>>
>> Last Modified: 2009-01-30
>>
>> Chair(s):
>>
>> TBD
>>
>> Applications Area Director(s):
>>
>> Chris Newman <chris.newman@sun= .com>
>> Lisa Dusseault <lisa@osafoun= dation.org>
>>
>> Applications Area Advisor:
>>
>> TBD
>>
>> Mailing Lists:
>>
>> https://ww= w.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 revealing their credentials, or=
>> even their identity. For example, a photo-sharing site that suppor= ts
>> 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 consist 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= ir
>> behalf
>>  * A mechanism for signing HTTP requests with the token-secre= t pair
>>
>> The Working Group will produce one or more documents suitable for<= BR> >> consideration as Proposed Standard, based upon the OAuth
>I-D, that will:
>>  * Align OAuth with the Internet and Web architectures, best<= BR> >practices
>> and terminology
>>  * Assure good security practice, or document gaps in its
>capabilities
>>  * Promote interoperability
>>
>> This specifically means that as a starting point for the
>working group
>> the OAuth 1.0 specification is used and the available
>extension points
>> are going to be utilized. It seems desireable to profile
>OAuth 1.0 in
>> a way that produces a specification that is a backwards compatible=
>> profile, i.e. any OAUTH 1.0 and the specification produced by this=
>> group must support a basic set of features to guarantee
>> interoperability.
>>
>> Furthermore, Oauth 1.0 defines three signature methods used
>to protect
>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group wil= l
>> work on new signature methods in case the existing mechanisms do n= ot
>> fulfill the security requirements. Existing signature
>methods will not
>> be modified but may be dropped as part of the backwards
>compatible profiling activity.
>>
>> In doing so, it should consider:
>>  * Implementer experience
>>  * Existing uses of OAuth
>>  * Ability to achieve broad impementation
>>  * Ability to address broader use cases than may be contempla= ted by
>> the original authors
>>  * Impact on the Internet and Web
>>
>> The Working Group is not tasked with defining a generally applicab= le
>> HTTP Authentication mechanism (i.e., browser-based "2-leg&quo= t;
>scenerio),
>> and should consider this work out of scope in its discussions.
>> However, if the deliverables are able to be factored in such a way=
>> that this is a byproduct, or such a scenario could be addressed by=
>> additional future work, the Working Group may choose to do so.
>>
>> After delivering OAuth, the Working Group MAY consider defining >> additional functions and/or extensions, for example (but not limit= ed
>> to):
>>  * Discovery of authentication configuration
>>  * Message integrity
>>  * Recommendations regarding the structure of the token
>>
>> Goals and Milestones:
>>
>> 12/2009     Submit document(s) suitable for pu= blication as
>standards-track
>> RFCs.
>>
>> _______________________________________________
>> oauth mailing list
>> oauth@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/oauth
>>
>

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

--_000_C5A8C0A311CC5eranhueniversecom_-- --===============0495164254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============0495164254==-- From oauth-bounces@ietf.org Fri Jan 30 20:43:32 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB893A68A1; Fri, 30 Jan 2009 20:43:32 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D16D3A685F for ; Fri, 30 Jan 2009 20:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSNk+2K3kvhx for ; Fri, 30 Jan 2009 20:43:30 -0800 (PST) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id 456F03A679C for ; Fri, 30 Jan 2009 20:43:30 -0800 (PST) Received: from [192.168.1.66] ([71.146.5.160]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEB00382JRBPLG2@vms173019.mailsrvcs.net> for oauth@ietf.org; Fri, 30 Jan 2009 22:42:48 -0600 (CST) Message-id: <4983D6C7.8070201@gte.net> Date: Fri, 30 Jan 2009 20:42:47 -0800 From: Krishna Sankar User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-version: 1.0 To: Eran Hammer-Lahav References: In-reply-to: Cc: Hannes Tschofenig , "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org +1. We bounded with enough flexibility. Should we mention anything about extensions or any extensibility framework ? Cheers Eran Hammer-Lahav wrote: > I like the proposed charter. I think it offers enough flexibility for > changes while maintaining the spirit and framework of the OAuth Core > 1.0 spec. > > EHL > > > On 1/30/09 2:32 PM, "Hannes Tschofenig" wrote: > > We need a couple of folks agreeing the charter proposals. > > Next, there is the question whether a meeting slot at the next > IETF meeting > (in San Francisco) should be requested (e.g., in the form of a > BOF). This > would give some discussion time for the details of the BOF or if > everyone > likes the charter till then already one could disuss the technical > details > instead. > > The Area Directors are then requested to charter a working group. They > discuss it within the IESG and get feedback from the IAB. They > also need to > find chairs for the group. > > Ciao > Hannes > > >-----Original Message----- > >From: Blaine Cook [mailto:romeda@gmail.com] > >Sent: 30 January, 2009 21:04 > >To: Hannes Tschofenig > >Cc: oauth@ietf.org > >Subject: Re: [oauth] OAUTH Charter Proposal > > > >+1. This looks awesome, thanks Hannes. What are the next steps? My > >understanding is that first we need some kind of consensus on > >this charter, and then ?? > > > >b. > > > >On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig > > wrote: > >> Hi all, > >> > >> After a chat with Lisa I got in touch with Eran to slightly > >revise the > >> charter text that Sam and Mark put together for the last > >IETF meeting. > >> > >> It should addresses some of the comments provided during the > >BOF. Your > >> feedback is welcome. > >> > >> Ciao > >> Hannes > >> > >> ------------------------------------- > >> > >> Open Authentication Protocol (oauth) > >> > >> Last Modified: 2009-01-30 > >> > >> Chair(s): > >> > >> TBD > >> > >> Applications Area Director(s): > >> > >> Chris Newman > >> 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 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 consist 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, based upon the OAuth > >I-D, that will: > >> * Align OAuth with the Internet and Web architectures, best > >practices > >> and terminology > >> * Assure good security practice, or document gaps in its > >capabilities > >> * Promote interoperability > >> > >> This specifically means that as a starting point for the > >working group > >> the OAuth 1.0 specification is used and the available > >extension points > >> are going to be utilized. It seems desireable to profile > >OAuth 1.0 in > >> a way that produces a specification that is a backwards compatible > >> profile, i.e. any OAUTH 1.0 and the specification produced by this > >> group must support a basic set of features to guarantee > >> interoperability. > >> > >> 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 in case the existing mechanisms do not > >> fulfill the security requirements. Existing signature > >methods will not > >> be modified but may be dropped as part of the backwards > >compatible profiling activity. > >> > >> In doing so, it should consider: > >> * Implementer experience > >> * Existing uses of OAuth > >> * Ability to achieve broad impementation > >> * Ability to address broader use cases than may be contemplated by > >> the original authors > >> * Impact on the Internet and Web > >> > >> The Working Group is not tasked with defining a generally applicable > >> HTTP Authentication mechanism (i.e., browser-based "2-leg" > >scenerio), > >> and should consider this work out of scope in its discussions. > >> However, if the deliverables are able to be factored in such a way > >> that this is a byproduct, or such a scenario could be addressed by > >> additional future work, the Working Group may choose to do so. > >> > >> After delivering OAuth, the Working Group MAY consider defining > >> additional functions and/or extensions, for example (but not limited > >> to): > >> * Discovery of authentication configuration > >> * Message integrity > >> * Recommendations regarding the structure of the token > >> > >> Goals and Milestones: > >> > >> 12/2009 Submit document(s) suitable for publication as > >standards-track > >> RFCs. > >> > >> _______________________________________________ > >> oauth mailing list > >> oauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ------------------------------------------------------------------------ > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sat Jan 31 03:36:31 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D663A68A1; Sat, 31 Jan 2009 03:36:31 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749ED3A68A1 for ; Sat, 31 Jan 2009 03:36:29 -0800 (PST) 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 LjIUP7q4WERH for ; Sat, 31 Jan 2009 03:36:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5BEF73A63EB for ; Sat, 31 Jan 2009 03:36:25 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2009 11:36:05 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp011) with SMTP; 31 Jan 2009 12:36:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/t6eNNiKvtZfrEmsOeJuQXESaF3t52xwytJ/fan9 DCpw15kpcCkgs1 From: "Hannes Tschofenig" To: "'Krishna Sankar'" , "'Eran Hammer-Lahav'" References: <4983D6C7.8070201@gte.net> Date: Sat, 31 Jan 2009 13:36:48 +0200 Message-ID: <044801c98398$34fd6860$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4983D6C7.8070201@gte.net> Thread-Index: AcmDXmTqiV5NqU5GRtS6Lq5bWBMkIgAOXW0A X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org >Should we mention anything about extensions or any >extensibility framework ? > >Cheers > What specifically do you have in mind? A document that describes an extensibility framework? Highlighting in the charter what extension points could/should be used? Ciao Hannes _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sat Jan 31 10:53:18 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FA33A69D0; Sat, 31 Jan 2009 10:53:18 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4EC28C13C for ; Sat, 31 Jan 2009 10:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIhY7CD6IzTu for ; Sat, 31 Jan 2009 10:53:16 -0800 (PST) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by core3.amsl.com (Postfix) with ESMTP id 48FA83A69D0 for ; Sat, 31 Jan 2009 10:53:16 -0800 (PST) Received: from [192.168.1.66] ([71.146.5.160]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KEC00JQLMVTIPH5@vms173009.mailsrvcs.net> for oauth@ietf.org; Sat, 31 Jan 2009 12:47:54 -0600 (CST) Message-id: <49849DFD.4020607@gte.net> Date: Sat, 31 Jan 2009 10:52:45 -0800 From: Krishna Sankar User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-version: 1.0 To: Hannes Tschofenig References: <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net> In-reply-to: <044801c98398$34fd6860$0201a8c0@nsnintra.net> Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Three vectors: a) While we cannot legislate extensibility, an extensibility guideline document need to be part of the deliverables. When the main OAuth discussions occur, there will be things we will say "this is not core but belongs to extensions" or we might make certain assumptions that we need to explicitly state or we might have certain insights. This document can systemically capture all these artifacts. We also might need to add security considerations as well as interoperability and conformance for extensions. b) As a part of the charter we should add : * Promote interoperability * Provide guidelines for extensibility The group should think about extensibility & document the results of the deliberations c) While I like an extensibility framework, it might prove to be too much and might not be practical. So am happy at the level of guidelines, insights and suggestions. Cheers Hannes Tschofenig wrote: > >Should we mention anything about extensions or any > >> extensibility framework ? >> >> Cheers >> >> > > What specifically do you have in mind? > A document that describes an extensibility framework? > Highlighting in the charter what extension points could/should be used? > > Ciao > Hannes > > > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sat Jan 31 13:37:09 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F763A6857; Sat, 31 Jan 2009 13:37:09 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF9A3A6857 for ; Sat, 31 Jan 2009 13:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 YeEUyz4X9wW9 for ; Sat, 31 Jan 2009 13:37:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0365D3A67E9 for ; Sat, 31 Jan 2009 13:37:06 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2009 21:36:45 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp001) with SMTP; 31 Jan 2009 22:36:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19c0/Eq8BRci+PDVnPGl8vnDShVeJY8VpV0+vVOlT qsE3NZBrXKFL2W From: "Hannes Tschofenig" To: "'Krishna Sankar'" References: <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net> <49849DFD.4020607@gte.net> Date: Sat, 31 Jan 2009 23:37:27 +0200 Message-ID: <045601c983ec$1e919e30$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49849DFD.4020607@gte.net> Thread-Index: AcmD1RuIJO0h8Ed8Qd+/qfZDUf/3MAAFGRsg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Krishna, Thanks for your quick response. >Three vectors: > >a) While we cannot legislate extensibility, an extensibility >guideline >document need to be part of the deliverables. When the main >OAuth discussions occur, there will be things we will say >"this is not core but belongs to extensions" or we might make >certain assumptions that we need to explicitly state or we >might have certain insights. This document can systemically >capture all these artifacts. We also might need to add >security considerations as well as interoperability and >conformance for extensions. A description on how OAUTH can (or should) be extended is certainly useful (better explicit than implicit). This could, for example, be part of the main specification. I have also seen separate documents that illustrate how a protocol (or a set of protocols) can be extended. Example: Design Guidelines for RADIUS http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt This document has been written some time after the deployment happened and provides a sort of best current practice on how to build RADIUS extensions. I believe it is a bit early for these type of documents. So, my proposal would be to capture the most important extensibility aspects within the main specification itself. Later, when some expertise can be gained with OAUTH extensions one can start thinking about capturing the design experience in a document. I guess we are doing fine with the security considerations as every IETF document needs to contain a section describing them. In any case, if you already have some ideas for text (or already a text proposal) for the OAUTH draft feel free to post something to the list (even though it is not directly related to the charter discussion itself). >b) As a part of the charter we should add : > >* Promote interoperability >* Provide guidelines for extensibility > >The group should think about extensibility & document the >results of the deliberations Explicitly stating extensibility in the charter sounds useful to me. I added it to the charter text. > >c) While I like an extensibility framework, it might prove to be too >much and might not be practical. So am happy at the level of >guidelines, insights and suggestions. Ok. Ciao Hannes > >Cheers > >Hannes Tschofenig wrote: >> >Should we mention anything about extensions or any >> >>> extensibility framework ? >>> >>> Cheers >>> >>> >> >> What specifically do you have in mind? >> A document that describes an extensibility framework? >> Highlighting in the charter what extension points >could/should be used? >> >> Ciao >> Hannes >> >> >> > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sat Jan 31 18:29:08 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7D63A68BB; Sat, 31 Jan 2009 18:29:08 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B61A3A68BB for ; Sat, 31 Jan 2009 18:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qKRMrqBMlxS for ; Sat, 31 Jan 2009 18:29:06 -0800 (PST) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 4B1813A67BD for ; Sat, 31 Jan 2009 18:29:06 -0800 (PST) Received: from [192.168.1.66] ([71.146.5.160]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-2.01 (built Jun 13 2007; 32bit)) with ESMTPA id <0KED00C0J87L5BF3@vms173003.mailsrvcs.net> for oauth@ietf.org; Sat, 31 Jan 2009 20:28:34 -0600 (CST) Message-id: <498508D1.5010706@gte.net> Date: Sat, 31 Jan 2009 18:28:33 -0800 From: Krishna Sankar User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-version: 1.0 To: Hannes Tschofenig References: <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net> <49849DFD.4020607@gte.net> <045601c983ec$1e919e30$0201a8c0@nsnintra.net> In-reply-to: <045601c983ec$1e919e30$0201a8c0@nsnintra.net> Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hannes, Thank you. Agreed on all. Cheers & have a nice weekend Hannes Tschofenig wrote: > Hi Krishna, > > Thanks for your quick response. > > >> Three vectors: >> >> a) While we cannot legislate extensibility, an extensibility >> guideline >> document need to be part of the deliverables. When the main >> OAuth discussions occur, there will be things we will say >> "this is not core but belongs to extensions" or we might make >> certain assumptions that we need to explicitly state or we >> might have certain insights. This document can systemically >> capture all these artifacts. We also might need to add >> security considerations as well as interoperability and >> conformance for extensions. >> > > A description on how OAUTH can (or should) be extended is certainly useful > (better explicit than implicit). This could, for example, be part of the > main specification. I have also seen separate documents that illustrate how > a protocol (or a set of protocols) can be extended. Example: Design > Guidelines for RADIUS > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt > This document has been written some time after the deployment happened and > provides a sort of best current practice on how to build RADIUS extensions. > I believe it is a bit early for these type of documents. > > So, my proposal would be to capture the most important extensibility aspects > within the main specification itself. Later, when some expertise can be > gained with OAUTH extensions one can start thinking about capturing the > design experience in a document. > > I guess we are doing fine with the security considerations as every IETF > document needs to contain a section describing them. > > In any case, if you already have some ideas for text (or already a text > proposal) for the OAUTH draft feel free to post something to the list (even > though it is not directly related to the charter discussion itself). > > >> b) As a part of the charter we should add : >> >> * Promote interoperability >> * Provide guidelines for extensibility >> >> The group should think about extensibility & document the >> results of the deliberations >> > > Explicitly stating extensibility in the charter sounds useful to me. > I added it to the charter text. > > >> c) While I like an extensibility framework, it might prove to be too >> much and might not be practical. So am happy at the level of >> guidelines, insights and suggestions. >> > > Ok. > > Ciao > Hannes > > >> Cheers >> >> Hannes Tschofenig wrote: >> >>> >Should we mention anything about extensions or any >>> >>> >>>> extensibility framework ? >>>> >>>> Cheers >>>> >>>> >>>> >>> What specifically do you have in mind? >>> A document that describes an extensibility framework? >>> Highlighting in the charter what extension points >>> >> could/should be used? >> >>> Ciao >>> Hannes >>> >>> >>> >>> > > > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth