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 phil.h...@oracle.com On 2013-08-22, at 1:18 PM, Justin Richer <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> 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 >>>> 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
