True however this is more like a client cert and that didn't take off because of distribution and maintenance issues.
On 2013-08-22, at 4:43 PM, Phil Hunt <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 > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
