George That case can be solved with a simple assertion swap. We just have to profile it.
Phil On 2013-08-28, at 9:20, George Fletcher <gffle...@aol.com> wrote: > > On 8/28/13 12:02 PM, Phil Hunt wrote: >> Please define the all in one case. I think this is the edge case and is in >> fact rare. >> >> I agree, in many cases step 1 can be made by simply approving a class of >> software. But then step 2 is simplified. >> >> Dyn reg assumes every registration of an instance is unique which too me is >> a very extreme > If you have a mobile app that needs to do the code flow... which requires a > client_secret in order to retrieve the access token and refresh token, how > does the app do this without per app instance registration? > > I'd argue that almost all user facing mobile apps will want the above flow > and that's not a small, rare edge case. > > Thanks, > George >> position. >> >> Phil >> >> On 2013-08-28, at 8:41, Justin Richer <jric...@mitre.org> wrote: >> >>> 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 > > -- > <XeC>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
