Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details -- Correction!

[Justin Richer]

But it also assumes, in many cases, a pre-registration step. I think you 
might be simplifying for the case of one piece of software with the same 
parameters talking to the same server many times. In some sense, it 
doesn't matter to a client developer whether they have to send their 
display name as part of a JSON object or as part of a signed JWT (though 
the former's simpler, the results are the same), they still have to send 
it to the server. You kick the can down the road and set up something 
where there's a pre-registration step where common elements of the 
client's registration are fixed -- but then the server's going to have 
to be able to get those common elements at registration time and (later) 
at authorization time. Unless you're building inside of a single 
security domain, this becomes tricky, with all kinds of trust and policy 
issues. But it's useful and it can be done -- that's what we did with 
the "trusted registration" extension that BB+ uses, with registries and 
discovery using the initial access token. The server effectively parses 
the initial access token and looks up information about the client at 
the registry. We also toyed with the idea of packing the registration 
information into the token itself. Either way, the server has to decide 
that it trusts whoever issued that token, and it has to be able to 
verify the token's veracity. In BB+, we're using discovery to find the 
JWK that was used to sign the token and (optionally) token introspection 
to verify that the initial access token hasn't been decomissioned by the 
registry server. In this case, it's the registry that holds the fixed 
information about the client -- not the auth server -- and so the trust 
model is different.

I think we're better off starting with the fully open case, where 
neither the app nor the server really know anything about each other, 
and build from there. We know that that's a case that people want to 
solve. Note that BB+ builds directly on what's already there -- you 
don't have to burn down the house in order to hang a painting. I think 
that there are so many similarities between the two that the software 
statement work can do the same.

I'd also like to point out something about passing client information 
around: in the "fully stateless assertion" world that's being proposed 
(where there *is* no registration step), the client ends up passing its 
full registration information (as a software statement) with *every* 
call to the authorization endpoint. The fact that the registration is 
encoded in an assertion is immaterial. Having the server be truly 
stateless dramatically increases the amount of information sent over the 
wire at runtime -- that's a pretty universal tradeoff, and that's not a 
cost that everyone wants to pay.

 -- Justin

On 08/22/2013 03:57 PM, Phil Hunt wrote:
Agreed.

The problem for dyn reg is most params are optional and passed at reg 
time. I think this also represents huge complexity to client app 
developers since each sp may be different. Move bulk of info to 
statement simplifies the registration and encourages uniformity.

Phil

On 2013-08-22, at 12:53, Justin Richer <jric...@mitre.org 
<mailto:jric...@mitre.org>> wrote:

Phil, thanks for writing this down. I think that part of the 
confusion in this conversation may come from the nature of items such 
as the client id, client secret, and even the registration access 
token. In many instances, these are simply random values that the 
server generates and stores for later use. However, as you point out, 
OAuth doesn't state that that has to be the case any more than it 
states that a server must store access tokens. The important thing is 
that the auth server be able to recognize and verify each of these 
values. As such, nothing is stopping the server from staying 
stateless and sending signed values to the client for each or all of 
these fields, much in same way that a server can issue signed access 
tokens that carry all their rights and state within. As long as all 
of these values remain opaque to the client, everything in OAuth 
still works. It also works fine within the current DynReg framework, 
as John has just pointed out under a separate thread.

 -- Justin

On 08/22/2013 03:22 PM, Phil Hunt wrote:
I have attached a PDF including some of my thoughts, concerns, and 
suggestions for the upcoming meeting.

Phil

@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com







On 2013-08-22, at 4:06 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" 
<hannes.tschofe...@nsn.com> wrote:

> I messed up the conference bridge time; here is the corrected 
version but the details are actually the same.
>
> Meeting Number: 702 442 101
> Meeting Password: oauth
>
> -------------------------------------------------------
> To join the online meeting
> -------------------------------------------------------
> 1. Go to 
https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&PW=NOTlkZjIwNTEy&RT=MiMyNQ%3D%3D 

> 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=268691357&UID=0&PW=NOTlkZjIwNTEy&ORT=MiMyNQ%3D%3D 

>
> -------------------------------------------------------
> To join the Teleconference
> -------------------------------------------------------
> Global dial-in numbers: http://www.nokiasiemensnetworks.com/nvc
> Conference Code: 944 910 5485
>
> To update this meeting to your calendar program (for example 
Microsoft Outlook), click this link:
> 
https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=KseMD/IKx0YGjSRaNyDJbqnmJ2i-xirziLGyc2bHNI8=&RT=MiMyNQ%3D%3D
>
>> -----Original Message-----
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
Behalf
>> Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>> Sent: Wednesday, August 21, 2013 6:35 PM
>> To: oauth mailing list
>> Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: 
Thu 22
>> Aug, 2pm PDT: Conference Bridge Details
>>
>> Here is the conference bridge and Webex information.
>>
>> From an agenda point of view I guess we should start at a basic 
level,
>> namely with what we have already in the dynamic client registration
>> document (and folks may have actually missed it). There are two use
>> cases described in the WG document, namely
>> - Use Case #1: Open Registration (Appendix B.1)
>> - Use Case #2: Protected Registration (Appendix B.2)
>>
>> Then, we could talk about some more sophisticated use cases where
>> information for protected registration is provided by a third party.
>>
>> --------------------
>>
>> Meeting Number: 702 442 101
>> Meeting Password: oauth
>>
>> -------------------------------------------------------
>> To join the online meeting
>> -------------------------------------------------------
>> 1. Go to
>> 
https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&PW=NOTlkZjIwNTEy&RT=
>> MiMzMA%3D%3D
>> 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=268691357&UID=0&PW=NOTlkZjIwNTEy&ORT
>> =MiMzMA%3D%3D
>>
>> -------------------------------------------------------
>> To join the teleconference only
>> -------------------------------------------------------
>> Global Dial-In Numbers: http://www.nokiasiemensnetworks.com/nvc
>> Conference Code: 944 910 5485
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth