[OpenID] RP Discovery

[Peter Williams]

> OpenID was not intended to be used for every request to a relying
> party that the user needs to remain authenticated against. There is
> too much protocol overhead (several requests) to do this for each
> request to the relying party.

(1) Is it clear yet whether an OP can just send an Auth response,
without waiting to be asked? 

We saw earlier some UK folk show Auth 2.0 language that - without even
over parsing - does suggest this mode is a design-intent, and one should
expect folks to implement support for it.

(2) Are OPs required to get a fresh copy of the RP's XRDS EACH TIME they
are about to send an Auth Response, or can the agent use a cached copy
and still be conforming?

(3) when we talk of https, is it legitimate to use NON_PKI SSL
ciphersuites?

One always has to be careful, whenever one uses SSL with general public
PKI. SSL exchanges handshakes (and certs) whenever the party in the
server role decides. This will normally cause the client to do an OCSP
ping, on a CA endpoint (e.g. ev-ocsp) This is a classical trap&trace
surveillance signal; telling the CA who is talking to who. It binds the
IP address of the consumer to the domain name of the server, along with
a timestamp. Some of the larger CAs (e.g. VeriSign) do have contracts
with the phone companies, enabling the carriers to meet their CALEA
obligations to the FBI to facilitate interception and trace&trace.

In analyzing any authentication protocol that is so design-dependent on
https (for dumb mode verification, for assuring DH associations) one
really has to include the SSL signals in the analysis, and then the
PKI-related signals that emanate from the use of SSL.

There is point whining about cardspace or openid
auditing/privacy/tracking features, if SSL is then leaving the barndoor
open.