Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
PR #67388 intentionally models RegistrationPath and RefreshPath as nonempty application-local PathString values. The handler owns those local request paths, prepends Request.PathBase when advertising them, and derives refresh-cookie scoping from the local refresh path. This is a safe, conformant server subset, but it cannot represent every URL reference allowed by DBSC.
The W3C DBSC protocol and Chromium support secure same-site absolute registration and refresh URLs. The current model therefore cannot cover a sibling endpoint origin, an alternate port, arbitrary public-to-local proxy path translation, or query-based routing.
Describe the solution you'd like
Design separate browser-advertised registration and refresh URL-reference options while retaining local handler dispatch paths. Define precedence and consistency rules between the advertised references, local paths, Request.PathBase, and refresh-cookie path.
The design should address:
- HTTPS with an explicit localhost development exception, and rejection of user-info and fragments.
- Validation of every redirect hop before forwarding DBSC proof, session, or cookie data.
- Same-site checks using Public Suffix List/registrable-domain semantics.
- Cookie Domain, Path, Secure, and SameSite applicability across the advertised topology.
- Accepted Host restrictions and trusted forwarded scheme, host, and prefix configuration.
- A non-permissive CORS posture; endpoint reachability must not imply credentialed cross-origin API access.
- Interaction with
IncludeSite, an explicit scope origin, /.well-known/device-bound-sessions, and Data Protection/ticket sharing between applications.
- Compatibility and migration behavior for the existing local
PathString options.
Required coverage should include same-origin absolute URLs, secure same-site sibling origins, alternate ports, proxy-translated paths, query routing, invalid/cross-site/insecure destinations, redirects that change site or security, cookie applicability, PathBase behavior, host filtering, trusted forwarding, and multi-application Data Protection. The design requires a security/threat review before implementation.
This is related to, but separate from, #67827: advertised endpoint location controls where protocol requests are sent, while that issue controls subdomain registration requesting registrable-domain-root site scope. See also PR #67388.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
PR #67388 intentionally models
RegistrationPathandRefreshPathas nonempty application-localPathStringvalues. The handler owns those local request paths, prependsRequest.PathBasewhen advertising them, and derives refresh-cookie scoping from the local refresh path. This is a safe, conformant server subset, but it cannot represent every URL reference allowed by DBSC.The W3C DBSC protocol and Chromium support secure same-site absolute registration and refresh URLs. The current model therefore cannot cover a sibling endpoint origin, an alternate port, arbitrary public-to-local proxy path translation, or query-based routing.
Describe the solution you'd like
Design separate browser-advertised registration and refresh URL-reference options while retaining local handler dispatch paths. Define precedence and consistency rules between the advertised references, local paths,
Request.PathBase, and refresh-cookie path.The design should address:
IncludeSite, an explicit scope origin,/.well-known/device-bound-sessions, and Data Protection/ticket sharing between applications.PathStringoptions.Required coverage should include same-origin absolute URLs, secure same-site sibling origins, alternate ports, proxy-translated paths, query routing, invalid/cross-site/insecure destinations, redirects that change site or security, cookie applicability, PathBase behavior, host filtering, trusted forwarding, and multi-application Data Protection. The design requires a security/threat review before implementation.
This is related to, but separate from, #67827: advertised endpoint location controls where protocol requests are sent, while that issue controls subdomain registration requesting registrable-domain-root site scope. See also PR #67388.