Subject Re: The Most Important Attribute
From Chad La Joie <lajoie@xxxxxxxxx>
Date Wed, 06 Jul 2011 07:33:01 -0400

That all sounds fine with the exception that that's not how credit card
processing is done.

On 7/6/11 7:06 AM, David Chadwick wrote:
> 1. User consent is paramount. Not only does the user consent in
> releasing this attribute to the SP, but the user can withdraw his
> consent after the fact and can end up with the goods from the SP and the
> money still in his account.

Actually, user consent is non-existent.  That's one reason why credit
card theft is so very easy to pull off.  And the user can not simply
withdraw their agreement to pay a merchant.  There is a fairly lengthy
procedure, usually spanning months, for this that involves the user, the
credit card processing gateway, the issuing bank, and the merchant.

> 2. The user can self assert it. But the SP does not believe it. Instead
> the SP checks with the IDP to ensure that the attribute is valid and has
> not been revoked. So the SP gets a highly trusted assertion from the IDP
> about the validity of the attribute. The IDP may (with 3D secure) check
> user consent and user authn at the time of the transaction (though not
> in the US we are told).

The majority of checking occurs only at reconciliation time, which is
usually a nightly process.  In general, for most payment processing
networks, the only thing checked when you swipe the card is that it
wasn't revoked a couple days ago and your pin number if you're using a
system that supports that.  For online transactions there will usually
also be check that the postal code matches the one on file with the
bank.  The visa/mastercard network also experimented with full address
validation but this was found to be entirely too difficult and error
prone so they stopped.

It might also be worth noting that the "3D secure" protocol has already
been found to be riddled with holes.

> 3. There is no privacy protection. The attribute is globally unique,
> identifies the user uniquely, and the SP can track all the user's
> transactions, as can the IDP with all the SPs.

No, brick-and-mortar merchants will only record the date and the
authorization number returned by the payment processing gateway.  These
two pieces of data, along with the merchant code, are then used for any
subsequent update to a transaction (e.g., reversing a charging, adding a
tip on to a bill, etc.).  That combination is in fact opaque to you, the
merchant, and the payment gateway.  Only the issuing bank can link the
information together.

Web-based merchants work the same way but due to an irregularity of the
PCI rules that govern credit card transactions, they are allowed to keep
your credit card data if you let them.  However, there is still no way
to derive the authorization code for a transaction from the credit card
number.  So if the merchant doesn't write out a link between the two
somewhere (and they almost never do), it's still opaque.

In summary, almost *nothing* in real life works by the strictures people
are discussing putting in place here.  People who have a fiduciary
incentive to favor consent and LoA and all the extra stuff people try to
layer on top, without actually addressing the immediate needs, will
continue to do so.  Thankfully, as Rhys already pointed out, the rest of
the world can continue to go about their day getting stuff done.

And yes, I used to write credit card processing software and know enough
about it to thoroughly scare me any time I think about using getting a
credit card.

Chad La Joie
trusted identities, delivered