Thank you Andrew. Good information to me. ---- hdknr
2010/3/31 Andrew Arnott <[email protected]>: > 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 <[email protected]> > 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 <[email protected]>: >> >> 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 <[email protected]> >> >>> 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 >> >>>> [email protected] >> >>>> 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 >> >>> [email protected] >> >>> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> > _______________________________________________ >> > specs mailing list >> > [email protected] >> > http://lists.openid.net/mailman/listinfo/openid-specs >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
