StoredUriValidator Class

Refuses a registration carrying a relative URI in any member, so no address is stored on a client without something having read it.

public class StoredUriValidator : Abblix.Oidc.Server.Endpoints.DynamicClientManagement.Validation.SyncClientRegistrationContextValidator

Inheritance System.Object → SyncClientRegistrationContextValidator → StoredUriValidator

Remarks

Every URI member is named here, including the ones another validator also looks at. Those others are each GATED on something that is not the address - a pairwise subject type, a TLS authentication method, a backchannel delivery mode, a grant type that redirects - so a registration naming none of those walks past them with the member stored. What is asked here is asked unconditionally.

What makes this a defect rather than tidiness is frontchannel_logout_uri. A relative value reaches FrontChannelLogoutService, which builds the logout page's frame-source policy with System.Uri.GetLeftPart(System.UriPartial) - and that raises on a relative URI, unconditionally, at logout rather than at registration.

ABSOLUTENESS only. The scheme requirements in this pipeline are conditional - a native client's redirect URI carries its own, a fetched address answers to the deployment's policy - and the validators that own those conditions already state them. What is unconditional is that a stored address must name somewhere.

The list is written out rather than reflected over, because a reader of this file should be able to see what is checked. What keeps it from falling behind - which it did twice while it was shorter - is UriMemberCoverageTests, which finds every URI member on the model by its TYPE and requires this validator to refuse a relative value in each. A member added without a line here fails that row.