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

Hi Henry,

On 10/6/2011 7:12 PM, Henry Story wrote:

[snip]

> 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!
>

Re. capturing/describing the semantics of a HTML form, you may have a 
look at RDForms [1]

> 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!)
>

What about utilising the HTTP LINK header for this issue?


> 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?
>

Yep! Generally, this seems to be a nice application of combining the 
principles of the REST architectural style, the Linked Data publishing 
guideline and the common Semantic Web technologies ;)

Cheers,


Bo


[1] http://vocab.deri.ie/rdforms

Received on Friday, 7 October 2011 08:32:16 UTC