RE: WebID, BrowserID and NSTIC

One could adopt doctrines on governance and privacy.  However, were not the founding principles to have no "governance" (and not address privacy, until at least the password problem was actually solved)? Incidentally, at a recent conference of identity type folks, any and all uses of SSL were decried (as being 1995-class solutions, that "hold back" web identity). The message was drummed into the attendees repeatedly, influence opinion. THe very model of SSL and firewalls (that seperate https browsers from resource servers) was characterised as flawed. Certificates, CAC smartcards, and (offline) PKI in general was all generally denounced - in favor of online agents doing such as the OAUTH v2 protocol, pingbacks, between PCs, smart mobile devices and face-book style applications. Various allusions were made to VERY close coordination between UK, US, Canada, Australia over the transational-version of NSTIC, in coordination with "preferred vendors" - who are not authorized to release publicly what is going on. People feel VERY THREATENED by javascript-SSL (with ciphers implemented in javascript, and jusing HTTP as  the SSL record layer), though there are moves at the same time to open up the content security model in browser so (downloaded) javascript libraries in browsers can intercept the javascript processing pipeline. This should all allow a new generation of https, divorced from TCP. With luck, this should allow some of the connectionless versions of SSL to come more to the fore, leveraging group key management and multi-casting (over such as jabber transport channels).  > Date: Mon, 25 Jul 2011 03:02:58 +0200
> From: melvincarvalho@gmail.com
> To: fcorella@pomcor.com
> CC: henry.story@bblfish.net; public-xg-webid@w3.org; kplewison@pomcor.com
> Subject: Re: WebID, BrowserID and NSTIC
> 
> On 24 July 2011 19:34, Francisco Corella <fcorella@pomcor.com> wrote:
> > Henry,
> >
> > Thank you very much for introducing me to the WebID mailing list.  And
> > sorry for the delay in replying to your message --- I had to find out
> > more about WebID and do some thinking.
> 
> Hi Francisco & welcome! :)
> 
> >
> > You were asking what is going at NSTIC (the National Strategy for
> > Trusted Identities in Cyberspace) and how WebID could be used there.
> > Well, NSTIC is just getting started.  It was officially launched on
> > April 15, and there have been two workshops so far, on "governance"
> > and "privacy", which I attended.  A technical workshop will take place
> > in the bay area, I'm told, during the week of September 19.  I'm proud
> > that the Pomcor white paper that you referenced is the first technical
> > contribution to NSTIC, as far as I know.
> >
> > For more information on NSTIC I recommend looking at the official
> > NSTIC Web site, at http://www.nist.gov/nstic/.  The main document
> > there is the "Full NSTIC Strategy Document", at
> > http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf,
> > which unfortunately is rather verbose.  What I find most interesting
> > about NSTIC is the ambitious goals that it sets for building privacy
> > into identity technology.  I recommend reading the post by Howard
> > Schmidt to the White House blog, entitled "The National Strategy for
> > Trusted Identities in Cyberspace and Your Privacy", at
> > http://www.whitehouse.gov/blog/2011/04/26/national-strategy-trusted-identities-cyberspace-and-your-privacy.
> 
> Thanks for the pointers, a very interesting read.  I think some of the
> goals and use cases are excellent.  Perhaps the XG could adopt some of
> this as part of the design goals of WebID.
> 
> >
> > Third-party login protocols like OpenID and OAuth don't meet the
> > privacy goals of NSTIC because they require the identity provider to
> > know who the relying party is.  How about WebID?  A WebID is a
> > self-signed certificate, so at first glance there is no identity
> > provider.  But the relying party verifies the public key by fetching
> > the WebID profile document, so in a sense the server that hosts the
> > document plays the role of identity provider.  Does the server learn
> > who the relying party is?  It learns its IP address, which may or may
> > not be sufficient to identify it.
> >
> > I don't think the fact that the server learns the IP address of the
> > relying party is a big deal, but as I was writing this I realized that
> > it can be avoided.  Just like BrowserID has an option to submit to the
> > relying party a signed token so that the relying party doesn't have to
> > use webfinger to fetch the public key, WebID could have an option
> > where the server signs the WebID certificate; then the relying party
> > would not have to fetch the profile document.  Data from the profile
> > document could be included in the certificate, if that's useful to the
> > relying party.
> >
> > The signature would be computed using the same private key that is
> > associated with the TLS certificate of the server; i.e. the server
> > certificate would be dual-purpose, and the WebID certificate would
> > have a certificate chain including the TLS certificate chain.  Notice
> > that the trust model would not change.  It is equivalent to verify
> > that the user's public key is in the profile document by accessing the
> > server and fetching the document or by being told that this is so by
> > the server, through the server's signature on the WebID certificate.
> 
> This is a neat solution.
> 
> Although the first cut of the Protocol involves dereferencing the URI.
>  In practice, public keys are often cached.  Due to the nature of
> linked data the assertions made in a single page can be replicated in
> any number of trusted repositories, including a local store.  So it
> may be possible to go through a proxy.
> 
> A similar approach is taken in the perspectives project which performs
> monitoring of private keys http://perspectives-project.org/
> 
> >
> > The privacy goals of NSTIC include revealing as little information as
> > necessary to the relying party, and preventing relying parties that
> > share information from jointly tracking the user if at all possible.
> > WebID, if used as a general purpose identifier for the Web at large,
> > does not meet that goal.
> 
> This is a tricky problem.
> 
> It should be possible to issue a number of persona based on a given identity.
> 
> It is theoretically possible to assert belonging to a group, say the
> group of over 13 year olds, without revealing your exact ID.  It would
> be an interesting project to make a proof-of-concept of this kind of
> system.  Would need a little thought some kind of crypto solution such
> as hashing, blinding or zero knowledge proof may be appropriate here.
> Some work to be done here...
> 
> >
> > This not a theoretical issue, it is a very practical one.  If WebID
> > were used as a general purpose WebID, a malicious medical insurance
> > company in the US could set up a health information Web site with
> > discussion groups.  If a user signed up with a WebID and joined a
> > discussion group on cancer, the insurance company could later deny
> > insurance to the user on suspicion that the user had cancer or a
> > dependent who has cancer.  This issue can be avoided by using instead
> > a "login certificate" issued by the relying party itself, as we
> > propose in section 4.6 of our white paper.
> 
> Very good point.
> 
> If I've understood correctly 4.6 looks quite similar to what we do
> already using the <KEYGEN> tag.  In this case the IdP can create a
> certificate that points to their own site, in which case the public
> key lookup can be done internally.  Though I wonder how different this
> is from a cookie or HTML5 browser data storage?
> 
> The question then starts to become how can you easily manage the
> different certificates.
> 
> >
> > On the other hand I think WebID is very useful in use cases where the
> > relying party must know the user's identity within a social context.
> > One such use case, and a very broad one, is setting up a shared Web
> > site (or wiki) that should only be accessible to specific people.
> > Possible purposes of such a site range from collaboration in
> > scientific research to managing a little league team.
> 
> Very much so, access control is seen as something that is is very
> important for WebID to enable.  Particularly at the document level, as
> well as a site.  Tim Berners-Lee made reference to UNIX file system
> permissions, when he was making an analogy to WebID.  While it's not a
> 100% like-for-like, it could be an interesting part in the evolution
> of the Web.
> 
> >
> > 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: WebID XG <public-xg-webid@w3.org>
> > Sent: Wednesday, July 20, 2011 1:48 AM
> > Subject: WebID, BrowserID and NSTIC
> >
> > A very interesting article is up "BrowserID and NSTIC" http://bit.ly/oIKw1P
> > .
> > NSTIC stands for "National Strategy for Trusted Identities in Cyberspace"
> >
> > The article finally points us to the documentation of the BrowserId spec
> > "The verified e-mail protocol"
> >   https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest
> > which is nice. Weird how that link never seems to have appeared anywhere.
> >
> > And it points to a very interesting PDF that I have not had time to read in
> > full
> > detail "proposed NSTIC architecture".[1]
> >
> > I pointed out the relation between WebID and BrowserId on that blog post,
> > and perhaps we
> > will be able to have Francisco Corella talk to us a bit more about what is
> > going
> > on at NSTIC and how WebID could be used there.
> >
> >     Henry
> >
> >
> > [1] http://pomcor.com/whitepapers/ProposedNSTICArchitecture.pdf
> >
> > Social Web Architect
> > http://bblfish.net/
> >
> >
> >
> >
> >
>