[OpenID] My 2 Cents to the OpenID foundation
john.bradley at wingaa.com
Wed Apr 8 15:44:15 UTC 2009
My point is that a OP probably isn't going to pass a PCI audit to be
able to store credit card numbers, if they tell the auditor they are
going to give unauthenticated RPs peoples visa number + expirety date
+ EV Code + Name over an unencrypted channel.
They may be able to pass a PCI audit and be able to store cards to
perform some sort of payment processing like paypal, but that doesn't
involve disclosing the card numbers to RPs.
Yes you can use AX 1.0 as a part of an overall solution. Remember SSL
for the RP is not required or even enforceable in AX 1.0 and openID 2.0.
That raises an interesting point for openID 2.1, should the OP be
able to restrict the return_to URI to SSL only, in cases where it
wants to protect sensitive payload in the response, or is separate
encryption of the token with an audience restriction better using an
asymmetric proof-key better?
One thing openID needs to do is remember its use case.
Is expanding openID to cover financial and other high value
transactions the correct thing to do if it raises overall complexity
Once openID starts requiring XML DSIG and SAML token parsing, I think
it becomes a different animal.
The world already has Information-Cards and ID-WSF (SAML) in that space.
FYI over on the Concordia list Scott Cantor and I are discussing
combining information-cards and ID-WSF to create a web based card
Not quite a bridge from WS-Trust to ID-WSF but more a way to use the
ID-WSF redirect protocol to communicate WS-SecurityPolicy from the RP
and return a SML token to the RP while maintaining compatibility with
other WS-Federation actors.
Securely dealing with attribute information is not an easy thing.
Perhaps we can get further down the road in AX 2.0, but I also don't
want to give up the qualities of openID that differentiate it from
other SSO solutions.
On 8-Apr-09, at 7:54 AM, Peter Williams wrote:
> PCI does not addressing the security of the payment flow itself.
> It addresses the pre-conditions of security, through risk management
> practices. PCI is little more than BS7799 best practices, tuned up
> for credit card data, to which an enforcement regime has been
> Today, a browser user on a non PCI-controlled site applies SSL to
> access a web form at the old VeriSign payment gateway, now hosted/
> owned by paypal. Over that SSL channel PCI-controlled data flows
> between a PCI complying site, and the users home (which is typically
> not a controlled environment). There is no reason under PCI why an
> RP could not be an agent of that user, using AX over https to
> cooperate with OP fronting that very webform with an AX gateway at
> paypal. PCI doesn’t care, and doesn’t constrain protocols. As long
> as the RP site/system can pass its PCI audit, nothing in PCI
> criteria constrains the protocol selection – the particular audit
> firms may (probably because they only having methodologies for
> particular protocol suites, and wish to sell that).
> It is also unlikely that PCI rules are going to allow any OP to
> store credit cards numbers and make them available via AX.
> There is going to have to be something other than AX as it is now
> for authenticating financial transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general