Re: Foaf-browser-app -- keygen in rdf

Come to think of it, all of the thinking below may be mostly superfluous. Just to summarise: the problem is creating a certificate for a browser like the FOAF Address Book that the University of Leipzig put together. In order to do that one first needs to be logged in - to get the keygen in html to work.

BUT: if a cell phone uses just one keychain, which I imagine small phones like Android do, then one can just create the certificate in the browser and then use it from any other application. In that case it would be simply a case of getting the user to open his browser and to make the certificate there.

Is that method possible, Tim? If so it seems a lot simpler than all the other attempts below. And of course a lot more secure at the same time....

Henry

On 6 Oct 2011, at 19:12, Henry Story wrote:

> 
> 1. Keygen end point
> -------------------
> 
> One way to do this is to have the same logic as with the web services we are using now. Ie to have the equivalent of a form where a user can publish a key. This would be useful because then the rdf and the html worlds would work in parallel.
> 
> Perhaps a profile would work something like this:
> 
> <> a foaf:Profile;
>   foaf:primarySubject :me .
> 
> :me a foaf:Person;
>    foaf:name .... 
> 
> <certGen> a xhtml:Form, cert:CreationForm;
>    xhtml:parameter [ xhtml:name "keygen"
>                      a xhtml:Keygen ];
>    xhtml:parameter [ xhtml:name "webid";
>                      xhtml:value "http://harvard.edu/profile/george#me"
>                    ] .
> 
> Or perhaps something better, but the idea would be to describe a form in such a way that it can know that it has to generate a public/private key and send it to that collection. But wait! Before we can even do that, we need to be authenticated!
> 
> 1.1 Logging in to create a cert
> -------------------------------
> 
> So before one can do anything like create public/private keys to create certificates,  the user first needs to authenticate with that site in a manner that is easy to understand for said human user.
> 
> So the current Android app does that by asking the user to upload a pem file to the phone, but clearly that is not going to work with most users - it's just too complicated. The reasonable way to do that on the phone is to do what one does on the web: log in using well understood username password auth, then create a certificate. So that means that the phone needs to not only know what the certificate endpoint is, but needs to also know how to login using said username password. So perhaps just the old HTTP Authentication mechanisms should be used there? But perhaps one should also develop a username/password relation also?
> 
> ---8<--- the document ---8<---
> <> a foaf:Document;
>  auth:login </login> .
> 
> --8<--- the login page ---8<---
> 
> <login> a xhtml:Form;
>    xhtml:parameter [ xhtml:name "username"
>                      a  login:UserName ];
>    xhtml:parameter [ xhtml:name "password";
>                      a login:Password ] .
> 
> 
> 1.2 SPARQL and forms
> --------------------
> 
> Notice how Forms look so much like queries? That is because a form is a query of the server to the user (who could also be a robot). So we could think of FORMS as frozen SPARQL queries, as I argued a few years ago in "SPARQLing AltaVista: the meaning of forms" http://blogs.oracle.com/bblfish/entry/sparqling_altavista_the_meaning_of
> 
> Essentially that name value pairs are the answers we find in SPARQL answer sets, and the query asked is from the server to us.
> 
> When we login what are we asked?
> 
> SELECT ?username ?password 
> WHERE {
>  <http://harvard.edu/person/joe> a foaf:Account; 
>         foaf:accountName ?username;
>         auth:password ?password .
> }
> 
> So perhaps our browser having authentified the server, and checked with the user whether it is allowed to get
> an answer to such a question, finds and returns the answer (usually by asking the user).
> 
> Now the problem is that we do need to know not only that that query comes from the server but that it has asked by the server administrator, and not say just put there on a blog entry, or on some other part of the site - in which case it would be all too easy to get robots to send the password to the wrong agent. This is really the problem that WebID solves so nicely, btw: we know that it is the server administrator asking the question, because the question comes from the TLS layer, which if that is not controlled by the admin, nothing is certain anymore.
> 
> I don't think we can even rely on HTTP headers too much, even though we should. HTTP headers is what the server says about the document. There should be the place where the server states who made the document for example - by pointing to the WebID of the admin perhaps. But following that through will be quite difficult even if it were reliable. One would then have to prove that that was really the WebID of the admin, which well, I suppose could be done for example if one could find the same WebID in the certificate sent by the https endpoint (but then that would require CAs to do some work!)
> 
> So perhaps the most secure low security way to update a resource is after all just to do an HTTP PUT or UPDATE (?) to what one knows to be one's home page, and have the server ask for a username password using HTTP-Auth. Perhaps that username password could be a onetime password, just to be on the safe side. (But then one would need to pass that message to the user somehow). So perhaps here the best thing to do is simply to have the server send back an http representation of the login form, and have the cell phone show a simple web browser for that view?

Social Web Architect
http://bblfish.net/

Received on Thursday, 6 October 2011 19:19:35 UTC