sketch of a foaf+ssl+openid service
By bblfish on Feb 12, 2009
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.
- 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)
- When Romeo clicks the login button he opens an https request to the foaf+ssl+openid service.
- 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): 00:b6:bd:6c:e1:a5:ef:51:aa:a6:97:52:c6:af:2e: 71:94:8a:b6:da:9e:5a:5f:08:6d:ba:75:48:d8:b8: 01:50:d3:92:11:7d:90:13:89:48:06:2e:ec:6e:cb: 57:45:a4:54:91:ee:a0:3a:46:b0:a1:c2:e6:32:4d: 54:14:4f:42:cd:aa:05:ca:39:93:9e:b9:73:08:6c: fe:dc:8e:31:64:1c:f7:f2:9a:bc:58:31:0d:cb:8e: 56:d9:e6:da:e2:23:3a:31:71:67:74:d1:eb:32:ce: d1:52:08:4c:fb:86:0f:b8:cb:52:98:a3:c0:27:01: 45:c5:d8:78:f0:7f:64:17:af Exponent: 65537 (0x10001)
- The Subject's Alternative Name WebId
X509v3 extensions: ... X509v3 Subject Alternative Name: URI:http://romeo.net/#romeo
- The User's Public key
- The server looks in the client certificate for the
Subject Alternative Namein the SSLv3 extensions, and fetches the foaf file at that URL
- 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 <http://romeo.net/#rome> controls <http://romeo.net/> web page. This is enough for simple authentication. (For more on this see Creating a Web of Trust withouth Key Signing Parties )
- 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.
- The browser then redirects to the Original service.
- 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.))
- Having verified the identity of the user, the service could optionally GET the user's foaf file, for public information about him.
- Or it could check the relation that user has to it's trusted graph of friends,
- 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.