Dynamic client registration + stateless is probably the broader
solution that also covers use-cases if I had to pick just one.
That's my point. I have to decide what to implement in my service since
we need a solution for our (partner) apps. And right now I'm tending
more towards dynamic client registration + stateless. In my opinion,
it's not only broader but easier to use from a client developer's
perspective (that's what I care more about than server-side complexity).
regards,
Torsten.
John B.
On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt
<[email protected] <mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>> wrote:
Hi John,
why not make the more secure option the only one?
regards,
Torsten.
John Bradley <[email protected] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>>
Date: 2013/10/19
Subject: New Version Notification for
draft-sakimura-oauth-tcse-02.txt
To: Nat Sakimura <[email protected]
<mailto:[email protected]>>, John Bradley
<[email protected]
<mailto:[email protected]>>, Naveen Agarwal
<[email protected] <mailto:[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 <http://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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
