Friday Apr 03, 2009

Global Identity in the iPhone browser

Typing user name/passwords on cell phones is extreemly tedious. Here we show how identification & authentication can be done in two clicks. No URL to type in, no changes to the iPhone, just using bog standard SSL technology tied into a distributed global network of trust, which is known as foaf+ssl.

After having installed a foaf+ssl certificate on my phone (which I will explain how to do in my next post), I directed Safari to, which is a foaf+ssl enabled web site. This brought up the following screen:

empty page

This is a non personalised page. In the top right is a simple foaf+ssl login button. This site was not designed for the iPhone, or it would have been a lot more prominent. (This is easy to change for of course). So I the zoomed onto the login link as shown in the following snapshot. Remember that I don't have an account on This could be the first time ever I go there. But nevertheless I can sign up: just click that link.

login link

So clicking on this foaf+ssl enabled link brings up the following window in Safari. Safari warns me first that the site requires a certificate. The link I clicked on sent me to a page that is requesting my details.

certificate warning

As I do in fact want to login, I click the continue button. The iPhone then presents me with an identity selector, asking me which of my two certificates I want to use to log in:

certificate selection

Having selected the second one, the certificate containing my WebId is sent to the server, which authenticates me. The information from my foaf file is then used to personalise my experience. Here gives me a nice human readable view of my foaf file. I can even explore my social network right there and then, by clicking on the links to my friends. Again, this will work even if you never did go to before. All you need is of course a well filled out foaf file, which services such as are making very easy to do. Anyway, here is the personalised web page. It really knows a lot about me after just 2 clicks!


The site currently has another tab, showing my activity stream of all the chats I have on the web, which it can piece together since I linked all my accounts together in my foaf file, as I explained in the post "Personalising my Blog" a few months ago.

activity stream

Other web sites could use this information very differently. My web server itself may also decide to show selected information to selected servers... Implementing this is it turns out quite easy. More on that on this blog and on the foaf-protocols mailing list.

Thursday Feb 12, 2009

sketch of a foaf+ssl+openid service

Discussing foaf+ssl with Melvin Carvalho he pointed out that we need a service to help non https enabled servers to participate in our distributed open secure social network. This discussion led me to sketch out the following simple protocol, where I make use of parts of the OpenId protocol at key points. This results in something that does what OpenId does, but without the need for users to remember their URL, and so without many of the problems that plague that protocol. And all this with minimal protocol invention.

So first here is the UML sequence diagram for what I am calling here tentatively foaf+ssl+openid.

  1. First Romeo arrives on a public page with a login button.
    • On an OpenId server there would be a field for the user to enter their ID, with foaf+ssl this is not needed. So we have a simple login button.
    • That button's action attribute points to some foaf+ssl+openid service that server trusts (it is therefore an https URL). It can be any such service. In OpenId the Id entered by the user points the server to a web page that points the service to an openid server the user (Romeo here) trusts. All of this is no longer needed with this protocol. The html for the login button can be static.
    • The URL has to encode information for the foaf+ssl service to know who to contact back. One should use exactly the same URL format here as OpenId does. (minus the need to encode User's URL since that will be in the X509 certificate)
  2. When Romeo clicks the login button he opens an https request to the foaf+ssl+openid service.
  3. The foaf+ssl+openid service on opening the connection asks for the client's certificate after sending its own. This would contain
    • The User's Public key
            Subject Public Key Info:
                  Public Key Algorithm: rsaEncryption
                  RSA Public Key: (1024 bit)
                      Modulus (1024 bit):
                      Exponent: 65537 (0x10001)
    • The Subject's Alternative Name WebId
              X509v3 extensions:
                 X509v3 Subject Alternative Name: 
    The ability for browsers to do this is all part of the standard TLS handshake available in most browsers for a few generations.
  4. The server looks in the client certificate for the Subject Alternative Name in the SSLv3 extensions, and fetches the foaf file at that URL
  5. The service then does a simple match on the information from the foaf file and the information from the certificate. If they match the foaf+ssl+openid service knows that the user <> controls <> web page. This is enough for simple authentication. (For more on this see Creating a Web of Trust withouth Key Signing Parties )
  6. Depending on the result, the foaf+ssl+openid service can return a redirect with an authentication token to the original service Romeo wanted to log into. This can also be done using the patterns developed in the OpenId community. foaf+ssl+openid sequence diagram
  7. The browser then redirects to the Original service.
  8. The service now has Romeo's URL. But to avoid a man in the middle attack, or replay attacks it follows the OpenId protocol and does a little check with its service on a token sent to it in the redirect in step 6.
    ((Perhaps this step could be avoided if the foaf+ssl+openid service made public it's public key, and encrypted some token sent to by the client to the server. But we could just stick closely to the well trodden OpenId path and just reuse their libraries.))
  9. Having verified the identity of the user, the service could optionally GET the user's foaf file, for public information about him.
  10. Or it could check the relation that user has to it's trusted graph of friends,
  11. and return a presonalised resource

One could also imagine a foaf+ssl+openid server enabled with attribute exchange functionality, which it could get access to simply by reading the foaf file.

I am not sure how much of a problem it really is for servers not to have SSL access. But this could easily fill that gap.




« June 2016