On 22 Oct 2012, at 17:14, Harry Halpin <[email protected]> wrote: > On 10/22/2012 04:04 PM, Henry Story wrote: >> On 22 Oct 2012, at 14:32, Harry Halpin <[email protected]> wrote: >> >>> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>>> On 22 October 2012 11:59, Kingsley Idehen <[email protected]> wrote: >>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>>> Where we came in was me pointing out that if you disconnect your >>>>>>> identities by using multiple WebIDs, then you have a UI problem, and >>>>>>> since then the aim seems to have been to persuade us that multiple >>>>>>> WebIDs are not needed. >>>>>> Multiple WebIDs (or any other cryptographically verifiable identifier) >>>>>> are a >>>>>> must. >>>>>> >>>>>> The issue of UI is inherently subjective. It can't be used to objectively >>>>>> validate or invalidate Web-scale verifiable identifier systems such as >>>>>> WebID or any other mechanism aimed at achieving the same goals. >>>>> Ultimately what matters is: do users use it correctly? This can be tested >>>>> :-) >>>>> >>>>> Note that it is necessary to test the cases where the website is evil, >>>>> too - something that's often conveniently missed out of user testing. >>>>> For example, its pretty obvious that OpenID fails horribly in this >>>>> case, so it tends not to get tested. >>>> Okay. >>>>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) are >>>>>> going >>>>>> to knock up some demonstrations to show how this perceived UI/UX >>>>>> inconvenience can be addressed. >>>>> Cool. >>>> Okay, ball is in our court to now present a few implementations that >>>> address the UI/UX concerns. >>>> >>>> Quite relieved to have finally reached this point :-) >>> No, its not a UI/UX concern, although the UI experience of both identity on >>> the Web and with WebID in particular is quite terrible, I agree. >> It completely depends on the browsers: >> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection >> If you are on Linux just file a bug request to your browser if you are >> unhappy, or even better hack up a good UI. It's easy: just make it simpler. >> >>> My earlier concern was an information flow concern that causes the issue >>> with linkability, which WebID shares to a large extent with other >>> server-side information-flow. >> Including BrowserId. Which has 2 tokens that can be used to identify the >> user across sites: >> >> - an e-mail address ( useful for spamming ) >> - a public key, which can be used to authenticate across sites >> >> >>> As stated earlier, as long as you trust the browser, BrowserID does >>> ameliorate this. >> No it does not improve linkability at all. Certainly not if you think the >> site you are authenticating to is the one you should be worried about, >> because just using a public key >> by itself is enough for Linkability in the strict (paranoid) sense. That is >> if you >> consider the site you are logging into to as the attacker, then by giving >> two sites >> a public key where you have proven you control the private key is enough for >> them to know that >> the same agent visited both sites. That is because the cert:key relation is >> inverse functional. >> >> So in simple logical terms if you go to site1.org and identify with a public >> key pk, >> and they create a local identifier for you <http://site1.org/u123>, and then >> you go site s2.net and identify with the same public key pk and they give >> you an identifier <http://s2.net/lsdfs> >> (these need not be public) and then they exchange their information, then >> each of the sites would have the following relations ( written in >> http://www.w3.org/TR/Turtle ) >> >> @prefix cert: <http://www.w3.org/ns/auth/cert#> >> >> <http://site1.org/u123> cert:key pk . >> <http://s2.net/lsdfs> cert:key pk . >> >> because cert:key is defined as an InverseFunctionalProperty >> ( as you can see by going http://www.w3.org/ns/auth/cert#key ) >> >> Then it follows from simple owl reasoning that >> >> <http://site1.org/u123> == <http://s2.net/lsdfs> . >> >> One cannot get much simpler logical reasoning that this, Harry. >> >> >>> There is also this rather odd conflation of "linkability" of URIs with >>> hypertext and URI-enabled Semantic Web data" and linkability as a privacy >>> concern. >> I am not conflating these. > To quote the IETF document I seem to have unsuccessfully suggested you read a > while back, the linkability of two or more Items Of Interest (e.g., subjects, > messages, actions, ...) from an attacker's perspective means that within a > particular set of information, the attacker can distinguish whether these > IOIs are related or not (with a high enough degree of probability to be > useful) [1]. If you "like linkability", that's great, but probably many > use-cases aren't built around liking linkability.
The use of e-mail addresses as the primary identifier of BrowserId is defended for exactly the reason that web sites want to be able to communicate back with the user. It is a core part of the BrowserId marketing spiel. So linkability is core to BrowserID in that respect, and it is a core use case. But the problem here is that one cannot speak of linkability full stop. One has to bring some further elements into consideration. The definition from the draft-hansen-privacy-terminology-03 that you quote suggests that linkability is relative to an agent, call him 'A'. It is imagined that A has attackers, and so at least it is logically possible that A have friends too. Communicating with friends is about building links, indeed this is what building communities is about. So building a social web is about building links in a distributed decentralised manner. We want to both increase linkages between people and increase their autonomy. From this it follows that A when communicating has to consider two groups of people 1- friends: those people with whom A wishes to increase linkages with 2- enemies: those with whom A wishes to avoid linkages leaking to - the attacker as per draft-hansen-privacy-terminology-03 This is a bit rough of a distinction but I think it makes clear that you cannot just talk about linkability being good or bad without taking into considerations what the communication is about - with whom someone is communicating - and what the social network of the person is about - who his friends and enemies are. > This has very little with hypertext linking of web-pages via URIs. Well that is why above my argument was based in terms of public keys not URIs. But I could also have made it in terms of e-mail address for BrowserID. Here let me do it for you. Imagine you go to two web sites with BrowserID: site1.org and s2.net . Each captures your e-mail address. They then exchange information ( and they trust each other too - that is an important point btw. ) Each site then has the following graph in store @prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://site1.org/u123> foaf:mbox <mailto:[email protected]> . <http://s2.net/lsdfs> foaf:mbox <mailto:[email protected]>. From which they can deduce because since foaf:mbox is an owl:InverseFunctionalProperty ( just look up http://xmlns.com/foaf/0.1/mbox ) that <http://site1.org/u123> owl:sameAs <http://s2.net/lsdfs> . There you go: linkability via e-mail addresses. > I think you want to use the term "trust across different sites" rather than > linkability, although I see how WebID wants to conflate that with trust, > which no other identity solution does. A link does not necessarily mean > trust, especially if links aren't bi-directional. There are many different types of links, some indicate trust, some don't. One can also have the equivalent of bidirectional links. A has a document where he points to B as a friend, and B returns the favour by placing a link from his document to A. > > As explained earlier, Mozilla Personae/BrowserID uses digital signatures > where an IDP signs claims but transfers that claim to the RP via the browser > (thus the notion of "different information flow") and thus the RP and IDP do > not directly communicate, reducing the linkability of the data easily > gathered by the IDP (not the RP). As I prooved above, BrowserID by using Public Keys and by using e-mail identifiers furthermore, is giving a linkable identity to sites people use to log into. So you don't get away from the paranoid view of linkability being a problem, without getting any major interesting gain. > I know WebID folks believe IDP = my homepage, but for most people IDP would > likely not be a homepage, but a major identity provider for which data > minimization principles should apply, including ownership of the social > network data of an individual and a history of their interactions with every > RP. The point of this e-mail was to show that the type of linkability WebID provides is here in order to make it possible for people to choose not to inhabit such a future. > I am not defending BrowerID per se: Personae assumes you trust the browser, > which some people don't. Also, email verification, while common, is not great > from a security perspective, i.e. STARTLS not giving error messages when it > degrades. BrowserId will be an interesting tool in the future, when cryptography in the browser is available. Until then it has a strong centralisation focus. WebID delivers what BrowserId promises to do, but now. Anyway, you need to be more careful about talk of linkability, since to talk of linkability as good or bad without taking the context of who is talking to whome, who is in the role of the enemy etc, makes no sense. > > Perhaps a more productive question would be why would someone use WebID > rather than OpenID Connect with digital signatures? that can be a discussion for another day perhaps. > > Although, I have ran out of time for this for the time being. > >> >> My point from the beginning is that Linkability is both a good thing and a >> bad thing. >> >> As a defender of BrowserId you cannot consistently attack WebID for >> linkability concerns and find BrowserId not to have that same problem. So I >> hate to reveal this truth to you: but we have to fight this battle together. >> >> And the battle is simple: the linkability issue is only an issue if you >> think the site you >> are authenticating to is the enemy. If you believe that you are in relation >> with a site that >> is under a legal and moral duty to be respectful of the communication you >> are having with it, >> then you will find that the linkability of information with that site and >> across sites is exactly what you want in order to reduce privacy issues that >> arise out of centralised systems. >> >>> I do think many people agree stronger cryptographic credentials for >>> authentication are a good thing, and BrowserID is based on this and OpenID >>> Connect has (albeit not often used) options in this space. I would again, >>> please suggest that the WebID community take on board comments in a polite >>> manner and not cc mailing lists. >> All my communications have been polite, and I don't know why you select out >> the WebID community. >> As for taking on board comments, why, just the previous e-mail you responded >> to was a demonstration that we are: CN=WebID,O=∅ >> >> >> >>>> >>>> >> Social Web Architect >> http://bblfish.net/ >> > Social Web Architect http://bblfish.net/
smime.p7s
Description: S/MIME cryptographic signature
