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

[Torsten Lodderstedt <[e-mail]>]

Authz server and resource server need to agree on a token format. The client never needs to interpret the token content. Since we are talking about clients, where is the connection? 

regards,
Torsten.



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