Since a subset of the WG (Just, Robert, and me) kept going for about 30 minutes after Thursday's call ended, I said I'd pull out this part of the notes to highlight it for everyone and ensure you have a real chance to think about it.

This was a really fascinating discussion. Our conclusion was that the redirect-back from the claims interaction endpoint, rather than try to duplicate the token (was RPT) endpoint status messages as it had kind of been doing, should sync up directly with what OAuth does instead. The basic thing it needs to achieve (as far as the client actually cares) is "yes, continue, everything went fine" or "something went wrong".

If you don't agree, shout now! (I'm going to try and implement this in the next editors' draft so you can see what you think...)

====

#298 (Reconsider whether ticket should be on all redirect-back AS responses):

We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end?

(The formal meeting ended and we kept going ad hoc.)

Redirect-back: Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop.

Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response.

Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference).

Token request: Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process.

Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used.

• invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change)
• invalid_scope: no
• request_submitted: yes (a change)
• need_info: 
• not_authorized: remove (a change)

AI: Eve: Send separate note to the WG proposing this and asking for feedback.