From oauth-bounces@ietf.org Mon Dec 1 06:07:03 2008 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 AC6C13A6A27; Mon, 1 Dec 2008 06:07:03 -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 733683A6A18 for ; Mon, 1 Dec 2008 06:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN-VQJIVb9nS for ; Mon, 1 Dec 2008 06:07:01 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 3664A3A6A27 for ; Mon, 1 Dec 2008 06:07:01 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E3384268; Mon, 1 Dec 2008 09:06:37 -0500 (EST) From: Sam Hartman To: oauth@ietf.org Date: Mon, 01 Dec 2008 09:06:37 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Subject: [oauth] Draft minutes for the oauth bof 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 When I try and upload these through the tool, it creates empty minutes. I'm going to submit them manually, but meanwhile, here are my minutes of the BOF. I trimmed some of the discussion about backward compatibility; I believe that I included representative points from all sides, but not a full transcript. If you feel there are important aspects of the discussion that are not covered or otherwise believe the minutes should be improved, please let Mark and I kno. Oauth BOF minutes November 17, 2008 1300-1500 Chairs: Sam Hartman and Mark Nottingham scribe: Ted Hardie Larry Half and Blake Cook gave a use case presentation describing the problem that oauth solves and how it came about. The primary problem oauth solves is delegating access to resources held at a service provider to consumers of a resource under the control of a user. Typically today, this is done using passwords. However as sites adopt other authentication mechanisms, they may not have a password to give out. Oauth arose to solve this need. The presentation also presented a use case where oauth is used to control access to information private to some consumer. eric Rescorla (ekr): Is this the same as the standard web authentication problem? Larry: yes The room discussed whether this was an interesting problem. Phillip Hallam-Baker (phb): This is interesting from the SAML, WS*, etc space; the critical issue is UI. We need to work out how the user understands what they are doing. He did not understand the UI in the presentation. We should not take this on unless we handle the UI problem. ekr: This is a system not a protocol. There is a method for granting delegated access to resources and technology for doing user web authentication. The first is interesting. The second is not coupled to the first. Hannes Tschofenig: This is an interesting problem. Getting UI folks interested would be good, but the UI work should not block the other work. Dave Crocker: Yes, this is very interesting.Having UI folks look at this is separate expertise and separate work. Leif: This is interesting; the oauth group can help the IETF in this space. Jeff Hodges (jeffh): Yes, this is interesting. UI should be separated. Bob Morgan (rlbob): This is interesting. We're seeing this in the higher education area; we need a good security review and to be well integrated into larger architectures. There is sufficient interest for work in this area; strong hum for, no opposed. Eran Hammer gave a presentation on the oauth protocol describing its flow. About half to two thirds had read the spec before. Stephen Farrell gave a presentation on implications he has run into using oauth in a mobile environment. Phones do not seem to support the current oauth work flow. He would like to add a requirement that we support current phones. Mark presented a proposed charter. The charter assumes that the existing draft is a starting point for the work. Dave Crocker: The first paragraph needs to be improved to better introduce the problem. He will volunteer to work on text. ekr: The problem is important but this charter is not a reasonable starting point. There are three aspects to the proposal: an http handshake, set of mechanisms to pass tokens, and authentication mechanism. This charter bakes in some connections between these three. While we should not gratuitously break existing oauth, we should not bake in these connections. Chairs would like to get comments on what level of interoperability with oauth we need. phb: We'll inevitably make changes to parts. Stephan Wegner: The oauth webpage indicates that oauth is done and that the current work is extensions. Is the IETF really getting change control here? If we see a need to make a change, will people actually adopt it? Eran: No one can speak for the entire community, but yes, we want oauth reviewed, and if problems are found, fixed. If this charter is approved, most of the companies involved will have someone at the table involved in the consensus process. Pasi: It's unlikely that we will not need to make changes. He favors oauth 1.1, not a clean slate. Stephen Farrell : also agrees with oauth 1.1 style lisa (as AD): No one expects bit-for-bit compatibility. This is a big thing; a lot of people in the web community like it. Code can change over time. ekr: Concerned about backward compatibility text in charter. He thinks it may go too far and wants to know what it means. Pasi: There seem to be specific design requirements that went into the signature that may have to do with ease of implementation in certain environments. these should be called out. Ted Hardie: There is something working in the wild; now you want to spec it out and standardize it. You don't want gratuitous changes, but you will be part of the IETF if this work happens. You will be part of the group deciding what changes to make. The chairs believed there may be a rough consensus in favor of trying to develop an oauth 1.1, but the consensus was rather weak. There definitely is not a consensus to start fresh, but people seem to need more information to make a decision on what level of compatibility is required. Ted Hardie: Negotiation and extensibility will be important as changes are made. Blocking issues in the charter: Greg Lebobits wants us to commit to fixing security problems in some possibly incremental time frame rather than simply documenting gaps. Stephen Farrell believes that the mobile use cases need to be discussed in the charter. rlbob believes that negotiation is needed and has a blocker re/related to service discovery. Ekr wants to understand what level of backward compatibility is required and what changes are acceptable. Sam wants channel binding and mutual authentication as a security option. Potential document authors:Jeff Hodges, Eran, Blain, Larry, ekr, Hannes, Stephen Farrell, David Recordon Dave Crocker would be willing to be considered as a chair. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Dec 1 12:30:06 2008 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 D91C93A6BAF; Mon, 1 Dec 2008 12:30:06 -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 DFE613A69F4 for ; Mon, 1 Dec 2008 12:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpRf6ZpwCEEF for ; Mon, 1 Dec 2008 12:30:04 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id A4C6B28C0FA for ; Mon, 1 Dec 2008 12:30:04 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mB1KU1Wc024660 for ; Mon, 1 Dec 2008 12:30:01 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 12:30:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 12:30:00 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBC2@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Algorithm choice (from the 'tother list) Thread-Index: AclT85WADWkukeBPRm2Sq0S0pagwaw== From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 01 Dec 2008 20:30:00.0867 (UTC) FILETIME=[95979F30:01C953F3] Subject: [oauth] Algorithm choice (from the 'tother list) 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="===============1507083686==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org This is a multi-part message in MIME format. --===============1507083686== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C953F3.95853B3A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C953F3.95853B3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should not specify SHA-1 as a required algorithm. This has nothing to do with the security arguments. It is just a matter = of it being one of those arguments that the security area has pretty = much decided not to have. The issue is not just the convenience or not = of this particular protocol deployment, it is the fact that the = algorithm choice does matter in some cases and arguing the difference is = simply too much effort. In most cases HMAC-MD5 is perfectly adequate. DIGEST-MD5 is perfectly = adequate. But I would not specify them for a new standards proposal = regardless of the cryptographic requirements. I regret not changing the = MD5 requirement to SHA. Not doing so has led to a huge amount of IETF = bandwidth since as folk propose updating it even though the strength of = the DIGEST construction is much greater than the strength of SHA-1 (or = come to that SHA-256). If we are only using MAC functions, CMAC-AES would be a better long term = choice than HMAC-SHA256 as we know that SHA256 is likely to change in = future while CMAC is a NIST approved standard. I seem to recall it will = be slower, but does that matter here? When HMAC was written we were confident about our hash functions and = worried about our encryption algorithms, in fact we had no encryption = algorithm of choice at the time. Today that is not the case and CMAC = offers the best possible future proofing. I would like CFRG to periodically issue an RFC specifying a small set of = preferred crypto algorithms. This would allow folk to specify = TLS+RFCxxxx crypto or IPSEC+RFCxxxx crypto as a requirement. It would = allow us to update the mandatory crypto suites for every IETF protocol = in one go (assuming the protocol in question supported the new alg). It = would also smooth the way for deployment of a coherent ECC based suite., = just specify TLS+RFCxxxy or such. If such a document were issued today the cipher suite recommendation = would clearly be: AES128/192/256, SHA2*, CMAC-AES, RSA2048 [or DSA2048 if compact = signatures are required] The only questionable algorithm there is SHA2. I can well imagine in = some instances wanting to insist on SHA512 instead of SHA256 because you = do get more rounds with more key a well. The fact that SHA2 is a less = preferred choice means that HMAC-SHA2 is also less preferred. Not = because we have any specific concern, but we have a choice and it is a = liability. I think you could then make an argument for HMAC-SHA256 and Camilla = being on a list of 'acceptable crypto' that may be supported but is not = mandatory. ------_=_NextPart_001_01C953F3.95853B3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Algorithm choice (from the 'tother list)

We should not specify SHA-1 as a required = algorithm.

This has nothing to do with the security arguments. It is just a matter = of it being one of those arguments that the security area has pretty = much decided not to have. The issue is not just the convenience or not = of this particular protocol deployment, it is the fact that the = algorithm choice does matter in some cases and arguing the difference is = simply too much effort.

In most cases HMAC-MD5 is perfectly adequate. DIGEST-MD5 is perfectly = adequate. But I would not specify them for a new standards proposal = regardless of the cryptographic requirements. I regret not changing the = MD5 requirement to SHA. Not doing so has led to a huge amount of IETF = bandwidth since as folk propose updating it even though the strength of = the DIGEST construction is much greater than the strength of SHA-1 (or = come to that SHA-256).


If we are only using MAC functions, CMAC-AES would be a better long term = choice than HMAC-SHA256 as we know that SHA256 is likely to change in = future while CMAC is a NIST approved standard. I seem to recall it will = be slower, but does that matter here?

When HMAC was written we were confident about our hash functions and = worried about our encryption algorithms, in fact we had no encryption = algorithm of choice at the time. Today that is not the case and CMAC = offers the best possible future proofing.


I would like CFRG to periodically issue an RFC specifying a small set of = preferred crypto algorithms. This would allow folk to specify = TLS+RFCxxxx crypto or IPSEC+RFCxxxx crypto as a requirement. It would = allow us to update the mandatory crypto suites for every IETF protocol = in one go (assuming the protocol in question supported the new alg). It = would also smooth the way for deployment of a coherent ECC based suite., = just specify TLS+RFCxxxy or such.

If such a document were issued today the cipher suite recommendation = would clearly be:
   AES128/192/256, SHA2*, CMAC-AES, RSA2048 [or DSA2048 if = compact signatures are required]

The only questionable algorithm there is SHA2. I can well imagine in = some instances wanting to insist on SHA512 instead of SHA256 because you = do get more rounds with more key a well. The fact that SHA2 is a less = preferred choice means that HMAC-SHA2 is also less preferred. Not = because we have any specific concern, but we have a choice and it is a = liability.

I think you could then make an argument for HMAC-SHA256 and Camilla = being on a list of 'acceptable crypto' that may be supported but is not = mandatory.

