Identity establishes the actor, not unlimited permission
Authentication answers whether the presented credential belongs to an account. Authorization still evaluates the organization, relationship, resource, action, and current policy.
Context is visible
Interfaces should identify the organization and application context in which a person is acting before a consequential action is approved.
Step-up follows risk
Sensitive actions can require stronger or more recent authentication according to the relying service’s risk decision.
Access is revocable
Membership, relationship, role, and delegated authority can change independently of the person’s identity record.
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific.
A sign-in password is not a vault secret
Authentication passwords are verified, not displayed back to the account holder or an organization. A pepper can strengthen a password verifier against database-only theft, but it does not make the original password recoverable.
Authentication recovery
Account recovery resets or replaces an authenticator after appropriate checks; it does not decrypt the old password.
Recoverable business credentials
A password or secret that a business must retain belongs in an encrypted organization vault with an explicit custody policy.
Personal material stays separate
Business recovery authority should never silently extend to a person’s private vault or unrelated credentials.
Explicit organization-custodian and multi-party recovery workflows are planned. They never turn an authentication password into recoverable data.
Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific.
Applications and agents act through separate grants
No inherited omnipotence
An application or AI agent does not automatically receive every permission held by the person who started it.
Purpose and time matter
Delegated authority should identify the task, audience, allowed action, resource boundary, and expiration where the integration supports it.
The resource still decides
The service holding the resource applies its own policy and can deny an otherwise valid request.
Strict attenuation, a size-limited signed-envelope verifier, runtime-opaque verified artifacts, and exact reference-service request binding exist in code and tests. Independent issuer-key resolution and relying-party rollout evidence remain gated.
Roadmap reference for narrowing delegated authority across actors and workloads; it is not represented as a generally available issuance flow.
OAuth 2.0 Rich Authorization Requests (RFC 9396)Roadmap reference for structured authorization detail. Current integrations must not assume this request shape is accepted.
DPoP (RFC 9449)Roadmap reference for sender-constrained OAuth tokens. It is not a blanket statement that current clients are sender constrained.