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

[George Fletcher <[e-mail]>]

So, if we take the current OAuth model that I think I hear you 
espousing... OAuth core is "local"  and "federated" scenarios need to be 
profiled to be "locked down" ... then shouldn't we do the same thing 
with the dyn reg spec? Consider what's proposed as "local" and the 
"federated" model is a profile (see my other post).

In the UMA case (as I'm actively involved in that effort) I would want 
the UMA spec to define where agreed upon formats are required. I 
wouldn't want that done in the OAuth core specs. The reason is that the 
specification narrows the scope of the applicabillity of the solution to 
the problem domain being solved. So UMA, which defines the problem space 
it's trying to solve, should be the spec to define the required formats. 
This is clean layering.

In this case of federated app deployments that you are discussing it 
seems like it requires a special profile for that problem domains space 
just as UMA defines it's own profile of OAuth2 for it's problem space 
and OpenID Connect defines it's profile for it's problem domain space.

Thanks,
George

On 8/28/13 1:03 PM, Phil Hunt wrote:
> I think many of the parameters in dyn reg need to be specified in the 
> statement -- the main change is we're moving dyn reg parameters into 
> the statement and locking them down between instances.  It keeps 
> hackers from changing individual instances and it minimizes state in 
> per instance registration.
>
> The reason OAuth doesn't have to define token formats is they are 
> largely "local".  Federated token scenarios (like UMA) obviously have 
> to have some OOB agreement on format.  Given that registration in most 
> of these cases is federated, it seems appropriate to define these 
> assertions. (In the non-federated cases (e.g. like Google), they can 
> do registration using workflows with the developer directly.)
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
>
>
> On 2013-08-28, at 9:55 AM, George Fletcher <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> OAuth has never specified anything regarding the format the "tokens" 
>> that the AS has to accept and that's one of it's virtues. It allows 
>> for many implementations from local only to federated.
>>
>> I fully believe there is value in defining profiles of OAuth for 
>> particular problem domains that put restrictions on client_id format, 
>> access_token format etc (e.g. the assertion set of specs). However, 
>> those should be layered on top of OAuth as a profile and not be 
>> forced into the core. Otherwise, we are forcing all implementations 
>> down a much narrower path than is supported today. I definitely don't 
>> want to see that happen.
>>
>> Thanks,
>> George
>>
>> On 8/28/13 12:48 PM, Phil Hunt wrote:
>>> You can pass anything as a client_id.  It just has to be accepted. 
>>> That's the point of us writing a draft here isn't it?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2013-08-28, at 9:45 AM, John Bradley <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> That is my concern as well, sending an assertion to the 
>>>> authorization endpoint requires a extension of OAuth to add another 
>>>> parameter or placing it in the client_id which you can do now with 
>>>> the dynamic reg spec if the AS wants to.
>>>>
>>>> Holding up client registration for something that will require an 
>>>> extension to OAuth is overdoing it.   We need something for the 
>>>> OAuth spec we have now without requiring clients implement the 
>>>> assertion flow and other extensions.
>>>>
>>>> John B.
>>>>
>>>> On 2013-08-28, at 12:39 PM, Justin Richer <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>> The initial_access_token doesn't assume that it's from the local 
>>>>> domain. It merely assumes that the authorization server accepts 
>>>>> the token, which would be true in the UMA case due to the 
>>>>> federation. It could also be the exact same kinds of mechanisms 
>>>>> that the software statement would use to achieve federation.
>>>>>
>>>>> I still don't see how an auth server is going to know about a 
>>>>> client's configuration state with the assertion swap method, since 
>>>>> there's no defined mechanism for sending a JWT assertion to the 
>>>>> authorization endpoint.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>> On 08/28/2013 12:35 PM, Phil Hunt wrote:
>>>>>> George,
>>>>>>
>>>>>> It would be reasonable for a client to submit an assertion, and 
>>>>>> obtain its own client assertion in return.  This is very close to 
>>>>>> what is happening per 2.1, 2.2 of 
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06
>>>>>>
>>>>>> In this case, the Software Statement is an authorization that is 
>>>>>> exchanged for a client assertion in return. Then the clients 
>>>>>> authenticate per section 2.2 of the JWT spec.
>>>>>>
>>>>>> Regarding initial_access_token.  This does have some of the 
>>>>>> characteristics I am speaking of. But it is unspecified and the 
>>>>>> assumption is that it is issued by the local domain.  This 
>>>>>> doesn't work in the UMA case because that's more like a federated 
>>>>>> model. Thus the specified software statement works because the AS 
>>>>>> can approve the client software based on name, and/or developer, 
>>>>>> and/or publisher -- whatever trust requires.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-08-28, at 9:29 AM, George Fletcher <[e-mail] 
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>> I can't say I understand what you mean by a simple assertion 
>>>>>>> swap... but if you are wanting to use a client_assertion flow 
>>>>>>> instead of the code flow then that's something completely 
>>>>>>> different. If you are saying that you want the client_id to 
>>>>>>> represent an "instance" in a stateless way using an "assertion" 
>>>>>>> then that's already possible today.
>>>>>>>
>>>>>>> George
>>>>>>>
>>>>>>> On 8/28/13 12:23 PM, Phil Hunt wrote:
>>>>>>>> George
>>>>>>>>
>>>>>>>> That case can be solved with a simple assertion swap. We just 
>>>>>>>> have to profile it.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On 2013-08-28, at 9:20, George Fletcher <[e-mail] 
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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]>  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]>  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 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]
>>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> <XeC> <http://connect.me/gffletch>
>>>>>>>
>>>>>>> -- 
>>>>>>> <XeC.png> <http://connect.me/gffletch>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> -- 
>> <XeC.png> <http://connect.me/gffletch>
>

-- 
George Fletcher <http://connect.me/gffletch>