------_=_NextPart_001_01C953F3.95853B3A-- --===============1507083686== 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 --===============1507083686==-- From oauth-bounces@ietf.org Fri Dec 5 09:44:44 2008 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 5E3DC3A696A; Fri, 5 Dec 2008 09:44:44 -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 D214F3A696A for ; Fri, 5 Dec 2008 09:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqcIKW8IJvnT for ; Fri, 5 Dec 2008 09:44:42 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 8E26F3A63D2 for ; Fri, 5 Dec 2008 09:44:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 93BDE1004165C; Fri, 5 Dec 2008 17:44:36 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFAX-telZ5CJ; Fri, 5 Dec 2008 17:44:35 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 215771004165A; Fri, 5 Dec 2008 17:44:32 +0000 (GMT) Message-ID: <4939688E.6080300@cs.tcd.ie> Date: Fri, 05 Dec 2008 17:44:46 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: oauth@ietf.org Subject: Re: [oauth] Draft minutes for the oauth bof 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 Sam, I'm wondering if anyone's been working on progressing the charter text? Be good to get some discussion of that on this list if someone's got a post-BoF version. Stephen. Sam Hartman wrote: > When I try and upload these through the tool, it creates empty > minutes. > > I'm going to submit them manually, but meanwhile, here are my minutes of the BOF. > > I trimmed some of the discussion about backward compatibility; I > believe that I included representative points from all sides, but not > a full transcript. If you feel there are important aspects of the > discussion that are not covered or otherwise believe the minutes > should be improved, please let Mark and I kno. > > > Oauth BOF minutes > November 17, 2008 1300-1500 > Chairs: Sam Hartman and Mark Nottingham > scribe: Ted Hardie > > Larry Half and Blake Cook gave a use case presentation describing the > problem that oauth solves and how it came about. The primary problem > oauth solves is delegating access to resources held at a service > provider to consumers of a resource under the control of a user. > Typically today, this is done using passwords. However as sites adopt > other authentication mechanisms, they may not have a password to give > out. Oauth arose to solve this need. > > The presentation also presented a use case where oauth is used to > control access to information private to some consumer. > > eric Rescorla (ekr): Is this the same as the standard web authentication problem? > Larry: yes > The room discussed whether this was an interesting problem. > > Phillip Hallam-Baker (phb): This is interesting from the SAML, > WS*, etc space; the critical issue is UI. We need to work out how the > user understands what they are doing. He did not understand > the UI in the presentation. We should not take this on unless we > handle the UI problem. > > ekr: This is a system not a protocol. There is a method for > granting delegated access to resources and technology for doing > user web authentication. The first is interesting. The second > is not coupled to the first. > > > Hannes Tschofenig: This is an interesting problem. Getting UI > folks interested would be good, but the UI work should not block > the other work. > > > Dave Crocker: Yes, this is very interesting.Having UI folks look > at this is separate expertise and separate work. > > > Leif: This is interesting; the oauth group can help the IETF in this space. > > Jeff Hodges (jeffh): Yes, this is interesting. UI should be separated. > > Bob Morgan (rlbob): This is interesting. We're seeing this in the > higher education area; we need a good security review and to be > well integrated into larger architectures. > There is sufficient interest for work in this area; strong hum for, no opposed. > > Eran Hammer gave a presentation on the oauth protocol describing its > flow. About half to two thirds had read the spec before. > > > Stephen Farrell gave a presentation on implications he has run into > using oauth in a mobile environment. Phones do not seem to support > the current oauth work flow. He would like to add a requirement that we support current phones. > > Mark presented a proposed charter. The charter assumes that the existing draft is a starting point for the work. > > > > Dave Crocker: The first paragraph needs to be improved to better > introduce the problem. He will volunteer to work on text. > > ekr: The problem is important but this charter is not a reasonable > starting point. There are three aspects to the proposal: an > http handshake, set of mechanisms to pass tokens, and > authentication mechanism. This charter bakes in some > connections between these three. While we should not > gratuitously break existing oauth, we should not bake in these > connections. > > Chairs would like to get comments on what level of interoperability with oauth we need. > > phb: We'll inevitably make changes to parts. > > Stephan Wegner: The oauth webpage indicates that oauth is done and > that the current work is extensions. Is the IETF really getting > change control here? If we see a need to make a change, will > people actually adopt it? Eran: No one can speak for the entire > community, but yes, we want oauth reviewed, and if problems are > found, fixed. If this charter is approved, most of the > companies involved will have someone at the table involved in > the consensus process. > > > Pasi: It's unlikely that we will not need to make changes. He favors oauth 1.1, not a clean slate. > > Stephen Farrell : also agrees with oauth 1.1 style > > > lisa (as AD): No one expects bit-for-bit compatibility. This is a > big thing; a lot of people in the web community like it. Code > can change over time. > > > ekr: Concerned about backward compatibility text in charter. He > thinks it may go too far and wants to know what it means. > > > Pasi: There seem to be specific design requirements that went into > the signature that may have to do with ease of implementation in > certain environments. these should be called out. > > > > Ted Hardie: There is something working in the wild; now you want > to spec it out and standardize it. You don't want gratuitous > changes, but you will be part of the IETF if this work happens. > You will be part of the group deciding what changes to make. > > > The chairs believed there may be a rough consensus in favor of trying > to develop an oauth 1.1, but the consensus was rather weak. There > definitely is not a consensus to start fresh, but people seem to need > more information to make a decision on what level of compatibility is > required. > > > Ted Hardie: Negotiation and extensibility will be important as changes are made. > > > Blocking issues in the charter: > > Greg Lebobits wants us to commit to fixing security problems in some > possibly incremental time frame rather than simply documenting gaps. > > > Stephen Farrell believes that the mobile use cases need to be discussed in the charter. > rlbob believes that negotiation is needed and has a blocker re/related to service discovery. > > Ekr wants to understand what level of backward compatibility is required and what changes are acceptable. > > Sam wants channel binding and mutual authentication as a security > option. > > Potential document authors:Jeff Hodges, Eran, Blain, Larry, > ekr, Hannes, Stephen Farrell, David Recordon > > Dave Crocker would be willing to be considered as a chair. > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sat Dec 13 05:53:58 2008 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 6FD2B3A6A0B; Sat, 13 Dec 2008 05:53:58 -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 1C2323A684A for ; Sat, 13 Dec 2008 05:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.18 X-Spam-Level: X-Spam-Status: No, score=0.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcwTAOGeYmZT for ; Sat, 13 Dec 2008 05:53:56 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (m4f7c36d0.tmodns.net [208.54.124.79]) by core3.amsl.com (Postfix) with ESMTP id B79C63A6A0B for ; Sat, 13 Dec 2008 05:53:54 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 603244267; Fri, 12 Dec 2008 12:14:41 -0500 (EST) From: Sam Hartman To: oauth@ietf.org Date: Thu, 11 Dec 2008 17:24:52 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Subject: [oauth] Interoperability and Backwards Compatibility 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 The next steps for us to take are to resolve the open issues on a charter and propose a charter to the IESG. In this discussion, I'm participating as an individual: my role as a BOF chair only extended through the meeting. Lisa may at some point select working group chairs or potential working group chairs, and these people will presumably try and get consensus here even before the working group is formed. One of the big issues surrounded what level of compatibility we want to have between whatever we develop and oauth 1.0. There are a few things that may not be obvious to those outside the IETF. In general, the IETF would never change the contents of something that were signed or hashed in a protocol like oauth without changing the name of the signature mechanism or some similar name. If there are two ways to do things and one allows implementers to distinguish the "old behavior" from the "new behavior," then the IETF prefers mechanisms that allow this sort of distinguishability. We have sometimes done something different, but it was explicitly because some implementations did it one way and some did it another and we wanted to maintain compatibility with someone rather than breaking everyone. Those cases typically are either very obvious (the spec is wrong and everyone does it the same way; we fix the spec) or heavily debated. I don't think they are likely to apply to oauth. So, what sorts of commitments to compatibility could we make? Well, the simplest is none. We could charter a working group without reference to the existing spec. Presumably someone would propose that the existing spec be used as input to the WG, but what that would mean would be debated in the WG itself. I suspect this would make no one happy; personally I do not support it. We could write a charter that says the work of the working group will be based on the existing oauth specification. What that means is that the working group inherently accepts the existing spec as a working group document. In order to change the document, there has to be rough consensus in the WG. In other words, the current spec would be a starting point. This has a fair amount of power: if someone proposes making a change and there is no agreement to do so, then things remain as they are in the current spec. Note that this would allow Eric to propose changes to use existing elements for HTTP authentication, or to try and pull apart how the document and protocol features are decomposed to try and address his concerns. If he gained consensus in the WG, the changes would be made. (I'm singling Eric out because he was particularly interested in how much compatibility we are offering.) In addition to basing the work on the existing spec, we could add some language to the charter indicating that compatibility is a goal. I'm not sure that this would have a significant effect other than allowing someone to bring up the argument that a change is not a good idea because it breaks compatibility. Someone can already bring up that claim, and it will be discussed in the WG like anything else. We could have language similar to the DKIM or XMPP charter saying that incompatible changes will only be made if they are necessary to meet the technical requirements of the WG. This has the effect of allowing a contributor or chair to argue that some change is unnecessary. To make the change, the group would need to agree both on the change and that it is required to meet the technical requirements of the group. I'd expect the group to need to agree on which technical requirement was impossible without the change. My personal opinion is that basing the work of the WG on the existing spec is sufficient. If oauth implementers and users show up, then they will be able to argue against changes that do not balance compatibility against value. If they don't show up, the work will be useless anyway. --Sam _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Tue Dec 16 00:02:01 2008 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 EE9AA28C125; Tue, 16 Dec 2008 00:02:01 -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 41B3828C125 for ; Tue, 16 Dec 2008 00:02:00 -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 oUom9WUlSyET for ; Tue, 16 Dec 2008 00:01:53 -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 A37F728C131 for ; Tue, 16 Dec 2008 00:00:57 -0800 (PST) Received: by qyk4 with SMTP id 4so3065168qyk.13 for ; Tue, 16 Dec 2008 00:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=PMP6d9TJ9C+FflFubAovOBswoYpOW2XnGvnc0cdg+P0=; b=hnogRqQy7k6A32xZylvU33X6GHBsJWqwTH8+PdyeFeDDhcXHsPZAmIl0cF58p10Gjk dVd71nQKKPW0TNigTQ+aoTYrARpxFQfZo+tZBn+eAAc0JzClDwk57ygQ//VXizbpWEUX CUdSvo8iGkM6+gwLjYHTLF32uhwhL9/AJNF7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vcmjiSOv7LbFaN6DMI9FxUItgJT++mqCuDmSugSJrSoCTrUHxum5OiMrohL7m/60FF pxOr1BsgE3LiV1Sc/m8g6de7Owfn2XU3sH6aCJNyBtzsQxxU+/gdAuhOgQfc/M5rdL9k 9/pTbornUgaLFrIOZ9QTJc2LJGzfs8WUHfLnE= Received: by 10.214.59.5 with SMTP id h5mr8950518qaa.187.1229414449271; Tue, 16 Dec 2008 00:00:49 -0800 (PST) Received: by 10.215.14.17 with HTTP; Tue, 16 Dec 2008 00:00:49 -0800 (PST) Message-ID: <6c0fd2bc0812160000p19933582r875df6f436e48088@mail.gmail.com> Date: Tue, 16 Dec 2008 09:00:49 +0100 From: "Hubert Le Van Gong" To: "Sam Hartman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Sam, Nice summary of the current state of affairs. IMHO starting from the existing spec makes sense but compatibility with existing OAuth 1.0 implementations cannot prevent changes to it. Adding something (taken verbatim from the XMPP charter) like the paragraph below will leave some leeway to make (deemed) necessary changes. "Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them." I like the idea Philip mentioned in a previous email on the list about having the CFRG issuing RFC on recommended crypto methods. This could be one of the deliverables for this charter. I would actually recommend this list includes at least one mandated algo to ensure interoperability between implementations of the resulting IETF spec - this is also an essential (and obvious) goal. BTW, was there a timeline created for this effort? Cheers, Hubert On Thu, Dec 11, 2008 at 11:24 PM, Sam Hartman wrote: > > > The next steps for us to take are to resolve the open issues on a > charter and propose a charter to the IESG. In this discussion, I'm > participating as an individual: my role as a BOF chair only extended > through the meeting. Lisa may at some point select working group > chairs or potential working group chairs, and these people will > presumably try and get consensus here even before the working group is > formed. > > > One of the big issues surrounded what level of compatibility we want > to have between whatever we develop and oauth 1.0. > > There are a few things that may not be obvious to those outside the > IETF. In general, the IETF would never change the contents of > something that were signed or hashed in a protocol like oauth without > changing the name of the signature mechanism or some similar name. If > there are two ways to do things and one allows implementers to > distinguish the "old behavior" from the "new behavior," then the IETF > prefers mechanisms that allow this sort of distinguishability. We > have sometimes done something different, but it was explicitly because > some implementations did it one way and some did it another and we > wanted to maintain compatibility with someone rather than breaking > everyone. Those cases typically are either very obvious (the spec is > wrong and everyone does it the same way; we fix the spec) or heavily > debated. I don't think they are likely to apply to oauth. > > So, what sorts of commitments to compatibility could we make? > > Well, the simplest is none. We could charter a working group without > reference to the existing spec. Presumably someone would propose that > the existing spec be used as input to the WG, but what that would mean > would be debated in the WG itself. I suspect this would make no one > happy; personally I do not support it. > > We could write a charter that says the work of the working group will > be based on the existing oauth specification. What that means is that > the working group inherently accepts the existing spec as a working > group document. In order to change the document, there has to be > rough consensus in the WG. In other words, the current spec would be > a starting point. This has a fair amount of power: if someone > proposes making a change and there is no agreement to do so, then > things remain as they are in the current spec. > > Note that this would allow Eric to propose changes to use existing > elements for HTTP authentication, or to try and pull apart how the > document and protocol features are decomposed to try and address his > concerns. If he gained consensus in the WG, the changes would be > made. > (I'm singling Eric out because he was particularly interested in how > much compatibility we are offering.) > > In addition to basing the work on the existing spec, we could add some > language to the charter indicating that compatibility is a goal. I'm > not sure that this would have a significant effect other than allowing > someone to bring up the argument that a change is not a good idea > because it breaks compatibility. Someone can already bring up that > claim, and it will be discussed in the WG like anything else. > > We could have language similar to the DKIM or XMPP charter saying that > incompatible changes will only be made if they are necessary to meet > the technical requirements of the WG. This has the effect of allowing > a contributor or chair to argue that some change is unnecessary. To > make the change, the group would need to agree both on the change and > that it is required to meet the technical requirements of the group. > I'd expect the group to need to agree on which technical requirement > was impossible without the change. > > My personal opinion is that basing the work of the WG on the existing > spec is sufficient. If oauth implementers and users show up, then > they will be able to argue against changes that do not balance > compatibility against value. If they don't show up, the work will be > useless anyway. > > > --Sam > _______________________________________________ > 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 Tue Dec 16 10:06:02 2008 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 98C1C3A6979; Tue, 16 Dec 2008 10:06:02 -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 30CE03A6906 for ; Tue, 16 Dec 2008 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+NITcou8wsa for ; Tue, 16 Dec 2008 10:06:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7A2453A68DD for ; Tue, 16 Dec 2008 10:06:00 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C4E1D451A; Tue, 16 Dec 2008 13:05:52 -0500 (EST) From: Sam Hartman To: "Hubert Le Van Gong" References: <6c0fd2bc0812160000p19933582r875df6f436e48088@mail.gmail.com> Date: Tue, 16 Dec 2008 13:05:52 -0500 In-Reply-To: <6c0fd2bc0812160000p19933582r875df6f436e48088@mail.gmail.com> (Hubert Le Van Gong's message of "Tue, 16 Dec 2008 09:00:49 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 >>>>> "Hubert" == Hubert Le Van Gong writes: Hubert> Hello Sam, Nice summary of the current state of affairs. Hubert> IMHO starting from the existing spec makes sense but Hubert> compatibility with existing OAuth 1.0 implementations Hubert> cannot prevent changes to it. Adding something (taken Hubert> verbatim from the XMPP charter) like the paragraph below Hubert> will leave some leeway to make (deemed) necessary changes. Hubert> "Although not encouraged, non-backwards-compatible changes Hubert> to the basis specifications will be acceptable if the Hubert> working group determines that the changes are required to Hubert> meet the group's technical objectives and the group Hubert> clearly documents the reasons for making them." I mentioned this as the third option. My question to you is what changes do you believe that the WG would have consensus to approve that would be blocked by this paragraph?Or alternatively, how do you believe this would help? _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Tue Dec 16 23:13:02 2008 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 0328A3A6AF5; Tue, 16 Dec 2008 23:13:02 -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 145153A6AF3 for ; Tue, 16 Dec 2008 23:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDqED09ljcZM for ; Tue, 16 Dec 2008 23:12:59 -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 2EEA23A6AEB for ; Tue, 16 Dec 2008 23:12:59 -0800 (PST) Received: by qyk4 with SMTP id 4so3603479qyk.13 for ; Tue, 16 Dec 2008 23:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/DJokiEbOit6cfcEfkXdDe+A/LtEwv0br+gk3c1vQ2c=; b=HQ0SS95GC6qlqC8mNRDrZu9uTPqHVCSwbDuK/DklFrIJf/p5naGow9SD8UVTYnQGb+ a2tozuehrHUwgfVqY9+Kn/DKKo+cP8qB00fFLmUr/luoVVQKBUBakHoUZjVTB8K5Qsga VM/QydtBPuMzeg5PQc6JA9Z0QXK+EH+AMM8fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=f9l6PvcUoOYhJ9oqufuH7QffQvZVdfox+Ge0OU1JSygsHaCdvcSmcnPJYQ7i5xazM5 mWDhvI758eJ/mpEJek2tybMSbwZSbOb1NO4cBb3uKQ1u9D2QfedBxzV1EqpdHYa4yD3u yfcd0e/mdEKJmU7ckoDN5BCdjnOggJ2DgFl6M= Received: by 10.214.217.14 with SMTP id p14mr370386qag.272.1229497971193; Tue, 16 Dec 2008 23:12:51 -0800 (PST) Received: by 10.214.241.7 with HTTP; Tue, 16 Dec 2008 23:12:51 -0800 (PST) Message-ID: <6c0fd2bc0812162312j4adf7a71ye719bcfc4089f7cf@mail.gmail.com> Date: Wed, 17 Dec 2008 08:12:51 +0100 From: "Hubert Le Van Gong" To: "Sam Hartman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <6c0fd2bc0812160000p19933582r875df6f436e48088@mail.gmail.com> Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Indeed I was expressing support for the third option you had mentioned. I think this paragraph highlights a usual occurrence in the standardization process of an existing specification: the input document is very seldom the same as the output document (i.e. this is not a rubber stamp session). Therefore, changes that might break backward compatibility are a possibility. In my experience it is always better to set things straight in the charter. Cheers, Hubert On Tue, Dec 16, 2008 at 7:05 PM, Sam Hartman wrote: >>>>>> "Hubert" == Hubert Le Van Gong writes: > > Hubert> Hello Sam, Nice summary of the current state of affairs. > Hubert> IMHO starting from the existing spec makes sense but > Hubert> compatibility with existing OAuth 1.0 implementations > Hubert> cannot prevent changes to it. Adding something (taken > Hubert> verbatim from the XMPP charter) like the paragraph below > Hubert> will leave some leeway to make (deemed) necessary changes. > > Hubert> "Although not encouraged, non-backwards-compatible changes > Hubert> to the basis specifications will be acceptable if the > Hubert> working group determines that the changes are required to > Hubert> meet the group's technical objectives and the group > Hubert> clearly documents the reasons for making them." > > > I mentioned this as the third option. My question to you is what > changes do you believe that the WG would have consensus to approve > that would be blocked by this paragraph?Or alternatively, how do you believe this would help? > > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Wed Dec 17 05:46:41 2008 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 ED8153A697A; Wed, 17 Dec 2008 05:46:41 -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 456843A6999 for ; Wed, 17 Dec 2008 05:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOq3GL2cw0ht for ; Wed, 17 Dec 2008 05:43:00 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 046C53A6AB3 for ; Wed, 17 Dec 2008 05:42:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3750486wfd.31 for ; Wed, 17 Dec 2008 05:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Z/F6X8ZvNOUNsz5PSY4yN2ffAALOEeeqUZXjnjRGBSg=; b=nZR0tsvGoup13vQ8BihmMTKGrMYeWs+zVMAAmwxK4XjPpn8ftMfFPMiSIKMpNTvfZ0 6HkcKNGTQjFgm+K5q6Y52ATKoc7KACmX7eQOf8Cj2H/it7Gj3cevy4Bp+KMTJM/sy9jD mnlFTQDv31qtDjNCWlEYiu9+NZCSPE6nwp/Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=vh0RHNK23kpehDtnfh1yJBurmlGEoxP4kJXUB62Wh7naoysXofcqmg7mrhZhBf0a2B Q8cWWoGG47WSNmigCa0rWFGvgIXOQ03mzOFj0dLn4NnJymfPTkUOrfUJ1ohkNwnFULNs 82wcm9vTm5INKxTiH8xn80ENFTLjF+7Na2nC8= Received: by 10.142.163.13 with SMTP id l13mr308601wfe.39.1229521371307; Wed, 17 Dec 2008 05:42:51 -0800 (PST) Received: by 10.143.31.18 with HTTP; Wed, 17 Dec 2008 05:42:51 -0800 (PST) Message-ID: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> Date: Wed, 17 Dec 2008 08:42:51 -0500 From: kellan To: "Sam Hartman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: fe0c544ba65251fe Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman wrote: > > One of the big issues surrounded what level of compatibility we want > to have between whatever we develop and oauth 1.0. > Just to be dense, why would there, or should there be compatibility changes? OAuth represents an extraction for the current crop of best practices in the space, a design philosophy that has been key in its meteoric acceptance. -kellan _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Wed Dec 17 06:01:30 2008 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 8BECD28C1E8; Wed, 17 Dec 2008 06:01:30 -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 22FE728C1E8 for ; Wed, 17 Dec 2008 06:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qweZzt-24zr for ; Wed, 17 Dec 2008 06:01:17 -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 332C228C1E7 for ; Wed, 17 Dec 2008 06:01:15 -0800 (PST) Received: by qyk4 with SMTP id 4so3740286qyk.13 for ; Wed, 17 Dec 2008 06:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WRsCL8A6IVQSymKYzN4Iasn/AEh2wKOFFZMuG3mHtpw=; b=RDZ8jmOz2KedsuMlojErbZ5Muk05X6MWlBTyRwl2pLPZI6EoZ++CbeKEwlIka7pzpP P+/rxZgJk1yrwEXIN4IfSz32Xu4hi62Ck4/JBqYLyn/G3kFV118VFJajfvBtD1y1KHBm N6ZpLWzezg1m8hjNJPDskRbDg5ZJ0QfGm3HF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fUqQ7E3M7lfQzbQSNB4awOKR4DIhn9rm2gkwu4UE+s+0Fm7W/i05ggAd1P+8msLEIS JTqwDokhVHF9ZNglvULO10oWwyWcp6Uu1LDrnREZjytnvyjY8yNZtTUMaPB/QK93gXNG KLZQBlWbesjDcv64FxCCjk45YiVGCojXita/w= Received: by 10.214.79.7 with SMTP id c7mr757020qab.357.1229522467708; Wed, 17 Dec 2008 06:01:07 -0800 (PST) Received: by 10.214.241.7 with HTTP; Wed, 17 Dec 2008 06:01:07 -0800 (PST) Message-ID: <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> Date: Wed, 17 Dec 2008 15:01:07 +0100 From: "Hubert Le Van Gong" To: kellan In-Reply-To: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Every time you submit a document as input to a standardization process, no matter how good it is, you face the possibility of seeing it changed. Otherwise why bother? Those changes may or may not introduce incompatibilities with some existing deployments. Examples (and those are *only* examples) might be the formal specification of the 2-legged version or the introduction of new security requirements. Cheers, Hubert On Wed, Dec 17, 2008 at 2:42 PM, kellan wrote: > On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman wrote: >> >> One of the big issues surrounded what level of compatibility we want >> to have between whatever we develop and oauth 1.0. >> > > Just to be dense, why would there, or should there be compatibility changes? > > OAuth represents an extraction for the current crop of best practices > in the space, a design philosophy that has been key in its meteoric > acceptance. > > -kellan > _______________________________________________ > 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 Wed Dec 17 06:33:06 2008 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 AEADE3A6905; Wed, 17 Dec 2008 06:33:06 -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 EF6103A6B02 for ; Wed, 17 Dec 2008 06:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEl2-0U6M2Ub for ; Wed, 17 Dec 2008 06:33:05 -0800 (PST) Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id 3B38D3A68EF for ; Wed, 17 Dec 2008 06:33:05 -0800 (PST) Received: from [192.168.2.147] (87-198-172-217.ptr.magnet.ie [87.198.172.217]) by chilco.textdrive.com (Postfix) with ESMTP id 1CB64DD562 for ; Wed, 17 Dec 2008 09:44:13 +0000 (UTC) Message-ID: <4948C9E9.8040204@dehora.net> Date: Wed, 17 Dec 2008 09:44:09 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: oauth@ietf.org References: <6c0fd2bc0812160000p19933582r875df6f436e48088@mail.gmail.com> <6c0fd2bc0812162312j4adf7a71ye719bcfc4089f7cf@mail.gmail.com> In-Reply-To: <6c0fd2bc0812162312j4adf7a71ye719bcfc4089f7cf@mail.gmail.com> Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Is it worthwhile released a draft that contains the same text as the current specification? It would be eseentially a reformatting, that allows people to track changes more easily in future revisions. It might also help get this group moving ;) Bill Hubert Le Van Gong wrote: > Indeed I was expressing support for the third option you had mentioned. > I think this paragraph highlights a usual occurrence in the standardization > process of an existing specification: the input document is very seldom > the same as the output document (i.e. this is not a rubber stamp session). > Therefore, changes that might break backward compatibility are a possibility. > In my experience it is always better to set things straight in the charter. > > Cheers, > Hubert > > > On Tue, Dec 16, 2008 at 7:05 PM, Sam Hartman wrote: >>>>>>> "Hubert" == Hubert Le Van Gong writes: >> Hubert> Hello Sam, Nice summary of the current state of affairs. >> Hubert> IMHO starting from the existing spec makes sense but >> Hubert> compatibility with existing OAuth 1.0 implementations >> Hubert> cannot prevent changes to it. Adding something (taken >> Hubert> verbatim from the XMPP charter) like the paragraph below >> Hubert> will leave some leeway to make (deemed) necessary changes. >> >> Hubert> "Although not encouraged, non-backwards-compatible changes >> Hubert> to the basis specifications will be acceptable if the >> Hubert> working group determines that the changes are required to >> Hubert> meet the group's technical objectives and the group >> Hubert> clearly documents the reasons for making them." >> >> >> I mentioned this as the third option. My question to you is what >> changes do you believe that the WG would have consensus to approve >> that would be blocked by this paragraph?Or alternatively, how do you believe this would help? >> >> > _______________________________________________ > 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 Wed Dec 17 08:50:48 2008 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 896613A6956; Wed, 17 Dec 2008 08:50:48 -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 6103A3A6956 for ; Wed, 17 Dec 2008 08:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEwnKYENzUkj for ; Wed, 17 Dec 2008 08:50:46 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 521283A6863 for ; Wed, 17 Dec 2008 08:50:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id E5B9B100415B7; Wed, 17 Dec 2008 16:50:36 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7mGuOA0oO-2; Wed, 17 Dec 2008 16:50:34 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 32A3810040701; Wed, 17 Dec 2008 16:50:34 +0000 (GMT) Message-ID: <49492E03.9050101@cs.tcd.ie> Date: Wed, 17 Dec 2008 16:51:15 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Hubert Le Van Gong References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> In-Reply-To: <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> X-Enigmail-Version: 0.95.7 Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 In the case of DKIM, we made only a few technical changes to the domainkeys spec, you can get a feel for what happened by comparing the relevant RFCs. Domainkeys (the starting spec) is RFC 4870, the resulting DKIM standard is RFC 4871. (We published those at the same time, partly to encourage folks to move to DKIM, which might or might not be worth doing again.) My impression is that in this case there'd be some crypto related changes, but I would imagine that those could (as happened with DKIM) be done so as to require just software updates, so that existing OAuth configurations could still work. However, I think the mobile use-case we presented might be a bigger change, hence our suggestion to document that in a separate RFC, which would have to be mentioned in the charter of course. I'm not sure if any of the other things people would like to change could be handled similarly. (BTW - can someone post that review EKR said he'd done but couldn't post to the other list?) Overall, I like the approach of copying from the XMPP or DKIM charter text. I don't think we need to specifically call out the "allowed changes" though, since people who want to suggest changes will do so anyway but from what I saw at the BoF I reckon the WG is unlikely to reach rough consensus on gratuitous changes so I don't think we need a list in the charter. S. Hubert Le Van Gong wrote: > Every time you submit a document as input to a standardization process, > no matter how good it is, you face the possibility of seeing it changed. > Otherwise why bother? > Those changes may or may not introduce incompatibilities with some > existing deployments. > Examples (and those are *only* examples) might be the formal specification > of the 2-legged version or the introduction of new security requirements. > > Cheers, > Hubert > > On Wed, Dec 17, 2008 at 2:42 PM, kellan wrote: >> On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman wrote: >>> One of the big issues surrounded what level of compatibility we want >>> to have between whatever we develop and oauth 1.0. >>> >> Just to be dense, why would there, or should there be compatibility changes? >> >> OAuth represents an extraction for the current crop of best practices >> in the space, a design philosophy that has been key in its meteoric >> acceptance. >> >> -kellan >> _______________________________________________ >> 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 Wed Dec 17 08:58:37 2008 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 2242928C195; Wed, 17 Dec 2008 08:58:37 -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 A3D4B28C195 for ; Wed, 17 Dec 2008 08:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC8c54doAEmz for ; Wed, 17 Dec 2008 08:58:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E134A28C170 for ; Wed, 17 Dec 2008 08:58:34 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 824DE451A; Wed, 17 Dec 2008 11:58:24 -0500 (EST) From: Sam Hartman To: kellan References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> Date: Wed, 17 Dec 2008 11:58:24 -0500 In-Reply-To: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> (kellan@pobox.com's message of "Wed, 17 Dec 2008 08:42:51 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 >>>>> "kellan" == kellan writes: kellan> On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman kellan> wrote: >> One of the big issues surrounded what level of compatibility >> we want to have between whatever we develop and oauth 1.0. >> kellan> Just to be dense, why would there, or should there be kellan> compatibility changes? Well, let's start with why should there be changes at all. If you don't think there should be changes, or you don't want to give change control to the IETF, then you don't want to form a working group within the IETF. Once you agree there are changes needed, you first have to answer the question of what changes are incompatible (something I side-stepped because it's kind of hard) before you can answer the question of why/if there need to be incompatible changes. It is very likely that answering the question of what bar should incompatible changes need to meet is easier than answering the question of what is an incompatible change. Some areas where I personally think there will be incompatible changes? The IETF almost always requires mandatory-to-implement security mechanisms for its specifications. Oauth currently has no mandatory-to-implement security mechanism. So, it's likely that whatever comes out the other end of the IETF will be different in that respect. Do you view that as an incompatible change? The argument for yes is that there exist oauth implementations today that comply with the current spec and will not comply with that spec. Do you view it as a problem? I hope not. I gave examples of areas where I think changes would be a really good idea in my security review. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Wed Dec 17 11:37:21 2008 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 762723A6AEA; Wed, 17 Dec 2008 11:37: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 5C0113A6AEA for ; Wed, 17 Dec 2008 11:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuG5N2OXv1uB for ; Wed, 17 Dec 2008 11:37:19 -0800 (PST) Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by core3.amsl.com (Postfix) with ESMTP id 883C93A67A8 for ; Wed, 17 Dec 2008 11:37:19 -0800 (PST) Received: from [68.29.183.216] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id BD7471F8F; Wed, 17 Dec 2008 11:41:55 -0800 (PST) From: Aaron Stone To: oauth@ietf.org, oauth@googlegroups.com In-Reply-To: <49492E03.9050101@cs.tcd.ie> References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> <49492E03.9050101@cs.tcd.ie> Date: Wed, 17 Dec 2008 11:33:03 -0800 Message-Id: <1229542383.29598.6394.camel@turtle> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 CC: OAuth@googlegroups: There's still a lot of OAuth discussion taking place on the Google Group. If the intention was to retire that list and move it to the IETF list, we have a buy-in problem. IMHO, a dual-list situation isn't good because we'll have implementers on one list and standardizers on another list. Better if we're all in the same place. Please make sure that you're subscribed to the oauth@ietf.org mailing list if you're interested in what's going into OAuth 1.1! Re: Interop: +1 for language that says change may occur. +1 for listing things we do know we need to work on. -1 against listing a closed set of allowable changes. We have some preliminary notions of what might change, but part of the WG process is to figure out what we don't know yet. It's already clear that there is a high bar for incompatible changes to get WG consensus. Requiring a re-charter to address as-yet-unknown issues is too much. Cheers, Aaron On Wed, 2008-12-17 at 16:51 +0000, Stephen Farrell wrote: [snip] > Overall, I like the approach of copying from the > XMPP or DKIM charter text. I don't think we need > to specifically call out the "allowed changes" > though, since people who want to suggest changes > will do so anyway but from what I saw at the BoF > I reckon the WG is unlikely to reach rough consensus > on gratuitous changes so I don't think we need > a list in the charter. > > S. > > > Hubert Le Van Gong wrote: > > Every time you submit a document as input to a standardization process, > > no matter how good it is, you face the possibility of seeing it changed. > > Otherwise why bother? > > Those changes may or may not introduce incompatibilities with some > > existing deployments. > > Examples (and those are *only* examples) might be the formal specification > > of the 2-legged version or the introduction of new security requirements. > > > > Cheers, > > Hubert > > > > On Wed, Dec 17, 2008 at 2:42 PM, kellan wrote: > >> On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman wrote: > >>> One of the big issues surrounded what level of compatibility we want > >>> to have between whatever we develop and oauth 1.0. > >>> > >> Just to be dense, why would there, or should there be compatibility changes? > >> > >> OAuth represents an extraction for the current crop of best practices > >> in the space, a design philosophy that has been key in its meteoric > >> acceptance. > >> > >> -kellan > >> _______________________________________________ _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Wed Dec 17 23:09:08 2008 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 98D7C3A6783; Wed, 17 Dec 2008 23:09: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 CA35C3A6783 for ; Wed, 17 Dec 2008 23:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKc4mcJcMwE2 for ; Wed, 17 Dec 2008 23:09:07 -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 C50A33A6403 for ; Wed, 17 Dec 2008 23:09:06 -0800 (PST) Received: by qyk4 with SMTP id 4so309458qyk.13 for ; Wed, 17 Dec 2008 23:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2B8xchqx2QgL83gKz2++fZQiTpZD95kVuRI0yItdxJg=; b=sEoorwRO/Bu3/bFD3LIvABVK4rE3IkvFFztnOsyEJVvtHNJJ1SXiu8cEqo/DjOyjYL dQbbAlMsinY3eK8z60Pq5vO5aLv98OPw/+YtBhKhjvttLn9gj2R2ndYtru+fCnWIaNDn XkfSu23kSVqWcXOyKYByRtCa8IQEvxo7KERTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tD7iFdl6NkNundD3Mj89Iyn4m4f/sMLszIgv39wdIZLj3FJ+RyX5Y7tvV0lN4PGm3R 7uypYBrcl6/ywKVIXxDeWb2cHB/GcAIxGNlTfTR4Qr6IEFQcdBaE+8RiVSolKsg3Vu// sTmE1o+SNof2Tw9K61Su7+JaZFH1CUOriIYiQ= Received: by 10.215.67.17 with SMTP id u17mr2031280qak.144.1229584138005; Wed, 17 Dec 2008 23:08:58 -0800 (PST) Received: by 10.214.241.7 with HTTP; Wed, 17 Dec 2008 23:08:57 -0800 (PST) Message-ID: <6c0fd2bc0812172308o201d6e5w4295e871c199b704@mail.gmail.com> Date: Thu, 18 Dec 2008 08:08:57 +0100 From: "Hubert Le Van Gong" To: "Aaron Stone" In-Reply-To: <1229542383.29598.6394.camel@turtle> MIME-Version: 1.0 Content-Disposition: inline References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> <49492E03.9050101@cs.tcd.ie> <1229542383.29598.6394.camel@turtle> Cc: oauth@googlegroups.com, oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 I don't think it was suggested to list allowable changes in the charter; if so I would certainly disagree too. >From what you wrote should I understand a charter has already been created? If so where is it available? Cheers, Hubert On Wed, Dec 17, 2008 at 8:33 PM, Aaron Stone wrote: > CC: OAuth@googlegroups: > There's still a lot of OAuth discussion taking place on the Google > Group. If the intention was to retire that list and move it to the IETF > list, we have a buy-in problem. IMHO, a dual-list situation isn't good > because we'll have implementers on one list and standardizers on another > list. Better if we're all in the same place. > > Please make sure that you're subscribed to the oauth@ietf.org mailing > list if you're interested in what's going into OAuth 1.1! > > Re: Interop: > +1 for language that says change may occur. > +1 for listing things we do know we need to work on. > > -1 against listing a closed set of allowable changes. > > We have some preliminary notions of what might change, but part of the > WG process is to figure out what we don't know yet. It's already clear > that there is a high bar for incompatible changes to get WG consensus. > Requiring a re-charter to address as-yet-unknown issues is too much. > > Cheers, > Aaron > > > On Wed, 2008-12-17 at 16:51 +0000, Stephen Farrell wrote: > [snip] >> Overall, I like the approach of copying from the >> XMPP or DKIM charter text. I don't think we need >> to specifically call out the "allowed changes" >> though, since people who want to suggest changes >> will do so anyway but from what I saw at the BoF >> I reckon the WG is unlikely to reach rough consensus >> on gratuitous changes so I don't think we need >> a list in the charter. >> _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 04:24:45 2008 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 B052128C21F; Thu, 18 Dec 2008 04:24:45 -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 27F8828C21B for ; Thu, 18 Dec 2008 04:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.921 X-Spam-Level: X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PRtfG4Uy7Ui for ; Thu, 18 Dec 2008 04:24:43 -0800 (PST) Received: from IE1EHSOBE003.bigfish.com (outbound-dub.frontbridge.com [213.199.154.16]) by core3.amsl.com (Postfix) with ESMTP id DD41C3A6933 for ; Thu, 18 Dec 2008 04:24:42 -0800 (PST) Received: from mail129-dub-R.bigfish.com (10.5.252.3) by IE1EHSOBE003.bigfish.com (10.5.252.23) with Microsoft SMTP Server id 8.1.291.1; Thu, 18 Dec 2008 12:24:34 +0000 Received: from mail129-dub (localhost.localdomain [127.0.0.1]) by mail129-dub-R.bigfish.com (Postfix) with ESMTP id 49DA81B4819F; Thu, 18 Dec 2008 12:24:34 +0000 (UTC) X-BigFish: VPS10(zz98dRzzzzz2dh6bh87il62h) X-Spam-TCS-SCL: 1:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail129-dub (MessageSwitch) id 1229603074117192_29437; Thu, 18 Dec 2008 12:24:34 +0000 (UCT) Received: from imx1.tcd.ie (imx1.tcd.ie [134.226.17.160]) by mail129-dub.bigfish.com (Postfix) with ESMTP id 069EC8F8053; Thu, 18 Dec 2008 12:24:34 +0000 (UTC) Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160]) by imx1.tcd.ie (Postfix) with SMTP id E9B5F496E; Thu, 18 Dec 2008 12:24:33 +0000 (GMT) Received: from imx1.tcd.ie ([134.226.17.160]) by imx1 ([127.0.0.1]) with SMTP (gateway) id A02FA6E4D56; Thu, 18 Dec 2008 12:24:33 +0000 Received: from [134.226.36.140] (unknown [134.226.36.140]) by imx1.tcd.ie (Postfix) with ESMTP id 4A7AB4971; Thu, 18 Dec 2008 12:24:33 +0000 (GMT) Message-ID: <494A412B.9080507@cs.tcd.ie> Date: Thu, 18 Dec 2008 12:25:15 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Aaron Stone References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> <6c0fd2bc0812170601j1c876fa4kda66644200447141@mail.gmail.com> <49492E03.9050101@cs.tcd.ie> <1229542383.29598.6394.camel@turtle> In-Reply-To: <1229542383.29598.6394.camel@turtle> X-Enigmail-Version: 0.95.7 X-AntiVirus-Status: MessageID = A12FA6E4D56 X-AntiVirus-Status: Host: imx1.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.98.1) Cc: oauth@googlegroups.com, oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Aaron Stone wrote: > CC: OAuth@googlegroups: > If the intention was to retire that list and move it to the IETF > list, we have a buy-in problem. Well, I'd reckon keeping both going at least until there is a WG formed would be better. Some IETF WGs also have associated lists that discuss specific implementation and/or deployment issues, so its not that unusual a situation and is ok so long as there's sufficient overlap of the right people. S. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 09:54:01 2008 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 B7ACA3A69FB; Thu, 18 Dec 2008 09:54:01 -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 594473A68D8 for ; Thu, 18 Dec 2008 09:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=-4.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CoIpxJwoZgP for ; Thu, 18 Dec 2008 09:53:59 -0800 (PST) Received: from outbound-mail-159.bluehost.com (outbound-mail-159.bluehost.com [67.222.39.39]) by core3.amsl.com (Postfix) with SMTP id A089E3A679C for ; Thu, 18 Dec 2008 09:53:59 -0800 (PST) Received: (qmail 15857 invoked by uid 0); 18 Dec 2008 17:52:31 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy5.bluehost.com with SMTP; 18 Dec 2008 17:52:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ojBPEGE6mKwGaD9lfrpSzA0O67iMmtwMYeiGcZzRlVrulmA/kJzmHfPyVnN4gvvd8hp4eINnyDIAQ1l/poz5HGKfFWOb3dnZGAJcp3VNi9HstGQZhPQZ9rKihxhZGmqr; Received: from c-75-69-14-217.hsd1.vt.comcast.net ([75.69.14.217] helo=[192.168.0.50]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LDN3f-0007FP-Go; Thu, 18 Dec 2008 10:53:11 -0700 Message-ID: <494A8E0F.7040008@jkemp.net> Date: Thu, 18 Dec 2008 12:53:19 -0500 From: John Kemp User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sam Hartman References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> In-Reply-To: X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 75.69.14.217 authed with john+jkemp.net} Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 Sam Hartman wrote: ... > > I gave examples of areas where I think changes would be a really good > idea in my security review. Checking the archives of this list, I can't immediately see where this security review is posted. Is it possible to provide a link to your review? Regards, - johnk _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 11:30:09 2008 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 A3C0F3A6B7B; Thu, 18 Dec 2008 11:30: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 C008B3A6B7B for ; Thu, 18 Dec 2008 11:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=-3.438, 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 5F323xVwx9Yu for ; Thu, 18 Dec 2008 11:30:05 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id ADE403A6915 for ; Thu, 18 Dec 2008 11:30:05 -0800 (PST) Received: (qmail 4795 invoked from network); 18 Dec 2008 19:16:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Dec 2008 19:16:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 18 Dec 2008 12:16:21 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 18 Dec 2008 12:16:19 -0700 Thread-Topic: Review of draft-hammer-oauth Thread-Index: AckyDcfNg02TwR0aSHSywZlsL1CAZQvN1MsO Message-ID: In-Reply-To: <20081019163556.916656D0085@kilo.rtfm.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [oauth] FW: Review of draft-hammer-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: , Content-Type: multipart/mixed; boundary="===============1157660812==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============1157660812== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C56FE183101DCeranhueniversecom_" --_000_C56FE183101DCeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------ Forwarded Message From: Eric Rescorla Date: Sun, 19 Oct 2008 09:35:56 -0700 To: Cc: , Subject: Review of draft-hammer-oauth $Id: draft-hammer-oauth-00-rev.txt,v 1.1 2008/10/18 20:56:37 ekr Exp $ This document describes a set of protocols for delegated access to resources. The paradigmatic case here is photo printing. User U has a set of photos on service provider SP (e.g., Flickr) and wants to have them printed by some printing service (called a Consumer, so C) and so needs to give C permission to access some set of photos on SP. This document actually describes three related but independent technical artifacts: - A set of new HTTP authentication mechanisms, including a shared secret mechanism based on HMAC-SHA1 and a digital signature mechanism based on RSA. - A set of message flows for a user to authorize a Consumer to access a given object. - A token mechanism for the SP to offload storage onto the Consumer. These are quite separable and should be standardized independently, if at all. In particular, if new authentication mechanisms are needed they should be standardized apart from OAuth. BACKGROUND This sort of delegated permissions is a fairly well-studied problem with several major classes of solution, depending on whether (1) the SP needs to be involved in the delegation operation and (2) the SP needs to store information about the delegation. I'll talk about two below, by way of example. Delegation Certificates: For example, one class of solution is "delegation certificates", which have the dataflow shown below: User Consumer SP ---------------------------------------------------- 1. Print R -------------------> 2. <----- Need permission for R 3. Token ---------------------> 4. Request R + Token ------> 5. <--------- Response for R 6. <------------------- Success In line 1, U requests C to do something (e.g., print it) with Resource R. C detects that it doesn't have an existing credential for R, and in line 2 asks U to give it one. U responds with a token (3) which C forwards to SP along with its request (4). We assume that U and SP share some sort of cryptographic credential (e.g., SP knows U's public key) which SP can use to verify the Token. SP checks that the token grants C permission to R (and that U owns R) and if so responds with R. C can then do whatever the task is, and reports success to U. Note that U hasn't had to interact with SP directly at all (though presumably it does in some other context.) It just cooks up the token to give to C and C takes it from there. What is the token? It could be an X.509 delegation certificate, or a SAML assertion, or some other authenticated token, but the key point is that SP wasn't involved in its creation. Nor does the SP need to store anything about C's permissions [depending on how the token is constructed, it may not even need to know anything about C at all, if the token is a bearer ticket]. This has a number of advantages, but also one major disadvantage: it requires U's participation in the construction of the token, which requires new software on U. o ACLs: Another class of solutions is access control lists; in a system of this type, SP would be involved in every delegation, as shown below: User Consumer SP ---------------------------------------------------- 1. Print R -------------------> 2. <----- Need permission for R 3. Let C access R ------------------------------------> 4. <------------------------------------------------ OK 5. You have access -----------> 6. Request for R ----------> 7. <--------- Response for R 8. <------------------- Success The key pieces of this system are messages 3 and 4, where U instructs SP to give C access to R. SP handles this by creating a local access control entry so that when C requests R, it knows to return it. Note that the standard procedure would be for C to have an account with SP, though it's at least possible for U to refer to C via a key pair, in which case C would not need an account and SP could just store the key pair in the ACL. A major advantage of this kind of scheme is that U can be very primitive, since it's just frobbing bits on SP. In fact, it can be a standard Web browser and redirects can be used to transition back and forth between SP and C. THE OAUTH SCHEME OAuth isn't precisely like either of the schemes I describe above. Rather, it's mostly an access control list based scheme but it (at least potentially) offloads storage onto C rather than storing the ACLs on SP. The dataflow as far as I can tell is shown below [Note: this document would really benefit from a diagram like the one below] User Consumer SP ---------------------------------------------------- 1. Print R -------------------> 2. Need to access R -------> 3. <----- Request Token (RT) 4. <------- Redirect to SP + RT 5. <----------- U authorizes C access to R -----------> 6. <------------------------------------ Redirect to C 7. Redirected to C -----------> 8. Request Token ----------> 9. <------ Access Token (AT) 10. Request for R + AT -----> 11. <--------- Response for R 12. <------------------- Success This is a little confusing because of the redirects, but what seems to be going on is as follows: 1: U requests C to print R. 2-3: C gets a "Request Token" from SP 4-7: U authorizes SP to give C access to R. The Request Token is used to carry the identity of R and C through the redirects and C back from SP to itself. Finally, U is redirected to C. 8-9: C redeems RT for an Access Token (AT) 10-11: C uses AT to access the resource. 12: C returns success to the user. As I said above, except for the redirects required by HTTP, this is basically an ACL scheme, except that because C stores the Access Token, SP is not required to store access information for C, but can (at least theoretically) extract it from AT. I don't know what real OAuth systems do. SEPARABILITY So, why do I say this is separable? 1. In order to know whether to grant C access to R, SP, needs to be able to authenticate C. However, there's nothing OAuth specific about authentication and so there's no reason that this should be tied to OAuth. Indeed, we already have a number of mechanisms for using both shared secrets (Digest, TLS-PSK,...) and digital signatures (TLS Client Auth, S-HTTP,...) as HTTP authentication mechanisms and I don't see any showstopping OAuth couldn't use those. It's certainly arguable that these are unsatisfactory, but if so the IETF should do a general set of new HTTP authentication protocols, not do something OAuth specific. 2. The Access Token redemption part of the dataflow is only necessary to offload data onto C. If SP is willing to store access control lists, then this can be omitted entirely, as far as I can tell. On the other hand, one might want to design a scheme where the user preemptively sets access control values but then the first time the Consumer contacts the SP it gets a token and then the SP forgets the ACL values. The point is that these are separable and shouldn't be rigidly slaved together. 3. As I indicated above in the Delegation Certificate section, there are useful architectures where there's no need to have an interlocking protocol with the client and the SP in order to authorize the consumer. However, because those architectures require the client to generate the token, and token format isn't standardized, this system can't be used in that way. I'm not saying that we need to do a DC/SAML type thing now, but the system should be constructed in such a way that it doesn't preclude it, and this one does not seem to be that way. SPECIFIC COMMENTS S 5.3.1. Please do not class signature schemes like RSA with MAC schemes like HMAC. They are not the same thing and it's really confusing to treat them the same way. S 12.12. This whole section belies a seriously confused model of how cryptographic entropy works. Well designed cryptographic PRNGs can produce a nearly arbitrary amount of pseudorandom data with no significant impact on security provided that they are initially seeded with an appropriate amount of entropy. (I'm talking about 100 or so bits here). If your system is constructed so that repeated requests for randomness cause either blocking or generation of weak keys then it is broken. Appendix A. This would be a lot more useful towards the front of the document so it provided context for the discussion of the PDUs. -Ekr ------ End of Forwarded Message --_000_C56FE183101DCeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Review of draft-hammer-oauth
------ Forwarded Message
From: Eric Rescorla <ekr@networkresonance.com>
Date: Sun, 19 Oct 2008 09:35:56 -0700
To: <draft-hammer-o= auth@tools.ietf.org>
Cc: <oauth@googlegroups.com>, <ietf-http-auth@osaf= oundation.org>
Subject: Review of draft-hammer-oauth

$Id: draft-hammer-oauth-00-rev.txt,v 1.1 20= 08/10/18 20:56:37 ekr Exp $

This document describes a set of protocols for delegated access
to resources. The paradigmatic case here is photo printing.
User U has a set of photos on service provider SP (e.g., Flickr)
and wants to have them printed by some printing service (called
a Consumer, so C) and so needs to give C permission to access
some set of photos on SP.

This document actually describes three related but independent
technical artifacts:

- A set of new HTTP authentication mechanisms, including
  a shared secret mechanism based on HMAC-SHA1 and a
  digital signature mechanism based on RSA.
- A set of message flows for a user to authorize a Consumer
  to access a given object.
- A token mechanism for the SP to offload storage onto the
  Consumer.

These are quite separable and should be standardized independently,
if at all. In particular, if new authentication mechanisms are
needed they should be standardized apart from OAuth.


BACKGROUND
This sort of delegated permissions is a fairly well-studied
problem with several major classes of solution, depending on
whether (1) the SP needs to be involved in the delegation
operation and (2) the SP needs to store information
about the delegation. I'll talk about two below, by way
of example.

Delegation Certificates:
For example, one class of solution is "delegation certificates",<= BR> which have the dataflow shown below:

    User        &nbs= p;          Consumer &nbs= p;            &= nbsp;    SP
    ---------------------------------------------------= -
1.  Print R ------------------->
2.  <----- Need permission for R
3.  Token --------------------->
4.             =             &nb= sp;   Request R + Token ------>
5.             =             &nb= sp;   <--------- Response for R
6.  <------------------- Success

In line 1, U requests C to do something (e.g., print it)
with Resource R. C detects that it doesn't have an existing
credential for R, and in line 2 asks U to give it one.
U responds with a token (3) which C forwards to SP along
with its request (4). We assume that U and SP share some
sort of cryptographic credential (e.g., SP knows U's public
key) which SP can use to verify the Token. SP checks that
the token grants C permission to R (and that U owns R)
and if so responds with R. C can then do whatever the task
is, and reports success to U.

Note that U hasn't had to interact with SP directly at all
(though presumably it does in some other context.) It just
cooks up the token to give to C and C takes it from there.
What is the token? It could be an X.509 delegation certificate,
or a SAML assertion, or some other authenticated token, but
the key point is that SP wasn't involved in its creation.
Nor does the SP need to store anything about C's permissions
[depending on how the token is constructed, it may not even
need to know anything about C at all, if the token is a bearer
ticket].

This has a number of advantages, but also one major disadvantage:
it requires U's participation in the construction of the token,
which requires new software on U. o


ACLs:
Another class of solutions is access control lists; in a system
of this type, SP would be involved in every delegation, as shown
below:

    User        &nbs= p;          Consumer &nbs= p;            &= nbsp;    SP
    ---------------------------------------------------= -
1.  Print R ------------------->
2.  <----- Need permission for R
3.  Let C access R ------------------------------------>
4.  <------------------------------------------------ OK
5.  You have access ----------->
6.             =             &nb= sp;   Request for R ---------->
7.             =             &nb= sp;   <--------- Response for R
8.  <------------------- Success

The key pieces of this system are messages 3 and 4, where
U instructs SP to give C access to R. SP handles this by
creating a local access control entry so that when C
requests R, it knows to return it. Note that the standard
procedure would be for C to have an account with SP,
though it's at least possible for U to refer to C via
a key pair, in which case C would not need an account
and SP could just store the key pair in the ACL.

A major advantage of this kind of scheme is that U can
be very primitive, since it's just frobbing bits on SP.
In fact, it can be a standard Web browser and redirects
can be used to transition back and forth between SP and
C.


THE OAUTH SCHEME
OAuth isn't precisely like either of the schemes I describe
above. Rather, it's mostly an access control list based scheme
but it (at least potentially) offloads storage onto C rather
than storing the ACLs on SP. The dataflow as far as I can
tell is shown below [Note: this document would really
benefit from a diagram like the one below]

    User        &nbs= p;          Consumer &nbs= p;            &= nbsp;    SP
    ---------------------------------------------------= -
1.  Print R ------------------->
2.             =             &nb= sp;   Need to access R ------->
3.             =             &nb= sp;   <----- Request Token (RT)
4.  <------- Redirect to SP + RT
5.  <----------- U authorizes C access to R ----------->
6.  <------------------------------------  Redirect to C
7.  Redirected to C ----------->
8.             =             &nb= sp;   Request Token ---------->
9.             =             &nb= sp;   <------ Access Token (AT)
10.             = ;            &n= bsp;  Request for R + AT ----->
11.             = ;            &n= bsp;  <--------- Response for R
12. <------------------- Success

This is a little confusing because of the redirects, but what
seems to be going on is as follows:

1:     U requests C to print R.
2-3:   C gets a "Request Token" from SP
4-7:   U authorizes SP to give C access to R. The Request Token        is used to carry the identity of = R and C through
       the redirects and C back from SP = to itself. Finally,
       U is redirected to C.
8-9:   C redeems RT for an Access Token (AT)
10-11: C uses AT to access the resource.
12:    C returns success to the user.

As I said above, except for the redirects required by HTTP, this is
basically an ACL scheme, except that because C stores the Access
Token, SP is not required to store access information for C, but can
(at least theoretically) extract it from AT. I don't know what real
OAuth systems do.


SEPARABILITY
So, why do I say this is separable?

1. In order to know whether to grant C access to R, SP, needs to
   be able to authenticate C. However, there's nothing OAuth=
   specific about authentication and so there's no reason th= at
   this should be tied to OAuth. Indeed, we already have a n= umber
   of mechanisms for using both shared secrets (Digest, TLS-= PSK,...)
   and digital signatures (TLS Client Auth, S-HTTP,...) as    HTTP authentication mechanisms and I don't see any showst= opping
   OAuth couldn't use those. It's certainly arguable that    these are unsatisfactory, but if so the IETF should do a = general
   set of new HTTP authentication protocols, not do somethin= g
   OAuth specific.

2. The Access Token redemption part of the dataflow is only
   necessary to offload data onto C. If SP is willing to sto= re
   access control lists, then this can be omitted entirely,<= BR>    as far as I can tell. On the other hand, one might want t= o
   design a scheme where the user preemptively sets access    control values but then the first time the Consumer conta= cts
   the SP it gets a token and then the SP forgets the ACL va= lues.
   The point is that these are separable and shouldn't be    rigidly slaved together.

3. As I indicated above in the Delegation Certificate section,
   there are useful architectures where there's no need to    have an interlocking protocol with the client and the SP<= BR>    in order to authorize the consumer. However, because thos= e
   architectures require the client to generate the token,    and token format isn't standardized, this system can't be= used
   in that way. I'm not saying that we need to do a DC/SAML<= BR>    type thing now, but the system should be constructed in    such a way that it doesn't preclude it, and this one does=
   not seem to be that way.


SPECIFIC COMMENTS
S 5.3.1.
Please do not class signature schemes like RSA with MAC
schemes like HMAC. They are not the same thing and it's
really confusing to treat them the same way.

S 12.12.
This whole section belies a seriously confused model of how
cryptographic entropy works. Well designed cryptographic PRNGs can
produce a nearly arbitrary amount of pseudorandom data with no
significant impact on security provided that they are initially seeded
with an appropriate amount of entropy.  (I'm talking about 100 or so bits here). If your system is constructed so that repeated requests
for randomness cause either blocking or generation of weak keys
then it is broken.

Appendix A.
This would be a lot more useful towards the front of the document so
it provided context for the discussion of the PDUs.




-Ekr




 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 BF25F28C173; Thu, 18 Dec 2008 11:30:13 -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 28CBA28C171 for ; Thu, 18 Dec 2008 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=-3.523, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrqGkXNzr-ss for ; Thu, 18 Dec 2008 11:30:10 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CCD6528C173 for ; Thu, 18 Dec 2008 11:30:09 -0800 (PST) Received: (qmail 4819 invoked from network); 18 Dec 2008 19:16:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Dec 2008 19:16:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Dec 2008 12:16:35 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 18 Dec 2008 12:16:34 -0700 Thread-Topic: [oauth] Secdir Review of draft-hammer-oauth-00.txt Thread-Index: Ackwnhy0BjsO7Gu+TYGpkH6jmtcp8Qwpwc2i Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [oauth] FW: Secdir Review of draft-hammer-oauth-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: , Content-Type: multipart/mixed; boundary="===============0170532560==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0170532560== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C56FE192101DDeranhueniversecom_" --_000_C56FE192101DDeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------ Forwarded Message From: Sam Hartman Reply-To: Date: Fri, 17 Oct 2008 14:21:58 -0700 To: Cc: , , Subject: [oauth] Secdir Review of draft-hammer-oauth-00.txt [For the oauth list: The IETF has a security directorate (see sec.ietf.org) which is a group of experts that review IETF drafts for security issues. I'm a member of that directorate and have been asked by the area director sponsoring the oauth BOF at the next IETF to perform such a review of the oauth draft. Typically reviews happen fairly = late in the process, although as in this case they can happen early on requ= est.] I have reviewed draft-hammer-oauth-00 as a special requests. These comments are primarily intended for the security and applications area directors as input into considering the oauth bof. These comments should also be taken as input into the consensus process surrounding the draft. Background: Oauth provides a way to delegate access to a resource in HTTP. The canonical example is a user who has photos stored say at photos.example.net and wants to buy prints from printer.example.com. The user does not want to give printer.example.com their name and password for photos.example.net; depending on what authentication is in place they may not even be able to do so. Oauth provides a way that after obtaining consent from the user, printer.example.com can gain a token that can be used to access the protected resource. The printer service may only be granted access to some photos--the ones that the user wants printed. The access may be time limited and have other restrictions. This mechanism is similar to proxy tickets in Kerberos and proxy certificates in grid contexts. It is related to constrained delegation in Microsoft Kerberos, although involves significantly less trust of the consumer (party seeking delegated access to a protected resource). The protocol roughly runs as follows: 1) Consumer makes a request to the service provider (where the protected re= sources live) and gets a blob called a request token 2) Consumer redirects the user to the service provider passing along the bl= ob ; if the user authorizes the transaction then the consumer is notified. 3) Consumer asks service provider to turn the request token into another bl= ob called an access token. 4) Consumer can use the access token to access protected resources. Associated with each token is a shared secret used to provide integrity protection and peer entity authentication of the party making the request. One thing we've been looking at with HTTP authentication schemes is whether they are browser specific or whether they will work well in atom/dav/etc environments. Most of oauth will work well in a non-browser context. However oauth redirects the user from the consumer to the service provider to seek authorization for the request token. This tends to mean that the service provider and consumer tend to need to have the same idea about what kind of agent the user is using. It seems clear that the service provider can enable whatever they like, but that oauth may have limitations when being used with classes of agent the service provider has never considered. I found the spec sufficiently clear. While I do have a lot of detailed comments, I'd expect that at this point in the process. Whenever you bring some idea into an large organization like the IETF, you're almost certainly guaranteed that there are a set of things that the organization cares about in its specs that need to be addressed. Interoperability The oauth document is not really a complete protocol; it is more like a set of components that can be used in building a higher level protocol. To some extent this is necessary: a consumer that wants to talk to a photo store will not know what to do if it is talking to a blog. Also, oauth treats issues like naming of resources to be accessed, naming of users etc as an API matter to be handled at a layer above oauth. However it really seems like there are a lot of things that are not specified in the spec that need to be done for interoperability. It seems like the description of how a service uses oauth would need to be a fairly significant document. In addition, the security analysis of oauth itself is going to be somewhat incomplete; oauth will need to be analyzed in the context of the using service. I realize that to some extent the same can be said for RFC 2822 or HTTP. However my qualitative feeling that this is more true for oauth. Oauth does not have mandatory-to-implement algorithms for security. We typically require that. There is no mandatory-to-implement method for conveying request parameters. There is no interoperable way to find the lifetime of a request or access token, to find out when an access token has been revoked, etc. Security Consumers are typically in different organizations than service providers. Their may be a potentially large number of consumers. However there is no automated key management for a shared secret used to authenticate the consumer to the service provider. I think RFC 4107 will require us to create such a mechanism. Section 12.8 implies that the consumer secret might not be secret--in particular, a single consumer secret would be used in all instances of a desktop application. That is, you'd download a binary, and inside that binary would be a secret used to authenticate to some provider. The text and concept will require revision to survive last call in the IETF. The oauth parts of messages from the client to a server are optionally integrity protected. However there is no response protection. At least for the hmac-sha1 signature type adding response protection would be trivial. It would be reasonably trivial for the RSA signature type, although the consumer would then need to know the public key of the service provider. Oauth service providers send shared secrets back to consumers for request and access tokens. There are two potential issues with this. First, the consumer does not contribute to the secret. Second, there is no mandatory confidentiality protection of the secret. This issue needs significant discussion with the security community if only to satisfy people that the oauth spec is reasonable in this regard. Oauth responses can be cut&pasted onto different requests. Fixing the response integrity problem does not inherently fix this issue. Oauth provides no mutual authentication. We have typically expected authentication systems that we're designing to provide mutual authentication especially when there is no good reason not to do so. It seems like fixing the response integrity problem could also fix fix the lack of mutual authentication. The replay prevention mechanism has a significant DOS concern for the service provider. A request contains a nonce and a timestamp. The timestamp must be non-decreasing but is not required to be particularly close to current time nor to ever change. The nonce is required to be unique for a given timestamp. So, if a particular consumer never changes the timestamp then the server must retain all nonce values presented to it. Mechanisms such a digest handle this by providing a server challenge in the www-authenticate header and providing a mechanism for dealing with the server and client getting out of sync. Oauth is less likely to actually use www-authenticate than digest. One possible solution would be to define an error meaning that the consumer must use a timestamp at least as large as some value in a future request. However without some sort of server challenge this requires synchronizing replay state across all instances of a service provider. For example, if you have a bunch of edge servers that implement your service, you need to make sure that all of them are aware of the nonce values that have been used. I suspect that in practice people would not implement replay protection in that environment. I'd like to see optional support for channel binding to TLS when TLS is used. In many cases oauth has a shared secret between the consumer and the service provider or a shared secret specific to the token in question. Using this secret to confirm that we're talking to the right server at the TLS level will provide extra defenses against phishing or other server substitution attacks. The support for channel binding should be good enough that the consumer can tell securely whether the server verified the channel binding. Adding this to the protocol is relatively easy. In some implementations, implementing it will also be easy; in others it might be fairly difficult. Thus I think the feature should be optional, but secured against downgrade attacks. The specification does not provide for automated key management of RSA public keys; I think this too will be required by RFC 4107. I can understand why you want to rule enrollment (initial key discovery) out of scope. However you need to provide a mechanism for a consumer to change its public key. Section 6.2 provides user interface requirements for what a service provider must do when seeking consent. I didn't see any problems with this, but I want to call it to the attention of the security community. Section 6.3 does not actually require that the service provider check that the request token is authorized. This requirement is critical; fortunately I think it is obvious enough that people are unlikely to omit the check in implementations. Extensibility The oauth extensibility model should be improved. There is a version field, but the behavior for an unknown version is unspecified. I know there are a lot of arguments about how to handle versioning. This behavior is inconsistent with all of them. You could drop the field; you could require an error if the version number does not match; you could use HTTP-style versioning where minor version mismatch is OK but major version mismatch generates an error. There is an error for parameter not understood. It seems like sending this error in response to an unknown parameter is permitted. Unfortunately, this combined with the way the version number is handled means there is no way for a new consumer to indicate support for a new feature while working with an old service provider. It may be desirable to have critical (the other guy must fail if he does not understand) parameters, but it seems like optional parameters as a way of extending the protocol are also required. Phishing I'm still thinking about the phishing implications of oauth. It's clear that oauth has the concerns associated with any redirect scheme. A malicious consumer can redirect the user to a phishing site rather than the actual service provider. This is only bad if the user discloses credentials or other confidential information to the malicious service provider. So, it could be seen as a mistrusted introduction problem. I analyze situations like that and ask myself how well will this approach work if the target of the redirect actually improves their authentication technology. Oauth seems like it scores reasonably under this analysis. However because there are three parties involved in the protocol the phishing issues are more complicated. If there is a problem it's relatively subtle; I'm not comfortable saying that I've analyzed things sufficiently, although assuming that mutual authentication and binding to TLS are added, I think I'm happy with everything I've considered so far. Of course, phishing defense only makes sense when TLS is being used. The point of phishing is to obtain confidential information. Without confidentiality protection being provided, there's no hope of preventing the attack. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "= OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscribe@googlegroup= s.com For more options, visit this group at http://groups.google.com/group/oauth?= hl=3Den -~----------~----~----~----~------~----~------~--~--- ------ End of Forwarded Message --_000_C56FE192101DDeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [oauth] Secdir Review of draft-hammer-oauth-00.txt
------ Forwarded Message
From: Sam Hartman <hartmans-ietf@mit.edu>
Reply-To: <oauth@googlegroups.= com>
Date: Fri, 17 Oct 2008 14:21:58 -0700
To: <secdir@ietf.org>
Cc: <oauth@googlegroups.com>, <lisa@osafoundation.org>= ;, <draft-hammer-oauth@too= ls.ietf.org>
Subject: [oauth] Secdir Review of draft-hammer-oauth-00.txt



[For the oauth list: The IETF has a security directorate (see
sec.ietf.org) which is a group of experts that review IETF drafts for
security issues.  I'm a member of that directorate and have been asked=
by the area director sponsoring the oauth BOF at the next IETF to
perform such a review of the oauth draft.  Typically reviews happen fa= irly late in the process, although as in this case they can happen early on= request.]

I have reviewed draft-hammer-oauth-00 as a special requests.  These comments are primarily intended for the security and applications area
directors as input into considering the oauth bof.  These comments
should also be taken as input into the consensus process surrounding
the draft.

Background:

Oauth provides a way to delegate access to a resource in HTTP. The
canonical example is a user who has photos stored say at
photos.example.net and wants to buy prints from printer.example.com.
The user does not want to give printer.example.com their name and
password for photos.example.net; depending on what authentication is
in place they may not even be able to do so.  Oauth provides a way
that after obtaining consent from the user, printer.example.com can
gain a token that can be used to access the protected resource.  The printer service may only be granted access to some photos--the ones
that the user wants printed.  The access may be time limited and have<= BR> other restrictions.


This mechanism is similar to proxy tickets in Kerberos and proxy
certificates in grid contexts.  It is related to constrained
delegation in Microsoft Kerberos, although involves significantly less
trust of the consumer (party seeking delegated access to a protected
resource).

The protocol roughly runs as follows:
1) Consumer makes a request to the service provider (where the protected re= sources live) and gets a blob called a request token
2) Consumer redirects the user to the service provider passing along the bl= ob ; if the user authorizes the transaction then the consumer is notified.<= BR> 3) Consumer asks service provider to turn the request token into another bl= ob called an access token.
4) Consumer can use the access token to access protected resources.

