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

Re: Shared Public Knowledge

From: Bob Pinheiro <Bob.Pinheiro@FSTC.org>
Date: Wed, 11 Apr 2007 21:28:37 -0400
To: <michael.mccormick@wellsfargo.com>,<public-wsc-wg@w3.org>
Message-ID: <E1HboAV-00085v-1V@aji.w3.org>
I agree that knowledge-based authentication does 
have a legitimate role to play in identity 
authentication, but (IMHO) only for initially 
helping to establish someone's identity when no 
prior business relationship exists.   KBA should 
only be used infrequently, because the underlying 
assumption on which it is based is fundamentally 
flawed; namely that there is information about 
each of us that is "secret" and that would be 
difficult for an identity thief to 
obtain.  Although I would agree that this 
assumption may be true enough most of the time to 
make KBA useful in certain circumstances, the 
ChoicePoint breach (and others too numerous to 
mention) demonstrates how apparently common it is 
for this "secret" information to be leaked.

I think a better long term approach for identity 
authentication, especially when initially 
establishing one's identity with some entity for 
purposes of opening new accounts etc., might be 
to rely on a trusted third party Identity 
Provider to vouch for your identity in situations 
where you are initially unknown to the 
entity.  This is the idea on which Microsoft's 
CardSpace Managed Cards is based.  If Managed 
Cards were to become widely available from 
various IdPs, you presumably could go to an 
Identity Provider (possibly a bank or other FI) 
and rigorously establish your identity using KBA, 
paper documents, or whatever else is deemed to be 
sufficient.  The IdP would issue you a Managed 
Card, together with credentials for subsequent 
authentication when you desire to use the Managed 
Card to assert your identity to some relying 
party (provided the relying party entity where 
you need to establish your identity trusts the 
IdP).  So rather than having to verify your 
identity using KBA or knowledge of a SSN or 
whatever at each site where you are unknown, you 
establish your identity once at the IdP and then 
use Managed Cards from that point onward.

As an example of how this might be useful, 
consider the website annualcreditreport.com, 
where you can go (in the US) to get a free credit 
report each year from the three credit 
bureaus.  After asking for the usual identity 
information (name, birthdate, SSN, etc.), the 
site asks some knowledge-based questions.  In my 
experience, these seem to be mostly mortgage or 
credit card-related questions.  Imagine instead 
that you could choose some Managed Card to assert 
your identity to annualcreditreport.com.  You 
choose the appropriate Managed Card and then must 
authenticate yourself to the IdP, using some 
strong mutual authentication scheme.  The IdP 
then issues a token that you pass along to 
annualcreditreport.com, and that asserts your identity to the site.

There are issues with using third party IdPs in 
this way, namely liability issues and a viable 
business model, but in concept this is 
interesting.  Wells Fargo in particular is an IdP 
in the GSA's E-Authentication federation, but 
whether it could be a viable IdP for 
consumer-based CardSpace-type applications is (I assume) not yet established.

Bob Pinheiro

At 07:47 PM 4/11/2007, michael.mccormick@wellsfargo.com wrote:

>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 tthe 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)             7       612-667-7037 (fax)
>(       612-590-1437 
>(cell)             J       michael.mccormick@wellsfargo.com (AIM)
>2       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 Thursday, 12 April 2007 01:49:24 UTC

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