Attendees
Aaron Parecki
Atul Tulshibagwale
Darin McAdams
Simon Russell
Wils Dawson
Discussion
Proof of Possession
There was discussion of SEP-1415: HTTP Message Signing. While being inclined toward the general idea of message signing, this particular approach raised several considerations:
- It forces all servers into a stateful pattern in which init() becomes a client registration operation within a public, unauthenticated API subject to DDoS events. While the same concerns could be raised for OAuth DCR, DCR centralizes this responsibility at the Authorization Server. This alternative would shift the burden to each server, and into a data plane API where it’s more difficult to apply the types of throttling protections used for DCR. While there is some debate on whether MCP is truly stateless today, the inclination is to avoid decisions that knowingly block stateless implementations.
- There is a preference for solutions that are additive to OAuth as opposed to alternatives to OAuth. The reasons for this are twofold. One is to avoid a large pivot on the authorization spec that audiences are currently implementing. The other is that real world experience with HTTP Message Signatures has shown them to frequently be insufficient on their own, but rather a better-together capability alongside an additional auth token that can encapsulate information such as scoped down permissions and other session properties. (AWS as a reference example.)
- There is a preference to keep cryptographic client identity in the identity layer, not mixed into the MCP protocol negotiation. Keep init() focused on capability discovery.
HTTP Message Signing + OAuth emerged as the preferred approach, and there has been a history of IETF draft specs to define the binding between the two. These drafts stalled in the past as HTTP Message Signing itself was still in draft stage. But, now that HTTP Message Signing is finalized, we can rehydrate the discussions.
The alternative consideration was DPoP. DPoP has a significant advantage in that it's already defined for OAuth flows. But, the problem is that DPoP only signs the HTTP endpoint and method. In a typical REST API, the endpoint tells you a lot - POST /users vs DELETE /users/123 are clearly different operations. But MCP uses JSON-RPC over a single endpoint, so all requests go to something like POST /mcp regardless of whether you're listing tools, calling a specific function, or accessing resources. This creates a much wider replay window than we'd want.
Narrowing the replay window will necessitate a formula to extract request details from the JSON-RPC payload and include that in the request signature. HTTP Message Signing tends to be more flexible than DPoP in terms of including extra information in the signature, and in fact SEP #1415 already includes a full Content-Digest in the message signature.
Next Steps
- Darin to connect with Justin Richer about rehydrating the specs for OAuth + HTTP Message Signatures.
- Open a new MCP SEP to initiate public discussion on this approach.
Workload Identity Federation
The pattern of exchanging a workload identity token for an access_token to a resource server is frequently encountered in production systems across all types of different workloads, but has never been officially profiled as an interoperable spec. It was noted that at least 3 draft proposals take different approaches to standardizing it:
These also share similarities to the patterns observed in SEP-646: Enterprise Managed Authorization Profile.
While we can see a direction we can go, there is a need for spec rationalization amongst the existing drafts.
Next Steps
- Darin to connect with spec authors for rationalization. Bring back a single proposal.
Spec Structure For Profiles
As we define these optional behaviors, there was widespread agreement that we shouldn't consolidate all the behaviors into a single spec with a lot of "MAY" conditions. Instead, describe each profile in its own specification. It's a "MAY" to use the profile, but when you do, the profile defines "MUST"s.
Someone needs to propose the specific mechanics for doing so. For example, one simple option could be creating a sub-folder under the auth spec named "Auth Profiles", containing each of these opt-in behaviors. There may be discussion on the granularity of the profiles, and whether a guiding principle of the group should be to avoid overlapping profiles that solve the same problem but in different ways (i.e. don't have two options for adding Proof of Possession).
One possible approach is to take the profiles that we know are coming and sketch a proposed structure for the specification documents, then share for discussion.
Next Steps
- Darin to connect with Paul Carleton on spec organization.
Attendees
Aaron Parecki
Atul Tulshibagwale
Darin McAdams
Simon Russell
Wils Dawson
Discussion
Proof of Possession
There was discussion of SEP-1415: HTTP Message Signing. While being inclined toward the general idea of message signing, this particular approach raised several considerations:
HTTP Message Signing + OAuth emerged as the preferred approach, and there has been a history of IETF draft specs to define the binding between the two. These drafts stalled in the past as HTTP Message Signing itself was still in draft stage. But, now that HTTP Message Signing is finalized, we can rehydrate the discussions.
The alternative consideration was DPoP. DPoP has a significant advantage in that it's already defined for OAuth flows. But, the problem is that DPoP only signs the HTTP endpoint and method. In a typical REST API, the endpoint tells you a lot - POST /users vs DELETE /users/123 are clearly different operations. But MCP uses JSON-RPC over a single endpoint, so all requests go to something like POST /mcp regardless of whether you're listing tools, calling a specific function, or accessing resources. This creates a much wider replay window than we'd want.
Narrowing the replay window will necessitate a formula to extract request details from the JSON-RPC payload and include that in the request signature. HTTP Message Signing tends to be more flexible than DPoP in terms of including extra information in the signature, and in fact SEP #1415 already includes a full Content-Digest in the message signature.
Next Steps
Workload Identity Federation
The pattern of exchanging a workload identity token for an access_token to a resource server is frequently encountered in production systems across all types of different workloads, but has never been officially profiled as an interoperable spec. It was noted that at least 3 draft proposals take different approaches to standardizing it:
These also share similarities to the patterns observed in SEP-646: Enterprise Managed Authorization Profile.
While we can see a direction we can go, there is a need for spec rationalization amongst the existing drafts.
Next Steps
Spec Structure For Profiles
As we define these optional behaviors, there was widespread agreement that we shouldn't consolidate all the behaviors into a single spec with a lot of "MAY" conditions. Instead, describe each profile in its own specification. It's a "MAY" to use the profile, but when you do, the profile defines "MUST"s.
Someone needs to propose the specific mechanics for doing so. For example, one simple option could be creating a sub-folder under the auth spec named "Auth Profiles", containing each of these opt-in behaviors. There may be discussion on the granularity of the profiles, and whether a guiding principle of the group should be to avoid overlapping profiles that solve the same problem but in different ways (i.e. don't have two options for adding Proof of Possession).
One possible approach is to take the profiles that we know are coming and sketch a proposed structure for the specification documents, then share for discussion.
Next Steps