There are some scenarios where OPs may intentionally use private associations even if the RP has a shared association it could use. A DotNetOpenAuth OP, for example, may use a private association instead of a shared one if any of the following are true:<br>
<ol><li>The RP is an OpenID 1.1 RP, and thus not guaranteed to provide its own replay protection. <br></li><li>The shared association is of a lower grade than that required by the OP (perhaps for this particular assertion).</li>
<li>The shared association is very near expiration or has expired.<br></li><li>Unsolicited assertions (as has already been said on this thread).<br></li></ol>--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Wed, Mar 31, 2010 at 4:25 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We aren't saying that OP should always use private associations.<br>
<br>
If the RP provides an association handle the OP should use that association.<br>
<br>
If the RP doesn't provide an association handle or the OP is generating a assertion without a request from the RP, the OP SHOULD use a private association. The only real exception to the SHOULD would be due to some out of band understanding between the OP and RP.<br>
<br>
John B.<br>
<div><div></div><div class="h5"><br>
<br>
On 2010-03-31, at 2:06 AM, nara hideki wrote:<br>
<br>
> Breno , John , thank you very much for you suggestion.<br>
><br>
> If private associations are more secure and good for OPs, OPs should<br>
> use private associations if they want to not only in the case of<br>
> unsolicited assertions.<br>
> Actually we can, I think. But OPs will have performance hits in turn.<br>
><br>
> ----<br>
> <a href="http://hdknr.com" target="_blank">hdknr.com</a><br>
><br>
> 2010/3/26 John Bradley <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>>:<br>
>> The other reason for Recommending private associations is that the OP need not keep track of what RP has been given a particular association handle. There is no verification of RP identity by the OP in the spec.<br>
>><br>
>> Unless some mechanism outside the spec is used the only thing a OP can use is a private association.<br>
>><br>
>> John B.<br>
>> On 2010-03-26, at 5:02 AM, Breno de Medeiros wrote:<br>
>><br>
>>> On Fri, Mar 26, 2010 at 08:04, nara hideki <<a href="mailto:hdknr@ic-tact.co.jp">hdknr@ic-tact.co.jp</a>> wrote:<br>
>>>> Hi experts,<br>
>>>><br>
>>>> I'm afraid that this question has been discussed ,but I can't found that.<br>
>>>><br>
>>>> "10. Responding to Authentication Requests" of Auth 2.0 Final says:<br>
>>>><br>
>>>> OPs SHOULD use private associations for signing unsolicited<br>
>>>> positive assertions.<br>
>>><br>
>>> It could lead to less interoperability -- if the RP has revoked the<br>
>>> key (e.g., because it suspects that the key has been compromised),<br>
>>> then the RP would reject the assertion as an error (recognizing the<br>
>>> revoked handle).<br>
>>><br>
>>> A similar situation appears if the OP has a policy on key refresh rate<br>
>>> that is longer than the RP's. That would cause the RP to revoke the<br>
>>> key when the OP still believes it as valid.<br>
>>><br>
>>> I think the current reading of the spec promotes interoperability with<br>
>>> flexibility in key management, and that's good for security.<br>
>>><br>
>>>><br>
>>>> I'd like to know the reason why "SHOULD is used rather than "MAY".<br>
>>>> Is there any security threat if we don't use private associations<br>
>>>><br>
>>>> Thanks in advance.<br>
>>>><br>
>>>> -----<br>
>>>> <a href="http://hdknr.com" target="_blank">hdknr.com</a><br>
>>>> _______________________________________________<br>
>>>> specs mailing list<br>
>>>> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> --Breno<br>
>>><br>
>>> +1 (650) 214-1007 desk<br>
>>> +1 (408) 212-0135 (Grand Central)<br>
>>> MTV-41-3 : 383-A<br>
>>> PST (GMT-8) / PDT(GMT-7)<br>
>>> _______________________________________________<br>
>>> specs mailing list<br>
>>> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
>><br>
>><br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</div></div></blockquote></div><br>