Re: [OAUTH-WG] OAUTH Report for IETF-83

Eran Hammer <eran@hueniverse.com> Fri, 30 March 2012 07:37 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE421F8622 for <oauth@ietfa.amsl.com>; Fri, 30 Mar 2012 00:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNZxrGydKM8M for <oauth@ietfa.amsl.com>; Fri, 30 Mar 2012 00:37:25 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 67EAD21F85F4 for <oauth@ietf.org>; Fri, 30 Mar 2012 00:37:25 -0700 (PDT)
Received: (qmail 24476 invoked from network); 30 Mar 2012 07:37:24 -0000
Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Mar 2012 07:37:24 -0000
Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id rjdQ1i0010U5vnL01jdQ03; Fri, 30 Mar 2012 00:37:24 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 30 Mar 2012 00:37:24 -0700
From: Eran Hammer <eran@hueniverse.com>
To: William Mills <wmills@yahoo-inc.com>, Derek Atkins <derek@ihtfp.com>, "saag@ietf.org" <saag@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Date: Fri, 30 Mar 2012 00:37:15 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0OPDQnyHD4N+ubRGuCp/Me96jLUgAA40mw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5D5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <sjmk423bf7c.fsf@mocana.ihtfp.org> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 07:37:26 -0000


> -----Original Message-----
> From: William Mills [mailto:wmills@yahoo-inc.com]
> Sent: Thursday, March 29, 2012 11:13 PM
> To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
> 
> Thanks for the process lecture....  except we already had extensive
> discussion of same in the WG meeting...

The comment shared with the list was:

"There was also consensus to include Simple Web Discovery (in addition to, and separate from, Dynamic Client Registration)"

This "lecture" is my attempt at understanding how the people in the room (I was unable to afford flying to Paris or be up at 4am) got from the Dynamic Client Registration proposal which does not even mention SWD (but does rely on an outdated version of RFC 6415), to including SWD as a "separate" item without any direct link to OAuth (other than "interest in the room").

Since the chair implied that there was already consensus (which is a very significant IETF process statement), raising process issues is one tool the IETF provides for those in disagreement.

> Partially this issue was raised because my draft does a discovery thing and I
> want this sorted out to figure out what hooks I need to put in so I can get
> done.  I want to be consistent with whatever will be the chosen standardized
> usage. I really DO NOT care how we solve the problem as long as it's solved.

I DO care how we solve this problem, but more importantly, defining what the problem actually is. 

> I think your point that host-meta and LINK/REL solve the same problem is a
> fair one, it came up in the room.  Another comment in the room was that for
> JS based stuff JSON is far easier to deal with than XML, and I think that's
> probably also really true, so there are some competing isues.

This just shows how little technical due-diligence was done by this group.

RFC 6415 provides full JSON support. The WebFinger draft which slightly extends RFC 6415, makes JSON support required and adds the 'resource' query parameter [1]. A additional 'rel' query parameter has also been proposed and is being discussed on the APPS discuss list.

I guess my question is, why isn't RFC 6415 by the simple virtue of it being a publish IETF proposed standard RFC the default and obvious choice here? Why isn't this discussion framed in terms of making enhancements to RFC 6415 (as already in progress by the WebFinger proposal, which BTW, is also under discussion for IETF venue) or in terms of discussing why RFC 6415 is not the suitable choice for the yet-to-be-defined OAuth discovery framework?

Is this group even aware that the 5 years effort (!) leading to RFC 6415 was primarily done for OAuth discovery? There is so much relevant history here being completely ignored.

If the OAuth charter is going to mention SWD, it must also mention RFC 6415 as an equal alternative to be discussed by the WG. The charter discussion is clearly not the place to make this decision. In addition, if this WG is going to busy itself with helping find SWD a proper home, that discussion must also include finding a proper home for the WebFinger proposal, given the clear IETF conflict in promoting both.

The discovery solution adopted by OAuth is very likely to have significant influence over future web discovery beyond OAuth. The stakes here are pretty high.

EH

[1] http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02#section-4.2