[foaf-dev] Re: privacy and open data
Story Henry
henry.story at bblfish.net
Tue Mar 25 17:16:04 GMT 2008
On 25 Mar 2008, at 17:44, Peter Williams wrote:
>
> Henry Story wrote:
>
> > The server would then just need to get the foaf file, find the pgp
> > public key, to verify that the reques does indeed come from the
> owner of the foaf file."
>
> Loving to solve trust problems using public key control systems (my
> own discipline), I'm supportive.
>
:-)
> However, the use of "just" is a little dis-ingenuous, above. 15
> years of the PGP model working in other information flow sphere's
> did not reduce the key distribution issue set down to a simple
> "just". Nothing in the PGP model of web of trust has shown itself
> better than other models at scaling a wot, todate. A fair amount of
> highly-doctrinal arguments are bandied around, tho.
>
Is the key distribution issue still a problem now? With linked data I
have my foaf file point to the URL of the pgp key.
So my foaf file contains the following triples:
:me is wot:identity of [ a wot:PubKey;
wot:pubkeyAddress <http://bblfish.net/people/henry/henry.pubkey.asc
>;
wot:fingerprint
"0DF560B5DADF6D348CC99EA0FD76F60D4CAE10D7";
wot:hex_id "4CAE10D7";
wot:length 1024 ] .
so if someone trusts the foaf file has not been corrupted - not unlike
trusting that the OpenId Resource has not been corrupted - then the link
to the PGP key deals with the problem of finding the key, right?
I don't think we need Web Of Trust at this level. Here I am just
trying to define a very simple method of authentication.
1. the client ( Beatnik perhaps ) sends an RDFAuth header in its HTTP
Header request with an encrypted string and a pointer to my foaf file
2. the server then
a. find the foaf
b. find the public PGP key (other encryption mechanisms could work)
c. checks that the encrypted string I sent it could only be
generated by someone who had the private key of the public key
=> it then knowns that the client making the request is indeed the
owner of the foaf file.
This is a lot simpler than OpenId to put in place, once one gets over
the restrictions OpenId imposed itself by limiting itself to legacy
web browsers.
> What's interesting about the particular wot model referred to in
> foaf/semweb is the notion that one relies on the public key only
> once its endorsed by a sufficient "weighting" of those members on
> one or your own particular friend lists.
>
I was not suggesting this be done here.
What I describe in
http://blogs.sun.com/bblfish/entry/cryptographic_web_of_trust
could be used as a further way of validating the authenticity of the
foaf file.
Here all the server needs to know is your name. Ie.
<http://bblfish.net/people/henry/card#me>
in my case. The server could then give you access rights simply based
on this, by checking that your name (URI) is in a list of accepted URIs.
The list itself could be generated using a web of trust mechanism, but
say crawling foaf files the way the DIG group did it.
http://dig.csail.mit.edu/breadcrumbs/node/206
> This is a variant of the aborted IETF efforts of the SKMI WG.
> Beware, that fully generalized metric-based reliance models were
> properly and carefully patented in the mid 90s, folks, with both the
> core claims and the continuances set to run for a good amount of
> time yet. The prior art disclosed DARPA research reports of the
> early 1990s that provided for the restricted use of metrics in a
> specific (TTP) model of key distribution, for the selection of
> alternative routing graphs through a key-certification space
> starting at well-known public (vs restricted access personal) trust
> points.
>
Thanks for the warning.
> Remember to apply your core research skills, re the literature (and
> G8 patent databases).
>
Well I try to think of obvious things. Those I am told can't be
patented :-)
Henry
> ______________________
> _________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080325/022b414d/smime-0001.bin
More information about the foaf-dev
mailing list