CredentialBinding.match selects by scheme, host, method, and path only.CredentialAuth is a oneOf where one binding carries exactly one auth rendering.
If two different real credentials legitimately need to reach the same destination shape, there's currently no way to express that. Two bindings with an overlapping match fail closed as ambiguous (OSEP-0012 names this as an intentional simplification).
The problem is that "same destination shape" doesn't imply "same credential."
When adopting credential vault (and thanks for the implementation !), we've found at least two concrete cases that we can't solve in the current form of the vault:
- A single SaaS API exposes multiple logical environments/regions behind identical hostname and path where the differentiator is different API keys. A sandbox that needs access to both at the same time has only one binding slot but two real credentials to place in it.
- Two different clients in the same sandbox (say, an npm-compatible package manager and a Yarn-compatible one) both resolve packages from the same private registry host and path, but authenticate with different schemes - one sends a bearer token, the other sends Basic auth from a
user:pass pair. Both are legitimate and both hit the same scheme+host+method+path but only one binding can occupy that space.
In both cases, the fake placeholder value each client sends before injection could already be distinct - it's derived from whatever env var or config field that specific client reads. The credential match rule collides on destination host, but the requests themselves could be differentiated.
I suggest a narrow fix along those lines:
- Let
CredentialMatch optionally match on the content of a header the client already sends (e.g. an existing Authorization prefix or a specific already-known placeholder value), used only to disambiguate otherwise-overlapping bindings, not as a replacement for the existing scheme/host/method/path match.
_binding_matches/_select_binding in mitmscripts/system.py already have precedence handling for the ambiguous-match case; this would slot in as an additional, higher-precedence dimension rather than a re-architecture.
I haven't found this discussed in the OSEP-0012 review thread or in an existing issue - flagging this as a problem statement first, before writing anything resembling a design proposal.
I'm happy to draft an OSEP if that's the right next step, or if there's a simpler solution I'm missing, I'd be happy to try it out first.
CredentialBinding.matchselects by scheme, host, method, and path only.CredentialAuthis aoneOfwhere one binding carries exactly one auth rendering.If two different real credentials legitimately need to reach the same destination shape, there's currently no way to express that. Two bindings with an overlapping match fail closed as ambiguous (OSEP-0012 names this as an intentional simplification).
The problem is that "same destination shape" doesn't imply "same credential."
When adopting credential vault (and thanks for the implementation !), we've found at least two concrete cases that we can't solve in the current form of the vault:
user:passpair. Both are legitimate and both hit the samescheme+host+method+pathbut only one binding can occupy that space.In both cases, the fake placeholder value each client sends before injection could already be distinct - it's derived from whatever env var or config field that specific client reads. The credential match rule collides on destination host, but the requests themselves could be differentiated.
I suggest a narrow fix along those lines:
CredentialMatchoptionally match on the content of a header the client already sends (e.g. an existingAuthorizationprefix or a specific already-known placeholder value), used only to disambiguate otherwise-overlapping bindings, not as a replacement for the existing scheme/host/method/path match._binding_matches/_select_bindinginmitmscripts/system.pyalready have precedence handling for the ambiguous-match case; this would slot in as an additional, higher-precedence dimension rather than a re-architecture.I haven't found this discussed in the OSEP-0012 review thread or in an existing issue - flagging this as a problem statement first, before writing anything resembling a design proposal.
I'm happy to draft an OSEP if that's the right next step, or if there's a simpler solution I'm missing, I'd be happy to try it out first.