Associated with each token is a shared secret used to provide
integrity protection and peer entity authentication of the party
making the request.

One thing we've been looking at with HTTP authentication schemes is
whether they are browser specific or whether they will work well in
atom/dav/etc environments.  Most of oauth will work well in a
non-browser context.  However oauth redirects the user from the
consumer to the service provider to seek authorization for the request
token.  This tends to mean that the service provider and consumer tend=
to need to have the same idea about what kind of agent the user is
using. It seems clear that the service provider can enable whatever
they like, but that oauth may have limitations when being used with
classes of agent the service provider has never considered.


I found the spec sufficiently clear.  While I do have a lot of
detailed comments, I'd expect that at this point in the process.
Whenever you bring some idea into an large organization like the IETF,
you're almost certainly guaranteed that there are a set of things that
the organization cares about in its specs that need to be addressed.


            &nb= sp;            =   Interoperability

The oauth document is not really a complete protocol; it is more like
a set of components that can be used in building a higher level
protocol.  To some extent this is necessary: a consumer that wants to<= BR> talk to a photo store will not know what to do if it is talking to a
blog.  Also, oauth treats issues like naming of resources to be
accessed, naming of users etc as an API matter to be handled at a
layer above oauth.  However it really seems like there are a lot of things that are not specified in the spec that need to be done for
interoperability.  It seems like the description of how a service uses=
oauth would need to be a fairly significant document.  In addition, the security analysis of oauth itself is going to be somewhat
incomplete; oauth will need to be analyzed in the context of the using
service.
I realize that to some extent the same can be said for RFC 2822 or
HTTP.  However my qualitative feeling that this is more true for
oauth.


