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

On 6 Oct 2011, at 16:00, Kingsley Idehen wrote:

> On 10/6/11 8:23 AM, Henry Story wrote:
>> On 6 Oct 2011, at 14:14, Kingsley Idehen wrote:
>> 
>>> On 10/6/11 6:11 AM, Bob Ferris wrote:
>>>> Hi Henry,
>>>> 
>>>> On 10/4/2011 8:04 PM, Henry Story wrote:
>>>>> While playing with the very cool Foaf-browser Android application [1], I noticed that there are a couple of things that we need to standardise to make that type of application seamless.
>>>>> 
>>>>> As it requires having an Android phone which not everyone may have, I put together a little video of the Foaf-browser here
>>>>> 
>>>>>    http://vimeo.com/30014844
>>>>> 
>>>> This is an interesting representation of this Social Web Android application.
>>>> 
>>>> +1 re. the UX/usability remarks
>>> This tool is a good start, but UX/usability always struggles if the fundamental UI/UX bottleneck of Linked Data isn't addressed. The problem boils down to labels for URIs across TBox and ABox. Pulling it off requires a Linked Data platform that's able to use reasoning to harmonize labels across a variety of Annotation Properties. Doing this has to scale (as we demonstrate with 29+ Billion triples at: http://lod.openlinksw.com ).
>> Kingsley, the usability issues I describe have nothing to do with reasoning.
> 
> I am referring to the need for labels replacing URIs i.e., automated generation of anchors for text when presenting relations that describe a subject.
> 
> This is the key to the matter. I've used the tool, and that's the only real UI/UX hurdle. They already figured out the value of QR Codes etc..

Ah ok, yes. I see one can automate that. For a specialised tool such as an address book, one could quite well hard code it....
But yes. I see what you mean.

> 
>> They have to do with with focus on solving those problems. Some of those problems have to do with some missing information which we need to think about. For example the Foaf-browser is an address book that runs on a cell phone and is written in Java. It needs to be able to find the form to create a Secured WebID.
> 
> I think that's a separate product. Basically, a phone hosted WebID generator. We are making such a thing anyway. So stay tuned.

That's not difficult to do. I can in no time write up some code for the telephone to create a public private key. What is needed is a way to send the key to the profile so that it is published there, and so what we need is a way to do that without having to do complex setup of a each android phone, for each particular site. Ie: we need a standard authentication procedure for the time before we are authentified using WebID, so that we can create the WebID. And that has to be a one click procedure - or else we loose a lot of users.

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?


> 
>> There are usability problems that will come up with reasoning. But since we are all getting going, and we need to work together people should try to publish data that will require a minimum or no reasoning.
> 
> My points is that via a Web Service the reasoning burden is alleviated. The make retrieve a data object and its representation includes:
> 
> 1. de-referencable name
> 2. a literal label.
> 
> The service does the work. The client just gets the data objects.

Well yes, the cell phone could just do html viewing. Things tend to be a bit slower that way though, and don't work that well with low connections or when roaming across countries where suddenly MBytes are extremely expensive.

> 
>>  Then we are more likely to get other people on board, and work together as a community.
> 
> I am making the same point, but its kinda lost in translation .

Ok. We're focusing in on the problems. 

Btw, it is writing a client such as this that I ended up feeling the need for WebID. So I think that by building these we will get to find the issues we need to solve.

> 
> 
>>> We do offer an API into our faceted browser engine that enables anyone leverage this functionality. Thus, I need to double check that we actually surface what I've described since it took some serious engineering to pull off this solution in the manner I just described.
>> We are speaking cell phones here. If you want to market your product here is an opening for you: do you have a version of virtuoso that runs efficiently on iPhones, which java cannot reach?
> 
> We can make a version of Virtuoso run wherever we choose if we deem it useful.

Ok. I don't think I need it to run on an iPhone anymore, but some people were interested last week. I'll get in contact with you if that turns up again.

Henry

> 
> Kingsley
>> Henry
>> 
>>> Links:
>>> 
>>> 1. http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtFacetBrowserInstallConfig -- Virtuoso's DBMS hosted Faceted Browsing Service .
>>> 
>>> Kingsley
>>>> Cheers,
>>>> 
>>>> 
>>>> Bo
>>>> 
>>>> 
>>>>> where I also go into detail in some of the things that need to be improved, as I show how it works.
>>>>> 
>>>>> 1. SEAMLESS STARTUP
>>>>> ===================
>>>>> 
>>>>> In order to allow seamless startup, there has to be a way for a user once he has installed the browser to find his home page.
>>>>> 
>>>>> We discussed this yesterday on the WebID-XG incubator group meeting with Tim.
>>>>> 
>>>>> a. getting to the home page
>>>>> ---------------------------
>>>>> 
>>>>> Clearly getting to the home page of the user is going to be important. That will require him to either:
>>>>> 
>>>>>  - know his profile url
>>>>>  - the company he is with to have implemented something like web finger, so that one could just ask him for his email address
>>>>>  - ..
>>>>> 
>>>>> We seem to have a few protocols to help here. What clearly was missing was the keygen equivalent for an application like that.
>>>>> 
>>>>> b. keygen form pointer
>>>>> ----------------------
>>>>> 
>>>>>  We need  some way to get the equivalent of a keygen form in rdf. Then a non html browser could know where it needs to send an html POST of a keygen like response. Any ideas how to do this?
>>>>> 
>>>>> 2. EDITING
>>>>> ----------
>>>>> 
>>>>> I suppose the RW community group have some idea of what is needed to allow such a tool to become an editor.
>>>>> 
>>>>> 
>>>>> Henry
>>>>> 
>>>>> 
>>>>> [1] http://code.google.com/p/mssw/wiki/Screenshots
>>>>> 
>>>>> 
>>>>> You can run it in a emulator - very slow btw, but if you don't want to buy a phone it saves money.  Here is what I learned looking at it: The running stable release of the Address Book is
>>>>> 
>>>>> http://code.google.com/p/mssw/downloads/detail?name=mssw-0.9.6-stable.apk
>>>>> 
>>>>> The emulator can be found here:
>>>>> 
>>>>>  http://developer.android.com/guide/developing/devices/emulator.html
>>>>> 
>>>>> Once installed the tools/android  tool allows starts a GUI which allows one to create a virtual device. Perhaps one first has to install android 2.3.3 which is more like a phone, and create a virtual device for that. Then can launch the device. One installs the app on the virtual phone using once it is running
>>>>> 
>>>>> ../platform-tools/adb install mssw-0.9.6-stable.apk
>>>>> 
>>>>> (there may be a GUI way of doing that)
>>>>> 
>>>>> 
>>>>> [2] this is true for creating WebIDs, for loving in and so on....
>>>> 
>>>> 
>>> 
>>> -- 
>>> 
>>> Regards,
>>> 
>>> Kingsley Idehen	
>>> President&   CEO
>>> OpenLink Software
>>> Web: http://www.openlinksw.com
>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>> Twitter/Identi.ca: kidehen
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 6 October 2011 17:12:35 UTC