Quote from: gmaxwell on October 22, 2013, 03:40:34 PM

Quote from: Carlton Banks on October 22, 2013, 02:58:31 PM

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

Well, you in fact addressed a different concern, one that I do not share. The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.

I will be agonisingly clear. The recipient of a payments request has no way of knowing that a request will be initiated, unless they analyse the code behind every event triggering piece of interface on every payments form on every website they use, every time they use it. The website can choose various ways of utilising the Payments Protocol, for instance using the CA or self-signing. This is all a consequence of the directionality of the request itself. Logically, it can only ever come from the requester. Payee will never request payment from themselves using the Payments Protocol.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.

Quote from: gmaxwell on October 22, 2013, 03:40:34 PM

Quote from: Carlton Banks on October 22, 2013, 02:58:31 PM

Quote from: gmaxwell on October 22, 2013, 02:16:24 PM

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

I have no comment on the "qualitative security" of the channel.

Your own text (bolded) does not constitute such a comment?