Oauth does not have mandatory-to-implement algorithms for security.
We typically require that.  There is no mandatory-to-implement method<= BR> for conveying request parameters.

There is no interoperable way to find the lifetime of a request or
access token, to find out when an access token has been revoked, etc.


            &nb= sp;            =       Security

 Consumers are typically in different organizations than
service providers.  Their may be a potentially large number of
consumers.  However there is no automated key management for a shared<= BR> secret used to authenticate the consumer to the service provider.  I think RFC 4107 will require us to create such a mechanism.

Section 12.8 implies that the consumer secret might not be secret--in
particular, a single consumer secret would be used in all instances of
a desktop application.  That is, you'd download a binary, and inside that binary would be a secret used to authenticate to some provider.
The text and concept will require revision to survive last call in the
IETF.


The oauth parts of messages from the client to a server are optionally
integrity protected.  However there is no response protection.  A= t
least for the hmac-sha1 signature type adding response protection
would be trivial.  It would be reasonably trivial for the RSA
signature type, although the consumer would then need to know the
public key of the service provider.

Oauth service providers send shared secrets back to consumers for
request and access tokens.  There are two potential issues with this.<= BR> First, the consumer does not contribute to the secret.  Second, there<= BR> is no mandatory confidentiality protection of the secret.  This issue<= BR> needs significant discussion with the security community if only to
satisfy people that the oauth spec is reasonable in this regard.

