W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

Re: WebID, BrowserID and NSTIC

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 25 Jul 2011 03:02:58 +0200
Message-ID: <CAKaEYh+5GWuSm_yXxv77uUUDDJYYfLp+-9xy=q9MuuhwHPN0fg@mail.gmail.com>
To: Francisco Corella <fcorella@pomcor.com>
Cc: Henry Story <henry.story@bblfish.net>, WebID XG <public-xg-webid@w3.org>, Karen Lewison <kplewison@pomcor.com>
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/
Received on Monday, 25 July 2011 01:03:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:46 UTC