RE: Shared Public Knowledge

 
Depending on the user agent / web service being used, I think that both
sides of the authentication issue are important (client / server).
Strong server to user authentication ensures that the user agent is
connecting to the desired site and the connection has trust,
confidentiality and integrity. However, if anyone can authenticate to
the site or hack the site, user data stored on the site is subject to
compromise.  If we can't trust the data stored on the site, does it
matter that the server presents itself to the user as authentic? 
 
Bill 
 



________________________________

 From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
michael.mccormick@wellsfargo.com
 Sent: Thursday, April 12, 2007 7:35 PM
 To: Mary_Ellen_Zurko@notesdev.ibm.com
 Cc: public-wsc-wg@w3.org
 Subject: RE: Shared Public Knowledge
 
 
 Thanks for this clarification.  But my concern is if W3C
declares SPK based site-to-user authentication to be an anti pattern,
that certainly implies it should never be used in the other direction
either.

________________________________

 From: Mary Ellen Zurko
[mailto:Mary_Ellen_Zurko@notesdev.ibm.com] 
 Sent: Thursday, April 12, 2007 3:17 PM
 To: McCormick, Mike
 Cc: public-wsc-wg@w3.org
 Subject: Re: Shared Public Knowledge
 
 
 
 I would like to do a rewind on this thread. Everyone who
participated, go back to the proposed recommendation that we discussed:
http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge 
 
 It's about authenticating the server to the user (since that's
one of our primary goals). Not the user to the server. 
 
 So I will assume all discussion of the latter was interesting
and informative (it was for me), but not about the actual proposal
being discussed. Maybe that's because the proposal is about something
nobody does or wants to do. That would make it nice and safe for our
recommendations :-). 
 
           Mez
 
 Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l
333-6389)
 Lotus/WPLC Security Strategy and Patent Innovation Architect
 
 
 
 
<michael.mccormick@wellsfargo.com> 
Sent by: public-wsc-wg-request@w3.org 

04/11/2007 07:47 PM 

To
<public-wsc-wg@w3.org> 
cc
Subject
Shared Public Knowledge 

  




 I had to drop off the line for a few minutes at the top of the
hour during this morning's meeting.  Regrettably that moment came
during the Lightning Discussions just as Chuck Wade was responding to
MEZ's presentation on Shared Public Knowledge (SPK).  By the time I
rejoined to discussion had moved on to the next topic. 

 What I would have said given the opportunity is that Chuck is
100% right.  In our industry this battle has been fought many times and
I see little good coming from taking a hard line against all online use
of SPK. 

 Many US companies rely on services provided by the likes of
Choicepoint & Acxiom to perform Knowledge Based Authentication (KBA) or
Out of Wallet Authentication (OOWA) of consumers in certain situations,
especially in cases where no prior business relationship exists between
the FI and said consumer. 

 These KBA systems typically ask a series of randomly chosen
multiple choice questions designed to score a user's knowledge of
semi-private information about himself or herself.  Examples might
include "What model car do you drive"? or "What’s the amount of your
monthly mortgage payment?".  A determined criminal could undeniably
obtain this information from public sources, perhaps even use it to
impersonate others, but that doesn't mean there is no legitimate use
case for KBA. 

 A blanket prohibition against KBA is unnecessary and would
never be accepted.  Asking the user enough SPK based questions is not
an unreasonable authentication technique as long as the associated risk
is low, or when SPK is only being used to supplement some other
credential for extra assurance. 

 The much maligned Mother's Maiden Name is an example of weak
KBA … but much stronger ones are possible using the enormous databases
of personal data that are available from brokers today.  So I think the
SPK "anti-pattern" would benefit from being softened a bit to
acknowledge there's a place for it under certain conditions. 

 Thanks, Mike 

 Michael McCormick, CISSP 
 Lead Architect, Information Security Technology 
 Wells Fargo Bank 
 255 Second Avenue South 
 MAC N9301-01J 
 Minneapolis MN 55479 
 *      612-667-9227 (desk)             *       612-667-7037
(fax) 
 (       612-590-1437 (cell)             :-)
michael.mccormick@wellsfargo.com (AIM) 
 *       612-621-1318 (pager)            *
michael.mccormick@wellsfargo.com
<mailto:michael.mccormick@wellsfargo.com>  

 “THESE OPINIONS ARE STRICTLY MY OWN AND NOT NECESSARILY THOSE
OF WELLS FARGO" 
 This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to receive
this for the addressee, you must not use, copy, disclose, or take any
action based on this message or any information herein.  If you have
received this message in error, please advise the sender immediately by
reply e-mail and delete this message.  Thank you for your cooperation.