Messages - Clarify the request_uri use

Request URI came from the early discussion among me, John and Breno. (Back then, the WG only had me, John, and Breno.-- long time ago!)

While it had much more documentation in early days, the current spec's documentation on requst_uri is very thin especially in Messages and most readers probably would not get what it was.

We should probably clarify what is the intended use.

For those who were not in the discussion back then, here are the requirements resulted in the needs of request_uri.

Request Object can become big. It may not be able to travel through the browser redirect. It also would cause usability problem (latency) on a mobile network. We need some way to address it.
Sometimes, you may want to authenticate the client at the client association phase. (Client registration phase)
Most claims request for a client would stay constant. There is not much point in being so dynamic as to request parameter. In fact, sometimes, IdP or Trustframework provider may want to examine the claims request before accepting it. (I think this is going to be the predominant requirement from the privacy protection and IdP liability limitation point of view. -- Apparent user consent action does not necessarily create a valid consent.)

To address those requirements, request_uri were created because of the following reasons:

For latency: just pass the reference to the request object - just like scopes in OAuth 2.0. (Note, there were no trace of OAuth 2.0 back then.)
Have the client create request files and place it in the SSL server under their control. At the association/registration time, the server can pull those and check the SSL certs to identify/authenticate the client.
Have the client register request file as above at the registration time. Have the hash of the file be in request URL so to make sure the integrity of the file. If needed, the request file may be signed by a third party, such as trust framework provider to make sure that the request complies with policies/rules/laws. The IdP MAY only allow the request_uri that was pre-registered. There is a propagation latency problems, but as long as the registration is not so dynamic as to allow the authorization request immediately after that, it should be fine.

We initially wanted everything captured in the request file, but to avoid CRSF etc., we at least had to have state (and/or nonce) outside the request file, which could have been included in the request object as that one is dynamic. Later, when we created id_token_hint, it became apparent that it has to be outside the request file because it cannot be determined at the registration time.

I do not think people understands this. Even I was almost forgetting it. It is probably worthwhile noting those in the sepc.

FYI, the above "signed request file by the trust framework provider' was tested in Jan-Mar. 2011 in a prototype system funded by the research grant from the Japanese government (METI) successfully. The model is very close to German eID AwswisApp system deployed in November 2010. The difference is that they use ASN.1 while we used early version of JWS.

(I can provide an overview of the system if you guys want. )

Comments (4)