[OpenID] My 2 Cents to the OpenID foundation
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
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.
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
> 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...
Size: 2486 bytes
Desc: not available
More information about the general