[OpenID] My 2 Cents to the OpenID foundation

John Bradley john.bradley at wingaa.com
Wed Apr 8 19:30:09 UTC 2009


I am not implying that openID cannot be used to access those PCI  
compliant sites.

I am only speculating that moving a visa number between sites with AX  
will need more that what AX 1.0 currently has to make the PCI auditors  
happy.   The case of authenticating a user to a PCI site is a separate  

Simply using HMAC-SHA256 associations will not solve all of the issues  
with conveying that sort of information across the Web.

John Bradley

On 8-Apr-09, at 12:11 PM, Peter Williams wrote:

> So, this is the crux of our openid adoption issue.
> So we manage a network of hundreds of websites operating offsite,  
> many of which take credit card data. All fall under the PCI umbrella  
> logically, but many do not -  actually. Some billion dollar order  
> payment gateways play games with the PCI rules and act as an  
> merchant aggregator (thus ensuring that the PCI rules only apply to  
> the gateway hub, not to the spokes). The PCI and transaction  
> acquiring world can actually deal with those _disclosed_ risks,  
> requiring only that https is used between the remote site/spoke and  
> the auditable hub (think RP and auditable OP). that is: https from  
> browser to RP storing sensitive data: https from RP to  OP  
> converying application instructions for said data; and then OP talks  
> to VISANet through various switches.
> But to the use case! either openid can or cannot be used to access  
> those n00 sites, which either store sensitive data or are messaging  
> proxies to an “OP” (which then stores the sensitive information  
> remotely).
> If openid cannot be trusted for this function (to pay a $1 bill by  
> visa at those n00 sites), there are only 2 choices:
> 1.       The same site ALSO offers websso by other protocol suites  
> (i.e. SAML2)
> 2.       The RP site retains its local identity management process.
> AS it standard today, we do both 1 and 2, somewhat undermining openid.
> We are getting into a conundrum. RPs must delegate all sensitive  
> attribute management/processing to OPs, but openid does not have  
> suitable design to work with RPs doing anything sensitive.
> Or as sun used to put it: openid is ONLY for that which doesn’t  
> matter to you if you were to lose it, tomorrow. And that includes  
> access to any site where you have to  pay a subscription (by CC).
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090408/a8cc2cd6/attachment-0002.bin>

More information about the general mailing list