Align Enterprise-Managed Authorization with id-jag-04 and promote to stable#29
Open
pcarleton wants to merge 3 commits into
Open
Align Enterprise-Managed Authorization with id-jag-04 and promote to stable#29pcarleton wants to merge 3 commits into
pcarleton wants to merge 3 commits into
Conversation
Reduce duplication by referencing draft-ietf-oauth-identity-assertion-authz-grant-04 for roles, token exchange parameters, ID-JAG claims, and processing rules, keeping only MCP-specific constraints inline. - Adopt 'Resource Authorization Server' terminology from id-jag §2 - Replace parameter/claim tables with section references plus MCP deltas - Keep `resource` REQUIRED in this profile (id-jag-04 made it optional) - Drop the restriction on `actor_token` (removed upstream in -03) - Replace multi-tenant implementation notes with reference to id-jag §6 - Reference id-jag §5 for cross-domain client_id handling - Add Discovery section referencing `authorization_grant_profiles_supported`
Move the extension from specification/draft/ to specification/stable/ to indicate it is ready for use and has reference implementations. Update the README to list stable and draft extensions separately, and update the in-document status banner to match.
pcarleton
changed the title
aaronpk
reviewed
Jun 17, 2026
| In this profile: | ||
|
|
||
| - `audience` **MUST** be the issuer identifier of the Resource Authorization Server. | ||
| - `resource` is **REQUIRED** and **MUST** be the Resource Identifier of the MCP Server as defined in [RFC9728](https://datatracker.ietf.org/doc/html/rfc9728). |
Contributor
There was a problem hiding this comment.
Suggested change
| - `resource` is **REQUIRED** and **MUST** be the Resource Identifier of the MCP Server as defined in [RFC9728](https://datatracker.ietf.org/doc/html/rfc9728). | |
| - `resource` is **OPTIONAL** and if set, **MUST** be the Resource Identifier of the MCP Server as defined in [RFC9728](https://datatracker.ietf.org/doc/html/rfc9728). |
Feels like we should make this "optional" right now since that's how the implementations currently work.
aaronpk
reviewed
Jun 17, 2026
| &client_id=2ec954a1d60620116d36d9ceb7 | ||
| &client_secret=a26d84873504215a34a86d52ef5cd64f4b76 | ||
| ``` | ||
|
|
Contributor
There was a problem hiding this comment.
Suggested change
| If the client uses SAML for single sign-on to the IdP, see [Section 4.5](https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html#section-4.5) for details on how the client can exchange the SAML assertion for a refresh token, then use the refresh token to request an ID-JAG. |
aaronpk
reviewed
Jun 17, 2026
|
|
||
| The ID-JAG is a JWT issued and signed by the IdP with the claims defined in [Section 3.1 of draft-ietf-oauth-identity-assertion-authz-grant](https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.html#section-3.1). | ||
|
|
||
| In this profile, the `resource` claim is **REQUIRED** and **MUST** contain the Resource Identifier of the MCP Server. |
Contributor
There was a problem hiding this comment.
Suggested change
| In this profile, the `resource` claim is **REQUIRED** and **MUST** contain the Resource Identifier of the MCP Server. | |
| In this profile, the `resource` claim **MUST** contain the Resource Identifier of the MCP Server if present. |
aaronpk
reviewed
Jun 17, 2026
| { | ||
| "jti": "9e43f81b64a33f20116179", | ||
| "iss": "https://acme.idp.example", | ||
| "sub": "U019488227", |
Contributor
There was a problem hiding this comment.
Suggested change
| "sub": "U019488227", | |
| "sub": "U019488227", | |
| "email": "user@example.com", |
aaronpk
reviewed
Jun 17, 2026
aaronpk
reviewed
Jun 17, 2026
aaronpk
reviewed
Jun 17, 2026
Co-authored-by: Aaron Parecki <aaron@parecki.com>
aaronpk
reviewed
Jun 17, 2026
|
|
||
| In most enterprise deployments, the IdP policy will only allow users to sign in to pre-registered clients. The MCP client will likely need to be pre-registered with the enterprise IdP for single sign-on. | ||
|
|
||
| It is also assumed that the MCP client will be pre-registered with the Resource Authorization Server. |
Contributor
There was a problem hiding this comment.
Suggested change
| It is also assumed that the MCP client will be pre-registered with the Resource Authorization Server. |
aaronpk
reviewed
Jun 17, 2026
|
|
||
| ### 7.2 Scope of Enterprise Visibility and Policy Enforcement | ||
|
|
||
| This specification enables the enterprise IdP to be part of the issuance of the access token at the MCP Server. The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual API calls between the MCP Client and Server. |
Contributor
There was a problem hiding this comment.
Suggested change
| This specification enables the enterprise IdP to be part of the issuance of the access token at the MCP Server. The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual API calls between the MCP Client and Server. | |
| This specification enables the enterprise IdP to be part of the issuance of the access token at the MCP Server. The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual MCP traffic between the MCP Client and Server. |
aaronpk
reviewed
Jun 18, 2026
|
|
||
| The Identity Assertion JWT Authorization Grant follows three steps: | ||
|
|
||
| 1. Single Sign-On to the MCP Client via OpenID Connect or SAML |
Contributor
There was a problem hiding this comment.
Suggested change
| 1. Single Sign-On to the MCP Client via OpenID Connect or SAML | |
| 1. Single Sign-On to the MCP Client via OpenID Connect or SAML | |
| 1a. optionally exchange the SAML assertion for a Refresh Token |
aaronpk
reviewed
Jun 18, 2026
| The core flow is as follows: | ||
|
|
||
| - A user logs in to an MCP Client through their enterprise Identity Provider, resulting in an Identity Assertion (ID Token or SAML assertion) being issued to the MCP Client. | ||
| - The MCP Client sends a Token Exchange [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)] request to the Identity Provider including the identity assertion and identifier of the MCP Server it is attempting to access, and obtains a Identity Assertion JWT Authorization Grant (ID-JAG). |
Contributor
There was a problem hiding this comment.
Suggested change
| - The MCP Client sends a Token Exchange [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)] request to the Identity Provider including the identity assertion and identifier of the MCP Server it is attempting to access, and obtains a Identity Assertion JWT Authorization Grant (ID-JAG). | |
| - For SAML: | |
| - The MCP Client sends a Token Exchange request to the Identity Provider with the SAML assertion, and obtains a Refresh Token. | |
| - The MCP Client sends a Token Exchange [[RFC8693](https://datatracker.ietf.org/doc/html/rfc8693)] request to the Identity Provider including the ID Token or Refresh Token, and the identifier of the MCP Server it is attempting to access, and obtains a Identity Assertion JWT Authorization Grant (ID-JAG). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two changes to the Enterprise-Managed Authorization extension:
1. Reduce duplication against id-jag-04
References draft-ietf-oauth-identity-assertion-authz-grant-04 directly for roles, token exchange parameters, ID-JAG claims, and processing rules, keeping only MCP-specific constraints inline.
resourceREQUIRED in this profile (id-jag-04 made it optional)actor_token(removed upstream in -03)client_idhandlingauthorization_grant_profiles_supported(id-jag §7.2)resourceclaim in the ID-JAG2. Promote to
specification/stable/Moves the document from
draft/to a newstable/directory to indicate it is ready for use and has reference implementations. README updated to list Stable and Draft extensions separately; in-document status banner updated to match.Examples and the sequence diagram are unchanged.