pub enum ClientRegistration {
None,
Dynamic,
DynamicOrMetadataDocument,
MetadataDocument,
}Expand description
How a client is expected to register with an authorization server.
Not a bitmask because the three states are a progression, not a set: a
client that treats 2026-07-28 as “both work” would send a Dynamic Client
Registration request to a server that has been told to deprecate it, and a
server that rejects it looks like a broken server rather than a wrong client.
Variants§
None
The revision specifies no authorization framework at all.
2024-11-05. Its vendored changelog has no authorization entry, so a
client that registers against an OAuth server is doing something the
revision never asked for.
Dynamic
RFC 7591 Dynamic Client Registration.
2025-03-26 and 2025-06-18. The framework was introduced here
(2025-03-26 changelog §1, PR #133) with no alternative registration
mechanism named, so this is what those revisions’ servers implement.
DynamicOrMetadataDocument
Both, with Client ID Metadata Documents recommended.
2025-11-25 changelog §8 (SEP-991, PR #1296) adds Client ID Metadata
Documents as a recommended registration mechanism and does not deprecate
Dynamic Client Registration, so a client may use either. Prefer
Self::preferred over “either” when choosing.
MetadataDocument
Client ID Metadata Documents; Dynamic Client Registration deprecated.
2026-07-28 changelog §4 (PR #2858) deprecates RFC 7591 “in favor of”
Client ID Metadata Documents, keeping it only “for backwards
compatibility with authorization servers that do not support” them. So
this is a preference with a fallback, not a removal — see
Self::supports_dynamic.
Implementations§
Source§impl ClientRegistration
impl ClientRegistration
Sourcepub const fn supports_dynamic(self) -> bool
pub const fn supports_dynamic(self) -> bool
Whether a client may register through RFC 7591.
true even for Self::MetadataDocument: the deprecation is a
statement about what the spec prefers, and the spec keeps the mechanism
for servers that do not implement the replacement. A client that
refused outright would fail against those servers, and a server that
implements only RFC 7591 is not misconfigured.
Sourcepub const fn supports_metadata_document(self) -> bool
pub const fn supports_metadata_document(self) -> bool
Whether a client may register with a Client ID Metadata Document.
Sourcepub const fn preferred(self) -> Option<Self>
pub const fn preferred(self) -> Option<Self>
The mechanism to try first.
Metadata documents wherever they exist, because a client that leads with
the mechanism its own revision deprecates is doing the wrong thing
against a server that supports both. Falls back to dynamic registration
only where documents are not defined, so this never returns
Self::None for a revision that can register at all.
Sourcepub const fn fallback(self) -> Option<Self>
pub const fn fallback(self) -> Option<Self>
What to try after self did not work, or None at the end of the list.
The second half of Self::preferred: a client has to be able to fall
back, and Self::MetadataDocument is precisely the revision whose
servers may still implement only RFC 7591.
Sourcepub const fn application_type_required(self) -> bool
pub const fn application_type_required(self) -> bool
Whether application_type must be sent during registration.
2026-07-28 changelog §8 (SEP-837): clients “MUST specify an
appropriate application_type during Dynamic Client Registration to
avoid OpenID Connect redirect URI conflicts”. A MUST, so this is
about revisions that require the field, not about ones that tolerate it.