Rubric v0
wif.tax grades how a product lets machines authenticate. The question for every product is the same: can I use this without holding a long-lived secret?
If the answer is no, the product is charging you a tax. You pay it in rotation toil, vault sprawl and, eventually, an incident.
Unit of assessment
One YAML file per product, not per vendor. AWS is two hundred products. Datadog is one product with a hundred integrations. When a vendor's products differ materially in auth, each gets its own file. "Our other API supports OIDC" does not defend the one that doesn't.
Each product is graded on two surfaces, and each surface gets its own letter. The product's headline grade is the lower of the two, because the weakest link is the one that leaks.
Tier gates, both surfaces. If the graded mechanism needs a paid or enterprise
tier, grade the mechanism anyway and record the tier in tier_gated. The
scoreboard shows the gate.
Inbound
How my workload authenticates to the product's API or control plane.
The product accepts a short-lived token from any OIDC issuer I configure. I can constrain trust by issuer, subject and audience. No long-lived secret exists anywhere in the path.
Federation works, but only from a fixed list of issuers the vendor chose, typically GitHub Actions, GitLab and the big three clouds. I cannot bring my own issuer.
The product issues short-lived tokens, but getting them requires a long-lived static secret. Examples are an OAuth2 client secret, a service account private key, or a static mTLS client cert with no federation. Better than raw keys, but still a secret to rotate.
Only long-lived keys are available, but the vendor passes at least 3 of the 5 hygiene checks below.
Long-lived keys, and fewer than 3 hygiene checks pass. The key you create today will work in 2031 unless someone remembers.
Outbound
How the product reaches into my infrastructure (cloud accounts, repos, other SaaS) on my behalf.
On AWS, a cross-account IAM role with external ID. On GCP, service account impersonation or federation. On Azure, a federated credential on a multi-tenant app. Or the product is itself an OIDC issuer I can trust. No long-lived secret is exchanged.
Keyless on at least one supported cloud, but at least one integration still wants a static key.
Access uses short-lived tokens, but setup requires me to hand over a long-lived secret, such as an OAuth refresh token minted from a client secret I manage.
The integration wants a static key, but the vendor documents least-privilege policy, supports scoped keys and explains rotation.
The integration wants a long-lived, broadly scoped credential and gives no least-privilege guidance.
Hygiene checks
These apply to any long-lived credential the product still issues. Each is a yes/no with a citation. They decide D versus F. Every card shows them, so a vendor stuck at D or F still has something to fix this quarter.
Evidence
Every grade and every hygiene check needs a receipt. That is a URL to vendor documentation or a vendor statement, plus the date it was checked. No receipt, no grade. A grade changes only when the receipts change. This rule keeps us factual, and it is exactly what the crawler produces.
checked_on must be within the last 12 months, or the card is flagged stale.
Login-walled documentation. If the docs that would settle a hygiene check are
behind a customer login, the check fails. No receipt, no pass. If those unverifiable
items could change the headline grade, the card also gets confidence: low with the
reason, and the site shows it. Vendors get credit by publishing the documentation.
Aembit also supports authentication to the Aembit API using a native authentication capability which utilizes OIDC (Open ID Connect tokens) ID Tokens.
Status
Graded and current.
Was D or F, now A or B, with the date. Vendors that fix it get a permanent gold star.
The vendor has contested the grade and we are re-checking. Shown with the vendor's statement.