Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

contextualize verifier policy (or something like that) #368

Closed
bc-pi opened this issue Nov 6, 2023 · 1 comment
Closed

contextualize verifier policy (or something like that) #368

bc-pi opened this issue Nov 6, 2023 · 1 comment

Comments

@bc-pi
Copy link
Collaborator

bc-pi commented Nov 6, 2023

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants