Re: NSTIC WebID Teleconf minutes for 1 August 2011

Henry,

I would love to refer to your Issuer WebID idea when we revise the Pomcor whitepaper.  I could put a reference to the entry for the message below in the WebID XG mailing list archives.  If there was a short write-up in the w3.org site, e.g. in the WebID wiki, that would even better.

Francisco

 
Francisco Corella, PhD
Founder & CEO, Pomcor
Twitter: @fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com


>________________________________
>From: Henry Story <henry.story@bblfish.net>
>To: "public-xg-webid@w3.org XG" <public-xg-webid@w3.org>
>Cc: Corella Francisco <fcorella@pomcor.com>
>Sent: Friday, August 5, 2011 1:51 AM
>Subject: NSTIC WebID Teleconf minutes for  1 August 2011
>
>Hi,
>
>Thanks a lot to Francisco Corella for joining us this Monday in explaining what the National Strategy for Trusted Identities in Cyberspace ( NSTIC ) is working on and presenting the white paper his team put together for that project. The minutes were taken carefully with the help of Martin Gaedke here 
>
>    http://www.w3.org/2011/08/01-webid-minutes.html
>
>This is helping us fill out our ISSUE-8 .
>
>   I myself like Francisco's idea of variable security: different use cases need different security technologies. It would be interesting to look at the use cases presented in his paper [1] and  see how much of that one could do in a RESTful manner with WebID.  This triggered me to think of the following cases:
>
>1. ISSUER WebIDs
>---------------- 
>
>I think all of the NSTIC technology relies on Issuers not remaining anonymous, so for them WebID is not a problem. Trusting issuers is just as big a problem for the current PKIX stack as identification of subjects. It is because there is no way to "follow one's nose" easily as far as Certificate Authorities goes, that all browsers are so much tied to the current ones, and that new ones such as banks, governments, age-certifiers, and so many more are having difficulty emerging on the scene. 
>
>   The semantic linked data web can help tremendously here. Each state could put together a list of accredited players in each of these areas: who can vouch for age, who for criminal records, who for someone being a bank. There is nothing new here. This is how we work. One can't just open a bank without consulting one's national government for example. These institutions will overlap in most countries, some countries will just point to the list in other countries leaving it to them to keep that information up to date locally - in a DNS like manner. These files would be on the Web in a linked data manner. The US government server would have a file perhaps reachable at <https://data.gov/banks> containing relations such as
>
><https://wellsfargo.com/about/#wf> a us:Bank .
><https://group.barclays.com/co#bk> a uk:Bank .
>
>...
>
>  Relying parties that would want to make financial transactions with keys signed by these banks would be able to find the current public key of those banks at their WebID location. Each country would have its own trusted list of links that its companies would use for reference to know which partners they can rely on for legal protection when dealing with them. Banks could then also easily change their keys in case of compromise.
>
>  Perhaps age verification agencies need not be directly specified by governments, but would be something that other institutions such as banks, drivers licences agencies, or others could provider. The trust of those agencies would depend on the trust one has in their relation to these other organisations. In other words, social network effects take place just as much at the Issuer level as they do at the Subject level. Working with the web at that level seems very feasible.
>
>2. Anonymous subjects
>---------------------
>
>   We already have anonymous subjects currently. When an agent connects to a web server using TLS he is currently anonymous (or would be if browsers such as Safari did not send certificates without asking). What is needed is a way for the server to be able to query the client in that session for information, which needs to be signed by some partner. Imagine that the Browser is a web server too. I have not looked into WebSockets, but that seems like the right space to look into. So what happens here? Well we should be able to work with relative URLs. Essentially the browser can say that his subject alternative name is  </person/#me>, without revealing his global name. This is the same as when someone comes into a shop and the shopkeeper greets the new person with hello, and the person says call me "George". Rather than: call me George who lives 1 rue de Rennes, Paris, France. They can have a friendly conversation by using first names, but it would not
 be enough (in a pre 1980ies world, where we don't have cameras everywhere) to identify the client when he has left the shop. So now the server has a session relative name. The server could do a sparkle query and ask for the age as signed by some of the Certificate Authorities as Identified by the Issuer Alternative Names given in 1 above. Or perhaps more simply this could be done in a RESTful manner, with the profile page </person/index.{rdf,html}> containing
>
>:me foaf:age g .
>g = { id2343 a us:Adult;
>         XXXXX
>    } signature [ by TrusticAge;
>                  tripleSig "sDFSFSDF..." ] .
>
>
>So what we are missing is that XXXXX - a way for the user to be able to be identified as being the subject id2343 without using the a key that is always the same, and which could therefore be used as an identifier. I suppose this is what some of the technologies discussed in that paper make available.
>
>The above shows I think how one can try to use as many existing web technologies as possible to move forwards. This would reduce friction and make it much more likely that things get adopted quickly.
>
>    Perhaps we can work on fleshing some of this out here.
>
>
>    Henry
>
>
>[1] http://pomcor.com/whitepapers/ProposedNSTICArchitecture.pdf
>
>Social Web Architect
>http://bblfish.net/
>
>
>
>
>