hurrah!
(not necessarily for losing a way to sign the body, but for simplicity and
avoiding some of the potential inconsistencies w/ bodyhash).
Is your plan to reserve an empty line 6 for the Normalized Request String
(which was used for bodyhash) or eliminate it, brining the total to six
haven't described a problem.
On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org
wrote:
First we should agree on a common understanding of the spec. The
reason why age works with unsynchronized clocks is that the client
determines issue_date based on the time when it receives
On Jun 1, 2011, at 7:58 AM, Eran Hammer-Lahav wrote:
I don't think you have made the case why you age is any harder to implement
than a timestamp. It is not that your email isn't clear, it's that we're not
convinced that timestamp will produce any better result than age in practice.
This
Provider: api.megaworld.com
Software Program: A universal binary iOS app called MegaWorld for iOS
Client ID: mega_app
User: Frankie in London
Username: frankie_uk
Device A: Frankie's iPhone
Device B: Frankie's iPad
Now imagine MegaWorld for iOS installed on device A B. Client ID is the
-Original Message-
From: Skylar Woodward [mailto:sky...@kiva.org]
Sent: Wednesday, June 01, 2011 12:16 AM
To: Eran Hammer-Lahav
Cc: Adam Barth; OAuth WG
Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Provider: api.megaworld.com
Software Program
On Jun 1, 2011, at 10:18 AM, Brian Eaton wrote:
And it would meet the requirement of having a clear path forward for
people who don't want to trust native apps to keep secrets really
secret.
I just want to re-iterate my point from a few months ago that it necessarily
helpful to draw the line
On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote:
(Some web apps might not be able to keep secrets based on open development
or deployment model).
Can you clarify what you mean by this?
Simple really, I just mean for some developers it might be more important to
have an open development
The group is operating under the assumption that most native apps are publicly
deployed or that copies of the app bundle/binary can at least be obtained by a
malicious party. Whether and open system or a high protected system like
Playstation 3 its always possible for the attacker to
On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote:
for mounting the attack. I firmly believe that secrets can be
sufficiently obfuscated in code delivered in binary format without the
benefit of a symbol table, so as to be sufficiently resistant to
discovery via disassembly by attackers you'd
clock provided by all modern operating systems.
Adam
On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward sky...@kiva.org wrote:
But see, now you are specializing the use of MAC token even more - now it's
becoming a service mainly for user-agents on home desktops? This is further
, Skylar Woodward sky...@kiva.org wrote:
I don't think you read my first message on the topic (or I wrote too much).
Age is fragile because if the clock changes between issue_date and the time
of submission, it will fail. We know many people don't have synchronized
clocks, but using age only
, 2011 at 1:04 AM, Skylar Woodward sky...@kiva.org wrote:
It seems we're failing to communicate. Or you're not understanding my use
cases. Age doesn't just work. It only works for a limited number of uses
cases that must include all of yours - and it is brittle at that. It doesn't
work for any
phil.h...@oracle.com
On 2011-05-31, at 2:41 PM, Adam Barth wrote:
You haven't described a problem.
On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org
wrote:
First we should agree on a common understanding of the spec. The
reason why age works
to continue
the discussion. Let's try to move forward with your answer to the second
question.
On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org wrote:
First we should agree on a common understanding of the spec. The reason why
age works with unsynchronized clocks
... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- .-..
.- .-. — .-- --- --- -.. .-- .- .-. -..
skylar woodward
Kiva Developer Program / build.kiva.org / @buildkiva
On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote:
Any kind of clock sync requirement for user-agents (basically, home desktops)
it completely impractical
You may have noticed, on page 8 the host is listed as example.net - should be
example.com, I believe. (draft v5)
All in all, I'm in support of the changes in v2. Certainly addresses my
hesitations from v2.
skylar
On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote:
(Please discuss this
Just for the record, I spoke with Marius just now and they'll be using Eran's
suggested URN for this (as well as 'oob' as a non-complient alias):
urn:ietf:wg:oauth:2.0:oob
Still remains to be codified in some way as an official suggestion. Would this
belong in the core spec?
skylar
Resending to the list from my subscribed account...
Begin forwarded message:
From: Skylar Woodward sky...@larw.com
Date: May 23, 2011 6:14:00 PM PDT
To: Skylar Woodward sky...@kiva.org
Cc: Eran Hammer-Lahav e...@hueniverse.com, OAuth WG oauth@ietf.org
Subject: Re: [OAUTH-WG] issues
inline.
On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote:
Hi Skylar,
Am 06.04.2011 18:02, schrieb Skylar Woodward:
Well, I should elaborate. The method of authorization is open to the client,
and in this case (Kiva), MAC tokens are being used. The client authenticates
(as it were) for their
spoof-able nature - native clients are an important part of the ecosystem.
skylar
On Apr 4, 2011, at 5:08 PM, Marius Scurtescu wrote:
On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward sky...@kiva.org wrote:
In our implementation (not yet public) we accept the empty string
suggests a changing random string
instead.
Phil
phil.h...@oracle.com
On 2011-04-08, at 12:10 AM, Skylar Woodward wrote:
Yes, I can see how this might seem confusing. Actually, we're
authenticating the client with authorization server - not a resource
request. On the MAC threads
Torsten, that's what the spec recommends already. That's my assumption for
everything I've discussed thus far - that clients who can't keep secrets are
never issued them and thus must omit them out of lack of having any.
We're just splitting hairs on the definition of omit. Also, there's
I agree with Marius' points. We plan to support the auth-code flow for native
apps as well. There is no reason why native apps can't perform a successful
auth-code flow, they just do so without client credentials. However, the spec
doesn't make it clear that this is viable option.
skylar
, Phillip Hunt wrote:
It doesn't require client side ssl.
Phil
Sent from my phone.
On 2011-04-04, at 11:47, Skylar Woodward sky...@kiva.org wrote:
How does the client app transmit the nonce (random number) to the web
browser for redirect to the provider? If the client app does
. That browser is capable of running SSL with server authentication
only.
Phil
phil.h...@oracle.com
On 2011-04-04, at 12:08 PM, Skylar Woodward wrote:
Maybe you can explain your example in more detail then? I'm assuming your
client app is a web application hosted on web server supporting
In our implementation (not yet public) we accept the empty string () as the
value for clients not issued secrets. While this was done to simplify the
interface and implementation, it would make it compliant in my view. In this
case, the authorization server is validating the credentials, which
phil.h...@oracle.com
On 2011-04-04, at 12:52 PM, Skylar Woodward wrote:
I'm confused - it seems like you're mixing web clients and native clients in
this most recent explanation. It's perfectly reasonable that the
authorization code will always be returned by a provider in a secure
confusion, I'm going to
need someone else to defend your argument. I'm either completely
misunderstanding the case you're presenting, or you are.
See inline...
On Apr 4, 2011, at 11:30 PM, Phillip Hunt wrote:
On 2011-04-04, at 18:39, Skylar Woodward sky...@kiva.org wrote:
On Apr 4, 2011, at 4:06
Am I the only one still supporting SHOULD on this case? If someone else
supports this language, please speak up. Otherwise, it seems the group SHOULD
move forward with MUST.
As a provider, we (Kiva) must deal with the possibility of an ecosystem of
developer apps which can't feasibly serve
A requirement for TLS on the callback would make OAuth prohibitive for many of
our developers. The developers are usually volunteers and they are already
donating their own resources to help a non-profit (from which US law mandates
the developers cannot profit). In other cases the developers
-Original Message-
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Thursday, March 31, 2011 10:30 AM
To: Eran Hammer-Lahav
Cc: Skylar Woodward; Dick Hardt; OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
+1
I agree this is not just about setting one TLS setting
Francisco, correct me if I'm wrong, but in your discussion you assume that the
application is incapable of keeping secrets from the public (eg, mobile,
desktop apps, etc.). According to the spec, those applications should never
receive client credentials to begin with. They can't keep secrets
-03-07 at 14:37 -0500, Skylar Woodward wrote:
Justin has well stated my view on this. Folks here have explained how the
flows can work for (or doesn't prohibit) a native app, but it also seems
clear that new readers don't pick up how native apps fit into the flow in a
1st or 2nd pass.
So
you suggested is a good start.
Marius
From: Marius Scurtescu [mailto:mscurtescu at google.com]
Sent: Friday, January 28, 2011 10:07 AM
To: Eran Hammer-Lahav
Cc: Skylar Woodward; OAuth WG
Subject: Re: [OAUTH-WG] Native Client Extension
On Fri, Jan 28, 2011 at 8:21 AM, Eran Hammer-Lahav
I had assumed a use case for this was an entirely browser-based client. Such a
client would be limited to same-host requests. Providing a proxy to make token
requests just opens the possibility of abuse of client proxies with poor
security practices - and for no added value. If a client can't
I think it's meant to be there. If you look at Signature Base String
construction, item 9 is a normal line item just like all others and should
have a newline at the end. So you can think of it as the params as one sting w/
newline between followed by a newline. In the example, it looks like
#2
On Feb 9, 2011, at 12:04 AM, Mike Jones wrote:
Given that people are clearly voting to change the bearer token scheme name,
but that there is also significant discussion asking for “OAuth2” to be part
of the name, I’d like to settle the matter by vote on the list. Please vote
for one
On Feb 8, 2011, at 6:45 AM, Eran Hammer-Lahav wrote:
This authentication method comes with well understood security properties. By
making query parameters optional because of developer ease, providers will be
giving up an important part of the protection this protocol offers. This is
I struggled w/ this conflict as well during implementation since we also tie
the redirection URI to client identity. However, URI preregistration is not
required by the spec (3.1.1, paragraph 3, so, if a provider's redirect_uri
validation is not dependent on client_id (be it a subset of URIs,
A couple of editorial notes:
3.2 has a mismatch of parameters between the example and the text (eg, using
access token j92fsdjf094gjfdi,... where h480djs93hd8 from 1.1 is used in the
example). The timestamp and nonce are also mismatched, though bodyhash seems
correct. As a result, the
comments below...
On Feb 4, 2011, at 6:22 AM, Manger, James H wrote:
Comments on draft-hammer-oauth-v2-mac-token-02
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
This draft is a good improvement.
(continuing numbering from my previous comments)
11. The access token
On body-hash...
Having completed a trial implementation, it seems redundant, and potentially
problematic, to include the body-hash in the Authentication header. The danger
is that implementors may neglect to recalculate the hash themselves, reusing
the value (even if incorrect) provided by the
While I'm mostly indifferent between #1 and #3, I cast my vote for #1 for the
sake of garnering consensus.
Also, it seems important to some that the current specs be usable outside of
OAuth. While I'm not convinced there are sufficient other use cases being
examined to deliver the extra-OAuth
I was also thinking providers could specify a redirect_url on their own domain,
such as
http://www.kiva.org/oauth/callback/oob
But an urn or custom scheme (either is fine) that everyone can agree upon would
my preference, primarily to reduce developer confusion, but similarly for the
be an extension defined that
makes this exceptional case clearly defined to co-exist with the core language
of MUST, REQUIRED, and absolute.
On Jan 28, 2011, at 1:44 AM, Marius Scurtescu wrote:
On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward sky...@kiva.org wrote:
Marius,
I support the extension
On Jan 26, 2011, at 9:09 PM, Marius Scurtescu wrote:
- 4.1. Authorization Code. It is stated that authorization code is
suitable for clients that can hold a secret. Not necessarily true, it
is the best flow for native apps, for example.
We concur with this as well. Our current implementation
Marius,
I support the extension (as per my previous letter, as I missed this thread
over the holidays) and Kiva is/was planning to support this as well. Given the
unpredictable technology environments of many of our customers, this flow is
essential for our implementation.
However, now
This is excellent. Thanks for pulling together a signature-based token spec.
Some feedback:
- As I think was mentioned in a previous post, this spec is also attractive as
method for asserting client credentials (eg, for access token requests). Your
point is noted on substituting client_id as
+1
More feedback on the token specs (and v12) is in my queue for tonight, but this
has also been a concern of mine and this seems to be a more elegant protection
against conflicts than adding a version parameter.
On Jan 26, 2011, at 6:14 PM, William Mills wrote:
Broken record: using a prefix
On Oct 27, 2010, at 8:09 PM, Freeman, Tim wrote:
The questions currently interesting to me about use cases are:
* The only use cases that made sense to me about signatures used them for
auditability, where they enabled blame to be properly placed after
information leaked to the wrong
Apologies in advance for adding a new thread, but I've only just switched from
digest mode. I'm jumping into the middle of the discussion as our organization
(kiva.org) is in the process of becoming an OAuth provider and we're planning
to start with a OAuth 2.0-based API (or nearly so) out of
51 matches
Mail list logo
