W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

RE: Shared Public Knowledge

From: Doyle, Bill <wdoyle@mitre.org>
Date: Fri, 13 Apr 2007 11:31:14 -0400
Message-ID: <518C60F36D5DBC489E91563736BA4B5801691A82@IMCSRV5.MITRE.ORG>
To: <michael.mccormick@wellsfargo.com>, <Mary_Ellen_Zurko@notesdev.ibm.com>
Cc: <public-wsc-wg@w3.org>
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? 


	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
	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


	From: Mary Ellen Zurko
	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:
	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 :-). 
	Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l
	Lotus/WPLC Security Strategy and Patent Innovation Architect
Sent by: public-wsc-wg-request@w3.org 

04/11/2007 07:47 PM 

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
	(       612-590-1437 (cell)             :-)
michael.mccormick@wellsfargo.com (AIM) 
	*       612-621-1318 (pager)            *

	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 Friday, 13 April 2007 15:31:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:44 UTC