+1 How would clients find out? Discovery, docs?
Phil > On Nov 9, 2013, at 15:11, John Bradley <ve7...@ve7jtb.com> wrote: > > Yes tcse is a way to use the code flow without per instance registration, > and better security than a plain public client. > Not every instance needs to needs registered as long as the redirect_uri is > constant. > > There is however a difference in how grants are treated then you have > multiple instances with the same client_id. > If you want all copies of a app that the user has installed across devices to > have the same grants then use one client_id and tcse. > > If you want the grants to be separate so that one instance has RW and the > other RO scopes for example then you need dynamic client registration or to > re-confirm all scopes each time and not prompt only for new scopes for the > client. So there are legitimate reasons for doing both. > > John B. > > > >> On Nov 9, 2013, at 12:32 PM, Phil Hunt <phil.h...@oracle.com> wrote: >> >> Sounds interesting. >> >> I wonder about why one might choose a public model with tcse vs stateless >> client reg? >> >> Eg. Tcse might be more important for transient clients. >> >> Phil >> >>> On Nov 9, 2013, at 12:27, Torsten Lodderstedt <tors...@lodderstedt.net> >>> wrote: >>> >>> Hi, >>> >>> thanks for the explanation. Seems there is the simpler option sufficient to >>> solve the original problem but it's not secure enough to be a general >>> solution. >>> >>> Regarding implementation: The simpler option requires the developer to >>> create a value of reasonable randomness and the second additionally >>> requires to calculate the SHA correctly. I'm afraid client developers will >>> have trouble implementing it correctly. That's why the idea of OAuth always >>> was to push complexity to the server implementation. >>> >>> While thinking about your proposal, I remembered a potential alternative. >>> We initially discussed usage of dynamically issued client id/secrets (dyn. >>> client registration) in order to mitigate the threat. This has two >>> advantages: >>> - it utilizes general OAuth functionality >>> - usage of client credentials is easy from a client developers perspective >>> >>> This idea was originally rejected due to the potential implications on >>> scalability. The assumption was, potentially billions of client instances >>> could not be managed by the AS in a reasonable way. Based on the outcome of >>> the latest discussions around dynamic registration, we now know how to >>> implement registration in a stateless way using client secrets as >>> self-contained tokens. So this should not be a scalability issue any longer. >>> >>> Should we reconsider this alternative? >>> >>> regards, >>> Torsten. >>> >>>> Am 09.11.2013 um 19:04 schrieb Nat Sakimura <sakim...@gmail.com>: >>>> >>>> And adding to it, it is Google's application team that needs to be >>>> persuaded. As usual, persuading application people to use crypto is hard. >>>> We have to strike a point that is acceptable to them as well as being >>>> somewhat sensible security-wise. Having option to bump up the security is >>>> important as a future migration path as well, hence the current design. >>>> >>>> =nat via iPhone >>>> >>>> Nov 10, 2013 1:42、John Bradley <ve7...@ve7jtb.com> のメッセージ: >>>> >>>>> Simplicity for clients that don't need the extra security. I happen to >>>>> agree with you but it is Google that needs the convincing, as they have >>>>> deployed the non crypto version. >>>>> As with many things getting people to adopt it is the trick. >>>>> >>>>> John B. >>>>> >>>>>> On Nov 9, 2013, at 8:15 AM, Torsten Lodderstedt >>>>>> <tors...@lodderstedt.net> wrote: >>>>>> >>>>>> Hi John, >>>>>> >>>>>> why not make the more secure option the only one? >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> John Bradley <ve7...@ve7jtb.com> schrieb: >>>>>>> >>>>>>> With a native app using a captive browser with no malware, only the >>>>>>> response is susceptible to interception, making encrypting the request >>>>>>> redundant. >>>>>>> In other environments and with some user groups the request's challenge >>>>>>> needs to be protected from interception. This may be more the case in >>>>>>> a desktop environment where there is less control over the browser. >>>>>>> >>>>>>> I expect that we will come to two options one unprotected requests and >>>>>>> one for protected requests. >>>>>>> >>>>>>> To Phil's point this is not about identifying the class of software >>>>>>> this is about matching a response to an instance of software. >>>>>>> A software statement gives you a hint about the class of software but >>>>>>> not the instance without per client registration. >>>>>>> >>>>>>> This method gives you the ability to securely return the token to only >>>>>>> the instance of the client that requested it without the overhead of >>>>>>> per instance dynamic registration. >>>>>>> >>>>>>> This is a practical solution to a real problem people are having today, >>>>>>> and versions of this are in production now. >>>>>>> >>>>>>> Nat and I are trying to document it so that there can be >>>>>>> interoperability rather than every AS doing something different. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>>> On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt >>>>>>>> <tors...@lodderstedt.net> wrote: >>>>>>>> >>>>>>>> Hi Nat, >>>>>>>> >>>>>>>> what's the rationale for having different algorithms to produce a >>>>>>>> code challenges? As this may cause interop issues there should be good >>>>>>>> reasons to introduce variants. >>>>>>>> >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> >>>>>>>> Am 19.10.2013 12:15, schrieb Nat Sakimura: >>>>>>>>> Incorporated the discussion at Berlin meeting and after in the ML. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Nat >>>>>>>>> >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: <internet-dra...@ietf.org> >>>>>>>>> Date: 2013/10/19 >>>>>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt >>>>>>>>> To: Nat Sakimura <sakim...@gmail.com>, John Bradley >>>>>>>>> <jbrad...@pingidentity.com>, Naveen Agarwal <n...@google.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt >>>>>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>>>>> IETF repository. >>>>>>>>> >>>>>>>>> Filename: draft-sakimura-oauth-tcse >>>>>>>>> Revision: 02 >>>>>>>>> Title: OAuth Symmetric Proof of Posession for Code Extension >>>>>>>>> Creation date: 2013-10-19 >>>>>>>>> Group: Individual Submission >>>>>>>>> Number of pages: 8 >>>>>>>>> URL: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt >>>>>>>>> Status: >>>>>>>>> http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>>>>>>> Htmlized: >>>>>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 >>>>>>>>> Diff: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> The OAuth 2.0 public client utilizing authorization code grant is >>>>>>>>> susceptible to the code interception attack. This specification >>>>>>>>> describe a mechanism that acts as a control against this threat. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>>> submission >>>>>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>>>> >>>>>>>>> The IETF Secretariat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nat Sakimura (=nat) >>>>>>>>> Chairman, OpenID Foundation >>>>>>>>> http://nat.sakimura.org/ >>>>>>>>> @_nat_en >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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
