Re: WebID, BrowserID and NSTIC

Peter,

Why would there be two camps?  Sometimes you need a trusted third
party, sometimes you don't.  Actually, the way I see it, there is a
range of trust models, different models being suitable for different
credentials in different use cases:

1. Trusted third party.  

Examples: 

(*) The Social Security Administration (SSA) asserts that you have a
social security number; you submit the SSA credential as you apply for
employment.

(*) An email service asserts that you have a certain email address
when you log in to a Web site, so that you don't have to go through
the process of verifying the address by clicking on a link in a
message that the site sends you.

2. Web of trust.

Example: Shared Web site for collaboration.  Accounts to access the
site are created for people known to the creator of the site, either
directly or indirectly through other people.  A user logs in with a
credential that asserts that her identity is a particular node in a
web of trust linking people known to the creator of the site.

This trust model is missing in our proposed NSTIC architecture and we
plan to add it when we revise the white paper.

3. Third party acting on behalf of the user.

Example: User uses a credential from a personal data site (see
http://personaldataecosystem.org/) to provide personal data to a
relying party, rather than entering the data after logging in to the
relying party.  The advantage of this is that the user maintains the
personal data in only one place, rather than at each relying party.

4. No third party involvement.

Example: most Web sites today, where the user registers with a
username and a password.

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


>________________________________
>From: Francisco Corella <fcorella@pomcor.com>
>To: Henry Story <henry.story@bblfish.net>; WebID XG <public-xg-webid@w3.org>
>Cc: Karen Lewison <kplewison@pomcor.com>
>Sent: Sunday, July 24, 2011 10:34 AM
>Subject: 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/
>>
>>
>>
>>
>>
>
>