thewriteid > components
DESCRIPTION
TheWriteID is a work in progress, both as a technical solution and as a commercial offer. It aims to be the identity layer on top of the internet with the sole and only goal to regain control over one’s online and digital identity by extracting it from current networks & services. The best part of TheWriteID is that the data is encrypted locally so we can’t read out the identity data itself, unless a user decides to share it. We aim to make true identity manageable and re-usable for other networks and services, by introducing variable personas. In essence, we wonder how we can evolve from an internet of connected devices to a truly internet of connected people? TheWriteID aims to get us from the era of connected contexts to one where users are free to handle their identity and all its slight variations with who they want/like/decide. Digital identity, as it could have been: www.TheWriteID.com.TRANSCRIPT
TheWriteID
A hypothe/c iden/ty brokerage service
Digital Iden/ty, as it should be. TheWriteID is a work in progress, both as a technical solu/on and as a commercial offer. It aims to be the iden%ty layer on top of the internet with the sole and only goal to regain control over one's online and digital iden%ty by extrac/ng it from current networks & services. The best part of TheWriteID is that the data is encrypted locally so we can't read out the iden/ty data itself, unless a user decides to share it. We aim to make true iden%ty manageable and re-‐usable for other networks and services, by introducing variable personas. In essence, we wonder how we can evolve from an internet of connected devices to a truly internet of connected people? TheWriteID aims to get us from the era of connected contexts to one where users are free to handle their iden/ty and all its slight varia/ons with who they want/like/decide. Digital iden/ty, as it should be: www.TheWriteID.com.
From here…
To here…
TheWriteID
iden/ty brokerage service
TheWriteID components.
Don’t trust service servers. As the user cannot trust the server as such, we envision a client-‐side applica/on, that is downloaded and running in the browser. We'd need to set up the client-‐side applica/on in such a way that no further server calls to TWID are required. Examples of such applica/ons already exist, as prototypes or as proof-‐of-‐concepts:
Cappucino framework hMp://cappuccino.org/learn/demos/
GitHubIssues hMp://githubissues.heroku.com/
Cappucino comes to mind as a framework to create and deliver this client-‐side applica/on, but there are other alterna/ves as well. The idea is to move all logic and handling as quickly as possible to the browser, as this is only program (to a degree) that can be trusted by the user.
Background on Cappucino
hMp://en.wikipedia.org/wiki/Cappuccino_(applica/on_development_framework
A possible alterna/ve to Cappucino hMp://sproutcore.com
Another approach is to use browser-‐na/ve applica/ons that can be run on a per-‐browser basis – browser plugins, XUL-‐based applica/ons, or apps available through AppStores.
XUL for Mozilla browsers hMps://developer.mozilla.org/en/XUL
Extensions for Google Chrome browsers hMps://chrome.google.com/webstore/category/extensions?hl=nl
Depending on what limits we encounter in a proof-‐of-‐concept phase, it is possible that certain routes might not be op/mal so choose (browser memory limit, processing resources, instancing, sandboxing, …).
Works in browser. We have a limited, not maintained, proof-‐of-‐concept available by simple request. Mail /mdeconinck at gmail for access.
TheWriteID Prototype hMp://writeid.sumocoders.be/
Encrypted authen%ca%on. There are many ways to authen/cate yourself towards the applica/on. We can select PKI or key-‐pair-‐ based authen/ca/on mechanisms. A lot of implementa/ons of this are already available. Our preference goes to as liMle in-‐between-‐people as possible, so key-‐pairs seems the way to go here. Examples are, on different levels of implementa/on and for different use-‐cases:
Belgium eID hMp://eid.belgium.be/nl/ Implementa/on of TaxOnWeb with
hMps://eservices.minfin.fgov.be/portal/nl/public/ci/zen/welcome
TrueCrypt hMp://www.truecrypt.org/ OpenPGP
hMp://en.wikipedia.org/wiki/PreMy_Good_Privacy#OpenPGP
GPG hMp://en.wikipedia.org/wiki/GNU_Privacy_Guard General background about public-‐key cryptography
hMp://en.wikipedia.org/wiki/Public-‐key_cryptography
Remote storage. We envision RemoteStorage to be the storage protocol of choice, as this allows for distribu/on of the data accessed acer usage. We also see RemoteStorage as a way of spreading risk, and see it as a way of coping with the limita/ons of the client-‐side applica/on within the browser. RemoteStorage providers can be both trusted and non-‐trusted, in the sense that we might use specific features of a provider, or choose not to implement these. We at least want to provide the op/on to the TWID user to encrypt the data being stored remotely. That way, only the user can unlock the content to be managed – making it secure from man-‐in-‐the-‐middle aMacks and remote snooping on the server. Before the remote storage is being used again, the client-‐side applica/on encrypts everything again before shudng down.
Remote Storage protocol
hMp://www.w3.org/community/unhosted/wiki/RemoteStorage
Unhosted hMp://unhosted.org/#remotestorage
However, we don't see any problem to also store data on untrusted remote storage providers, like Dropbox, Google Docs, Amazon S3, WeTransfer, etc.
Decrypted authen%ca%on. When the remote storage yields the dataset that has been encrypted earlier, the client-‐side applica/on needs to decrypt everything before it can be accessed. There are mul/ple ways of doing this, and based on the encryp/on defined earlier, it is necessary custom crypto development will have to take place. On the other hand, the proof-‐of-‐concept has been made already with the Stanford JS Crypto Library men/oned below.
Stanford JS Crypto Library hMp://crypto.stanford.edu/sjcl/
It’s simple.
TheWriteID ra%onale.
The iden%ty API exchange. The TWID client-‐side applica/on can talk to prac/cally any service offering an interface for data exchange, and this in both direc/ons. We can import data from accounts that TWID gets access too. And the client-‐side applica/on can push data to networks the TWID account can connect too. Authen/ca/on will be needed for every /me a connec/on is made in both direc/ons, which is where Oauth comes in for the authen/ca/on from client-‐side applica/on to each network or external service.
Open Authen/ca/on hMp://oauth.net/
End note. Many thanks to… Frank Guthorel – Code d’Or Tijs Verkoyen – Sumocoders Jan De Poorter – Sumocoders Sebas/an Hagens – Sebas/x Kaliya – Iden/ty woman Peter Van der Auwere -‐ SWIFT Elias Bizannes – Startupbus Kenneth De Buck – Bold Graphics Florian Brondel S/jn Van Herck And many more who gave us feedback, /ps, support and their love.
Tim De Coninck – A cup of T
You could not do any of us a bigger favor than to make TheWriteID happen acer all. hMp://www,.thewriteid.com | @TheWriteID