[OpenID] My 2 Cents to the OpenID foundation

Brian Kissel bkissel at janrain.com
Wed Apr 8 20:32:49 UTC 2009


JAL is passing credit card information to partner websites via OpenID with NRI's implementation of Nat's Trusted Data Exchange (TX) extension which is now being refined for the Commerce Exchange (CX) spec.

Nat, are there "PCI" requirements in Japan and how are they being addressed by JAL and other retailers in Japan?

Cheers,

Brian
==============
Brian Kissel
Cell: 503.866.4424
Fax: 503.296.5502


-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of John Bradley
Sent: Wednesday, April 08, 2009 12:30 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] My 2 Cents to the OpenID foundation

Peter,

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
issue.

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.
>
>



__________ Information from ESET NOD32 Antivirus, version of virus signature database 3994 (20090407) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 3994 (20090407) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




More information about the general mailing list