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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Aug 2013 16:34:44 +0000

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 22 Aug 2013 11:06:07 +0000

I messed up the conference bridge time; here is the corrected version but the details are actually the same. 

1. Go to https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&PW=NOTlkZjIwNTEy&RT=MiMyNQ%3D%3D 

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: [email-masked] [mailto:[email-masked]] 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
> 
> 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
> Then, we could talk about some more sophisticated use cases where
> information for protected registration is provided by a third party.
> 
> --------------------
> 
> 1. Go to
> https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&PW=NOTlkZjIwNTEy&RT=
> MiMzMA%3D%3D
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Aug 2013 12:22:32 -0700

I have attached a PDF including some of my thoughts, concerns, and suggestions for the upcoming meeting.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 22 Aug 2013 19:39:27 +0000

Phil, this just brings me back to the question, "why are we doing this in OAuth" ? Configuration endpoint (nothing to do with OAuth), Registration Endpoint (too complicated, goes beyond the bounds of OAuth), why not just a stateless and state full registration message and that's it?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, August 22, 2013 12:23 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details -- Correction!

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 22 Aug 2013 15:47:21 -0400

Tony, I look forward to seeing the concrete specification and 
implementation of your idea.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 22 Aug 2013 15:53:46 -0400

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:
> www.independentid.com <http://www.independentid.com>
> [email-masked]
>
>
>
>
>
>
>
> > I messed up the conference bridge time; here is the corrected 
> version but the details are actually the same.
> >
> https://nsn.webex.com/nsn/j.php?ED=268691357&UID=0&PW=NOTlkZjIwNTEy&RT=MiMyNQ%3D%3D 
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Aug 2013 12:54:59 -0700

I don't think open vs close has a big impact on design. The issue of state full vs stateless are foundational. 

So we need to talk about when and why state full registration is needed. 

Phil

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Aug 2013 12:57:40 -0700

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 <[email-masked]> 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
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 22 Aug 2013 16:18:51 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Aug 2013 13:43:55 -0700

TLS doesn't define how servers obtain certificates. It just assumes they are installed.  The same thing is happening here.

I'm not sure why this is objectionable. It is simply a broader model of your proprietary (meaning specific) solution for BB+.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-22, at 1:18 PM, Justin Richer <[email-masked]> wrote:

> 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
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 22 Aug 2013 20:49:26 +0000

Phil, I'm not objecting to it! I never have been! I've been saying all along it's a proper extension to the base dynamic registration spec because it defines optional functionality in addition to said base spec. Why do you object to it being an extension?

 -- Justin

On Aug 22, 2013, at 4:43 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2013-08-22, at 1:18 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

On 2013-08-22, at 12:53, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2013-08-22, at 4:06 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]><mailto:[email-masked]> wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 22 Aug 2013 16:52:42 -0400

True however this is more like a client cert and that didn't take off because of distribution and maintenance issues.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Aug 2013 13:55:21 -0700

Specifics?

Phil

@independentid
www.independentid.com
[email-masked]