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

[Justin Richer <[e-mail]>]

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:*[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
>>
>
>