Re: WebID, BrowserID and NSTIC

On 25 July 2011 22:50, Francisco Corella <fcorella@pomcor.com> wrote:
>> 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 is pretty interesting.  Am looking through it in more detail, thanks.

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

If you look at http://webid.info/ about 3 minutes 40 seconds into the
video there's some markup.

Tho I'm not sure how well KEYGEN works with IE.

There also is an HTML5 / javascript page that creates a certificate
here: https://webid.digitalbazaar.com/manage/

Libraries behind are open source

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

Received on Thursday, 28 July 2011 16:21:17 UTC