Module discovery 

Authorization-server discovery, and the validations that make it safe.

The chain is: PDS → /.well-known/oauth-protected-resource → issuer → /.well-known/oauth-authorization-server → endpoints.

Every link is attacker-influenced. The PDS comes from a DID document that a did:web host or plc.directory served; the issuer comes from the PDS. So each document must prove it is talking about itself:

• the protected-resource document’s resource must equal the PDS origin,
• it must name exactly ONE authorization server,
• the authorization-server document’s issuer must equal the URL it was fetched from — the mix-up defence, and the reason these documents must not be fetched through a redirect,
• and if the AS lists protected_resources, the PDS must appear in it.

The last one closes the loop in the other direction: without it a PDS can unilaterally name an authorization server that has never heard of it.

Structs

AuthorizationServer

The endpoints a validated authorization server offers.

Functions

authorization_server_url

Where an issuer’s authorization-server metadata lives.

discover

Resolve a PDS to its authorization server, both fetches and both validations.

discover_with

discover with the fetch injected.

origin_of

The origin of a URL: scheme + host + non-default port, and nothing else.

protected_resource_url

Where a PDS’s protected-resource document lives.

resolve_documents

Validate an already-fetched pair of discovery documents.

validate_authorization_server

Validate /.well-known/oauth-authorization-server and return its endpoints.

validate_issuer_form

An issuer identifier must be canonical before it can be compared.

validate_protected_resource

Validate /.well-known/oauth-protected-resource and return its issuer.