Is there a reason we need to restrict the issuer discovery to OIDC? I believe we could also use the OAuth2 Authorization Server Metadata when supported.

We did consider both, but opted to pick one for the sake of simplicity.

I foresee folks wanting support for both. Is there a way to include a requirement for some form of discovery and use OIDC as the example in this document?

Agree that keeping things simple for the majority of the document is preferred so it's easy to follow.

@wdawson, can you expand a little on the reason for supporting a second method (apart from folks thinking it might be a good idea)?

One of the goals with this SEP is to allow easy re-use of existing workload identity infrastructure, specifically K8S and SPIFFE based systems.

Both K8S and SPIFFE based solutions commonly support OpenID Discovery documents (SPIRE, the open source SPIFFE implementation, has a OIDC discovery extension and OIDC discovery is also commonly supported on commercial SPIFFE implementations). Neither of them support OAuth Authorization Server Metadata, so adding Oauth2 Authorization Metadata Discovery as a supported method may have the unintended consequence of forcing existing issuers to add support for a duplicative discovery mechanism when it is not needed.

Are there any other large scale, widely deployed, workload identity infrastructures out there that don't support OIDC discovery already?

You'd know better than me. I think OIDC makes sense as the example for the reasons you said. I just didn't want to restrict it technically unless we needed to, so that folks could build other solutions that use OAuth AS discovery as a viable alternative. But I hear you from a clarity perspective and don't feel strongly enough here, especially if the large, widely deployed options are OIDC only.

Thanks @wdawson. I will add a bit more of this context to the "Why OpenID Connect Discovery?" section for clarity.

I think implementors can always support additional mechanisms - I don't recall text prohibiting that, but for interoperability and keeping things simple, we should not encourage it. If there are compelling reasons to add it explicitly later, we can always do that in a future SEP.

We probably want something about what a trusted issuer is, and how an MCP Server's AS might be configured with trusted issuers. I'm ok saying that the process is out of scope of this document, may happen by a variety of mechanisms, etc. But we should probably have at least one example, probably as an example from the motivation section.

How trust is established, or what the basis of trust is a business decision, not something we can define here.

I am also unsure if we gain much by trying to be more specific in defining how an AS might maintain a list of trusted issuers. That is an implementation choice and it is not immediately apparent how that improves interoperability.

How trust is established, or what the basis of trust is a business decision, not something we can define here. I am also unsure if we gain much by trying to be more specific in defining how an AS might maintain a list of trusted issuers. That is an implementation choice and it is not immediately apparent how that improves interoperability.

I totally agree. I'm coming at this more from a layperson's reading of the document and not understanding what a "trusted issuer" is, or that it's different from any old iss claim in a random token. I think we need to define the term for the purposes of this document, without being specific about the details. Something like:

"The Authorization Server is configured with a set of issuers (defined by a URL), which are considered 'trusted issuers'. The nature of that trusted relationship and the mechanism by which the set is populated or maintained is out of scope of this document and left up to the implementer. JWTs not issued by these trusted issuers can be safely rejected by the AS."

Feel free to ignore or wordsmith. Again, my primary concern is making sure that folks who aren't steeped in Identity will be able to understand what "trusted issuer" means.

Thanks, that is a helpful clarification. I will take a look at the best ways to provide clarity. Thanks for the suggestion.

I don't know that we need specific caching guidance, but calling it out as a security concern might be nice. I like what you did in the security considerations section, however, referencing the existing documents for their best practices. I assume there's something already in those discovery specifications.

Let me double check - I think you are right, but we can be a bit more specific about where this comes into play and reference specific section in security considerations to be more explicit about it. I will take a look.

We're restricted somewhat by RFC 7523. I might just call out that Authorization Servers SHOULD take that tradeoff into account.

That makes sense as a security consideration. I can add that.

I would be really curious to what degree this overlaps with the work captured by WIMSE. Ideally, we do not invent anything MCP-specific here and instead rely on existing standards, the saem way we did for the core authorization spec.

@localden - the really good news is we are not inventing anything new (deliberately so).

This proposal basically uses:

1. RFC7523 JWT Authorization Grants to request an access token
2. OpenID Connect Discovery to obtain the keys used to verify the JWT.

RFC 7523 was specifically designed for this kind of use case, while existing Kubernetes and SPIFFE based implementations already support OIDC key discovery.

Is the flow here mapping to a particular standard for WIF or is this MCP-specific? If AS has to implement a lot of this trust logic, where do they refer to?

This aspect of WIF is already supported by the most common JWT issuers. In terms of AS support, OIDC discovery is already commonly supported by IdPs (e.g. it is the mechanism used by Entra WIF). Trust configuration is implementation specific (in Entra if I recall, you had to explicitly define the OIDC discover point for an issuer that you trusted, along with a specific subject for example).

The reason for favouring OpenID Connect Discovery is because it is already used and supported by JWT issuers like Kubernetes and SPIFFE as well by Authorization Servers.

Assuming "TLS protected location" is basically a HTTPS endpoint?

Correct - I think I borrowed language from another draft - happy to clarify that in practice this is an HTTPS endpoint.

Also to clarify - this is intended as an extension, similar to other things in ext-auth? Or is the intent for this to be part of the core spec?

Correct. This is intended as an extension.

Needs clarification on which access token is used here.

Good catch, will do.

There is still a non-zero burden on AS to support this particular implementation, no?

This draft does not impose any new claims or processing rules - so if an authorization server already supports RFC 7523 and OpenID connect discovery would have very little, if any, additional work.

What does "authenticated" means in this context?

Server authentication. This can probably be simplified to say HTTPS similar to an earlier comment.

I feel like a lot of these are covered in existing OAuth RFCs, no? We should probably refer to those best practices rather than rewriting them here.

Agreed

Same as above, this feels like an implementation detail that should be captured by an OAuth RFC.

Agreed

Who's responsible for the mapping of this trust relationship?

This is configuration on the Authorization system - not unlike any other kind of misconfiguration that might result in privilege escalation.