Wiki · Concept · Last reviewed June 25, 2026

OpenID Connect Authority Claims

OpenID Connect Authority Claims is a draft OpenID eKYC-IDA extension for carrying verified claims about a person's authority to act for another person or legal entity.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: digital identity, OpenID Connect, delegated authority, legal entities, agent governance

Definition

OpenID Connect Authority claims extension is an OpenID Foundation eKYC-IDA draft snapshot, published May 25, 2026, by M. Haine and J. White. The eKYC-IDA working-group page lists it under Drafts, with current snapshot versions built automatically from the master branch. It should therefore be described as draft work, not as a final OpenID standard.

The draft extends OpenID Connect for a narrow but important problem: communicating verified claims about the authority a natural person has to act for another natural person or for a legal entity. That problem is different from ordinary sign-in, employee affiliation, corporate registry lookup, or a generic role label. It asks whether this person may act for that target, for which purposes, under which limits, and how that authority was granted.

Claim Structure

The draft builds on the verified_claims pattern from OpenID Connect for Identity Assurance. Inside the verified claims object, an authority object or array can express authority-to-act information as claims about the end-user. The draft's core sub-elements are applies_to, permission, and granted_by.

applies_to identifies the person or legal entity to which the authority applies. For a legal entity, the draft defines optional claims such as organization_name, registration_number, registration_authority_code, legal_jurisdiction, entity_legal_form, organization_status, incorporation_date, and organization_identifiers. For a natural person, it can use OpenID Connect person claims such as sub, name, given_name, family_name, birthdate, and address, when those are sufficient for the use case.

permission states what the end-user is allowed to do in relation to the target entity. The draft names role, validity period, budget, audience, functional domain, and whether the authority may be delegated. granted_by describes how the authority came to be held, including a method such as delegated, appointed, or self-asserted, plus optional information about the granting body and reason.

Scope Boundary

The draft is explicit about boundaries. Legal-entity details by themselves are out of scope because OpenID Connect is focused on claims about the end-user. Relationships between two legal entities are also out of scope. Simple affiliation, such as being an employee or student, is not enough unless the claim communicates authority to act. That boundary matters because agent systems are tempted to treat every organizational signal as permission.

Authority claims can be requested with the OpenID Connect claims request parameter, and scopes can request predefined claim sets. The draft warns that scopes can return more data than needed, so the relying party should request only required end-user claims and metadata. It also defines OpenID Provider metadata for advertising support for authority claims, supported permissions, supported granting methods, and supported authority claim fields.

Agent Context

Authority claims become especially relevant when an AI agent performs administrative work for a person: filing a tax form, managing a business account, talking to a benefits agency, changing a child's school record, sending payroll instructions, requesting pension information, or acting under power of attorney. The agent may be technically able to click and submit, but the governance question is whether the human principal had authority, whether the agent was authorized to use it, and whether the relying party can verify the chain without collecting unnecessary identity data.

A responsible agent flow would keep four records separate: the human's identity proofing, the authority claim, the agent delegation from the human to the software, and the resulting transaction. Collapsing those records into one "logged in user" event makes audits weak and appeals confused.

Governance Risks

Authority inflation. A relying party treats a narrow permission as general power to act.

Affiliation confusion. An employee, contractor, student, guardian, or adviser label is mistaken for authority over a specific decision.

Over-collection. A service asks for full identity and organizational records when a smaller authority proof would be enough.

Delegation fog. The human has authority, but the agent's authority to exercise it is undocumented.

Draft overreliance. A deployment treats a draft data model as if it solved local legal validity, liability, and due process.

Governance Pattern

Source Discipline

Claims about this topic should cite the exact draft snapshot and avoid flattening it into identity assurance, OpenID for Verifiable Presentations, or Verifiable Credentials. The technical carrier, the issuer, the trust framework, the authority scope, and the legal effect are separate facts.

Spiralist Reading

Spiralism reads authority claims as a way to make delegation inspectable before automation turns it into invisible momentum. The humane version says: this person may do this for that entity, within these limits, because of this grant. The dangerous version says: the session authenticated, so the machine may proceed. The difference is not philosophical. It is the record that lets someone stop, contest, or repair the act.

Open Questions

Sources

Return to Wiki