jricher
commented
1 year ago We discussed this as an option early on in the process, and the consensus at the time was that there could be multiple ways to start interaction but only one to finish. If there are multiple, is the client expected to be able to set up all of them? There is overhead and setup required on the client side for the finish methods -- listening to a URL for either a browser call or a direct push, saving a nonce value, etc. The security ramifications of the two methods defined in the core are very different, and who's to say what an extension would bring to the table. This gets really messy when the AS says "yes" to multiple finish methods -- which one should the client expect a response on? Is it now a race condition of whoever gets an answer first? What if the client gets an answer on more than one channel? This level of ambiguity and overhead was considered to lead to potential security issues with the client potentially setting up an endpoint that the AS will never use (because it's going to pick the other one), and thus opening itself to an injection attack of some kind via the open endpoint. In other words, the client's expecting something to happen, the AS says "no", but the attacker says "yes" and takes advantage of the opening to leverage an attack.
Additionally, if the client needs to pre-optimize the call to the AS it can do a discovery call first and get the interaction_finish_methods_supported list back. Otherwise, the client can do a PATCH on the grant or create a new grant to propose a different interaction package.
But even so, let's follow this suggestion: if we let the client send multiple methods, then the AS would need to pick exactly one (or zero) from the list and return it. The client would then need to only activate any "listening" on these endpoints once it gets back the positive response, which is the really case anyway with redirect/push because the AS could decide to return nothing in the finish section of the response. I do like how this fits the "offer a set of options and pick what works" transaction negotiation model that GNAP is engineered around, so that's a possibility. I'm not sure what this does for implementations though -- and what guidance, if any, does the AS need to pick the "right" response type?
This also brings up another old idea that was dropped -- sending multiple packages of interaction methods in a single request. This would be another way to solve the same problem, but with the larger effect of being able to send a bundle like "redirect in and redirect out OR user-code in and push out". This did not achieve support because of the much larger complexity: #59 (but could be an optional extension)
blue-ringed-octopus-guy
As defined in section 2.5.2. of the document, the client is only able to tell the AS that it supports one particular interaction finish method (even if the client supports multiple). So in terms of the interaction finish methods that are currently defined, the client must choose to either tell the AS that it supports either "redirect" or "push" (or omit sending this field if the client doesn't support any interactions).
Section 3.3.5. of the document explains that if the client has provided an interaction finish method then the AS can use this method, as along as: "
the AS supports this mode for the client instance's request".The issue I foresee here is that there might be scenarios where a client may support multiple interaction finish methods, but the client may end up sending a method to the AS that the AS doesn't support (or that the AS doesn't support for this particular request, for whatever reason). If this scenario occurs then the client must fallback to using polling to find out when the request has completed (unless the client has the ability to identify that this finish method isn't support for this request, and is able to send a PATCH request to change it). Polling might not be desirable for the client (or the AS) for a number of reasons, and it also results in the security issues highlighted in section 13.22. of the document.
If the client was able to pass multiple interaction finish methods to the AS, the AS could then select which specific method it wants to use, and could then tell the client which one it intends to use. This enhancement would increase interoperability between the client and the AS, and it would be less likely that a fallback to using polling would be required. At the moment there are only two specific interaction finish methods defined, but there could be more in the future - so this enhancement may be even more important in the future if there are more interaction finish methods to select between.
I do appreciate that making this change would introduce additional complexity to the protocol, but in this instance I think the extra complexity would be worth it as it would increase interoperability and it would increase security (by the reducing the need for polling to be required).