Specifics? Phil
@independentid www.independentid.com phil.h...@oracle.com On 2013-08-22, at 1:52 PM, John Bradley <ve7...@ve7jtb.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
