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

[Phil Hunt <[e-mail]>]

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
[e-mail]







On 2013-08-28, at 9:29 AM, George Fletcher <[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]> 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 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
>>>> 
>>>> 
>>> 
>>> -- 
>>> <XeC>
> 
> -- 
> <XeC.png>