[OpenID] Backwards Compatibility
Peter Williams
pwilliams at rapattoni.com
Tue Mar 17 20:07:06 UTC 2009
Yes - like SSL session state.
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Martin Atkins
> Sent: Tuesday, March 17, 2009 1:00 PM
> To: general at openid.net
> Subject: Re: [OpenID] Backwards Compatibility
>
> SitG Admin wrote:
> >> If anything, I'd like to see things removed from 2.0, such as the DH
> >> key exchange.
> >
> > +1; but my thought is more that network-based key exchange should be
> > optional; if I want to make sure that the OP responding to my
> browser's
> > request is hosted at the servers my bank has, why should I need PKI
> when
> > I can call them up (or visit in person), take home their key, and
> trust
> > *that*? Mutual authentication using the U.S. Postal Service as a
> trusted
> > 3rd party (routing mail correctly, not substituting or altering
> letters)
> > is just one alternative; that there *are* many, and this is just an
> > example of what may suit some people, brings to mind XRI more than
> > anything else.
> >
>
> It sounds like you're asking for pre-configured associations, which
> while not explicitly allowed by the spec today seem like they would
> work
> with the protocol as it currently exists.
>
> The two co-operating parties would need to simply pre-seed their
> association "cache" with an association that never expires.
>
> The protocol already describes the behavior when there is already an
> association, so the protocol should not need to be modified at all.
>
> However, it wouldn't hurt to include a sentence in the new spec
> allowing
> parties to use "other means" (deliberately vague) to determine a shared
> secret.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list