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

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

Return-Path: <eran@hueniverse.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E921E8043; Thu, 29 Mar 2012 19:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level:
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 EavrV-yvo+3K; Thu, 29 Mar 2012 19:25:33 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5521E801C; Thu, 29 Mar 2012 19:25:32 -0700 (PDT)
Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id reRY1i00110TkE001eRYvo; Thu, 29 Mar 2012 19:25:32 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 19:25:32 -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: Thu, 29 Mar 2012 19:25:23 -0700
Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83
Thread-Index: Ac0OA2EAhhPYKnyhR0i6KLfy2HrQpQAFc/Og
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <sjmk423bf7c.fsf@mocana.ihtfp.org> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com>
In-Reply-To: <1333063588.49896.YahooMailNeo@web31816.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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700
Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 02:25:38 -0000

The narrative so far:

The IETF has adopted host-meta as a general-purpose discovery mechanism in RFC 6415.
The OpenID Connect group, which utilizes OAuth but is out of scope for this WG, adopted SWD as its discovery mechanism.
The proposed charter references 'OAuth Dynamic Client Registration Protocol', which in turn references RFC 6415 as its discovery mechanism.

Am I missing a WG item or proposed draft which relies on SWD at this time? If I am, are these documents included in the proposed charter or are requested to be included (e.g. not SWT itself but other documents with dependencies on it)? In such documents, is SWD a required component which cannot be substituted with something else such as RFC 6415?

Here is how this process should work:


1.       The WG agrees on including a discovery related item in its charter. The dynamic client registration is a reasonable such item.

2.       The charter references an existing proposal as foundation.

3.       The WG begins discussing the proposed draft (which can happen at any time on the list as long as the chairs allow it).

4.       The WG discusses any required enabling technologies, their suitability, maturity, industry support, etc. In the case of dynamic registration, I expect the WG to discuss SWD (because it is the technology selected by the OpenID subset of this WG), host-meta (because it is an IETF proposed standard RFC), as well as other solutions (Link headers, other well-known URIs, etc.). The publication status of the proposed technologies is another factor.

5.       If an enabling technology is decided to be the most suitable, and is not available in normative reference form, the WG will discuss the best way to accomplish that. This includes identifying the right community, standards body, working group, etc. that is best to take on the work. If no suitable venue is found, the WG may decide to take on the work with very limited scope only to enable its own use cases.

I am not opposed to having this discussion, but why are *we* having it *now*, other than the OpenID Connect group, which has nothing to do with this WG, is stuck with the problem of finding a venue for this work, and are dumping it on our laps?

I do not recall this WG ever decided (or even *proposed*) to use SWD for any of its chartered items. When we have this discussion, I expect it to include a detailed examination of host-meta and other solutions *as equal* alternatives. The OpenID Connect group preference is a valid input as it covers some potential market share with OAuth deployment, but it is *far* from any significant deployment worthy of bypassing this evaluation.

Am I missing something here?

EH





From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

On the SWD stuff there was general discussion about "is this the right place?", and there "were issues raised".  The question was also asked "well, where is the right place?" which got crickets.  It is exactly coming back to the list for discussion to sort out the right place.

________________________________
From: Eran Hammer <eran@hueniverse.com<mailto:eran@hueniverse.com>>
To: Derek Atkins <derek@ihtfp.com<mailto:derek@ihtfp.com>>; "saag@ietf.org<mailto:saag@ietf.org>" <saag@ietf.org<mailto:saag@ietf.org>>; "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

Hi Derek,

Thanks for the notes. Is an audio recording available?

> -----Original Message-----
> From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf
> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
> To: saag@ietf.org<mailto:saag@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] OAUTH Report for IETF-83
>
> Hi,
>
> OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two
> hour session.  After introducing ourselves and welcoming me to the working
> group we thanked Barry and Blaine for their service.
>
> Torsten spoke about draft-ietf-oauth-v2-threatmodel.  This document has
> completed WG Last Call.  Torsten has applied changes based on the Last Call
> Comments and has published a new revision.  Barry promised to finish his
> PROTO Shepard review next week so we can send this document to the
> IESG.  He promises to take Mike Thomas' issues from the list into account and
> make sure that everyone is happy.
>
> [ I'd like to extend a personal thank you to Barry for continuing his role
>  as document shephard for this draft.  -- derek ]
>
> Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstanding issue Mike believes these documents
> are ready for WGLC.  Consensus in the room was to take these three docs to
> WGLC, which the chairs will do by the end of next week.
>
> The MAC Token draft has languished while time was spent working on the
> core document.  Eran was not here, nor was he online, to talk about the
> status of the MAC Token draft.  There were only a few people in the room
> interested in reviewing the draft, which was not a clear consensus of
> interest, even though this document does solve a problem that the bearer
> tokens cannot.  The chairs will take it to the list to evaluate if there is enough
> interest to continue with this document.

As I've updated the list and chairs on multiple occasions, the draft is practically ready. There was some late arriving feedback which I did not get around to process. However, the main issue is lack of WG interest in this work. I am still planning to finish it by making very minor tweaks to the current draft, but would be very happy to make it an individual submission.

The MAC draft has largely been my personal project to date.

> In a related note, this document (as well as the v2-bearer document) is not
> available off the tools page even though it has not expired.  I have taken the
> action item to get that sorted out.
>
> Finally, we spent the majority of our time talking about rechartering based on
> the proposed charter sent to the list by Hannes a week or two ago.
> Consensus of the room was that there was enough interest to recharter
> based roughly on the proposed charter.  There was also consensus to include
> Simple Web Discovery (in addition to, and separate from, Dynamic Client
> Registration), although we will need to work with the ADs to make sure it
> gets handled in the appropriate WG and Area.
> Moreover, it's important to make sure the appropriate applications area
> participants get involved in the SWD work.

There is something very awkward about discussing SWD both in the context of this working group, and in the context of future OAuth discovery work. The idea of picking a discovery mechanism before the WG had a single discussion about what is included in discovery and what are the use cases and requirement is absurd.

There has not been consensus on the list for including SWD in the WG charter.

The only justification I have heard so far for this WG to be the SWD venue is that it's easy because the author and a few other people interested are already here. That's not a valid reason.

Any further work on SWD also requires the IETF to view it in light of RFC 6415 (host-meta) which is a proposed standard approved in October 2011. The IETF is not in the 'flavor of the month' business. Proper process requires discussion about the merits of redoing the host-meta work from scratch in a non-compatible way just because a handful of people 'like it better' with little technical justification.

Either way, this discussion does not belong here.

EH

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