>Now maybe your way is the better way but why not let the market make that >decision?
So what is the hurry to get the dyn reg specification out the door, if we have the market data it will make the specification that much better. I agree that most of this can be done today w/o any additional specifications, that is what I question the complex, underspecified dyn reg specification that is being proposed. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Wednesday, August 28, 2013 9:55 AM To: George Fletcher Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details That's what I'm trying to do. All I have been asking for is time to explore the spec and to see how it can impact and simplify dyn reg -- which I believe is a significant amount. It would be pre-mature at this point to move Dyn Reg forward without exploring this. I still believe dyn reg is over-specified because it assumes *every* cllient registration is different when in fact 99.9% of registrations are going to fall in clusters of client applications. Much of the paramaters can be moved to step 1 of registration or at the least be bundled into the software assertion. Thus the reg endpoint only has to deal with truly instance specific details (e.g. like credential management). I don't pre-clude that most of dyn reg may remain intact, but it seems clear there will be substantive breaking changes that simplify registration. Phil @independentid www.independentid.com<http://www.independentid.com> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-08-28, at 9:47 AM, George Fletcher <gffle...@aol.com<mailto:gffle...@aol.com>> wrote: So Phil... given that you can do all this today with the existing set of specifications... why not write the software statements/client assertion registration spec so that it meets your use case and deployment needs. I'd much rather have two straight forward ways to do something when the core use cases are so different than to try and munge everything into one and end up with unnecessary complexity in one or both of the solutions. I see the use case you are trying to solve for as significantly different than the one I'm trying to solve for. Now maybe your way is the better way but why not let the market make that decision? We will not confuse developers by having two ways to do things as it will be very clear at the beginning of development which way is needed for their use case:) Thanks, George On 8/28/13 12:41 PM, Phil Hunt wrote: Yes. A client could pass the software statement *directly* as its client credential. Which is one of the *simple* solutions. 8-) The other case is where the client instance needs its own credential as George indicates. In that case it could swap the statement for a unique client assertion. Phil @independentid www.independentid.com<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-08-28, at 9:38 AM, Sergey Beryozkin <sberyoz...@gmail.com><mailto:sberyoz...@gmail.com> wrote: On 28/08/13 17:33, George Fletcher wrote: So I understand that you'd rather that OAuth doesn't require a client_secret and that's fine. However, I don't think we should impose that thinking on the rest of the world who have already implemented it and have it working and scaling without issues. If the core of this discussion is around replacing client_id and client_secret with a client_assertion then lets have that discussion separately and not bury it in the dynamic registration discussion. Could you not profile OAuth2 to support a flow that allows for retrieval of access and refresh tokens using code + client_assertion? Doesn't seem like that hard a profile and then the rest of this could fall out pretty easily. That is already supported AFAIK, something like grant_type=authorization_code &code=12345678 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Asaml2-bearer &client_assertion=Base64UrlEncoded-SAML2-Bearer-Assertion probably the same works with JWT Sergey Thanks, George On 8/28/13 12:28 PM, Anthony Nadalin wrote: I do think that this is the rare-edge use case, we would not want require client-secret, we already have that mess today with OAuth and trying not to continue the proliferation, we solve this today with our STS and assertion swaps/transformations, it scales, performs and we don't have the management debacle this specification creates *From:*oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] *On Behalf Of *George Fletcher *Sent:* Wednesday, August 28, 2013 9:21 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 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><mailto:jric...@mitre.org> <mailto:jric...@mitre.org><mailto: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><mailto:phil.h...@oracle.com> <mailto:phil.h...@oracle.com><mailto: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><mailto:hannes.tschofe...@nsn.com> <mailto:hannes.tschofe...@nsn.com><mailto: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 tohttps://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<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- George Fletcher <http://connect.me/gffletch><http://connect.me/gffletch> -- George Fletcher <http://connect.me/gffletch><http://connect.me/gffletch> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com<http://sberyozkin.blogspot.com/> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- <XeC.png><http://connect.me/gffletch>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
