thewriteid > components

15
TheWriteID A hypothe/c iden/ty brokerage service

Upload: tscape

Post on 05-Dec-2014

1.156 views

Category:

Technology


0 download

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

Page 1: TheWriteId > components

TheWriteID  

A  hypothe/c  iden/ty  brokerage  service  

Page 2: TheWriteId > components

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.    

Page 3: TheWriteId > components

From  here…  

Page 4: TheWriteId > components

To  here…  

Page 5: TheWriteId > components

TheWriteID  

iden/ty  brokerage  service  

Page 6: TheWriteId > components

TheWriteID  components.  

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

Page 8: TheWriteId > components

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/    

 

Page 9: TheWriteId > components

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    

Page 10: TheWriteId > components

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.    

Page 11: TheWriteId > components

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/  

     

Page 12: TheWriteId > components

It’s  simple.  

Page 13: TheWriteId > components

TheWriteID  ra%onale.  

Page 14: TheWriteId > components

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/  

   

Page 15: TheWriteId > components

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