...
If the client is concerned about HTTP parameter substitution of the ticket value after an end-user requesting party is redirected back after claims gathering, it can verify that the ticket initially sent to the authorization server is the same value that is subsequently returned by the authorization server. To verify that the ticket is the same in a stateless fashion, the client can send the ticket value in the state parameter, ideally in encrypted form, and then compare them on receiving the response from the authorization server.
...
| Anchor | ||||
|---|---|---|---|---|
|
TBS - Sec 3.4.1: discuss implications of this: "Once the authorization server adds the requested authorization data, it returns an HTTP 200 (OK) status code with a response body containing the RPT with which it associates the requested authorization data. If the client did not present an RPT in the request for authorization data, the authorization server creates and returns a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the requested authorization data, which MAY be either the RPT that was in the request or a new one. Note: It is entirely an implementation issue whether the returned RPT is the same one that appeared in the request or a new RPT, and it is also an implementation issue whether the AS chooses to invalidate or retain the validity of the original RPT or any authorization data that was previously added to that RPT; to assist in client interoperability and token caching expectations, it is RECOMMENDED that authorization servers document their practices."
...
| Anchor | ||||
|---|---|---|---|---|
|
...