So why are you fighting so hard against standardizing software assertions? You're affectively already using the solution for BB+.
The fact that a standardized initial_access_token eliminates most of the registration endpoint seems to be your primary objection. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-28, at 9:41 AM, Justin Richer <jric...@mitre.org> wrote: > Yes, that already works. And you could accomplish that with the current > dynamic registration spec, too -- it's just that client assertions were > deemed too-underspecified to include in the base draft, and nobody's stepped > up to offer a full writeup and extension of using other auth mechanisms > (outside of OpenID Connect). > > -- Justin > > On 08/28/2013 12:38 PM, Sergey Beryozkin 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 >>> >> >> > > _______________________________________________ > 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