Oauth responses can be cut&pasted onto different requests.  Fixing= the
response integrity problem does not inherently fix this issue.

Oauth provides no mutual authentication.  We have typically expected authentication systems that we're designing to provide mutual
authentication especially when there is no good reason not to do so.
It seems like fixing the response integrity problem could also fix fix
the lack of mutual authentication.


The replay prevention mechanism has a significant DOS concern for the
service provider.  A request contains a nonce and a timestamp.  T= he
timestamp must be non-decreasing but is not required to be
particularly close to current time nor to ever change.  The nonce is required to be unique for a given timestamp.  So, if a particular
consumer never changes the timestamp then the server must retain all
nonce values presented to it.  Mechanisms such a digest handle this by=
providing a server challenge in the www-authenticate header and
providing a mechanism for dealing with the server and client getting
out of sync.  Oauth is less likely to actually use www-authenticate than digest.  One possible solution would be to define an error
meaning that the consumer must use a timestamp at least as large as
some value in a future request.  However without some sort of server challenge this requires synchronizing replay state across all
instances of a service provider.  For example, if you have a bunch of<= BR> edge servers that implement your service, you need to make sure that
all of them are aware of the nonce values that have been used.  I
suspect that in practice people would not implement replay protection
in that environment.  I'd like to see optional support for channel
binding to TLS when TLS is used.  In many cases oauth has a shared
secret between the consumer and the service provider or a shared
secret specific to the token in question.  Using this secret to
confirm that we're talking to the right server at the TLS level will
provide extra defenses against phishing or other server substitution
attacks.  The support for channel binding should be good enough that the consumer can tell securely whether the server verified the channel
binding.  Adding this to the protocol is relatively easy.  In som= e
implementations, implementing it  will also be easy; in others it
might be fairly difficult.  Thus I think the feature should be
optional, but secured against downgrade attacks.

