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 phil.h...@oracle.com On 2013-08-28, at 9:47 AM, George Fletcher <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 >> phil.h...@oracle.com >> >> >> >> >> >> >> >> On 2013-08-28, at 9:38 AM, Sergey Beryozkin <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] *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> 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> 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> >>>>> 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> >>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> George Fletcher <http://connect.me/gffletch> >>>>> >>>> -- >>>> George Fletcher <http://connect.me/gffletch> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> -- >>> Sergey Beryozkin >>> >>> Talend Community Coders >>> http://coders.talend.com/ >>> >>> Blog: http://sberyozkin.blogspot.com >>> _______________________________________________ >>> 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.png>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
