In my previous blog post, I described my new proposal for involving social network based authentication into WiFi access points. Now I want to go beyond the access points. Social network based authentication can be applied to many other scenarios such as:
- Sharing/Streaming any kind of file with another device which belongs to same person or social network:
- File exchange from laptop to smartphone
- Streaming audio/video from smartphone to TV
- Controlling car infotainment system with a smartphone.
- The destination for the navigation device can be entered by anyone from the family or a close friend inside the car by using their smartphone.
- Wearable medical sensors share information only with authorized medical stuff.
- When a patient visit doctor, or remotely for elderly patients, only the authorized doctor should be able to collect information from the sensors.
- Similarly, sensory information of a building should be accessed by officials in emergencies.
For all these scenarios we should understand that a device identity is a must. Like us, humans, every device should somehow present its properties, capabilities and more importantly its owner information. Then, when devices interact, they can incorporate this social information in authentication and authorization. Since devices should be able to comprehend the information in these social profiles, a structured presentation format from semantic web like RDF is a reasonable choice.
After having a social profile in somewhere on the web, we need to establish a bridge to it and existing password based single sign on solutions are the first candidates. Assume that a device has an embedded password and as username it uses the URL of its social profile. There is another malicious device, which has the same URL as username but a different password. Now, which password is true? We need an authentication server, like OpenID, Facebook Connect etc. Although seems pretty straightforward, password based solutions have challenges: ( i ) Central server is aware of all the attempts for access, it can abuse our privacy. ( ii ) How can we embed passwords? Can we remember all of them? ( iii ) Passwords allways require a central server involved in the process. What about ad hoc interaction?
As a decetralized solution, we can bridge devices to their social profiles by using WebID. WebID is a X509.v3 (can be self-signed) certificate which has an embedded link to a social profile. This social profile can be public, stored in any where on the web. For more detail please refer to WebID spec. With WebID based solution, there is no dependency in any kind of central server, and ad hoc operation is possible after the first interaction between two devices. In the first interaction, the authentication requires internet access, however, in the subsequent ones, the WebID certificate and profile can be stored in the peer like SSH authorized keys approach. Privacy is not a concern since even offline operation is possible and authenticator is the peer device not a centralized server. Lastly, embedded devices can be distributed with already installed WebID certificates. Then by granting access for the device profiles to their new owners, end users can manipulate the authentication and authorization.
WebID offers us a decentralized way of building social things. However, like every other technology it also has challenges. The main challenge is the computational requirements for asymmetric key cryptography. There are successful projects for applying asymmetric encryption and DTLS (datagram transport layer security). However, WebID as a protocol also requires parsing and inferring semantic web pages. All these together may be a challenge for constrained devices. Moreover, there are RFIDs which has no computational power. Therefore, we may need local gateways. For instance, our smartphones can collect sensory information and act as a gateway. The connection between the smartphone and sensors can be encrypted via embedded passwords, while smartphone is connected via WebID protocol to the outer world.