Re: WebID, BrowserID and NSTIC

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.

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.

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.

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

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.

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