Re: [foaf-dev] Re: privacy and open data

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@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev