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

On 6 October 2011 21:18, Henry Story <henry.story@bblfish.net> wrote:

> 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....
>
It's true that Android has a special storage for certificates, but I'm not
sure (haven't tested it) if the generated certificated is saved there or in
some kind of browser-only storage. So, this question requires more
experiments and code :)


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


-- 
Sincerely,
Timofey Ermilov