Not everyone has the time or inclination to follow and respond to all of this.
On Wed, Aug 28, 2013 at 10:01 AM, Anthony Nadalin <tony...@microsoft.com> wrote: > So I guess we should have different specifications for different use cases to > solve same requirements, I guess we should have done that we OAuth and not > worked out common flows, patterns, parameters, etc. I have only seen 2-3 > respond to the implementation status, once again people should post if they: > > 1. have implemented this as is > 2. plan on implementing as is > 3. what use case they are solving > 4. what modifications needed on top of this specification to actually solve > use case > > -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Wednesday, August 28, 2013 8:51 AM > To: Anthony Nadalin > Cc: Phil Hunt; oauth mailing list > Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 > Aug, 2pm PDT: Conference Bridge Details > > Except that folks are already actually implementing and using the spec, and > that all of the discussions around different specs are pretty clearly > pointing to different use cases and assumptions about the state of the world. > > Your arguments are invalid. > > -- Justin > > On 08/28/2013 11:49 AM, Anthony Nadalin wrote: >>> Therefore I once again call for the WG to finish the current dynamic >>> registration spec *AND* pursue the assertion based process that >>> Phil's talking about. They're not mutually exclusive, let's please >>> stop talking >> I see no reason to continue to push finish the current specification when >> there are so many discussions/issues going on as discussions will only lead >> to better specifications that folks can actually implement and use. >> >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Justin Richer >> Sent: Wednesday, August 28, 2013 8:42 AM >> To: Phil Hunt >> Cc: oauth mailing list >> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: >> Wed 28 Aug, 2pm PDT: Conference Bridge Details >> >> Except for the cases where you want step 1 to happen in band. To me, that is >> a vitally and fundamentally important use case that we can't disregard, and >> we must have a solution that can accommodate that. The notions of >> "publisher" and "product" fade very quickly once you get outside of the >> software vendor world. >> >> This is, of course, not to stand in the way of other solutions or approaches >> (such as something assertion based like you're after). It's not a >> one-or-the-other proposition, especially when there are mutually exclusive >> aspects of each. >> >> Therefore I once again call for the WG to finish the current dynamic >> registration spec *AND* pursue the assertion based process that Phil's >> talking about. They're not mutually exclusive, let's please stop talking >> about them like they are. >> >> -- Justin >> >> On 08/28/2013 11:17 AM, Phil Hunt wrote: >>> Sorry. I meant also to say i think there are 2 registration steps. >>> >>> 1. Software registration/approval. This often happens out of band. But in >>> this step policy is defined that approves software for use. Many of the reg >>> params are known here. >>> >>> Federation techniques come into play as trust approvals can be based on >>> developer, product or even publisher. >>> >>> 2. Each instance associates in a stateless way. Only clients that need >>> credential rotation need more. >>> >>> Phil >>> >>> On 2013-08-28, at 8:04, Phil Hunt <phil.h...@oracle.com> wrote: >>> >>>> I have a conflict I cannot get out of for 2pacific. >>>> >>>> I think a certificate based approach is going to simplify exchanges in all >>>> cases. I encourage the group to explore the concept on the call. >>>> >>>> I am not sure breaking dyn reg up helps. It creates yet another option. I >>>> would like to explore how federation concept in software statements can >>>> help with facilitating association and making many reg stateless. >>>> >>>> Phil >>>> >>>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" >>>> <hannes.tschofe...@nsn.com> wrote: >>>> >>>>> Here are the conference bridge / Webex details for the call today. >>>>> We are going to complete the use case discussions from last time >>>>> (Phil wasn't able to walk through all slides). Justin was also able >>>>> to work out a strawman proposal based on the discussions last week >>>>> and we will have a look at it to see whether this is a suitable >>>>> compromise. Here is Justin's mail, in case you have missed it: >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html >>>>> >>>>> Phil, please feel free to make adjustments to your slides given the >>>>> Justin's recent proposal. >>>>> >>>>> Topic: OAuth Dynamic Client Registration >>>>> Date: Wednesday, August 28, 2013 >>>>> Time: 2:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) >>>>> Meeting Number: 703 230 586 Meeting Password: oauth >>>>> >>>>> ------------------------------------------------------- >>>>> To join the online meeting >>>>> ------------------------------------------------------- >>>>> 1. Go to >>>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk >>>>> & >>>>> RT=MiM0 2. Enter your name and email address. >>>>> 3. Enter the meeting password: oauth 4. Click "Join Now". >>>>> >>>>> To view in other time zones or languages, please click the link: >>>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk >>>>> & >>>>> ORT=MiM0 >>>>> >>>>> To add this meeting to your calendar program (for example Microsoft >>>>> Outlook), click this link: >>>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2 >>>>> & >>>>> ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0 >>>>> >>>>> ------------------------------------------------------- >>>>> To join the teleconference only >>>>> ------------------------------------------------------- >>>>> Global dial-in Numbers: http://www.nokiasiemensnetworks.com/nvc >>>>> Conference Code: 944 910 5485 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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
