Does identity management clash with privacy http://www.infoworld.com/reports/SRidmgmtandprivacy.html
Frequently it seems that it isn't an identity management issue, but confusing identification and authentication. One of the things in X9.59 was rather than trying to blanket the world with deep layers of encryption (in order to protect credit card numbers, which still had to appear in the clear because of numerous business process issues) was to convert the information from shared-secret (needing hiding, privacy, confidentiality and encryption) to a non-shared secret with authentication. In the existing process with non-authenticated transactions, just learning a credit card number is sufficient for somebody to generate a fraudulent transaction (effectively making the credit card number a shared-secret and classified as one of the identity theft items). x9.59 changes the transactions from non-authenticated to authenticated and eliminates the ability to use an (x9.59) account number in fraudulent transactions. Not being able to use the account number for fraudulent transactions eliminates it as being classified as shared-secret or target of identity theft. In the non-authenticatted paradigm, it was not possible to bury the earth under deep enough layer of encryption to really protect it, since it was required to be in the clear as part of so many business processes. Part of the issue is being able to strongly characterize and differentiate authentication from identification. Changing a paradigm from identification-basd to authentication-based goes much further to protecting individuals, aka extermely strong encryption for protecting shared-secret, sensitive, and confidential information may be good, but not having shared-secret, sensitive, and confidential information is even better. Electronic transactions tend to involve authentication and permissions (or authorizations). Permissions and authorizations may also be considered as class of sensitive and confidential information (say like printing the current credit limit). Good protocols might be considered to be some simple authenticated request or assertion with simple yes/no response. This was the paradigm followed in X9.59 protocol work as well in the FSTC FAST work (effectively a debit-like transactions but instead of making an assertion about payment that was approved or not, the FAST assertions were about other facts like age limit, local liqueur/gambling regulations, etc). In the FAST scenario, it wasn't necessary to divulge a person's birth date, it was sufficient to assert that they were over 21 (or 18) and validate the assertion. misc past authentication/identification threads: http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#58 PKI's not working http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy http://www.garlic.com/~lynn/aadsm10.htm#anonpay Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure) http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda) http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction? http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long) http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email? http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI http://www.garlic.com/~lynn/2001c.html#8 Server authentication http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards! http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure? http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure? http://www.garlic.com/~lynn/2002.html#39 Buffer overflow http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ? http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders? http://www.garlic.com/~lynn/2002g.html#66 Formal Classification for Security Topics http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal http://www.garlic.com/~lynn/2002m.html#53 Authentication of others is a privilege, not a right http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key http://www.garlic.com/~lynn/2003f.html#37 unix http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
