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

From: Derek Atkins <[email-masked]>
Date: Thu, 29 Mar 2012 11:27:03 -0400

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.

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.

Hannes and I will revise the proposed charter and send it out to the WG
for additional comments and feedback.  Our goal is to send it to the
IESG for approval on their April 26th telechat.  This would hopefully
result in approval on the May 10th chat, after public comment.

We finished the meeting at 14h30.

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Eran Hammer <[email-masked]>
Date: Thu, 29 Mar 2012 08:44:57 -0700

Hi Derek,

Thanks for the notes. Is an audio recording available?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
> To: [email-masked]; [email-masked]
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

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

---

From: William Mills <[email-masked]>
Date: Thu, 29 Mar 2012 16:26:28 -0700 (PDT)

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 <[email-masked]>
>To: Derek Atkins <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, March 29, 2012 8:44 AM
>Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
> 
>Hi Derek,
>
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Eran Hammer <[email-masked]>
Date: Thu, 29 Mar 2012 19:25:23 -0700

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:[email-masked]]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: Derek Atkins <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83

Hi Derek,

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Derek Atkins
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

EH

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Thu, 29 Mar 2012 23:13:14 -0700 (PDT)

Thanks for the process lecture....  except we already had extensive discussion of same in the WG meeting...

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 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.  

-bill

>To: William Mills <[email-masked]>; Derek Atkins <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, March 29, 2012 7:25 PM
>Subject: RE: [OAUTH-WG] OAUTH Report for IETF-83
> 
>
>The narrative so far:
> 
>The proposed charter references ‘OAuth Dynamic Client Registration Protocol’, which in turn references RFC 6415 as its discovery mechanism.
> 
>From:William Mills [mailto:[email-masked]] 
>>From:Eran Hammer <[email-masked]>

---

From: Eran Hammer <[email-masked]>
Date: Fri, 30 Mar 2012 00:37:15 -0700

> Sent: Thursday, March 29, 2012 11:13 PM

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