<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Allen,<div><br></div><div>Sending the artifact unencrypted in the indirect request and response allows an eavesdropper to intercept it in both directions.</div><div><br></div><div>If the artifact is not encrypted in the indirect channel then the OP must validate the direct request somehow.</div><div><br></div><div>The options for that are:</div><div>1. Mutual TLS</div><div>2. Direct request signed by the private key of the RP, the cert needs to be sent so the return_to can be validated. This would also use normal TLS.</div><div>3. Encrypt the entire response in the direct channel with the public key from RP discovery</div><div>4. The RP must sign the request with the shared association secret. The same association handle needs to be used for direct and indirect communications.</div><div><br></div><div>I need to think about 4 a bit but it may work.</div><div><br></div><div>John B.</div><div><div><div>On 20-Aug-09, at 1:18 PM, <a href="mailto:openid-specs-request@lists.openid.net">openid-specs-request@lists.openid.net</a> 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: medium; 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: 0px; "><span class="Apple-style-span" style="font-family: monospace; ">Date: Thu, 20 Aug 2009 11:16:23 -0700<br>From: Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>><br>Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1<br>To: "<a href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a>" <<a href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a>><br>Message-ID: <<a href="mailto:4A8D92F7.1000808@yahoo-inc.com">4A8D92F7.1000808@yahoo-inc.com</a>><br>Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br><br>In the interest of improving security, would it make sense to require<span class="Apple-converted-space"> </span><br>the RP to sign the request when exchanging the Artifact for the<span class="Apple-converted-space"> </span><br>response? If the request was signed, then even if the artifact was<span class="Apple-converted-space"> </span><br>easedropped, possession of the artifact by itself does not allow the<span class="Apple-converted-space"> </span><br>attacker to get the data.<br><br>Given that many RPs don't use HTTPS, it's very likely that Artifacts<span class="Apple-converted-space"> </span><br>will be passed around in the clear. Although requiring the RP to sign<span class="Apple-converted-space"> </span><br>the request when exchanging the artifact for the assertion would<span class="Apple-converted-space"> </span><br>increase the complexity, it might be worth it.<br><br>Allen<br><br><br></span></span></blockquote></div><br></div></body></html>