One can relate all instances of the same app using an initial access token. So doing per client instance registration does not preclude to manage grants per app.
John Bradley <[email protected]> schrieb: >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 <[email protected]> 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 ><[email protected]> 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 <[email protected]>: >>> >>>> 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 <[email protected]> のメッセージ: >>>> >>>>> 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 ><[email protected]> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> why not make the more secure option the only one? >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> John Bradley <[email protected]> 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 ><[email protected]> 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: <[email protected]> >>>>>>>> Date: 2013/10/19 >>>>>>>> Subject: New Version Notification for >draft-sakimura-oauth-tcse-02.txt >>>>>>>> To: Nat Sakimura <[email protected]>, John Bradley ><[email protected]>, Naveen Agarwal <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
