On Tue, Jun 8, 2010 at 11:07 PM, John Kemp <[email protected]> wrote: > On Jun 8, 2010, at 4:30 PM, Story Henry wrote: >> On 8 Jun 2010, at 22:18, Eddy Nigg (StartCom Ltd.) wrote: >>> On 06/08/2010 08:47 PM, From Story Henry: >>>> You DON't need to export the certificate! You just create a new one: it's >>>> a one click procedure! >>> Doesn't that defeat the purpose and protection of using digital >>> certificates in first place? >> >> No. >> >> That's the trick of foaf+ssl: we do not rely on Certificate Authorities to >> vouch for the client. The certificates can be either self signed, or signed >> by some unknown CA. >> >> The trick used is the same as the one used by OpenID. ( In fact OpenID >> inspired much of what is behind Web ID. ) The SSL connection lets the server >> know that the client has the private key of the public key sent in the X.509 >> certificate. Because the X.509 certificate also contains the Web ID (in the >> subject alternative name position), the server can do an HTTPS get on the >> WebID and if the public key matches there, Identity is proven. >> >> So we do change the server SSL/TLS proof method. I have put this past a lot >> of security experts in the past year, and we have implementations in most >> major languages. If you can see a problem > > I see only the same problem I saw (and reported to you) 2 years ago - which > is that for all the cryptography involved, it still seems possible for an > individual to self-assert that they have a WebID and that it is linked to > some certificate and private/public key. Which is to say, why bother with all > the crypto if a user can self-assert his or her WebID and FOAF file anyway?
Perhaps I've lost touch with OpenID, but my understanding was that in the general case OpenID also comes with no built-in grounding to trusted claims, or to society at large. It does more often show up with the account holder packaged alongside a big and well-known provider, who may or may not be checking various things claimed by the end user. But as you say, OpenID works in self-assert mode too, though (although sometimes I get the impression this mode has 2nd-class citizen status). For example, I have been using <http://danbri.org/> as a self-asserted OpenID for years (sometimes self-hosted via wordpress, sometimes via yahoo, livejournal or whoever). Regardless, the fact of my ownership of the danbri.org domain and control of its HTTP services is something you'll have to check from elsewhere. As Henry said, that's where Social Web comes in, and the auth*n stuff takes a back seat. So the layering and perspective is a little different, but the core issues don't go away. OpenID isn't a distributed trust system either. FOAF itself works fine alongside OpenID and alongside FOAF+SSL; and FOAF+SSL (especially as browser cert UI improves) is a fine way to login to my OpenID provider. The difference in perspective seems to be on the role and centrality of providers. FOAF, as an application of RDF, sees the world as a soup of source-attributed claims. Some come from users, some come from big companies who have checked out some of the things the user claimed (like control of an email address); others can come from statistics and community, others from govt officials. RDF apps, like any other, have to figure out who is saying what, and from that, figure out what to do and who to trust. The notion of providers and services is still there, but playing different roles. So http://www.advogato.org/person/connolly/foaf.rdf for example is an aggregate from the Advogato community about one of its members (plus some unchecked claims from the account holder, like name). The challenge for those advocating provider-less identity is to figure out how to pull together useful factoids from an inclusively large variety of such sites before the spammers arrive in bulk. And unless I've missed a memo, OpenID hasn't solved the spam problem either... cheers, Dan > > OpenID relies on an OpenID provider "vouching" that a particular URI is > "owned" by some user for whom the OpenID provider has an account. You could > also run your own OpenID provider and self-assert that way. And the question > is whether that is a particularly interesting thing to do in a Web context > (as we self-assert all the time without any special protocols needed and it > works fine for many things without new techniques, systems or other > technology). So this puts the two approaches on the level. FOAF+SSL relies on external sources to check that <http://bblfish.net/people/henry/card#me> is actually Henry; so does OpenID, but it bakes a role for those external sources more strongly into the core spec (but leaves them optional). _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