The specification does not provide for automated key management of RSA
public keys; I think this too will be required by RFC 4107.  I can
understand why you want to rule enrollment (initial key discovery) out
of scope.  However you need to provide a mechanism for a consumer to change its public key.

Section 6.2 provides user interface requirements for what a service
provider must do when seeking consent.  I didn't see any problems with=
this, but  I want to call it to the attention of the security communit= y.

Section 6.3 does not actually require that the service provider check
that the request token is authorized.  This requirement is critical; fortunately I think it is obvious enough that  people are unlikely to<= BR> omit the check in implementations.


            &nb= sp;            =    Extensibility

The oauth extensibility model should be improved.  There is a version<= BR> field, but the behavior for an unknown version is unspecified.  I know=
there are a lot of arguments about how to handle versioning.  This
behavior is inconsistent with all of them.  You could drop the field;<= BR> you could require an error if the version number does not match; you
could use HTTP-style versioning where minor version mismatch is OK but
major version mismatch generates an error.

There is an error for parameter not understood.  It seems like sending=
this error in response to an unknown parameter is permitted.
Unfortunately, this combined with the way the version number is
handled means there is no way for a new consumer to indicate support
for a new feature while working with an old service provider.  It may<= BR> be desirable to have critical (the other guy must fail if he does not
understand) parameters, but it seems like optional parameters as a way
of extending the protocol are also required.


            &nb= sp;            =       Phishing

I'm still thinking about the phishing implications of oauth.  It's
clear that oauth has the concerns associated with any redirect scheme.
A malicious consumer can redirect the user to a phishing site rather
than the actual service provider.  This is only bad if the user
discloses credentials or other confidential information to the
malicious service provider.  So, it could be seen as a mistrusted
introduction problem.  I analyze situations like that and ask myself how well will this approach work if the target of the redirect
actually improves their authentication technology.  Oauth seems like it scores reasonably under this analysis.

