[OpenID] My 2 Cents to the OpenID foundation

Peter Williams pwilliams at rapattoni.com
Thu Apr 9 11:22:32 UTC 2009


The interesting thing is

PCI doesn't care, whether you do the openid extension, use OAUTH, or use https server-server to address wire-time communications security. What most matters is the RP (like the OP) has a data center that does "everything else"...that PCI requires for a controlled environment. The wire protocol is usually the least of one's worries in PCI, seeing as https solves 99% of the wire time requirements for inter-node transfer.

Unless the key management of the implementation of the RP's openid protocol machine is properly using an HSM, it going to be hard to pass a competent PCI audit, whose key management requirements are essentially FIPS 140-1 level 2 (and almost 3).Obviously, using cleartext openid associations, delegating to  https's handshake essentially, helps a lot here - since openid now has much less asymmetric key management and key wrapping to worry about. Openid's keyed-mac and nonce's are really only protecting the openid auth handshake's own security controls (and its realm/audience control in particular), not the integrity of the attribute transfer (since the SSL record layer is doing that, anyways).

But isn't it interesting to see openid/websso be used in ways beyond address book exchange, in the giant social networking sites. There is so much more to openid potential, than that represented by the mega OPs.

> -----Original Message-----
> From: Nat Sakimura [mailto:sakimura at gmail.com]
> Sent: Thursday, April 09, 2009 4:13 AM
> To: Brian Kissel
> Cc: John Bradley; Peter Williams; general at openid.net
> Subject: Re: [OpenID] My 2 Cents to the OpenID foundation
>
> Many of them are aware of PCI requirements for sure.
>
> In JAL's implementation, data requesting party signs a contract
> proposal
> which includes his public key, and JAL counter signs on behalf of the
> user,
> and the resulting "contract" is stored by each party.
>
> Then, the actual data is encrypted by the requester's public key (which
> is in the contract) and sent through the wire, server to server.
>
> It actually is a lot like OAuth, with more structured token which dubbs
> as
> an audit trail as well. I think we can make a profile for OAuth as
> well.
> (It is being discussed casually in OpenID Japan as well.)
>
> You might think that it is "complicated" but it is not.
> In practice, it is quite simple to code, and more over, it is simpler
> to
> maintain as a service than dealing with patchworks of various
> security measures.
>
> =nat
>
> On Thu, Apr 9, 2009 at 5:32 AM, Brian Kissel <bkissel at janrain.com>
> wrote:
> > 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
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/



More information about the general mailing list