private association fro unsolicited positive assertions

[Andrew Arnott]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100331/efe026e3/attachment.htm>