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 <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote: 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<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-08-22, at 1:18 PM, Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> 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 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<mailto:phil.h...@oracle.com> On 2013-08-22, at 4:06 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com><mailto: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> >> [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<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
