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. 

Received on Thursday, 12 April 2007 23:34:53 UTC