private association fro unsolicited positive assertions

nara hideki hdknr at ic-tact.co.jp
Thu Apr 1 06:42:53 UTC 2010


Thank you  Andrew. Good information to me.
----
hdknr

2010/3/31 Andrew Arnott <andrewarnott at gmail.com>:
> 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:
>
> The RP is an OpenID 1.1 RP, and thus not guaranteed to provide its own
> replay protection.
> The shared association is of a lower grade than that required by the OP
> (perhaps for this particular assertion).
> The shared association is very near expiration or has expired.
> 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
>
>


More information about the specs mailing list