Thoryn

Policy rules · Policy rules

Multi-credential issuer requirement

ALLOW only if both a Diploma and a Tax ID credential are present, each from an authorised issuer. Use it for high-stakes onboarding (employer, regulated finance) where one credential isn't enough.

Tested against:policyEngine: 1.0.0

policy-engine recipe — shared category architecture: how this pattern composes with Hub, Broker, and the rest of the catalog

Use case

A new-hire onboarding flow needs the candidate to present both a diploma (from an accredited university) and a tax ID (from a tax authority). One credential isn't enough; both must be present and from an authorised issuer.

Rule

{
  "all": [
    {
      "fact": "diploma_issuer",
      "operator": "in",
      "value": ["TU Delft", "UvA", "VU Amsterdam"]
    },
    {
      "fact": "tax_id_issuer",
      "operator": "in",
      "value": ["NL-Belastingdienst", "DE-Bundeszentralamt-Steuern"]
    }
  ]
}

Facts shape

data class OnboardingFacts(
  val diploma_issuer: String,
  val tax_id_issuer: String,
)

The host service extracts these from the verified-claims object Broker delivers — typically by mapping per-credential iss claims into named facts.

Trace — ALLOW

{
  "decision": "ALLOW",
  "trace": [
    { "all": [
        { "fact": "diploma_issuer", "operator": "in", "value": ["TU Delft","UvA","VU Amsterdam"], "actual": "TU Delft", "result": "pass" },
        { "fact": "tax_id_issuer", "operator": "in", "value": ["NL-Belastingdienst","DE-Bundeszentralamt-Steuern"], "actual": "NL-Belastingdienst", "result": "pass" }
      ],
      "result": "pass"
    }
  ]
}

When to use

  • High-stakes onboarding requiring multiple authoritative credentials
  • Regulated flows where each credential type has its own issuer trust list

When not to use

  • You only need one credential — use a single-leaf rule
  • Issuer trust changes often — use Trust Registry as the source of truth instead of inlining issuer lists in the rule

See also

More policy rules