Hi Noel, <br><br>I think it is a good idea not to store any PII. <br><br>Nickname can be gathered through SREG and then put into cookie (in encrypted form) so that <br>the server actually does not store anything, but can do it on the fly. <br>
<br>One point to note is NIST SP800-63, though. If you need to be at least Level 1, <br>you would have to wait for AuthN 2.1 where, hopefully, it will add RSA-SHA message signing. <br>Hopefully, you do not need to meet Level 1. <br>
<br>Regards, <br><br>=nat<br><br><div class="gmail_quote">On Thu, Jan 29, 2009 at 3:36 PM, Chris Messina <span dir="ltr"><<a href="mailto:chris.messina@gmail.com">chris.messina@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Glad to have your questions here, Noel.<div><br></div><div>You might appreciate the latest episode of theSocialWeb.tv where we actually discuss how the government might make use of the "Open Stack" and technologies like OpenID:</div>
<div><br></div><div><a href="http://tr.im/swtv_25" target="_blank">http://tr.im/swtv_25</a></div><div><br></div><div>As for your question -- I think it will be hard to provide a consistent, scalable or personalized service without holding some user information, at least in a cache. If you look at the restrictions that Facebook and MySpace put on sites that make use of their social identity services, they've had to relent on some of the requirements they had on third-parties not to store any user data for more than 24 hours because it was just too costly.</div>
<div><br></div><div>It certainly possible to consider keeping user data while the user is visiting the site and then destroy it when they leave -- gathering it afresh the next time the user signs in with their OpenID (presuming that their OP provides some kind of user data -- either via Attributes Exchange or SREG).</div>
<div><br></div><div>If you never referred to the user, you could actually use OpenID in a fairly anonymous way -- only using the OpenID to uniquely identify a particular identifier -- like servers do with IP addresses.</div>
<div><br></div><div>I guess it depends on your use case, but if you imagine that using an OpenID is kind of like using an email address for identification without the annoying inbox-based account verification, you can start to see how OpenID is much more convenient for generating new accounts.</div>
<div><br></div><div>Chris <div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Wed, Jan 28, 2009 at 1:29 PM, Dickover, Noel, CTR, NII/DoD-CIO <span dir="ltr"><<a href="mailto:Noel.Dickover.ctr@osd.mil" target="_blank">Noel.Dickover.ctr@osd.mil</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">UNCLASSIFIED<br>
<br>
Hi David, thanks for the response. I absolutely agree that if the<br>
government site is collecting personally identifiable information, they<br>
need to conduct a Privacy Impact Assessment, and take all the security<br>
precautions, and acquire all the necessary certifications and so forth<br>
with storing this information. Frankly, that whole process is a real<br>
bear to get through. And perhaps, for many types of interaction, the<br>
government shouldn't be collecting this information anyways.<br>
<br>
The goal I'm exploring would be to alleviate the need for the Federal<br>
Government to collect personally identifiable information at all<br>
(depending on the site of course). So instead of just allowing users to<br>
use an OpenID account to login to the government site as one of many<br>
options, I'm wondering if we restrict logins to OpenID accounts or<br>
others like it (leaving open the possibility for competition), can we<br>
alleviate the Federal Government the need of storing any personally<br>
identifiable information? If we can get to the point that there is no<br>
personally identifiable info in the govt app's database, than there<br>
won't be a privacy impact. If possible, this would result in huge cost<br>
and time savings in setting up collaboration sites with the public. For<br>
instance, in your wiki example below, if someone uses an OpenID account<br>
from Yahoo.com for instance, does your wiki database still store their<br>
personal information?<br>
<br>
Regarding the OpenID Attribute Exchange Extension, are there instances<br>
where sites using OpenID can display this information on the app's user<br>
profile page, or accordingly, restrict certain parts of that information<br>
based on user controls within their app?<br>
<br>
Thanks again for the response.<br>
<br>
<br>
Best,<br>
<font color="#888888"> Noel<br>
</font><div><div></div><div><br>
<br>
-----Original Message-----<br>
From: David Recordon [mailto:<a href="mailto:david@sixapart.com" target="_blank">david@sixapart.com</a>]<br>
Sent: Wednesday, January 28, 2009 2:38 PM<br>
To: Dickover, Noel, CTR, NII/DoD-CIO<br>
Cc: <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
Subject: Re: [OpenID] Applicability of OpenID to Federal Govt Social<br>
Software sites (U)<br>
<br>
Hi Noel,<br>
I definitely think you're on track here with the idea of allowing people<br>
to login to the site using an account they already have elsewhere via<br>
OpenID. The OpenID community uses a hosted wiki product<br>
(<a href="http://wiki.openid.net/" target="_blank">http://wiki.openid.net/</a>) where people are able to sign in using OpenID<br>
to edit the pages versus most traditional wikis which first require that<br>
you create a new account. This can be especially useful as people<br>
interact with more than one site within a community; for example, I can<br>
use the same OpenID to login to our wiki and blog/CMS.<br>
<br>
In terms of the legal aspects, my understanding is that if you're still<br>
collecting personally identifiable information you'll want to make sure<br>
that OpenID users still agree to your terms of service. That said,<br>
using the OpenID Attribute Exchange Extension allows you to<br>
programatically request information such as their name, timezone, or<br>
email address so that they don't need to type it in.<br>
<br>
In terms of current US Government implementations of OpenID the main one<br>
I'm aware of is that Change.gov supports OpenID sign in for commenting<br>
via the service Disqus. I was also out at the Smithsonian last week<br>
where I learned about a project there which will be accepting OpenID<br>
sign in as well.<br>
<br>
Cheers,<br>
--David<br>
<br>
On Jan 28, 2009, at 11:25 AM, Dickover, Noel, CTR, NII/DoD-CIO wrote:<br>
<br>
<br>
UNCLASSIFIED<br>
<br>
Greetings,<br>
<br>
I'm interested in knowing whether anyone has looked at using<br>
OpenID for Federal government-based social software sites. I'm currently<br>
working on implementing a wiki-based site for the US Department of<br>
Defense called DoD Techipedia. The external portion of this will allow<br>
interaction between government officials and industry representatives.<br>
In looking at the larger issue, many people working these issues in<br>
government are trying to work through the potential privacy impacts of<br>
keeping public data on a government website. It occurred to me that<br>
perhaps we should be looking at using something like OpenID for managing<br>
the external users to our systems.<br>
<br>
The hope would be that if users manage their own personal data<br>
through OpenID, the Federal Govt doesn't need to be responsible, or<br>
liable, for it. Am I on target here? If so, what would be necessary to<br>
make this happen? Or more to the point, has anyone already addressed<br>
this issue?<br>
<br>
<br>
Thanks in advance,<br>
<br>
Best,<br>
<br>
Noel Dickover<br>
DoD CIO, IT Investments and Commercial Policy Directorate<br>
Social Software and Emerging Technologies<br>
703-601-4729x152<br>
<a href="mailto:Noel.Dickover.ctr@osd.mil" target="_blank">Noel.Dickover.ctr@osd.mil</a><br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Web Advocate-at-Large<br><br><a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br>This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>