private association fro unsolicited positive assertions

David Fuelling sappenin at gmail.com
Sun Apr 11 14:08:58 UTC 2010


Wondering if it would make sense to integrate this info into the best
practices wiki page?  From my cursory glance I don't see most of Andrew's 4
points...not sure about the rest, but I don't mind helping to edit.

http://wiki.openid.net/OpenID-Security-Best-Practices

david

On Wed, Mar 31, 2010 at 9:39 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> 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:
>
>    1. The RP is an OpenID 1.1 RP, and thus not guaranteed to provide its
>    own replay protection.
>    2. The shared association is of a lower grade than that required by the
>    OP (perhaps for this particular assertion).
>    3. The shared association is very near expiration or has expired.
>    4. Unsolicited assertions (as has already been said on this thread).
>
> --
> Andrew Arnott
> "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
>
>
>
> On Wed, Mar 31, 2010 at 4:25 AM, John Bradley <john.bradley at wingaa.com>wrote:
>
>> We aren't saying that OP should always use private associations.
>>
>> If the RP provides an association handle the OP should use that
>> association.
>>
>> 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.
>>
>> John B.
>>
>>
>> On 2010-03-31, at 2:06 AM, nara hideki wrote:
>>
>> > Breno , John , thank you very much for you suggestion.
>> >
>> > If private associations are more secure and good for OPs, OPs should
>> > use private associations if they want to not only in the case of
>> > unsolicited assertions.
>> > Actually we can, I think. But OPs will have performance hits in turn.
>> >
>> > ----
>> > hdknr.com
>> >
>> > 2010/3/26 John Bradley <john.bradley at wingaa.com>:
>> >> 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.
>> >>
>> >> Unless some mechanism outside the spec is used the only thing a OP can
>> use is a private association.
>> >>
>> >> John B.
>> >> On 2010-03-26, at 5:02 AM, Breno de Medeiros wrote:
>> >>
>> >>> On Fri, Mar 26, 2010 at 08:04, nara hideki <hdknr at ic-tact.co.jp>
>> wrote:
>> >>>> Hi experts,
>> >>>>
>> >>>> I'm afraid that this question has been discussed ,but I can't found
>> that.
>> >>>>
>> >>>> "10.  Responding to Authentication Requests" of Auth 2.0 Final says:
>> >>>>
>> >>>>   OPs SHOULD use private associations for signing unsolicited
>> >>>> positive assertions.
>> >>>
>> >>> It could lead to less interoperability -- if the RP has revoked the
>> >>> key (e.g., because it suspects that the key has been compromised),
>> >>> then the RP would reject the assertion as an error (recognizing the
>> >>> revoked handle).
>> >>>
>> >>> A similar situation appears if the OP has a policy on key refresh rate
>> >>> that is longer than the RP's. That would cause the RP to revoke the
>> >>> key when the OP still believes it as valid.
>> >>>
>> >>> I think the current reading of the spec promotes interoperability with
>> >>> flexibility in key management, and that's good for security.
>> >>>
>> >>>>
>> >>>> I'd like to know the reason why "SHOULD is used rather than "MAY".
>> >>>> Is there any security threat if we don't use private associations
>> >>>>
>> >>>> Thanks in advance.
>> >>>>
>> >>>> -----
>> >>>> hdknr.com
>> >>>> _______________________________________________
>> >>>> specs mailing list
>> >>>> specs at lists.openid.net
>> >>>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> --Breno
>> >>>
>> >>> +1 (650) 214-1007 desk
>> >>> +1 (408) 212-0135 (Grand Central)
>> >>> MTV-41-3 : 383-A
>> >>> PST (GMT-8) / PDT(GMT-7)
>> >>> _______________________________________________
>> >>> specs mailing list
>> >>> specs at lists.openid.net
>> >>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >>
>> >>
>> > _______________________________________________
>> > specs mailing list
>> > specs at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100411/ce767229/attachment.htm>


More information about the specs mailing list