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
>________________________________
> From: Eran Hammer <e...@hueniverse.com>
>To: William Mills <wmi...@yahoo-inc.com>; Derek Atkins <de...@ihtfp.com>;
>"s...@ietf.org" <s...@ietf.org>; "oauth@ietf.org" <oauth@ietf.org>
>Sent: Thursday, March 29, 2012 7:25 PM
>Subject: RE: [OAUTH-WG] OAUTH Report for IETF-83
>
>
>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:wmi...@yahoo-inc.com]
>Sent: Thursday, March 29, 2012 4:26 PM
>To: Eran Hammer; Derek Atkins; s...@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 <e...@hueniverse.com>
>>To: Derek Atkins <de...@ihtfp.com>; "s...@ietf.org" <s...@ietf.org>;
>>"oauth@ietf.org" <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-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>>> Of Derek Atkins
>>> Sent: Thursday, March 29, 2012 8:27 AM
>>> To: s...@ietf.org; 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
>>https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
