JSS conneg returns text/turtle even when application/ld+json is listed first. When Turtle is returned, the keys are separate nodes not linked from #me via cert:key, causing verification to fail.
Fix: Change to 'Accept': 'text/html' to get the HTML with embedded JSON-LD.
The code in extractCertKeys looks for cert:key on the #me node and passes each key object to parseKeyObject. However, if cert:key contains @id references like:
Still prioritizes ld+json/turtle/json over HTML. The proposed 'Accept': 'text/html' would route through the HTML-with-embedded-JSON-LD branch immediately below.
Still the strict form. <script type="application/ld+json" id="me"> won't match. Proposed <script[^>]*type=…[^>]*> fix still applies as written.
3. @id references not dereferenced (lines 59-131) — unchanged
parseKeyObject reads cert:modulus / cert:exponent directly off the key object passed in. A key value of { "@id": "#key1" } carries neither, so the function returns null and the key is silently dropped. There's no graph traversal that looks up the referenced node in the JSON-LD document to find the actual modulus/exponent.
Interaction worth noting
Fixes 1 and 2 compose: even after loosening the regex, the HTML branch at webid-tls.js:158-160 only runs when contentType.includes('text/html'), which depends on the server returning HTML — which is unlikely while the Accept header still prioritizes ld+json. Fix the Accept header first, then the regex matters.
Fix 3 is independent and applies regardless of input format (Turtle parsed to JSON-LD, or JSON-LD/HTML directly).
Suggestion
Keep open — work is needed. Fix-order: (1) Accept header → (2) regex → (3) @id dereferencing. The first two are one-liner edits + a focused test each; the third is more design work (a small JSON-LD node-lookup helper, or just promoting @id references to a "follow these" pass before parseKeyObject).
Happy to take this on if it's the right priority — let me know.
Activity
fix(webid-tls): improve HTML profile parsing
melvincarvalho commented on Jun 7, 2026
Findings (2026-06-07): all three bugs still reproduce verbatim
Re-checked src/auth/webid-tls.js against the three issues described here. Nothing has changed — every cited line is still as filed.
1. Accept header (line 142) — unchanged
Still prioritizes ld+json/turtle/json over HTML. The proposed 'Accept': 'text/html' would route through the HTML-with-embedded-JSON-LD branch immediately below.
2. JSON-LD regex (line 160) — unchanged
Still the strict form. <script type="application/ld+json" id="me"> won't match. Proposed <script[^>]*type=…[^>]*> fix still applies as written.
3. @id references not dereferenced (lines 59-131) — unchanged
parseKeyObject reads cert:modulus / cert:exponent directly off the key object passed in. A key value of { "@id": "#key1" } carries neither, so the function returns null and the key is silently dropped. There's no graph traversal that looks up the referenced node in the JSON-LD document to find the actual modulus/exponent.
Interaction worth noting
Fixes 1 and 2 compose: even after loosening the regex, the HTML branch at webid-tls.js:158-160 only runs when contentType.includes('text/html'), which depends on the server returning HTML — which is unlikely while the Accept header still prioritizes ld+json. Fix the Accept header first, then the regex matters.
Fix 3 is independent and applies regardless of input format (Turtle parsed to JSON-LD, or JSON-LD/HTML directly).
Suggestion
Keep open — work is needed. Fix-order: (1) Accept header → (2) regex → (3) @id dereferencing. The first two are one-liner edits + a focused test each; the third is more design work (a small JSON-LD node-lookup helper, or just promoting @id references to a "follow these" pass before parseKeyObject).
Happy to take this on if it's the right priority — let me know.