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

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Aug 2013 07:48:55 +0200

Hi Phil,

You would send the client's credential to the authz endpoint, so it would go through the browser and would be exposed to other parties.

I agree with George and others. This is a topic different from dyn reg and should be handled independently. 

I personally consider assertions as means to client authentication an interesting option we should further evaluate. But this would be an evolution to OAuth itself.

regards,
Torsten.

Phil Hunt <[email-masked]> schrieb:
>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
>[email-masked]
>
>
>
>
>
>
>
>On 2013-08-28, at 9:45 AM, John Bradley <[email-masked]> 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 <[email-masked]> 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
>>>> [email-masked]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2013-08-28, at 9:29 AM, George Fletcher <[email-masked]>
>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 <[email-masked]> 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 <[email-masked]>
>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 <[email-masked]>
>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)" <[email-masked]> 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
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> <XeC>
>>>>> 
>>>>> -- 
>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth