contextualize verifier policy (or something like that)

[bc-pi]

In this thread https://mailarchive.ietf.org/arch/msg/oauth/SVXj_3sqcRT5o6S-f6NOATtK-ro/ is a discussion with Neil Madden that ultimately I interpret as being about how static a verifier's acceptance/validation policy has to be (especially with respect to key binding) and that the current draft can be read as prohibiting things like migration to a stricter policy over time. IMHO we don't want to unintentionally prohibit that kind of thing but absolutely need to keep general principle/requirement that a verifier have a validation policy that isn't unduly/unexpectedly influenced by the (sometimes attacker-controllable) content of the token. I'm not sure how to reasonably convey that in the context of the draft as it is. And don't want to make large changes for this. So this issue is a placeholder to look at small refinements to current text that could be perceived as too limiting/strict. And/or maybe adding a short new considerations section about verifier policy that explains that a policy isn't necessarily completely static.

[danielfett]

After re-reading the current text, I think that the wording right now (with the previous improvements) sufficiently addresses the problem. We agreed to close this issue.