IDProva vs OAuth Extensions for Agent Authentication

OAuth’s Original Design Intent

OAuth 2.0 (RFC 6749) solved an important problem: allowing a human user to grant a third-party application limited access to their resources without sharing their credentials. The classic example is “Sign in with Google” — the user authenticates with Google, consents to specific scopes, and the application receives a token.

This model has served the web well for over a decade. But it encodes a fundamental assumption: there is a human at the top of every authorization decision. The authorization server knows the user. The user consents. The application acts within the consented scope.

Agentic AI breaks this assumption in every dimension.

Where OAuth Falls Short for Agents

No Delegation Chains

In an agent system, authority flows through multiple hops. A human authorises Agent A. Agent A delegates a subset of its authority to Agent B. Agent B further sub-delegates to Agent C for a specific subtask. This is not an edge case — it is the fundamental operating pattern of multi-agent systems.

OAuth has no native mechanism for this. An OAuth access token represents a single delegation from the authorization server to the client. If Agent A wants to delegate to Agent B, it must either:

1. Share its token (violating the security model)
2. Act as a proxy, making requests on Agent B’s behalf (creating attribution confusion)
3. Register Agent B as a separate client and perform a new authorization flow (requiring infrastructure per agent)

None of these options preserve the delegation chain or enable a verifier to trace authority back to the original human principal.

No Audit Trail

OAuth tokens are bearer tokens. They authenticate requests, not actions. When Agent A uses an OAuth token to call an API, the API sees a valid token and processes the request. But there is no standard mechanism to:

• Record that the specific action was authorised by this specific token
• Chain that record to previous and subsequent actions
• Ensure the record is tamper-evident
• Map the record to compliance controls

Audit logging is left entirely to the resource server implementation. There is no protocol-level guarantee that actions are recorded, attributed, or integrity-protected. For compliance-sensitive environments, this is a critical gap.

No Agent Metadata

An OAuth client registration includes basic information: client ID, redirect URIs, allowed grant types. It does not include:

• What AI model the agent runs
• What runtime or framework it uses
• A hash of its current configuration
• Its trust level or assurance class
• Its capabilities or declared behaviours

When a resource server receives a request from an OAuth client, it knows which application is calling but not what kind of entity is behind it. For agent-to-agent interactions, this metadata is essential for making informed trust decisions.

No Post-Quantum Readiness

OAuth’s security model relies on the confidentiality of bearer tokens and the integrity of TLS. Token signatures (in JWT-based flows) typically use RS256 or ES256. Neither algorithm is quantum-resistant. The OAuth ecosystem has no standardised path to post-quantum cryptography.

For agent identity systems that will need to verify delegation chains and audit trails years or decades after creation, this is a significant long-term risk.

No Scope Narrowing Enforcement

OAuth scopes are strings. The authorization server issues a token with certain scopes, and resource servers enforce them. But there is no protocol-level enforcement that a sub-delegation (if it were possible) narrows scope. Nothing prevents an agent from attempting to grant broader permissions than it holds. Enforcement depends entirely on application logic.

IDProva’s Purpose-Built Approach

IDProva was designed from the ground up for agent authentication. Rather than extending a human-centric protocol, it provides primitives tailored to the agent interaction model.

Delegation Attestation Tokens (DATs)

Where OAuth has access tokens, IDProva has DATs. The differences are structural:

Aspect	OAuth Access Token	IDProva DAT
Delegation model	Single hop (server to client)	Multi-hop chains with parentDat references
Scope enforcement	Application-level	Protocol-level with mandatory narrowing
Identity semantics	Client ID	Full DID with agent metadata
Constraints	Scope strings only	Structured constraints (rate limits, IP ranges, geo-restrictions, max actions)
Audit linkage	None	Every Action Receipt references its authorising DAT
Revocation cascade	Token-level only	Revoking a parent invalidates all child DATs
Cryptography	RS256/ES256	Hybrid Ed25519 + ML-DSA-65

Scope Grammar with Mandatory Narrowing

IDProva uses a structured scope grammar:

namespace:resource:action

Examples:

mcp:tool:filesystem:read
mcp:tool:*:*
a2a:agent:billing-service:communicate

When Agent A delegates to Agent B, the protocol enforces that Agent B’s scope is a subset of Agent A’s scope. This is not advisory — it is cryptographically enforced during DAT verification. A DAT that claims broader scope than its parent is invalid.

Principal (Alice)
  scope: mcp:tool:*:*
  └─ DAT → Agent A
       scope: mcp:tool:*:*               (valid: subset of parent)
       └─ DAT → Agent B
            scope: mcp:tool:filesystem:*  (valid: narrower)
            └─ DAT → Agent C
                 scope: mcp:tool:filesystem:read  (valid: narrower still)

Constraint Inheritance

Beyond scope, DATs carry structured constraints that inherit through the delegation chain:

{
  "constraints": {
    "maxActions": 1000,
    "ipRange": ["10.0.0.0/8"],
    "rateLimit": "100/hour",
    "maxRedelegationDepth": 2,
    "geoRestriction": ["AU", "US"]
  }
}

A child DAT can tighten these constraints but never loosen them. If Agent A has maxActions: 1000, Agent B can set maxActions: 500 but not maxActions: 2000. This inheritance is verified at every step of the chain.

Chain Validation

Verifying an IDProva delegation chain is a recursive walk from leaf to root:

1. Decode the leaf DAT
2. Verify its signature against the issuer’s DID Document
3. Check temporal validity (not before, not after)
4. Check revocation status
5. If parentDat exists, verify the parent recursively
6. At each step, confirm that child scope is a subset of parent scope
7. At each step, confirm that child constraints are equal or tighter

If any step fails, the entire chain is invalid. There is no partial validation.

When to Use IDProva Alongside OAuth

IDProva is not a replacement for OAuth in all contexts. The two protocols serve different purposes and can coexist:

Use OAuth when:

• A human user is directly authorising an application
• You need SSO integration with existing identity providers
• The interaction follows the traditional user-app pattern
• You are integrating with third-party services that only support OAuth

Use IDProva when:

• Agents need to authenticate to other agents
• Delegation chains span multiple hops
• You need compliance-grade audit trails
• Agent metadata (model, runtime, trust level) matters for trust decisions
• Post-quantum cryptography is a requirement
• You need to trace any action back to a human principal through a delegation chain

Use both when:

• A human authenticates via OAuth, then the system issues an IDProva DAT to their agent
• The OAuth layer handles human identity; the IDProva layer handles agent identity
• External APIs use OAuth; internal agent-to-agent communication uses IDProva
• The OAuth access token becomes the proof that the human principal authorised the root IDProva delegation

This last pattern is likely the most common in enterprise deployments. OAuth and IDProva are complementary, not competitive. OAuth handles what it was designed for — human-to-application authorization. IDProva handles what OAuth was never designed for — agent-to-agent delegation, scoped authority chains, and tamper-evident audit trails.

The Practical Difference

Consider a concrete scenario: Agent A (authorised by Alice via her IdP) needs to delegate filesystem read access to Agent B for a 1-hour task, and every file read must be auditable.

With OAuth alone: Register Agent B as an OAuth client. Perform a client credentials flow or token exchange. Agent B gets an access token. Filesystem reads are logged in the application layer, with no guarantee of completeness or integrity. If Agent B delegates to Agent C, repeat the process. No chain. No narrowing enforcement. No audit linkage.

With IDProva: Agent A issues a DAT to Agent B with scope mcp:tool:filesystem:read, 1-hour expiry, and constraints maxActions: 100. Agent B presents the DAT to the filesystem service. Every file read produces a signed Action Receipt referencing the DAT. If Agent B delegates to Agent C, the DAT chain enforces scope narrowing. An auditor can verify the entire chain from Alice’s authorization through Agent A’s delegation to Agent C’s filesystem reads.

The second model provides what compliance frameworks require and what the first model leaves to application developers to implement ad hoc.

Explore the Delegation specification or try the Quick Start guide to see how IDProva handles agent authentication in practice.