Recording this rather than fixing it inline, because loosening an issuer comparison widens who may vouch for a WebID and that deserves its own review.
The inconsistency
Two places compare origins in the Solid-OIDC path, by different rules:
| Where |
Rule |
WebIdFetchPolicy.canonicalOrigin |
scheme + host + port, lowercased, default port made explicit |
WebIdIssuerVerifier.namesIssuer |
trailing slash tolerated, otherwise verbatim |
So the fetch policy tolerates case differences and an implicit :443/:80; the issuer comparison tolerates neither.
How it bites
A WebID profile naming http://Host.Docker.Internal:3939 would pass the fetch policy and fail the issuer match. Same for https://idp.example in the profile against https://idp.example:443/ as iss, or vice versa.
The failure is a 401 with WEBID_ISSUER_NOT_NAMED, which reads as "this issuer isn't authorised" when the truth is "these two strings differ in a way one comparison forgives and the other doesn't".
Why it isn't obviously a bug
namesIssuer being strict is defensible: an issuer comparison decides who may speak for a WebID, and normalising more means admitting more. The trailing-slash tolerance already exists only because CSS emits iss with one and hand-written profiles commonly omit it — a documented, observed case rather than a general principle.
So the fix may be to make the fetch policy stricter rather than the issuer comparison looser. Or to leave both and document the asymmetry.
What I'd want from whoever takes it
- A decision on direction, not just a shared helper — the two comparisons protect different things
- If they converge, tests showing exactly which differences are forgiven, per RFC 6454 origin semantics
- The
iss values real providers emit, captured rather than assumed (CSS's is already in fixtures/css/)
Context
Surfaced while preparing the first conformance run, where one origin string appears in four places: both trusted-origins entries, the seeded solid:oidcIssuer triple, and the iss claim. Mitigated there by defining it once and interpolating — but that's discipline, not a property of the code.
Related: #148 (the policy), #152 (profile seeding), #153 (the binding fix).
Recording this rather than fixing it inline, because loosening an issuer comparison widens who may vouch for a WebID and that deserves its own review.
The inconsistency
Two places compare origins in the Solid-OIDC path, by different rules:
WebIdFetchPolicy.canonicalOriginWebIdIssuerVerifier.namesIssuerSo the fetch policy tolerates case differences and an implicit
:443/:80; the issuer comparison tolerates neither.How it bites
A WebID profile naming
http://Host.Docker.Internal:3939would pass the fetch policy and fail the issuer match. Same forhttps://idp.examplein the profile againsthttps://idp.example:443/asiss, or vice versa.The failure is a 401 with
WEBID_ISSUER_NOT_NAMED, which reads as "this issuer isn't authorised" when the truth is "these two strings differ in a way one comparison forgives and the other doesn't".Why it isn't obviously a bug
namesIssuerbeing strict is defensible: an issuer comparison decides who may speak for a WebID, and normalising more means admitting more. The trailing-slash tolerance already exists only because CSS emitsisswith one and hand-written profiles commonly omit it — a documented, observed case rather than a general principle.So the fix may be to make the fetch policy stricter rather than the issuer comparison looser. Or to leave both and document the asymmetry.
What I'd want from whoever takes it
issvalues real providers emit, captured rather than assumed (CSS's is already infixtures/css/)Context
Surfaced while preparing the first conformance run, where one origin string appears in four places: both
trusted-originsentries, the seededsolid:oidcIssuertriple, and theissclaim. Mitigated there by defining it once and interpolating — but that's discipline, not a property of the code.Related: #148 (the policy), #152 (profile seeding), #153 (the binding fix).