-
assigned issue to
Registration - Add 'request_uris' to the Registration request
Issue #773
resolved
This was the intended use pattern of the request uris/ request files, but Registration spec. missed it out.
Add 'request_uris' which is an array of requst_uri to the Registration request.
Registration response returns the mapping like:
'request_refs':{
'https://client.example.com/request1.json':'server_generated_uri_1',
'https://client.example.com/request2.json':'server_generated_uri_2'
}
The value MUST be a URI(?). It can be the same as the input (key). Use the value as the request_uri.
The URI can be at the client or other places such as TFP or the server itself.
Request files can be signed by the TFP/trust aggregator.
IdP MUST accept the registered request_uri.
IdP MAY accept unregistered request_uri which would allow truly dynamic.
Comments (2)
-
-
- changed status to resolved
Fixed
#773- Added "request_uris" registration parameter to pre-register "request_uri" values.→ <<cset 661c6866c9d8>>
- Log in to comment
We will register an array of request_uris with fragments containing the hash value of the content. The fragments would not be sent with requests. There will be no server reply with separate identifiers.