On 2011-04-02, at 11:13 AM, Francisco Corella wrote:
>
> > Another example I mentioned earlier is when the client does
> > not expose the protected resources back to the bearer of the
> > code. For example, a Twitter application sending you emails
> > when someone stops following you. Since all i
I also am confused by change like this when we are at WGLC.
I was under the impression that once the WG finished last call, the IETF
security mafia experts would be reviewing the spec -- so it is unclear what
advantage this has for getting the spec finished.
On 2011-04-02, at 12:58 PM, David Re
I can't say I understand this change when we're so close to being finished.
On Fri, Apr 1, 2011 at 12:25 AM, Peter Saint-Andre wrote:
> As discussed in the WG session at Prague just now, in discussion with
> the Security Area Directors I have decided to move the OAuth Working
> Group from the App
On Apr 2, 2011, at 3:19 PM, Phillip Hunt wrote:
> If we take the current implementers as evidence it shows we have little or no
> security either due to misunderstandings or business decisions to accept risk
> for flexibility.
>
This type of language is also not helpful for moving us forward.
I don’t think a SHOULD leads to more than 2-3 lines clearly warning against a
MITM attack on the authorization code or the returned script (implicit grant).
The attack is simple and the warning is equally simple.
Different components of the protocol have different security issues and
complexity
For the record, I can except SHOULD. But my very strong feeling is this leads
to much more lengthy and complicated language.
I believe we have already crossed the line where it is no longer easy for
deployers to figure out if deployments are secure. It is now a spec challenging
to even subject
> -Original Message-
> From: Francisco Corella [mailto:fcore...@pomcor.com]
> Sent: Saturday, April 02, 2011 11:14 AM
> To: Dick Hardt; Skylar Woodward; Phillip Hunt; Eran Hammer-Lahav
> Cc: OAuth WG; Karen P. Lewison
> Subject: RE: to TLS or not on redirect on consumer websites :: securi
I don't think your statement that 'the IETF should endorse lack of security' is
accurate or helpful.
I completely rejects the notion that a SHOULD with strong language explaining
the risk is any less "secure" than a MUST.
The only impact of using a MUST vs. a SHOULD is that companies deploying
If this is changed to a MUST, Facebook will be in violation of the
specification moving forward. It is untenable to require all of our
*client* developers to implement TLS endpoints though we certainly
support developers who wish to do so. This is very different than
offerring our entire API (and n
> Another example I mentioned earlier is when the client does
> not expose the protected resources back to the bearer of the
> code. For example, a Twitter application sending you emails
> when someone stops following you. Since all it does is get
> the code and then uses it internally (no user log
Eran,
> Google, Facebook, and Yahoo! already indicated they will not enforce
> such a MUST. I could not get a clear answer from Twitter.
>
> However, no one representing this companies has bothered to express
> this view on the list, and to express how they would like the
> specification to handl
Another example I mentioned earlier is when the client does not expose the
protected resources back to the bearer of the code. For example, a Twitter
application sending you emails when someone stops following you. Since all it
does is get the code and then uses it internally (no user login func
Google, Facebook, and Yahoo! already indicated they will not enforce such a
MUST. I could not get a clear answer from Twitter.
However, no one representing this companies has bothered to express this view
on the list, and to express how they would like the specification to handle
this case. Thi
As has been pointed out in the discussions, if a website does not employe TLS
on connections on other connections, having TLS on the redirect does not add
security.
Depending on the resource grant being given, the nature of the website, not
running TLS may be an acceptable security tradeoff. N
Skylar,
> I'm going to summarize (hopefully faithfully) the attacks
> referenced here, with the hope of attempting to sum up the
> scope of attacks being documented.
Thank you for reading and summarizing the attacks.
> On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote:
>
> > Skylar,
> >
> > >
15 matches
Mail list logo