However because there are three parties involved in the protocol the
phishing issues are more complicated.  If there is a problem it's
relatively subtle; I'm not comfortable saying that I've analyzed
things sufficiently, although assuming that mutual authentication and
binding to TLS are added, I think I'm happy with everything I've
considered so far.  Of course, phishing defense only makes sense when<= BR> TLS is being used.  The point of phishing is to obtain confidential information.  Without confidentiality protection being provided,
there's no hope of preventing the attack.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups &= quot;OAuth" group.
To post to this group, send email to oau= th@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=3Den
-~----------~----~----~----~------~----~------~--~---


 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 B46663A6A34; Thu, 18 Dec 2008 13:40:56 -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 48AE23A6A34 for ; Thu, 18 Dec 2008 13:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.614 X-Spam-Level: X-Spam-Status: No, score=-5.614 tagged_above=-999 required=5 tests=[AWL=-3.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2k79MZXC6ka for ; Thu, 18 Dec 2008 13:40:54 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DECFA3A692D for ; Thu, 18 Dec 2008 13:40:54 -0800 (PST) Received: (qmail 9991 invoked from network); 18 Dec 2008 21:20:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Dec 2008 21:20:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Dec 2008 14:20:13 -0700 From: Eran Hammer-Lahav To: "oauth@googlegroups.com" , "oauth@ietf.org" Date: Thu, 18 Dec 2008 14:20:12 -0700 Thread-Topic: Community Update Thread-Index: AclhVmljQ5yxVV/vgE2rrYCYTixlVw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [oauth] Community Update 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 It has been a long time since we touched base as a community to check where we are and where we want to go. The last time we got together for such a discussion was at the OAuth Summit back in June. This is in no way an official update, as I hold no official capacity within the community. But I hope this is informational and useful. --- * OAuth @ the IETF Larry Halff, Blaine Cook, and I had conversations with folks from the IETF community over the past few months. These resulted in an IETF BoF session at the 73rd IETF meeting in MN last month. The BoF tried to answer two questions: 1. Is the problem of delegated auth as presented in the sharing of passwords across sites something the IETF community cares about and wants to work on? 2. If the answer to #1 is yes, is OAuth a good protocol to use as a starting point for solving it ("starting point" does not imply anything regarding the amount of changes)? The answer to both questions was a strong yes from those present at the meeting. The outcome of the meeting was to form the new oauth@ietf.org mailing list and to work on the proposed WG charter, hopefully in time for the next IETF meeting (74th, March 09 in CA). The main issue which needs to be resolved now is the "backward compatibility" language of the charter. The current OAuth spec has been submitted as an internet draft and is available at http://tools.ietf.org/html/draft-hammer-oauth-00. Note that the only official spec at this point is located at http://oauth.net/core/1.0. * OAuth IPR The OAuth Core 1.0 specification IPR license has been completed with a license attached to the spec (http://oauth.net/core/1.0) and signatures collected from all contributors. However, we were unable to come up with a satisfactory IPR policy for new work moving forward. Much of this effort has moved over to the work of the Open Web Foundation, which is currently discussing an IPR policy that will provide the OAuth community with a workable solution. At this point, proposals made with regard to OAuth do not have a clear IPR policy attached, and each author must choose how to address that. The IETF process, if successful, will produce a specification covered by the IETF IPR policy, but that is extremely weak. It may not block adoption but it offers much less protection than the current OAuth license. * Extensions There are currently 11 proposed OAuth extension. For the most part these are individual efforts with little community support or interest. Part of the work involved in writing the IETF charter and standardizing OAuth there is to figure out which of these extensions fit within the IETF core spec, which should be published as separate IETF standards, and which should remain as an individual effort. The current proposals are (available from http://code.google.com/p/oauth): - OAuth Discovery - Body Hash - Body Signature - Consumer Request - Gadgets - Key Rotation - Language Preference - Response Data Format - Session - OpenID extension (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid _oauth_extension.html) - Mobile (http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00) Other proposals not yet formalized include Token Attributes (access type, duration, scope), Token delegation (sharing tokens across multiple consumers), Header signatures (signing HTTP headers), and other security features. * Mailing Lists We currently have 3 OAuth mailing lists: - OAuth (oauth@googlegroups.com) - OAuth Extensions (oauth-extensions@googlegroups.com) - OAuth IETF (oauth@ietf.org) There are also a few language-specific lists: - OAuth Ruby (http://groups.google.com/group/oauth-ruby) - OAuth PHP (http://groups.google.com/group/oauth-for-php) - OAuth Perl (http://groups.google.com/group/oauth-perl) (I will send a separate post about how we should use these lists moving forward). --- Other topics we should review as the year comes to a close are the status of: * Adoption * Tutorials and Documentations * Code Libraries If anyone is willing to write those up, please post in reply. Thanks and Happy Holidays! EHL _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 14:21:55 2008 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 3FBD63A697F; Thu, 18 Dec 2008 14:21:55 -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 CA7303A697F for ; Thu, 18 Dec 2008 14:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-2.848, 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 WUCCh1BCYudA for ; Thu, 18 Dec 2008 14:21:53 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 07CC33A693E for ; Thu, 18 Dec 2008 14:21:53 -0800 (PST) Received: (qmail 16959 invoked from network); 18 Dec 2008 21:42:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Dec 2008 21:42:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Dec 2008 14:42:30 -0700 From: Eran Hammer-Lahav To: "oauth@googlegroups.com" , "oauth@ietf.org" Date: Thu, 18 Dec 2008 14:42:29 -0700 Thread-Topic: OAuth Mailing Lists Thread-Index: AclhWYZN7q9Jn5wuGEW+5kyAkypyTg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [oauth] OAuth Mailing Lists 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 There has been some discussion and confusion about the purpose of the three mailing lists and how they should be used moving forward. This is my suggestions: * oauth@ietf.org Home for the standardization effort taking place in the IETF. The effort has being labeled as "OAuth 1.1" but label has never been agreed on. The IETF is looking at producing a standard based on the OAuth Core 1.0 protocol with some potential changes and additions. That effort should produce the next iteration of the OAuth Core protocol and all *new work* related to the OAuth Core protocol should be move to the IETF list. This is especially important to those who have strong opinions about what the next iteration of the spec should look like, and how many changes should be allowed from the 1.0 specification. * oauth@googlegroups.com This is the main community list for the adoption of the OAuth Core 1.0 specification. This is the place to go for interoperability issues, developer support, questions about the specification, evangelism work, and general community communication that is not about the protocol itself. OAuth Core 1.0 is a stable and final specification and as such, can and should be adopted (today). It is hard to tell how long it will take the IETF process to produce a final specification (which is not guaranteed), and it is unlikely for a final spec to be completed in under a year. Therefore, the OAuth Core 1.0 specification is the only official final work available and the only one that should be adopted at this point. There is absolutely no reason to wait for some unknown specification to be produced at a later stage as OAuth already provides a working framework. * oauth-extensions@googlegroups.com This list (which has not been very active lately) is the place for technical discussions about additions and changes to the OAuth specification that are not covered by the IETF charter. Since the charter is still being worked on, extensions discussions should be happening on the IETF list until decided they are out of scope and at that point move here. --- Other suggestions? Feedback? EHL _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 14:44:00 2008 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 1CB293A69E3; Thu, 18 Dec 2008 14:44:00 -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 557093A69E3 for ; Thu, 18 Dec 2008 14:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywI-w5Z0o2vD for ; Thu, 18 Dec 2008 14:43:50 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 95EBE3A697F for ; Thu, 18 Dec 2008 14:43:49 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c5so238093anc.4 for ; Thu, 18 Dec 2008 14:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=BajOHy1olchEbe2lpLPHYWzSWiUrEO+1JR9d7vB/6hI=; b=Vr61NSiVbba07QFbwP0sDdxb6/IbOqX1YUZ8andHYq0RV+rD1RnLLEKLRr7bdAf10N /M2VHKXLQuiFqpeBErLRLOdCZdrQXlh7Pz9qG+Jgv/6NO0vRhDOQW21Q7M5dwdeh2P87 awj08Q8o9es+/+JOnHDxT4O8Uar03eX4f2q6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=WjTFBmh1w9AdTBresVvVS/LXBfukEr8EwUvf5XxArCFpY6a1UTIHpulDbNb4HaP/3D ynN7P8WnNJoK5h485WCE6t78tnDtWtealFMfxg2eGBlvfnH2GvJy+iajdtZAid58CU3z DIRn6ZozS3YOhg80vAkayuV5Jbny9cIf+S8e8= Received: by 10.231.15.74 with SMTP id j10mr80723iba.48.1229640220968; Thu, 18 Dec 2008 14:43:40 -0800 (PST) Received: by 10.231.19.203 with HTTP; Thu, 18 Dec 2008 14:43:40 -0800 (PST) Message-ID: <1bc4603e0812181443w7c991ff0s2c47c1c8b74c75ef@mail.gmail.com> Date: Thu, 18 Dec 2008 14:43:40 -0800 From: "Chris Messina" To: "Eran Hammer-Lahav" In-Reply-To: MIME-Version: 1.0 References: Cc: "oauth@googlegroups.com" , "oauth@ietf.org" Subject: Re: [oauth] OAuth Mailing Lists 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="===============0439786632==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0439786632== Content-Type: multipart/alternative; boundary="----=_Part_541_7911325.1229640220961" ------=_Part_541_7911325.1229640220961 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline That sounds okay, but I am concerned about the fracturing of the OAuth 1.1 work from the main OAuth community. Not that we shouldn't pursue this direction (as we already decided we should), but I'd like to know how we're going to bridge the social gap between these lists -- and keep one another informed of ongoing work. I presume that much of this will fall to Eran as the go-between, but who else is representing from the community side of OAuth on the IETF list and is willing to, from time to time, provide status updates and progress reports for implementors and adopters on this list? Just want to make sure that there's twoway visibility now that the IETF work is underway. Chris On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav wrote: > There has been some discussion and confusion about the purpose of the three > mailing lists and how they should be used moving forward. This is my > suggestions: > > * oauth@ietf.org > > Home for the standardization effort taking place in the IETF. The effort > has > being labeled as "OAuth 1.1" but label has never been agreed on. The IETF > is > looking at producing a standard based on the OAuth Core 1.0 protocol with > some potential changes and additions. > > That effort should produce the next iteration of the OAuth Core protocol > and > all *new work* related to the OAuth Core protocol should be move to the > IETF > list. This is especially important to those who have strong opinions about > what the next iteration of the spec should look like, and how many changes > should be allowed from the 1.0 specification. > > * oauth@googlegroups.com > > This is the main community list for the adoption of the OAuth Core 1.0 > specification. This is the place to go for interoperability issues, > developer support, questions about the specification, evangelism work, and > general community communication that is not about the protocol itself. > > OAuth Core 1.0 is a stable and final specification and as such, can and > should be adopted (today). It is hard to tell how long it will take the > IETF > process to produce a final specification (which is not guaranteed), and it > is unlikely for a final spec to be completed in under a year. > > Therefore, the OAuth Core 1.0 specification is the only official final work > available and the only one that should be adopted at this point. There is > absolutely no reason to wait for some unknown specification to be produced > at a later stage as OAuth already provides a working framework. > > * oauth-extensions@googlegroups.com > > This list (which has not been very active lately) is the place for > technical > discussions about additions and changes to the OAuth specification that are > not covered by the IETF charter. Since the charter is still being worked > on, > extensions discussions should be happening on the IETF list until decided > they are out of scope and at that point move here. > > --- > > Other suggestions? Feedback? > > EHL > > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Chris Messina Citizen-Participant & Open Technology Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private ------=_Part_541_7911325.1229640220961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline That sounds okay, but I am concerned about the fracturing of the OAuth 1.1 work from the main OAuth community. Not that we shouldn't pursue this direction (as we already decided we should), but I'd like to know how we're going to bridge the social gap between these lists -- and keep one another informed of ongoing work.

I presume that much of this will fall to Eran as the go-between, but who else is representing from the community side of OAuth on the IETF list and is willing to, from time to time, provide status updates and progress reports for implementors and adopters on this list?

Just want to make sure that there's twoway visibility now that the IETF work is underway.

Chris

On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
There has been some discussion and confusion about the purpose of the three
mailing lists and how they should be used moving forward. This is my
suggestions:

* oauth@ietf.org

Home for the standardization effort taking place in the IETF. The effort has
being labeled as "OAuth 1.1" but label has never been agreed on. The IETF is
looking at producing a standard based on the OAuth Core 1.0 protocol with
some potential changes and additions.

That effort should produce the next iteration of the OAuth Core protocol and
all *new work* related to the OAuth Core protocol should be move to the IETF
list. This is especially important to those who have strong opinions about
what the next iteration of the spec should look like, and how many changes
should be allowed from the 1.0 specification.

* oauth@googlegroups.com

This is the main community list for the adoption of the OAuth Core 1.0
specification. This is the place to go for interoperability issues,
developer support, questions about the specification, evangelism work, and
general community communication that is not about the protocol itself.

OAuth Core 1.0 is a stable and final specification and as such, can and
should be adopted (today). It is hard to tell how long it will take the IETF
process to produce a final specification (which is not guaranteed), and it
is unlikely for a final spec to be completed in under a year.

Therefore, the OAuth Core 1.0 specification is the only official final work
available and the only one that should be adopted at this point. There is
absolutely no reason to wait for some unknown specification to be produced
at a later stage as OAuth already provides a working framework.

* oauth-extensions@googlegroups.com

This list (which has not been very active lately) is the place for technical
discussions about additions and changes to the OAuth specification that are
not covered by the IETF charter. Since the charter is still being worked on,
extensions discussions should be happening on the IETF list until decided
they are out of scope and at that point move here.

---

Other suggestions? Feedback?

EHL




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



--
Chris Messina
Citizen-Participant &
 Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
------=_Part_541_7911325.1229640220961-- --===============0439786632== 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 --===============0439786632==-- From oauth-bounces@ietf.org Thu Dec 18 15:03:44 2008 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 517563A68D5; Thu, 18 Dec 2008 15:03:44 -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 C4E9C3A68D5 for ; Thu, 18 Dec 2008 15:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 792ESb0JGMAO for ; Thu, 18 Dec 2008 15:03:42 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 318AE3A63EB for ; Thu, 18 Dec 2008 15:03:42 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so755521wfd.31 for ; Thu, 18 Dec 2008 15:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KsclTJbGmBq3T1HsxAz64h90lQn7j4ZBJInWzEt2rgA=; b=Seay//o+85UzdFaQQ3X0E4buL2oqQnYqPyoA3l5ErB9C4G6AayMTpZPEEJ3ntvePLB uerCfjn81QM4wu9HwSm0IzOhgMycmI7x/B7MvfymFYVc9EDxbII0WBKT20IIlm6uEZmb TMmadhQFSNi7KTHnviPGeJOZ8ttjXyQf5/UKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=aznu1G6YHJghdBRRuHe8NYleYqBi6om2UuVk6sQqUYnCRBJQSVUox378SjISqxnqrM P7u7RJ1T6KlNP/KJiBBUM8o/nIP3B3YuUlpH9/5oVUqH2Y10g45cjKwtooGJR9wVHDNY uZy7Ptmjw6iviavo+MFp9fLRS275E8vykkWY4= Received: by 10.142.125.4 with SMTP id x4mr1009212wfc.315.1229641414472; Thu, 18 Dec 2008 15:03:34 -0800 (PST) Received: by 10.143.31.18 with HTTP; Thu, 18 Dec 2008 15:03:34 -0800 (PST) Message-ID: <422b9b380812181503j4e99d825g8c086bd03302b62e@mail.gmail.com> Date: Thu, 18 Dec 2008 18:03:34 -0500 From: kellan To: "John Kemp" In-Reply-To: <494A8E0F.7040008@jkemp.net> MIME-Version: 1.0 Content-Disposition: inline References: <422b9b380812170542g50763261x360575a9d52aa59e@mail.gmail.com> <494A8E0F.7040008@jkemp.net> X-Google-Sender-Auth: 2c7e1fb5f11d9ecc Cc: oauth@ietf.org Subject: Re: [oauth] Interoperability and Backwards Compatibility 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 On Thu, Dec 18, 2008 at 12:53 PM, John Kemp wrote: > Sam Hartman wrote: > > ... > > Checking the archives of this list, I can't immediately see where this > security review is posted. Is it possible to provide a link to your review? > http://groups.google.com/group/oauth/browse_thread/thread/a8875811676f39dd/47b760cd0d5d46d2 See also good comments from John Panzer and Brian. -kellan _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Thu Dec 18 15:24:28 2008 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 032BA3A6829; Thu, 18 Dec 2008 15:24: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 B75863A63EB for ; Thu, 18 Dec 2008 15:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[AWL=-2.698, 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 UzkUVS43c02y for ; Thu, 18 Dec 2008 15:24:16 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 39AA23A6829 for ; Thu, 18 Dec 2008 15:24:16 -0800 (PST) Received: (qmail 8076 invoked from network); 18 Dec 2008 23:06:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Dec 2008 23:06:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Dec 2008 16:06:58 -0700 From: Eran Hammer-Lahav To: Chris Messina Date: Thu, 18 Dec 2008 16:06:56 -0700 Thread-Topic: [oauth] OAuth Mailing Lists Thread-Index: AclhYhOy5nU7RlBsRXyFVpIvnUW8mgAAz7FC Message-ID: In-Reply-To: <1bc4603e0812181443w7c991ff0s2c47c1c8b74c75ef@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "oauth@googlegroups.com" , "oauth@ietf.org" Subject: Re: [oauth] OAuth Mailing Lists 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="===============1367371511==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============1367371511== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C570179010239eranhueniversecom_" --_000_C570179010239eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the key for a successful IETF work is that most of the active OAuth= members from the old list will join the new list as well. If you consider = this simply a separation between 1.0 deployment and 1.1 development, it doe= sn't really fracture the community. But either way I will be happy to bridg= e to two (and have been). EHL On 12/18/08 2:43 PM, "Chris Messina" wrote: That sounds okay, but I am concerned about the fracturing of the OAuth 1.1 = work from the main OAuth community. Not that we shouldn't pursue this direc= tion (as we already decided we should), but I'd like to know how we're goin= g to bridge the social gap between these lists -- and keep one another info= rmed of ongoing work. I presume that much of this will fall to Eran as the go-between, but who el= se is representing from the community side of OAuth on the IETF list and is= willing to, from time to time, provide status updates and progress reports= for implementors and adopters on this list? Just want to make sure that there's twoway visibility now that the IETF wor= k is underway. Chris On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav wr= ote: There has been some discussion and confusion about the purpose of the three mailing lists and how they should be used moving forward. This is my suggestions: * oauth@ietf.org Home for the standardization effort taking place in the IETF. The effort ha= s being labeled as "OAuth 1.1" but label has never been agreed on. The IETF i= s looking at producing a standard based on the OAuth Core 1.0 protocol with some potential changes and additions. That effort should produce the next iteration of the OAuth Core protocol an= d all *new work* related to the OAuth Core protocol should be move to the IET= F list. This is especially important to those who have strong opinions about what the next iteration of the spec should look like, and how many changes should be allowed from the 1.0 specification. * oauth@googlegroups.com This is the main community list for the adoption of the OAuth Core 1.0 specification. This is the place to go for interoperability issues, developer support, questions about the specification, evangelism work, and general community communication that is not about the protocol itself. OAuth Core 1.0 is a stable and final specification and as such, can and should be adopted (today). It is hard to tell how long it will take the IET= F process to produce a final specification (which is not guaranteed), and it is unlikely for a final spec to be completed in under a year. Therefore, the OAuth Core 1.0 specification is the only official final work available and the only one that should be adopted at this point. There is absolutely no reason to wait for some unknown specification to be produced at a later stage as OAuth already provides a working framework. * oauth-extensions@googlegroups.com This list (which has not been very active lately) is the place for technica= l discussions about additions and changes to the OAuth specification that are not covered by the IETF charter. Since the charter is still being worked on= , extensions discussions should be happening on the IETF list until decided they are out of scope and at that point move here. --- Other suggestions? Feedback? EHL _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C570179010239eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAuth Mailing Lists I think the key for a successful IETF work is that most of the active= OAuth members from the old list will join the new list as well. If you con= sider this simply a separation between 1.0 deployment and 1.1 development, = it doesn’t really fracture the community. But either way I will be ha= ppy to bridge to two (and have been).

EHL


On 12/18/08 2:43 PM, "Chris Messina" <chris.messina@gmail.com> wrote:

That sounds okay, but I am concerned about = the fracturing of the OAuth 1.1 work from the main OAuth community. Not tha= t we shouldn't pursue this direction (as we already decided we should), but= I'd like to know how we're going to bridge the social gap between these li= sts -- and keep one another informed of ongoing work.

I presume that much of this will fall to Eran as the go-between, but who el= se is representing from the community side of OAuth on the IETF list and is= willing to, from time to time, provide status updates and progress reports= for implementors and adopters on this list?

Just want to make sure that there's twoway visibility now that the IETF wor= k is underway.

Chris

On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
There has been some discussion and confusio= n about the purpose of the three
mailing lists and how they should be used moving forward. This is my
suggestions:

* oauth@ietf.org

Home for the standardization effort taking place in the IETF. The effort ha= s
being labeled as "OAuth 1.1" but label has never been agreed on. = The IETF is
looking at producing a standard based on the OAuth Core 1.0 protocol with some potential changes and additions.

That effort should produce the next iteration of the OAuth Core protocol an= d
all *new work* related to the OAuth Core protocol should be move to the IET= F
list. This is especially important to those who have strong opinions about<= BR> what the next iteration of the spec should look like, and how many changes<= BR> should be allowed from the 1.0 specification.

* oauth@googlegroups.com

This is the main community list for the adoption of the OAuth Core 1.0
specification. This is the place to go for interoperability issues,
developer support, questions about the specification, evangelism work, and<= BR> general community communication that is not about the protocol itself.

OAuth Core 1.0 is a stable and final specification and as such, can and
should be adopted (today). It is hard to tell how long it will take the IET= F
process to produce a final specification (which is not guaranteed), and it<= BR> is unlikely for a final spec to be completed in under a year.

Therefore, the OAuth Core 1.0 specification is the only official final work=
available and the only one that should be adopted at this point. There is absolutely no reason to wait for some unknown specification to be produced<= BR> at a later stage as OAuth already provides a working framework.

* oauth-extensions@googlegrou= ps.com

This list (which has not been very active lately) is the place for technica= l
discussions about additions and changes to the OAuth specification that are=
not covered by the IETF charter. Since the charter is still being worked on= ,
extensions discussions should be happening on the IETF list until decided they are out of scope and at that point move here.

---

Other suggestions? Feedback?

EHL




_______________________________________________
oauth mailing list
oauth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
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 145003A6829; Thu, 18 Dec 2008 16:02:25 -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 AAD2C3A6829 for ; Thu, 18 Dec 2008 16:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ome6rOnbih14 for ; Thu, 18 Dec 2008 16:02:22 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id F1E243A6804 for ; Thu, 18 Dec 2008 16:02:21 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so261022ywj.49 for ; Thu, 18 Dec 2008 16:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=CYd5IlzQBf7ZZApQBIKmSVR0Tk8T84JrgcLl33vsP7w=; b=Vnm7yqjzYur+Ag4HqbKJgNLOIBZDPbKABV4lPEanIbbGfIjtYXzGxClWvOeJOgBxnC HTwPXoaEwrIIawhyol+1MKprmki1elnaG4HXIIfc1Rc6EsNq827F3qzGg+U0Nh2E14Aq VzmpWY5smfJnL6MFn0Z2UBQzvXoxCzMjZ4z3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=aFITWuvYQi1sY/0HCIjlOLshpEN6MID2JapKGpfOmmSUDYzeIHQEiDqnNocN2x3uTs imoVJKRI2NDVLJ25cM0I9ZjfWXOuhBhMfE2Ip/JrjsVQ3f1yS1mV8lomvS55O7x3TTSj jkvah+Ypji9zcXg+41j6aQyYoLw5Ziuh8ZDtI= Received: by 10.231.16.129 with SMTP id o1mr82027iba.9.1229644933022; Thu, 18 Dec 2008 16:02:13 -0800 (PST) Received: by 10.231.19.203 with HTTP; Thu, 18 Dec 2008 16:02:12 -0800 (PST) Message-ID: <1bc4603e0812181602r3a8a8531qa4b86a2ebcf689fd@mail.gmail.com> Date: Thu, 18 Dec 2008 16:02:12 -0800 From: "Chris Messina" To: "Eran Hammer-Lahav" In-Reply-To: MIME-Version: 1.0 References: <1bc4603e0812181443w7c991ff0s2c47c1c8b74c75ef@mail.gmail.com> Cc: "oauth@googlegroups.com" , "oauth@ietf.org" Subject: Re: [oauth] OAuth Mailing Lists 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="===============0643358548==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0643358548== Content-Type: multipart/alternative; boundary="----=_Part_922_5818736.1229644933013" ------=_Part_922_5818736.1229644933013 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that's fine. I think there's plenty of advocacy and support still needed for OAuth 1.0, as it's in the wild now, that the need for the Google Group is not going to go away. The IETF list can be specifically (as you've suggested) about 1.1 work, which means that 1.0 will be covered under a certain set IPR scheme, whereas the 1.1 work will be under the IETF scheme (though hopefully something stronger from the OWF). Chris On Thu, Dec 18, 2008 at 3:06 PM, Eran Hammer-Lahav wrote: > I think the key for a successful IETF work is that most of the active > OAuth members from the old list will join the new list as well. If you > consider this simply a separation between 1.0 deployment and 1.1 > development, it doesn't really fracture the community. But either way I will > be happy to bridge to two (and have been). > > EHL > > > > On 12/18/08 2:43 PM, "Chris Messina" wrote: > > That sounds okay, but I am concerned about the fracturing of the OAuth 1.1 > work from the main OAuth community. Not that we shouldn't pursue this > direction (as we already decided we should), but I'd like to know how we're > going to bridge the social gap between these lists -- and keep one another > informed of ongoing work. > > I presume that much of this will fall to Eran as the go-between, but who > else is representing from the community side of OAuth on the IETF list and > is willing to, from time to time, provide status updates and progress > reports for implementors and adopters on this list? > > Just want to make sure that there's twoway visibility now that the IETF > work is underway. > > Chris > > On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav > wrote: > > There has been some discussion and confusion about the purpose of the three > mailing lists and how they should be used moving forward. This is my > suggestions: > > * oauth@ietf.org > > Home for the standardization effort taking place in the IETF. The effort > has > being labeled as "OAuth 1.1" but label has never been agreed on. The IETF > is > looking at producing a standard based on the OAuth Core 1.0 protocol with > some potential changes and additions. > > That effort should produce the next iteration of the OAuth Core protocol > and > all *new work* related to the OAuth Core protocol should be move to the > IETF > list. This is especially important to those who have strong opinions about > what the next iteration of the spec should look like, and how many changes > should be allowed from the 1.0 specification. > > * oauth@googlegroups.com > > This is the main community list for the adoption of the OAuth Core 1.0 > specification. This is the place to go for interoperability issues, > developer support, questions about the specification, evangelism work, and > general community communication that is not about the protocol itself. > > OAuth Core 1.0 is a stable and final specification and as such, can and > should be adopted (today). It is hard to tell how long it will take the > IETF > process to produce a final specification (which is not guaranteed), and it > is unlikely for a final spec to be completed in under a year. > > Therefore, the OAuth Core 1.0 specification is the only official final work > available and the only one that should be adopted at this point. There is > absolutely no reason to wait for some unknown specification to be produced > at a later stage as OAuth already provides a working framework. > > * oauth-extensions@googlegroups.com > > This list (which has not been very active lately) is the place for > technical > discussions about additions and changes to the OAuth specification that are > not covered by the IETF charter. Since the charter is still being worked > on, > extensions discussions should be happening on the IETF list until decided > they are out of scope and at that point move here. > > --- > > Other suggestions? Feedback? > > EHL > > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- Chris Messina Citizen-Participant & Open Technology Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private ------=_Part_922_5818736.1229644933013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that's fine. I think there's plenty of advocacy and support still needed for OAuth 1.0, as it's in the wild now, that the need for the Google Group is not going to go away.

The IETF list can be specifically (as you've suggested) about 1.1 work, which means that 1.0 will be covered under a certain set IPR scheme, whereas the 1.1 work will be under the IETF scheme (though hopefully something stronger from the OWF).

Chris

On Thu, Dec 18, 2008 at 3:06 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I think the key for a successful IETF work is that most of the active OAuth members from the old list will join the new list as well. If you consider this simply a separation between 1.0 deployment and 1.1 development, it doesn't really fracture the community. But either way I will be happy to bridge to two (and have been).

EHL



On 12/18/08 2:43 PM, "Chris Messina" <chris.messina@gmail.com> wrote:

That sounds okay, but I am concerned about the fracturing of the OAuth 1.1 work from the main OAuth community. Not that we shouldn't pursue this direction (as we already decided we should), but I'd like to know how we're going to bridge the social gap between these lists -- and keep one another informed of ongoing work.

I presume that much of this will fall to Eran as the go-between, but who else is representing from the community side of OAuth on the IETF list and is willing to, from time to time, provide status updates and progress reports for implementors and adopters on this list?

Just want to make sure that there's twoway visibility now that the IETF work is underway.

Chris

On Thu, Dec 18, 2008 at 1:42 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
There has been some discussion and confusion about the purpose of the three
mailing lists and how they should be used moving forward. This is my
suggestions:

* oauth@ietf.org

Home for the standardization effort taking place in the IETF. The effort has
being labeled as "OAuth 1.1" but label has never been agreed on. The IETF is
looking at producing a standard based on the OAuth Core 1.0 protocol with
some potential changes and additions.

That effort should produce the next iteration of the OAuth Core protocol and
all *new work* related to the OAuth Core protocol should be move to the IETF
list. This is especially important to those who have strong opinions about
what the next iteration of the spec should look like, and how many changes
should be allowed from the 1.0 specification.

* oauth@googlegroups.com

This is the main community list for the adoption of the OAuth Core 1.0
specification. This is the place to go for interoperability issues,
developer support, questions about the specification, evangelism work, and
general community communication that is not about the protocol itself.

OAuth Core 1.0 is a stable and final specification and as such, can and
should be adopted (today). It is hard to tell how long it will take the IETF
process to produce a final specification (which is not guaranteed), and it
is unlikely for a final spec to be completed in under a year.

Therefore, the OAuth Core 1.0 specification is the only official final work
available and the only one that should be adopted at this point. There is
absolutely no reason to wait for some unknown specification to be produced
at a later stage as OAuth already provides a working framework.

* oauth-extensions@googlegroups.com

This list (which has not been very active lately) is the place for technical
discussions about additions and changes to the OAuth specification that are
not covered by the IETF charter. Since the charter is still being worked on,
extensions discussions should be happening on the IETF list until decided
they are out of scope and at that point move here.

---

Other suggestions? Feedback?

EHL




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





--
Chris Messina
Citizen-Participant &
 Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
------=_Part_922_5818736.1229644933013-- --===============0643358548== 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 --===============0643358548==--