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.

1. TheWriteID
A
hypothe/c
iden/ty
brokerage
service

2. 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.

3. From
here…

4. To
here…

5. TheWriteID
iden/ty
brokerage
service

6. TheWriteID
components.

7. 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,
…).

8. 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/

9. 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

10. 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.

11. 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/

12. It’s
simple.

13. TheWriteID
ra%onale.

14. 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/

15. 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.
You
could
not
do
any
of
us
a
bigger
favor
than
to
make
TheWriteID
happen
acer
all.
hMp://www,.thewriteid.com
|
@TheWriteID
Tim
De
Coninck
–
A
cup
of
T