[OpenID] My 2 Cents to the OpenID foundation

John Bradley 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  
of implementation.
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.

John Bradley

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  
> attached.
> 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...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090408/50b88338/attachment.htm>

More information about the general mailing list