Because it is in the draft the WG is suppose to consider. It's a stated dependency.
EH > -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Wednesday, April 18, 2012 12:50 PM > To: Eran Hammer > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Dynamic Client Registration > > Hi Eran, > > why do you see a relationship between dynamic client registration and > discovery? Basically, we don't care so far how a client finds tokens and end- > user authorization point. Why is this any different for the client > registration > endpoint (or the revocation endpoint)? Or do you have a bigger picture in > mind? > > regards, > Torsten. > > Am 15.04.2012 22:36, schrieb Eran Hammer: > > Where did I say I'm not interested in this work?! > > > > All I was saying is that it would be better to postpone it until the > > discovery > layer, which this draft clearly relies upon, is a bit clearer. I would be > satisfied > with a simple note stating that if the discovery work at the APP area isn't > complete, the WG may choose to delay work on this document until ready. > > > > EH > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] > >> Sent: Sunday, April 15, 2012 9:01 AM > >> To: Eran Hammer > >> Cc: Hannes Tschofenig; oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Dynamic Client Registration > >> > >> Hi Eran, > >> > >> you are saying that you are not interested in the dynamic client > >> registration work and that's OK. There are, however, a couple of > >> other folks in the group who had expressed interest to work on it, to > review and to implement it. > >> > >> Note also that the discovery and the dynamic client registration is > >> different from each other; there is a relationship but they are > nevertheless different. > >> > >> Ciao > >> Hannes > >> > >> PS: Moving the Simple Web Discovery to the Apps area working group > >> does not mean that it will not be done. On the contrary there will be > >> work happing and we are just trying to figure out what the difference > >> between SWD and WebFinger is. > >> > >> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: > >> > >>> I'd like to see 'Dynamic Client Registration' removed from the > >>> charter along > >> with SWD for the sole reason that figuring out a generic discovery > >> mechanism is going to take some time and this WG has enough other > >> work to focus on while that happens elsewhere. I expect this to come > >> back in the next round with much more deployment experience and > discovery clarity. > >>> EH > >>> > >>>> -----Original Message----- > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Hannes Tschofenig > >>>> Sent: Friday, April 13, 2012 7:36 AM > >>>> To: oauth@ietf.org WG > >>>> Subject: [OAUTH-WG] Dynamic Client Registration > >>>> > >>>> Hi all, > >>>> > >>>> at the IETF#83 OAuth working group meeting we had some confusion > >>>> about the Dynamic Client Registration and the Simple Web Discovery > >>>> item. I just listened to the audio recording again. > >>>> > >>>> With the ongoing mailing list discussion regarding WebFinger vs. > >>>> Simple Web Discovery I hope that folks had a chance to look at the > >>>> documents again and so the confusion of some got resolved. > >>>> > >>>> I believe the proposed new charter item is sufficiently clear with > >>>> regard to the scope of the work. Right? > >>>> Here is the item again: > >>>> " > >>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to > >>>> the IESG for consideration as a Proposed Standard > >>>> > >>>> [Starting point for the work will be > >>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > >>>> ] > >>>> " > >>>> > >>>> Of course there there is a relationship between Simple Web > >>>> Discovery (or > >>>> WebFinger) and the dynamic client registration since the client > >>>> first needs to discover the client registration endpoint at the > >>>> authorization server before interacting with it. > >>>> > >>>> Now, one thing that just came to my mind when looking again at > >>>> draft- hardjono-oauth-dynreq was the following: Could the Client > >>>> Registration Request and Response protocol exchange could become a > >>>> profile of the SCIM protocol? In some sense this exchange is > >>>> nothing else than provisioning an account at the Authorization > >>>> Server (along with > >> some meta-data). > >>>> Is this too far fetched? > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> _______________________________________________ > >>>> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
