It looks like all three of these additional fields contain arbitrary data? Are there any reasons why these wouldn't be regular request parameters or defined by an actual protocol extension? Thinking on these more, they only appear to make sense if you control both the client and server implementations, at which point it's acceptable to do whatever additional logic you like (but you might want to codify that in an extension specification).

Without a specific use case it's hard to judge how this will be used, but extrapolating from the PR description, if what you want is a way to pass a webhook callback outside the scope of the specification, an extension seems to make more sense than having spec-defined fields which the host application can't use unless it's built-to-purpose for a specific use case (there's also a new Triggers and Events Working Group which should start to be a useful discussion platform for that particular topic once they're fully set up, but setting that aside).