The claim which meant three things
One directory group. Three applications. Three different grants. The group was called engineering-leads. It was asserted as a claim by the identity provider (IdP) in every federated token issued to a member.
The first application — the one whose access requirements were reviewed when the group was created — treated it as read access to a project dashboard. The second application, added to the federation two years later, treated it as approval authority over change requests. The third, onboarded after an acquisition, treated it as administrative rights to a production configuration store. Nobody forged a token. Nobody misconfigured the IdP. The assertion was valid at every step.
Authentication centralizes, the authorization premise distributes, and no system holds both ends of that relationship by default. The IdP knows that a principal is a member of engineering-leads. The relying parties each know what they grant on that membership. Neither knows what the other knows. The claim is correct. The consequences differ by application — and the gap between them is not recorded anywhere.
This is not an argument about protocol weakness. Security Assertion Markup Language (SAML) assertions and OpenID Connect (OIDC) tokens carry claims the IdP signs, and nothing here requires breaking that signature. The argument is structural: the meaning of a claim is determined at consumption, not at issuance, and in most federation deployments the consuming interpretations are not a recorded artifact.
What an assertion establishes
NIST SP 800-63 defines assurance levels across three distinct dimensions — identity proofing, authentication, and federation, treating each as a separate question with its own evidence standard. (Source: NIST SP 800-63 Digital Identity Guidelines, https://csrc.nist.gov/pubs/sp/800/63/3/final).
This separation matters here. A federation assertion at a given assurance level tells a relying party that the IdP has confidence in the binding between a credential and an identity. It says nothing about what that identity should be allowed to do.
SP 800-63B goes further in the authentication dimension, defining authenticator assurance as confidence in a claimant's control of an authenticator — confidence, in other words, in who is present (Source: NIST SP 800-63B-4, https://csrc.nist.gov/pubs/sp/800/63/b/4/final). It does not address what the relying party should conclude about entitlement. This determination is entirely local to the service provider (SP).
The practical consequence: a claim arriving in a token is an authenticated statement about group membership, role assignment, or attribute value. It is not a policy decision. The relying party's interpretation of that claim — what permission it triggers, at what scope, in what context — is made at the SP, stored in the SP's configuration, and changed at the SP without notifying the IdP or any co-consumer of the same claim. The assurance chain covers the identity assertion; it does not extend to the authorization interpretation.
What the relying party does with it
This is where the structural argument lives. The IdP issues a claim. The relying party receives it and maps it to a local permission. That mapping is the authorization decision, and it exists only in the SP's configuration — not in the identity directory, not in the token, not in any shared policy store unless the organization has explicitly built one.
Three consequences follow from this that practitioners encounter in operations.
First, co-consumers of the same claim operate on independent authorization premises. When engineering-leads grants read access in Application A and approval authority in Application B, neither application knows the other's interpretation. A change to group membership — adding a contractor for Application A's read access — simultaneously extends approval authority in Application B. The IdP behaves correctly throughout. The error is not in the assertion; it is in the absence of a shared understanding of what the assertion authorizes.
Second, membership criteria review does not propagate across consumers. Groups are typically reviewed against the requirements of the application that motivated their creation. Subsequent consumers inherit the membership without inheriting the review obligation. In environments where groups are reused across applications for operational convenience — a common pattern — this creates a gap where membership criteria and consumer permissions diverge over time.
Third, some identity platforms can report which applications consume a given claim, but even where that telemetry exists, what each application grants on the claim is not a platform-reported artifact by default. The consumption is technically visible in some configurations; the interpretation is not. That distinction matters for any control that attempts to use IdP-side telemetry as a substitute for a claim contract.
This last point is where the thesis has a boundary worth naming: relying parties that authorize on locally stored roles — where the claim triggers a role lookup rather than a direct permission grant — reduce the blast radius of claim drift because the local role definition is a controllable, reviewable artifact. The claim still needs a contract, but the interpretation layer is separated from the assertion layer, which is an architectural improvement.
The four ways a claim drifts
Claim drift does not require a misconfiguration. It requires only that the assertion remain valid while the conditions that justified it change. The table below names four concrete drift modes, their causal path, and which party can already see the problem.
| Drift | How It Happens | Who Is At Fault | Visible To The Identity Provider | Visible To The Relying Party |
|---|---|---|---|---|
| Co-consumer grant divergence | A group created for Application A (read access) is onboarded as a claim by Applications B (approval authority) and C (admin rights) without a cross-consumer review | Application owners, independently | No — the IdP sees one valid group and three valid consuming applications | Partially — each SP knows its own grant but not the others' |
| Membership criteria drift | Group membership is reviewed against Application A's requirements at creation; criteria shift as the team changes scope, but no downstream consumer is notified | Group owner and change management process | No — membership changes are valid directory operations | No — the SP receives the same claim name; the population behind it has changed |
| Claim consumed at different granularity | Application A treats the claim as a coarse flag (user is in the group: permit); Application B uses it to derive a fine-grained role (member → write access to production) | Consuming application developers | No | Yes — the SP that does fine-grained derivation can model this, but rarely audits it |
| Orphan claim post-decommission | The application that justified a group's creation is retired; the group persists and continues to be asserted to remaining consumers | Application decommission process | No — the IdP continues to assert the claim validly | No — the remaining SPs have no signal that the group's original justification is gone |
| Unilateral scope expansion | A group's scope is broadened in the directory (e.g., a department sub-group promoted to a department-wide group) to satisfy a new application; existing consumers receive the expanded membership without review | Directory administrator | Partially — the IdP can see membership growth, but not whether it represents intended scope for each consumer | No — the SP receives the same claim name with a larger population |
The one drift that a relying party can already see, when it looks, is claim-granularity divergence. An application that maps a claim to a fine-grained role has the role model; it can audit which members of the claim population hold which derived permissions. Practitioners who have not done that audit in the last review cycle have an immediate action: pull the role membership derived from each federated claim and compare it to the group membership criteria on file.
The contract a claim needs
The deliverable is not a new protocol. It is a recorded artifact that lives where records already exist. For each claim asserted in a federated environment, the contract names four things: the applications that consume it, what each grants on it, who may change its membership criteria, and who must be notified when they do.
That artifact can live in several places today without building new machinery. A configuration management database (CMDB) entry, tied to the group object, works in environments where the CMDB is maintained. An IdP-side application registration note, where the platform supports freeform policy annotation, serves the same purpose and keeps it co-located with the consumption record. A table in the identity governance tool, if one exists, is the highest-fidelity option because governance platforms often support review workflows against the same record. The format is less important than the practice: the contract must be updated when any of its four fields changes, and the notification obligation must be enforced by the change management process, not left to individual application owners.
A claim contract created at group creation and never updated is not a contract — it is a snapshot. The operational test is whether a change to group membership criteria triggers a notification to every consuming application before the change takes effect. In most environments, it does not.
The primary recommended control for environments without an existing claim contract is to enumerate consuming applications per claim before defining any permissions — not after. Enumerating consumers after the fact reveals the drift that exists; enumerating before deployment prevents the co-consumer divergence pattern from forming.
Relying parties that authorize on local roles rather than direct claim-to-permission mapping reduce — but do not eliminate — the need for this contract. The claim still drives role assignment and role assignment drives access. If the claim population expands unexpectedly, the role population expands with it. The contract is the only control that surfaces that dependency explicitly, and it is the only artifact that makes the consuming interpretations visible to the IdP side of the relationship.
Authentication is centralized. The authorization premise that rides on it is not. Until the contract exists, neither party holds both ends.
Sources
- NIST SP 800-63 Digital Identity Guidelines: https://csrc.nist.gov/pubs/sp/800/63/3/final
- NIST SP 800-63B-4: https://csrc.nist.gov/pubs/sp/800/63/b/4/final
