-
Notifications
You must be signed in to change notification settings - Fork 926
[draft] SEP client id metadata document #1296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐌 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.