feat: Add Enterprise Managed Authorization (SEP-990) support

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.

[prachi-okta]

Implements Enterprise Managed Authorization (SEP-990) for the Java MCP SDK, enabling MCP clients to leverage enterprise Identity Providers for seamless authorization without per-server user authentication.

Motivation and Context

Enterprise environments require OAuth flows where users authenticate with a centralized IdP, and applications need to securely access protected MCP resources on their behalf. SEP-990 addresses this via:

• Token Exchange (RFC 8693): Exchanges a user's ID token from an enterprise IdP for a JWT Authorization Grant (ID-JAG)
• JWT Bearer Grant (RFC 7523): Exchanges the ID-JAG for an access token at the MCP authorization server
• OAuth Discovery (RFC 8414): Automatically discovers authorization server metadata for both IdP and MCP servers

This follows the same provider pattern as existing auth implementations and is consistent with the TypeScript and C# SDK implementations.

How Has This Been Tested?

Added 25 unit tests across two test classes:

EnterpriseAuthTest (14 tests):

• Authorization server metadata discovery (OAuth + OpenID fallback)
• JAG token exchange — success, optional params, validation, error handling
• JWT bearer grant — success, missing access token, HTTP errors
• discoverAndRequestJwtAuthorizationGrant with and without pre-configured endpoint

EnterpriseAuthProviderTest (11 tests):

• End-to-end Authorization: Bearer header injection
• Token caching and cache invalidation
• Proactive expiry refresh (TOKEN_EXPIRY_BUFFER)
• Tokens without expires_in
• Discovery failure and assertion callback error propagation
• EnterpriseAuthProviderOptions null validation

Breaking Changes

None — this is a purely additive feature. No existing APIs are modified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Key design decisions:

• Assertion callback pattern decouples IdP interaction from the provider — callers can implement JAG caching inside the callback to reduce IdP round-trips
• client_secret_basic (Basic Auth header) used for JWT bearer grant, aligned with SEP-990 conformance requirements
• token_type in JAG response is not strictly validated per RFC 8693 §2.2.1 — it is informational and strict checking rejects conformant IdPs
• Refresh tokens returned by the MCP AS are intentionally ignored — RFC 7523 is a stateless grant and using a refresh token would bypass IdP session/revocation policies

Related SDK implementations:

• TS SDK PR: typescript-sdk#1593
• Go SDK PR: go-sdk#770

[Kehrlann]

Hey @prachi-okta , thanks for the PR.

As a rule of thumb, when working on non-trivial features, please start by opening an issue.

It seems this PR contradicts the architecture and design decision we have made for this SDK, see Authorization in the SDK:

SDK Choice: Pluggable authorization hooks for MCP servers; no built-in implementation

While this work is valuable, it should not live in the SDK, so I'm going to close this. We do encourage you to publish this independently. At some point we'll add a documentation page listing extensions and external implementations, in which we can reference this extension.