<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Having the artifact for the artifact response be unguessable is important.<div><br></div><div>For the request, if an attacker guesses the artifact they can't learn any information.</div><div><br></div><div>The best they can do is use it in a authentication attempt.&nbsp;</div><div><br></div><div>Given that anyone can make a artifact request to the OP for anyone else and get the request artifact that seems like a bunch of work for something that at best could be a denial of service.</div><div><br></div><div>If I were a OP I would probably generate the request artifacts as URL&nbsp;</div><div><br></div><div>eg <a href="https://myOP.com/server1/openID?HASH=RC5_HASH">https://myOP.com/server1/openID?HASH=RC5_HASH</a></div><div><br></div><div>That way I can use the URI for a database lookup if I have one server, &nbsp;or store the request in a file at the URL in rpf format if I have a cluster.</div><div><br></div><div>Others with clusters may want to compress and encrypt the request into the artifact, &nbsp;I suspect normal losses compression won't be enough in some cases.</div><div>You could do something custom to compress it but that is still non deterministic.</div><div>Thats is why I would store the request by a hash.</div><div><br></div><div>With most OP's using directed identity, I am guessing you are probably only going to store one entry per RP in a lot of cases.</div><div><br></div><div>I think those choices are up to the OP to make.</div><div><br></div><div>I don't think that there is a real requirement in 7.5 for the artifact to be unique or random.</div><div><br></div><div>The most you can say is that it is an opaque reference to the original request less than 400 characters.</div><div><br></div><div>We need precise language in 7.6 saying one of openid.artifact | openid.rpfurl is required.</div><div><br></div><div>The terminology that we have used in the openID specs where we have multiple optional elements is not super clear if one from a set is required.</div><div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 2010-04-29, at 2:23 AM, Nat wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br></div><div><br>On 2010/04/29, at 0:48, John Bradley &lt;<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div>Is the randomness requirement different for the request? &nbsp; I think that we can safely assume that the request can be public.</div></blockquote><div><br></div>I am not so sure about it. For a static request, it is safe to assume that it is a public request. However, for a dynamic request, there are chances that's request contains personalized data, which may be revealed at the OP.&nbsp;<div><br></div><div>Under such circumstances, it may be wise to use a randomized reference to the request, IMHO. &nbsp;</div><div><br><blockquote type="cite"><div>&nbsp;<div><br></div><div>The only randomness requirement would be to prevent an attacker from guessing it. &nbsp; I think it would be better to only assume it is a reference to the request and may be used across multiple requests.</div><div><br></div><div>Why do you think there is a randomness requirement?</div><div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 2010-04-28, at 10:32 AM, Nat wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>John,&nbsp;</div><div><br></div><div>I am open to call request artifact as something else, but I do not think it is a good idea to combine the request artifact and&nbsp;<span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">rpfurl as the randomness requirement is very different.&nbsp;</span><br><br>=nat @ Tokyo via iPhone</div><div><br>On 2010/04/28, at 23:25, John Bradley &lt;<a href="mailto:jbradley@mac.com"></a><a href="mailto:jbradley@mac.com">jbradley@mac.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div><span>Nat,</span><br><span></span><br><span>One simplification to consider for 7.6 may be to combine artifact and rpfurl.</span><br><span></span><br><span>If the OP has returned artifact that could be:</span><br><span>Some internal refrence ID.</span><br><span>A URL pointing to some internal reference.</span><br><span>Some compressed version of the request.</span><br><span></span><br><span>If we think of the value as a reference to the request then the rpfurl is also a reference to the request.</span><br><span></span><br><span>The only difference is that one is defined by the OP and the other by the RP.</span><br><span></span><br><span>It may be confusing for people to have two things called artifact one for the request and one for the response.</span><br><span></span><br><span>The request could be renamed to something like request_refrence </span><br><span></span><br><span>Some people may prefer them separate to make validation easier.</span><br><span></span><br><span>It is not a big thing.</span><br><span></span><br><span>John B.</span></div></blockquote></div></blockquote></div><br></div></div></blockquote></div></div></blockquote></div><br></div></body></html>