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

[Justin Richer <[e-mail]>]

I think it makes perfect sense to have different spects for different 
use cases to solve different requirements (and the requirements *are* 
different -- you keep bringing up fully stateless registration and 
that's just not a requirement for many people). The different specs can 
(and should) use common parameters and data models where it makes sense, 
and differ where it makes sense. You know, just like we did with the 
OAuth flows. There's a reason that the Client Credentials flow doesn't 
use the authorization endpoint, but the Code flow does. And there's also 
a reason why the "grant_type" parameter is an explicit extension point 
in OAuth.

The as-of-yet-completely-unspecified-and-unimplemented software 
assertions based "spec" can re-use the client model from the current 
dyn-reg, if it wants to and it makes sense to. It can use the same 
parameter names. Nobody's saying not to do that, Tony. But in addition 
to the responders who have implemented Dyn-Reg as it is, I'd like to 
hear from people who have implemented the stateless proposal as well. 
Anyone?

  -- Justin


On 08/28/2013 12:01 PM, Anthony Nadalin wrote:
> So I guess we should have different specifications for different use cases to solve same requirements, I guess we should have done that we OAuth and not worked out common flows, patterns, parameters, etc. I have only seen 2-3 respond to the implementation status, once again people should post if they:
>
> 1. have implemented this as is
> 2. plan on implementing as is
> 3. what use case they are solving
> 4. what modifications needed on top of this specification to actually solve use case
>
> -----Original Message-----
> From: Justin Richer [mailto:[e-mail]]
> Sent: Wednesday, August 28, 2013 8:51 AM
> To: Anthony Nadalin
> Cc: Phil Hunt; oauth mailing list
> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details
>
> Except that folks are already actually implementing and using the spec, and that all of the discussions around different specs are pretty clearly pointing to different use cases and assumptions about the state of the world.
>
> Your arguments are invalid.
>
>    -- Justin
>
> On 08/28/2013 11:49 AM, Anthony Nadalin wrote:
>>> 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
>> I see no reason to continue to push finish the current specification when there are so many discussions/issues going on as discussions will only lead to better specifications that folks can actually implement and use.
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Justin Richer
>> Sent: Wednesday, August 28, 2013 8:42 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
>>
>> 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]> 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]> 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 to
>>>>> https://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]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth