[Wg-p3] Prep For Privacy Workshop in Washington DC - August 10

Bob Pinheiro kantara at bobpinheiro.com
Tue Aug 4 21:23:04 PDT 2009

I believe that one of the motivators behind these eGov efforts was the 
desire to make government services more available to ordinary citizens.  
For instance, this could include allowing citizens to access the Social 
Security Administration's website (in the US) for the purpose of 
changing beneficiary information, or a mailing address.   In my view, 
there is a privacy issue if an imposter or other unauthorized individual 
is somehow able to access these applications due to any type of security 
failure.  Similar privacy issues can arise in other non-eGov 
applications as well.  For instance, there is a big push (in the US) to 
create electronic medical records.  A privacy issue exists if someone is 
able to gain unauthorized access to someone else's electronic health 

One type of  "security failure" that could lead to these privacy 
problems is the failure of policy makers to require adequate 
authentication for access to these applications.  Of course, it's open 
to debate as to what type of authentication should be required for 
accessing these eGov and health applications.  Such debates would likely 
involve some value judgements to be made about the degree of harm that 
would come to an individual if someone could break into his/her SSA 
account and change a mailing address or beneficiary.  Or if someone else 
could access their online health records.

At least as far as I can tell, the types of eGov applications that might 
involve individual citizens or consumers, as well as those involving 
consumer online health records such as Google Health and Microsoft's 
HealthVault, currently require only a static password for access.  So 
according to NIST 800-63 as well as the Trust Framework Provider 
Adoption Process document, these are essentially Assurance Level 2 
applications.  OMB-0404 defines the types of risks associated with the 
four Assurance Levels.  At AL-2, there is only a "low" risk of harm due 
to unauthorized release of sensitive personal information, whereas at 
AL-3 the risk of harm is deemed to be "moderate."

It shouldn't be very hard to argue that unauthorized access to eGov 
applications such as Social Security, or access to online health 
records,  may incur at least a "moderate" risk of harm to individuals. 
So I'd propose that authentication for these applications ought to be 
AL-3.  However, I suspect that the people who setup these eGov and 
online health databases didn't decide to choose password-only 
authentication because they first decided that there was only a "low" 
risk of harm to individuals.  The more likely reason is that there 
really is no alternative today for authentication of the 
masses.......people just don't have personal certificates or one-time 
password tokens, so the default is to use passwords.

Now everyone knows that using only passwords for protecting sensitive 
online resources and personal information is just not a good idea.  Even 
if you aren't tricked by a phishing email, there's always malware, 
social engineering, and brute force methods to get at these passwords.  
So now we have these new technologies and protocols such as SAML, 
OpenID, and Information Cards.  Will using these help to increase 
security and reduce privacy risks?  People speak of "SAML-based 
authentication", but SAML is just a way to secure the movement of 
identity information across boundaries, from an identity provider to a 
relying party.  You could use only passwords for authentication at an 
identity provider, and still use SAML for identity assertions to the 
relying party.  So whether we are talking about SAML, OpenID, or 
Information Cards, there still needs to be an authentication mechanism 
that's stronger than using just passwords.  Some OpenID providers allow 
authentication via one-time passwords or browser certificates, but most 
just rely on passwords.  The Information Card protocols allow several 
ways for a user/consumer to authenticate to the identity provider, 
including PKI certificates.  But still, Information Card deployments 
still seem to rely on only passwords for this authentication step. This 
seems especially dangerous when Information Cards reside in cloud-based 
selectors, since anyone who can successfully authenticate to the 
selector can then use the Information Card.  

Since this WG is concerned not only with privacy but with public policy, 
I'd propose that Kantara (by means of this WG as well as the Consumer 
Identity WG) at least consider taking the following stands:

    * That online eGov applications used by consumers, and other
      applications that involve sensitive personal information accessed
      by consumers (such as online health records), move away from
      authentication based on passwords only, and adopt stronger
      authentication methods.  Since the Assurance Level is dependent on
      the potential harm that might befall consumers who can be
      successfully impersonated online by a fraudster, it may first be
      necessary to make some statements concerning these levels of risk
      for various kinds of consumer eGov and other applications.   [Of
      course, Asssurance Level is also determined by other things such
      as how identity proofing is done, etc, but these are a bit removed
      from the point I'm trying to make.....that weak authentication is
      not good enough for protecting sensitive consumer eGov, health,
      and other apps....and that weak authentication leads to privacy

    * That new identity management schemes such as OpenID and
      Information Cards adopt stronger authentication mechanisms such as
      X.509 certificates or one-time passwords for authentication of the
      consumer to the identity provider, instead of basing this
      authentication on passwords only.


Bob Pinheiro
Chair, Consumer Identity WG
kantara at bobpinheiro.com

Brett McDowell wrote:
> I believe you should all also be subscribed to the community@ list, so 
> apology for the forward.  But I thought this WG might want to 
> deep-dive a bit more than the community@ list will so kicking off a 
> fresh thread.
> If you look closely at this agenda you'll see I'm on it.  I'd like to 
> as the P3WG for advice for how to position the privacy issues as they 
> relate to the Open Government topic, especially (but not exclusively) 
> in the US.  The context for this event is the US Government evaluating 
> the acceptance of more identity protocols to expand the user-base of 
> eGov applications.  The US Government has been accepting X.509 PKI for 
> awhile now, and SAML 2.0.  Now they are looking on OpenID and 
> Information Cards technology.  There are issues in the background 
> about how does any "credential provider/identity provider" prove they 
> meet the Level of Assurance requirements of the US Government, but 
> that's not the focus of Monday's event.  Monday's event seems to be 
> more focused on the privacy impact of these new technologies (and I 
> think pure PKI and SAML might get re-visited as well).
> With that... anyone have any comments or suggestions as I prepare my 
> notes for the workshop?
> Thanks in advance!
> Brett McDowell  |  +1.413.652.1248  |  http://KantaraInitiative.org
> Begin forwarded message:
>> *From: *"J. Trent Adams" <jtrentadams at gmail.com 
>> <mailto:jtrentadams at gmail.com>>
>> *Date: *August 4, 2009 7:14:04 AM EDT
>> *To: *community at kantarainitiative.org 
>> <mailto:community at kantarainitiative.org>
>> *Subject: **[Community] Privacy Workshop in Washington DC - August 10*
>> All -
>> In case you're interested in what the OpenID and InfoCard crew have been
>> up to for the past few months, now's your chance to find out.  Check out
>> the Privacy Workshop in Washington DC on August 10th.
>> http://www.idmanagement.gov/drilldown.cfm?action=privacy_workshop
>> The meeting will present the work that's been done so far, and solicit
>> questions and comments from the wider community.  Remember to register
>> as space is limited.
>> - Trent
>> -----
>> Open Government Identity Management Solutions Privacy Workshop, August
>> 10, 2009
>> Location of the Workshop: The American Institute of Architects (AIA)
>> Building, The AIA Boardroom, 1735 New York Avenue, NW, Washington, DC 
>> 20006
>> Agenda:
>> 8:00 am Registration & check-in
>> 9:00 am Welcome & Overview of the Initiative
>>    Judith Spencer Co-Chair ICAMSC
>> 9:15 am White House Vision
>>    Vivek Kundra, Federal CIO
>> 9:45 am Technical Approach
>>    Chris Louden, Protiviti Government Services
>> 10:30 am Break
>> 10:45 am Open Trust Frameworks for Open Government
>>    Don Thibeau (OpenID),
>>    Drummond Reed (InfoCard),
>>    Bob Morgan (InCommon),
>>    Brett McDowell (Kantara)
>> 11:30 am Panel discussion - benefits of initiative
>>    Representatives of OpenID,
>>    InfoCard,
>>    InCommon,
>>    Kantara Initiative
>> 12:30 pm Lunch (on own)
>> 1:30 pm Federal Privacy Considerations
>>    CIO Privacy Committee Chair/designee
>> 2:00 pm Panel discussion/question & answer session
>>    Privacy protections of the schemes;
>>    representatives from OpenID,
>>    InfoCard,
>>    Kantara Initiative,
>>    InCommon,
>>    & Federal Government
>> 3:15 pm Wrap-up - where to go for more information
>>    Judith Spencer
>> -----
>> -- 
>> J. Trent Adams
>> =jtrentadams
>> Profile: http://www.mediaslate.org/jtrentadams/
>> LinkedIN: http://www.linkedin.com/in/jtrentadams
>> Twitter: http://twitter.com/jtrentadams
>> _______________________________________________
>> Community mailing list
>> Community at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/community_kantarainitiative.org
> ------------------------------------------------------------------------
> _______________________________________________
> Wg-p3 mailing list
> Wg-p3 at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-p3_kantarainitiative.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-p3_kantarainitiative.org/attachments/20090805/a764db05/attachment-0001.html>

More information about the Wg-p3 mailing list