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

[Eran Hammer <[e-mail]>]

Hi Derek,

Thanks for the notes. Is an audio recording available?

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