<html><body bgcolor="#FFFFFF"><div><br><br>=nat @ Tokyo via iPhone</div><div><br>On 2010/04/30, at 0:17, John Bradley <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>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></blockquote><div><br></div>If the request was a pure authentication, you probably are right. However, if it were an e-commerce transaction, it would not be. <div><br></div><div>For example, it may be a purchase of a medication which may indicate certain desease. The OP may display that to the user for the consent of the payment etc. If the attacker can view that consent screen, it will be a release of sensitive information. <div><br></div><div><br><blockquote type="cite"><div><div><br></div><div>The best they can do is use it in a authentication attempt. </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 </div><div><br></div><div>eg <a href="https://myOP.com/server1/openID?HASH=RC5_HASH"><a href="https://myOP.com/server1/openID?HASH=RC5_HASH">https://myOP.com/server1/openID?HASH=RC5_HASH</a></a></div><div><br></div><div>That way I can use the URI for a database lookup if I have one server, 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, 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 <<a href="mailto:jbradley@mac.com"><a href="mailto:jbradley@mac.com">jbradley@mac.com</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>Is the randomness requirement different for the request? 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. <div><br></div><div>Under such circumstances, it may be wise to use a randomized reference to the request, IMHO. </div><div><br><blockquote type="cite"><div> <div><br></div><div>The only randomness requirement would be to prevent an attacker from guessing it. 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, </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 <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. </span><br><br>=nat @ Tokyo via iPhone</div><div><br>On 2010/04/28, at 23:25, John Bradley <<a href="mailto:jbradley@mac.com"></a><a href="mailto:jbradley@mac.com"><a href="mailto:jbradley@mac.com">jbradley@mac.com</a></a>> 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></div></blockquote></div></div></body></html>