[OpenID] The "keep context" problem

[Martin Atkins]

Peter Williams wrote:
> The equivalent SAML spec REQUIRES a containing protocol to protect the
> integrity of values such as return_to - being "relying party state" that
> is an data asset worth interfering with when attacking the security
> properties of the webSSO protocol run.
> 
> So, the question was..does OpenID protocol have the required state
> management feature/requirements? - not: shall each RP programmer do its
> own funky thing when improving the standard OpenID in the area of
> webSSO-related state management?
> 

The return_to value is a member of the set of parameters that MUST be 
included in the signed set.

-------------------------------------------

== openid.signed ==

Value: Comma-separated list of signed fields.

Note: This entry consists of the fields without the "openid." prefix 
that the signature covers. This list MUST contain at least 
"op_endpoint", "return_to" "response_nonce" and "assoc_handle", and if 
present in the response, "claimed_id" and "identity". Additional keys 
MAY be signed as part of the message.

For example, 
"op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".

-------------------------------------------
     (OpenID Authentication 2.0 Implementors Draft 11, section 10.1)

RPs are expected to check that firstly the openid.return_to value 
presented is suitable -- that is, it really *does* point at that 
specific RP -- and secondly that the signature (which includes the 
return_to value) is valid.

-------------------------------------------

== Verifying Assertions ==

When the Relying Party receives a positive assertion, it MUST verify the 
following before accepting the assertion:

* The value of "openid.return_to" matches the URL of the current request
* Discovered information matches the information in the assertion
* An assertion has not yet been accepted from this OP with the same 
value for "openid.response_nonce"
* The signature on the assertion is valid and all fields that are 
required to be signed are signed

-------------------------------------------
     (OpenID Authentication 2.0 Implementors Draft 11, section 11)

The sections following the above go on to explain in detail how each of 
these steps is to be performed.

Does this satisfy your definition of "the required state management 
feature/requirements"?