[OpenID] Only 303, not temp redirects (302/307), need changing

[Manger, James H]

Noah said:
"also consider changing the rules for 302 and 307 redirects
which are both clearly temporary and should not be canonicalised."


NO.
These temporary redirects (302 and 307) provide a path
between what the user types into an RP and their claimed_id.
This path is chosen by the user. It is particularly important
for a well-defined, widely-used, security-critical use case:
* the user enters "example.net" at the RP;
* the RP changes this text to "http://example.net/" and does a GET;
* the website returns a 307 Temporary Redirect to "https://example.net/";
* the RP does another GET, secured with TLS, receiving the OP details;
The claimed_id is "https://example.net/".
This is an important feature. One benefit is allowing users to use
more secure (https) OpenIDs without having to type in longer strings.

This behaviour does NOT violate HTTP. It must not be changed.
A change would be appalling for backward compatibility as lots of
302/307s are used.

The claimed_id should change with these redirects -- as OpenID specifies.
An RP should think of these redirects as the user's choice of a path from
what they type to their claimed_id. The possibility of temporary redirects
(307 or 302) is a reminded to the RP that it must not use the user-entered
identifier as an index into its account database. It must wait until it has
a claimed_id to know which account the user is trying to login to.
A RP does not need to worry that a temporary redirect may change
in future. It may change, but that means the user has chosen to map that
user-entered identifier to a different OpenID (a different account
at the RP). The user can still access the original account by entering
the original claimed_id.

A 301 Moved Permanently is in the same boat as 302 & 307.
These three response codes all mean:
  "The request HAS NOT succeeded. Try it again at a new URI."
=> "This is NOT the claimed_id. Try this new URI."


A 303 See Other response has a different meaning to 301/302/307. It means:
  "The request HAS succeeded. Response data can be collected at a new URI."
=> "This is the claimed_id. Get the OP details from a new URI."
OpenID/XRDS/Yadis has its own version of 303 -- the X-XRDS-Location header.
A response with such a header means:
  "The request HAS succeeded (you have reached the claimed_id).
  The OP details (in an XRDS file) are available from a new URI."
The specification of X-XRDS-Location is quite clear that the claimed_id
is the URI that returned the X-XRDS-Location header, not the URI listed in
that header.
HTTP defines 303 See Other to have the same sort of semantics as
OpenID defines for X-XRDS-Location. OpenID should treat a 303 much like it
treats X-XRDS-Location: don't change the claimed_id to the new URI.

The similarity between 303 and X-XRDS-Location also highlights that there
are NO SECURITY PROBLEMS with treating 303 as per the HTTP spec since
the security implications are identical to X-XRDS-Location.


As for user intentions with respect to a temporary redirect (A to B),
I see two user perspectives. There will be users with each perspective.
1. "I want entering A to be a shortcut for logging in with identity B";
2. "I want A to be my identity, but the OP details are temporarily at B".
At the moment OpenID assumes #1.
At least Sam Ruby, Noah, Brendan and I want #2.
Properly supporting HTTP 303 would allow users to be explicit:
301/302/307 implies #1,
303 implies #2.


Please do not try to change 302/307 while fixing 303.