request_submitted ticket parameter should not be a MUST
mrpotes opened this issue · 5 comments
Consider that the submitted request that has been submitted to the RO may be in the form of an email, or even a postal letter - the AS may not want to send tickets to be polled for something for the next week while waiting for action to be taken in response. We suggest changing It MUST include a ticket parameter to It MAY include a ticket parameter if the AS supports polling for a reaction to the submitted request.
This might also be an area that an UMA extension could explore - how the RqP gets notified that the RO has approved the submitted request.
For example, if you consider Google Docs, you can make a request for document access, the RO is notified by email and there is no expectation that access will be granted imminently. Instead, Google sends the RqP an email later if/when access is granted.
I raised a similar point in #298.
I think, indeed, in the case where client’s request does not need to be tied to previous context, AS MAY not return a ticket and the client can start the process over approaching the RS again. In all other cases, AS MUST return a ticket for the client to eventually get an RPT.
Though, I feel RqP notification is out of scope of the document.
In discussion with James and other colleagues, we talked about how the use cases break down into two big use cases: synchronous and asynchronous. We could use wording such as "The authorization server SHOULD document its intended types of request submissions in order to manage client expectations."
I agree that RqP notification, as well as request submissions to the RO, are outside the scope of the spec.
Discussion in UMA telecon 2017-08-03:
Eve's suggestion in the issue thread was that there are two use cases: synchronous and asynchronous. But what does that mean? She meant that by the time the RO responds, it would be impossible to consider their response during the RqP's session. But the discussion from issue #298 is about how it's not a matter of time elapsed, but use cases where the RO's policy says "ask me every time", such that not issuing a ticket at all means that the AS would have "amnesia" when the client returns even after a very lengthy period of time. If it returns directly to the AS with the ticket after, say, several days, ticket in tow, even if all the other necessary claims have expired etc., there might then be a record of the RO having said "yes" and claims-gathering could proceed as required. If we decide to change from MUST return a ticket to MAY, then all the client can do when the AS doesn't return a ticket is obviously to start over at the RS. It turns into a terminal type of error from a continuance type of error. Ultimately, a MUST forces it to be one kind of error, while a MAY lets the error function for two different kinds of use cases. So we have two clear options (probably still adding that the AS should document its type of request submissions regardless?):
- Option 1: Keep the MUST, which is a terminal error.
- Option 2: Change to MAY, which splits into terminal and continuance errors.
I think I got the logic sort of wrong in my notes from that meeting. Providing a ticket allows for authorization process continuance and not providing a ticket means authorization process termination. Also, just because the AS produces a ticket doesn't mean the client is required to use it.
The combination of always providing a ticket and documenting request submission types to manage client expectations (along with perhaps having a messaging extension for hinting) could lead to a system where the client could optimize its polling at the AS vs requesting the resource very nicely.
For completeness's sake, note that decision was made in UMA telecon 2017-08-08.