Additional post-interaction protocols

[jricher]

§4.4 Post-Interaction Completion Editor's note:

There might be some other kind of push-based notification or callback that the client can use, or an out-of-band non-HTTP protocol. The AS would know about this if supported and used, but the guidance here should be written in such a way as to not be too restrictive in the next steps that it can take. Still, it's important that the AS not expect or even allow clients to poll if the client has stated it can take a callback of some form, otherwise that sets up a potential session fixation attack vector that the client is trying to and able to avoid. There has also been a call for post-interaction that doesn't tie into the security of the protocol, like redirecting to a static webpage hosted by the client's company. Would this fit here?

[jricher]

Editors suggest postponing, these can be addressed when concrete suggestions are made.

[yaronf]

I don't see value in the "Postponed" tag. How about replacing with a concrete version number, e.g. -04, or an IETF session, IETF-111. This way we'd have some future reminder to look at these issues.

Also, how can something be both "pending close" and "postponed" at the same time?

This is completely process of course, feel free to move to the mailing list.

[jricher]

@yaronf The editors discussed these tags and will send a message to the list about the process and details of what they mean. Sorry for the confusion in the meantime!

[aaronpk]

Here's a link to the mailing list thread about dropping the "Postponed" label https://mailarchive.ietf.org/arch/msg/txauth/1WsiIjlgCYqfgO3Wkk60SgOiAP4/