pub struct AuthorizationModel {
pub specified: bool,
pub protected_resource_metadata: bool,
pub resource_indicators_required: bool,
pub oidc_discovery: bool,
pub incremental_scope_consent: bool,
pub issuer_parameter: bool,
pub credentials_bound_to_issuer: bool,
pub client_registration: ClientRegistration,
}Expand description
What a revision’s authorization spec requires of the two sides.
Built by authorization_model and read by the resource-server and client
paths. Copy so it can be held on a session without a reference, which
matters because every request handler consults it.
§Examples
use protocol_droid::domain::mcp::authorization::{
ClientRegistration, authorization_model,
};
use protocol_droid::domain::ProtocolVersion;
// 2026-07-28 deprecated RFC 7591 in favour of client id metadata documents.
assert_eq!(
authorization_model(ProtocolVersion::V2026_07_28).client_registration,
ClientRegistration::MetadataDocument,
);Fields§
§specified: boolThe revision defines an authorization framework.
false only for 2024-11-05, whose vendored changelog contains no
authorization entry at all. Everything else here is meaningless when this
is false, and a caller that has not checked it will advertise a
protected-resource document to a peer whose revision never defined one.
protected_resource_metadata: boolThe server is an OAuth resource server and publishes protected-resource metadata naming its authorization servers.
2025-06-18 changelog §3 (PR #338): “Classify MCP servers as OAuth
Resource Servers, adding protected resource metadata to discover the
corresponding Authorization server.” Absent from 2025-03-26, whose
framework predates the classification.
resource_indicators_required: boolA client MUST send the resource indicator (RFC 8707).
2025-06-18 changelog §4 (PR #734): “Require MCP clients to implement
Resource Indicators as described in RFC 8707 to prevent malicious
servers from obtaining access tokens.” A MUST on the client, and the
threat is concrete: without it, a token minted for one server can be
replayed at another.
oidc_discovery: boolAuthorization-server discovery may use OpenID Connect Discovery 1.0.
2025-11-25 changelog §1 (PR #797). An enhancement rather than a
replacement — /.well-known/oauth-authorization-server still works —
so this gates whether the client offers the other form, not which one
it requires.
incremental_scope_consent: boolWWW-Authenticate may carry incremental scope consent.
2025-11-25 changelog §3 (SEP-835). Lets a server name the exact scope
it wants instead of rejecting wholesale, so a client that does not read
it still works — it just re-prompts for everything.
issuer_parameter: boolA client MUST validate an iss parameter when the server sends one.
2026-07-28 changelog §7 (SEP-2468): authorization servers “SHOULD
include the iss parameter in authorization responses per RFC 9207, and
MCP clients MUST validate a present iss against the recorded
issuer before redeeming the authorization code”. So the server’s
obligation is a SHOULD and the client’s is a MUST — absent iss is
tolerated, present-and-wrong is fatal. Modelled as one row rather than
two because the client’s obligation is what code has to implement.
credentials_bound_to_issuer: boolPersisted client credentials are keyed by issuer and never reused across authorization servers.
2026-07-28 changelog §9 (SEP-2352): clients “MUST key persisted
credentials by the issuer identifier, MUST NOT reuse them with a
different authorization server, and MUST re-register when the
authorization server changes”. The first clause is why this is a domain
fact and not a storage detail: the key is part of the contract.
client_registration: ClientRegistrationHow a client registers. See ClientRegistration.
Implementations§
Source§impl AuthorizationModel
impl AuthorizationModel
Sourcepub const fn audience_bound(self) -> bool
pub const fn audience_bound(self) -> bool
Whether a token presented to this revision’s server must be audience- bound to this server’s canonical resource identifier.
True for every revision with an authorization framework, and true
regardless of Self::protected_resource_metadata — the metadata
document is how a client learns the audience, and refusing a
wrong-audience token is a separate rule that does not depend on the
client having done that discovery. 2024-11-05 is the only revision with
no authorization framework at all, and a token check with no audience
concept behind it is not a weaker check, it is a different one that this
crate does not implement.