cachability of delegated identity URLs / Consumer-Server comms

[Ken Horn]

Hmm, I'm not sure I'm following this exactly but a couple of comments:

Certainly in the Java world, you would tend to avoid establishing a 
session prior to completing authentication. Partly it's due to the fact 
that existence of a session normally means you're logged in, and hence 
lots of code relies on that (and having a session without an associated 
identity is an error - redirect to login page etc). The other reason is 
that you don't want to squander resources prior to having legitimate 
users - DoS etc.

Also, if I'm reading the previous thread correctly (from Nathan), the 
interaction is currently,
1) UA => consumer
2) consumer => server (but not specific to an identity, to get an 
association)
3) server response --> consumer
4) consumer response --> UA
5) UA => server
6) server response --> UA (assuming the server can auto log in the user, 
i'm ignoring the server specific stuff)
7) UA => consumer
at which point (all being well), the user has logged in.

If this is correct, I'm again uncomfortable with the server having to 
create and store (in general) an association with the consumer (which it 
has no reason to trust at this point) prior to being requested by an 
authenticated (to the server) user. Maybe I've got the sequence mixed 
up, but I prefer the previous DSA flow (hmm, would be nice to have a 
name/number to talk about the different versions :).

If the flow above is correct, do we have a fallback if the secrets 
change prior to expiry (eg server crashes, loses them, we don't want to 
wait 4 hours before people can log in with new secret based tokens)? Say 
if the verify fails, then the consumer should re-request the 
association? Again, the DSA flow was more robust I think in this regard.

Can we change the old spec page to say it's out of date and the wiki is 
the new version of the spec?  Can the spec state what the difference is 
between a dumb consumer and a smart one is? Is it just that a dumb one 
won't do any caching? Not sure, I seem to be struggling to follow this 
now - and I've been reading every email for weeks. Maybe some example 
flows, including failures (invalid login, sig fails to verify, etc) 
would help.