Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

[Sergey Beryozkin <[e-mail]>]

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:*[e-mail] [mailto:[e-mail]] *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<[e-mail]>  <mailto:[e-mail]>  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<[e-mail]>  <mailto:[e-mail]>  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)"<[e-mail]>  <mailto:[e-mail]>  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
>>
>>                     [e-mail]  <mailto:[e-mail]>
>>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>
>>                 _______________________________________________
>>
>>                 OAuth mailing list
>>
>>                 [e-mail]  <mailto:[e-mail]>
>>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>             _______________________________________________
>>
>>             OAuth mailing list
>>
>>             [e-mail]  <mailto:[e-mail]>
>>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     _______________________________________________
>>
>>     OAuth mailing list
>>
>>     [e-mail]  <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> --
>> George Fletcher <http://connect.me/gffletch>
>>
>
> --
> George Fletcher <http://connect.me/gffletch>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com