- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 24 Sep 2015 14:50:01 -0400
- To: Dave Longley <dlongley@digitalbazaar.com>
- CC: public-web-security@w3.org, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 09/24/2015 11:57 AM, Dave Longley wrote: > On 09/24/2015 01:07 AM, Harry Halpin wrote: >> On 09/23/2015 11:56 PM, Dave Longley wrote: >>> As this has degenerated into what I consider flaming, I've removed >>> others from the CC list and I don't plan on responding further. >>> >>> On 09/23/2015 09:12 PM, Harry Halpin wrote: >>>> TL;DR >>>> >>>> As its pretty clear we're just rehashing known problems with >>>> violating same origin policy and basic crypto key management >>>> issues, I will now turn my spam filter back on :) >>> I do agree we're getting no where, but for different reasons. >>> Accusing someone of positions they don't hold and then telling them >>> any response will be considered spam isn't a discussion. No wonder >>> the motivations of others are unclear to you. >> >> I apologize if I've misconstrued your position from specs you've >> written, code you've written, or blog posts. > > Thank you, apology accepted. > > Also, as always, we do plan on updating our specs as time permits. > Unfortunately, there's typically a lot going on ... all the time. > > Please keep in mind the "credentials-retrospective" post you referenced > is a draft. Perhaps we should add a section on differentiating > technologies from how they are spec'd at the protocol level (as I'm sure > you know, OAuth 2.0 removed signatures from the spec, with much > controversy and fallout [1][2]) vs. how they are used or could be used > and augmented in practice. The same treatment should be applied to all > specs and feedback is welcome. > > 1. > http://hueniverse.com/2010/09/15/oauth-2-0-without-signatures-is-bad-for-the-web/ > > 2. http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ > Great! Then again - let's work on a redesign *from the ground up* if needs be of the ideas in WebID and Credentials while maintaining SOP and reasonable security/privacy constraints. Although OAuth does effectively do signatures today, it has become more complex. Speaking of Eran, look at his latest blog posts - it might be useful to look at Eran's latest redesign of OAuth called Oz that tries a vast simplification [1]. There's also been very good privacy analysis of OAuth that notes that some form of mediators could lead to better anonymity by Danezis et al. [2]. Note that use of OAuth does *not* violate SOP because it asks for and gets permissions, and the data transfer is done server-to-server. Client-based sending of personal data has real difficulty in a multi-device world due to issues of syncing and devices being offline. However, you can *do* data transfer server-to-server with digital signatures and anonymizing property. But building from these kind of OAuth data-flows is probably the way to go, where key material can be dynamically bound to the session (ala TLS Token Binding) so avoiding "one key per user" designs. This slide-deck is a good overview [3]. Any re-design of these protocols will not come from a Community Group alone. While the work of some CGs have been evocative and interesting, they are not ready for standardization. Instead, a new effort will need a broad-based coalition that involves leading security experts, industry, and IETF/W3C. A solution that respects SOP, simplifies current flows, does not depend (but is ideally compatible with) on legacy non-Web standards, and offers better privacy/security *would* get uptake. While this would require *everyone* leaving their comfort zones, that is something I am interested in working on. cheers, harry [1] http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/ [2] http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/popets15-brokid.pdf [3] http://www.ietf.org/proceedings/91/slides/slides-91-uta-2.pdf
Received on Thursday, 24 September 2015 18:50:06 UTC