<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Peter,<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>One thing openID needs to do is remember its use case. </div><div><br></div><div>Is expanding openID to cover financial and other high value transactions the correct thing to do if it raises overall complexity of implementation.</div><div>Once openID starts requiring XML DSIG and SAML token parsing, I think it becomes a different animal. </div><div><br></div><div>The world already has Information-Cards and ID-WSF (SAML) in that space.</div><div><br></div><div>FYI over on the Concordia list Scott Cantor and I are discussing combining information-cards and ID-WSF to create a web based card selector.</div><div><a href="http://lists.projectconcordia.org/pipermail/community/">http://lists.projectconcordia.org/pipermail/community/</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards</div><div>John Bradley</div><div><br></div><div><br><div><div>On 8-Apr-09, at 7:54 AM, Peter Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">PCI does not addressing the security of the payment flow itself.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">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.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">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).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="border-top-style: none; border-right-style: none; border-bottom-style: none; border-width: initial; border-color: initial; border-left-style: solid; border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></b></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">It is also unlikely that PCI rules are going to allow any OP to store credit cards numbers and make them available via AX. <o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">There is going to have to be something other than AX as it is now for authenticating financial transactions.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div></div></div></span></blockquote></div><br></div></body></html>