A few comments on parts of the OAuth 2.0 Threat Model and Security
Considerations:
* [2.1. Scope] "Resource server URLs are static and well-known at
development time" is a very strong assumption. It eliminates much of the value
of having an OAuth standard (reducing it to aiding some s
Justin,
> The important thing is the logical distinction between
> "place where the client goes" and "place where the client sends an end
> user", and that those don't get folded into each other.
I certainly don't want to fold those two together.
The issue is whether the spec should fold together
Thanks for the clarification. Yes, the compromise makes sense.
Phil
phil.h...@oracle.com
On 2011-03-28, at 3:28 PM, Eran Hammer-Lahav wrote:
> The code is returned in two steps:
>
> 1. The authorization server replies to the user-agent request (providing
> authorization) with a redirection
The code is returned in two steps:
1. The authorization server replies to the user-agent request (providing
authorization) with a redirection instruction typically using the Location
response header field.
2. The user-agent makes an HTTP GET request to the provided location (which may
be someth
I just spotted that further down.
I am OK with no pad character as long as that isn't going to mess up string
parsing in some situations.
The empty string is arguably more compact.
John B.
On 2011-03-28, at 6:02 PM, Mike Jones wrote:
> Correct – good catch. I’ll update the draft. The inten
Correct - good catch. I'll update the draft. The intent was for there to be
no pad character in that case.
--
Mike
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, March 28, 2011 3:00 PM
To: Mike Jones
Cc: o
Mike in JWT 6.7 if the alg is none.
Otherwise, if the "alg" value
is ""none"", the JWT Claim Segment is the empty string.
I may be missing something. If the Alg is none then the Claim segment is still
the claim segment. It is the Crypto segment that would just be padding to
maintain th
This was referring to section 2.1 that the authorization server must use TLS
when returning an authorization code.
If it doesn't use TLS then the code being returned to the client can be
intercepted.
Or did I miss something?
Phil
phil.h...@oracle.com
On 2011-03-28, at 1:37 PM, Justin Riche
I'm fine with any of the options Eran proposed.
The document has become much more Eran's than anyone else's which leads me to
lean towards just listing Eran as the editor.
-- Dick
On 2011-03-27, at 1:43 AM, Peter Saint-Andre wrote:
>
>
> On 3/27/11 12:36 AM, Eran Hammer-Lahav wrote:
>> The s
Phil,
The main difference is that it's a requirement on the *client* instead
of the *provider* side of the equation, and clients aren't always even
speaking HTTP. I agree that all client web servers SHOULD do it. A
particular provider can even REQUIRE it for their registered clients, a
step that i
Justin, How is that so? Remember firesheep? I wouldn't want the authorization
code being exchanged without TLS in a cafe. Intercept is just too easy. And as
I mentioned earlier, client credentials are already very weak in many cases. In
contrast, two web servers are hard to sniff unless you are
No change then. But the security considerations section must reflect this.
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, March 28, 2011 10:05 AM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; OAuth WG
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth
+1 for SHOULD
... with a reference to the Security Considerations section that
addresses the issues. The one we're facing right now with this, is that
for easy development it's nice to allow the redirect_uri to be
http://localhost :) For production deployments, I agree that TLS is the
best op
It is apparently essential for the security of the protocol that the client
state is not guessable by an attacker, as described at:
http://www.ietf.org/mail-archive/web/oauth/current/msg05733.html
(That link might fail if the mail archive is reindexed. It's a 23 Mar 2011
email with subject
Eran, you are right about the plan. We have already had a couple of
iterations of distilling the separate document down into a security
considerations section for inclusion in the spec and will complete if based
on feedback Torsten received this week at IETF-80. I am unable to attend
Mark
oauth
What about non-http return uri's, or client-localhost, such as
someapp://app/?code=foo
http://localhost:87345/?code=foo
HTTPS makes sense when you're talking between two web servers, but it
seems to fall apart otherwise. I think SHOULD is appropriate here.
-- Justin
On Fri, 2011-03-25 a
I like the organization of the spec with its grant types structure. In
my reading of it, the two endpoints are logical and may be presented
from different URLs and crunched on by several processing engines in the
background. The important thing is the logical distinction between
"place where the cl
This is now published as an IETF draft. The IETF .txt version link is:
http://www.ietf.org/id/draft-jones-oauth-jwt-bearer-00.txt
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jone
These are now published as IETF drafts. The IETF .txt version links are:
http://www.ietf.org/id/draft-jones-json-web-token-03.txt
http://www.ietf.org/id/draft-jones-json-web-signature-01.txt
-- Mike
From: o
Hi Igor,
the writeup that Barry provided is not meant to be part of the OAuth core
draft. Instead, it explores the bigger OAuth security story.
We certainly do not have an endless amount of time at the face-to-face meeting.
So, Barry's presentation will be put at the end of the agenda and, if
It appears to me that the first part of the draft is an OAuth tutorial,
while the last part is written in "shoulds." While a discussion of the
user interface issues is interesting, I strongly believe that it is out
of scope of OAuth. Other than that, I don't see anything that stands
out as
I have also just submitted this draft:
http://tools.ietf.org/html/draft-leiba-oauth-additionalsecurityconsiderations
Hannes has asked me to talk about it for a few minutes in the OAuth
meeting on Friday, and I plan to.
Barry
___
OAuth mailing list
OAuth
22 matches
Mail list logo
