No certainly you can still manage grants per app class if you are doing per instance registration. It is however more of a UI challenge if you don't do per instance registration and you want to manage grants per instance.
I mostly wanted to point out that there are two models that AS use Twitter as an example give all instances of an application the same grans and I think even the same access token. (OAuth 1 don't blame me:) Facebook also treats instances as having consented to the same grants. That has been used for privilege escalation attacks if you can impersonate a client. Others try and treat different instances of a app as having separate grants. There are likely reasons to do both, that is for the AS to decide. Discovery and out of band API documentation around how scopes and grants are treated would likely be how a developer would find out what the thing to do is. If the AS supports tcse the client could discover it dynamically and use it as there is no real downside, though if it is already a confidential client client it would not add much. The stateless client registration is another way to get similar protection without adding tcse as an extension, however that is still more work for the server to implement than tcse. Dynamic client registration + stateless is probably the broader solution that also covers use-cases if I had to pick just one. John B. On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt <[email protected]> wrote: > 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
