[draft] SEP client id metadata document #1296
Conversation
| - `client_id`: matching the document URL exactly | ||
| - `client_name`: human-readable name for authorization prompts | ||
| - `redirect_uris`: array of allowed redirect URIs | ||
| - `token_endpoint_auth_method`: "none" for public clients |
There was a problem hiding this comment.
We should also reference the private_key_jwt authentication method: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
This would allow a web-server-based client to act as a proper confidential client, providing a high level of assurance compared to DCR.
There was a problem hiding this comment.
🐌 sorry for the delay. does this still make sense here? Thinking of this SEP being particularly for CIMD rather than trying to tackle software_statement-shaped problems. To mention private_key_jwt I think we'ed need to also add jwks_uri or jwks here for it to be useful, right?
There was a problem hiding this comment.
I think it makes sense to call out how a client can be authenticated in the context of the CIMD spec as it also serves as a mitigation against some of the exploits?
| This attack is concerning because the server sees the correct metadata | ||
| document and the user sees the correct client name, making detection | ||
| difficult. While platform-specific attestations (iOS DeviceCheck, Android | ||
| Play Integrity) could address this, they're not universally available. An |
There was a problem hiding this comment.
Let's expand on this and describe how an app developer can run a backend service that validates the DeviceCheck/Play Integrity signatures and returns a JWT the app can use with the private_key_jwt client authentication method. This would actually be a pretty reasonable level of assurance of the app's identity. This doesn't need to be specified normatively in this proposal, since the actual underlying OAuth mechanism used is only the private_key_jwt auth method.
There was a problem hiding this comment.
Perhaps the normative text can be left in the IETF draft, and we can just normatively reference that instead and outline the concept of using "private_key_jwt" here. Alternatively we can add a section to talk about client authentication as a core part of the spec, and not just as a mitigation in this section.
Proposing some expanded text below.
| This can be prevented by validating the URL's and the IP's those URL's resolve to prior to initiating a fetch request. | ||
|
|
||
|
|
||
| #### Risk: Distributed Denail of Service (DDoS) |
There was a problem hiding this comment.
| #### Risk: Distributed Denail of Service (DDoS) | |
| #### Risk: Distributed Denial of Service (DDoS) |
|
|
||
| The RFC for Client ID Metadata documents is still a draft. It has been implemented by the platform Bluesky, but has not been ratified or very widely adopted outside of that. | ||
|
|
||
| This has the risk that there are implementation challenges or flaws in the protocol that have not surfaced yet. However, even though DCR has been ratified, and it also has a number of implementation challenges that developers are facing when trying to use it in an open ecosystem context like MCP. Those challenges are the motiviation behind this proposal. |
There was a problem hiding this comment.
Probably worth adding something similar to BlueSky's call-out about the draft:
The Client ID Metadata Document specification (draft-parecki-oauth-client-id-metadata-document is still a draft and may evolve over time. Our intention is to evolve and align with subsequent drafts and any final standard, while minimizing disruption and breakage with existing implementations.
|
|
||
| Authorization for MCP is already challenging to fully implement for clients and servers. Questions about how to do it correctly and best practices are some of the most common in the community. Adding another branch to the authorization flow means this could be even more complicated and fractured, meaning fewer developers succeed in following the specification, and the promise of compatibility and an open ecosystem suffers as a result. | ||
|
|
||
| This proposal intends to simplify the story for authorization server and resource server developers by providing a clearer mechanism to trust redirect URIs and less operational overhead. This proposal depends on that simplicity being clearly the better option for most folks, which will drive more adoption and end up being the most supported option. If we do not believe that it is clearly the better option, then we should not adopt this proposal. |
There was a problem hiding this comment.
This proposal also provides a unified mechanism for both open servers and servers that want to restrict which clients can be used. Alternatives to this proposal require that clients and servers implement different mechanisms for the open and protected use cases
Co-authored-by: Aaron Parecki <aaron@parecki.com>
| difficult. While platform-specific attestations (iOS DeviceCheck, Android | ||
| Play Integrity) could address this, they're not universally available. An | ||
| approach using JWKS and short-lived JWTs signed by a server-side component | ||
| of the client could raise the cost of attack but cannot eliminate it |
There was a problem hiding this comment.
| of the client could raise the cost of attack but cannot eliminate it | |
| that asserts the identity of the client could raise the cost of attack. The JWT provides a cryptographic binding between the URL used as a client ID and the metadata document. These JWTs may be provisioned manually, or through automated mechanisms such as Attestation Based Client Authentication or SPIFFE. The MCP server accepts and verifies these JWTs as authentication credentials as defined in (see draft-parecki-oauth-client-id-metadata-document-03). Using short lived JWTs minimise the risk of credential compromise and replay, but does not eliminate it |
This is a placeholder for the actual SEP over here:
#991
I'm opening as a branch for easier collaborative editing.