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! :)
>

Thank you!

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

I wasn't familiar the Perspectives project.  At first glance it looks
like a very good idea.

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

As I said in my previous message to Nathan, multiple pseudonyms or
personae mitigate the problem but do not completely solve it.

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

An Idemix anonymous credential that includes a birthdate attribute
allows you to prove to a relying party that you are over 13 without
revealing your actual date of birth.  See Section 6.2.5 of
http://www.zurich.ibm.com/~pbi/identityMixer_gettingStarted/ProtocolSpecification_2-3-2.pdf.
Being able to do this is a goal of NSTIC according the same post by Howard
Schmidt that I referenced in a previous message.  You can find it at
http://www.whitehouse.gov/blog/2011/04/26/national-strategy-trusted-identities-cyberspace-and-your-privacy.

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

Could you send a link to a description of what you do with the
<KEYGEN> tag?

> Though I wonder how different this
> is from a cookie or HTML5 browser data storage?

It's functionally equivalent to a cookie or HTML5 browser data storage
(or Flash data storage), but more secure.  A cookie is a shared
secret, you have to send it to the relying party.  If you send it over
a TLS connection and nothing goes wrong, that's OK.  But if something
goes wrong due, e.g., to a vulnerability, and an attacker gets the
cookie, then the attacker can impersonate.  By contrast, the private
key associated with a certificate stays in the browser.  Sure, the
browser could be compromised, but that's less likely.  Another way to
put it: the attack surface against a cookie includes browser, server,
and transmission, whereas the attack surface against a private key
includes the browser only.

> The question then starts to become how can you easily manage the
> different certificates.

In our white paper we propose an HTTP extension that allows the
relying party to ask for the credentials it needs.  Then the browser,
if it has them, submits them using a proposed "client-initiated
exchange" within TLS, after asking the user for permission.

> >
> > 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: Melvin Carvalho <melvincarvalho@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>
>Sent: Sunday, July 24, 2011 6:02 PM
>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/
>>
>>
>>
>>
>>
>
>
>
>