0
TheWriteID	  A	  hypothe/c	  iden/ty	  brokerage	  service	  
Digital	  Iden/ty,	  as	  it	  should	  be.	  TheWriteID	   is	   a	   work	   in	   progress,	   both	   as	   a	   techn...
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	  cl...
Works	  in	  browser.	  We	  have	  a	  limited,	  not	  maintained,	  proof-­‐of-­‐concept	  available	  by	  simple	  re...
Encrypted	  authen%ca%on.	  There	  are	  many	  ways	  to	  authen/cate	  yourself	  towards	  the	  applica/on.	  We	  c...
Remote	  storage.	  We	  envision	  RemoteStorage	  to	  be	  the	  storage	  protocol	  of	  choice,	  as	  this	  allows...
Decrypted	  authen%ca%on.	  When	  the	  remote	  storage	  yields	  the	  dataset	  that	  has	  been	  encrypted	  earli...
It’s	  simple.	  
TheWriteID	  ra%onale.	  
The	  iden%ty	  API	  exchange.	  The	  TWID	  client-­‐side	  applica/on	  can	  talk	  to	  prac/cally	  any	  service	 ...
End	  note.	  	  Many	  thanks	  to…	  	  Frank	  Guthorel	  –	  Code	  d’Or	  Tijs	  Verkoyen	  –	  Sumocoders	  Jan	  De...
Upcoming SlideShare
Loading in...5
×

TheWriteId > components

984

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
984
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "TheWriteId > components"

  1. 1. TheWriteID  A  hypothe/c  iden/ty  brokerage  service  
  2. 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  ones  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  cant  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. 3. From  here…  
  4. 4. To  here…  
  5. 5. TheWriteID  iden/ty  brokerage  service  
  6. 6. TheWriteID  components.  
  7. 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.  Wed  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. 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. 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. 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  dont  see  any  problem  to  also  store  data  on  untrusted  remote  storage  providers,  like  Dropbox,  Google  Docs,  Amazon  S3,  WeTransfer,  etc.    
  11. 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. 12. It’s  simple.  
  13. 13. TheWriteID  ra%onale.  
  14. 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. 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    
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×