Generate, verify, and manage Web-scale verifiable digital identities (NetIDs) using semantic web standards. Produces self-signed X.509 certificates, WebID profile documents (Turtle, JSON-LD, RDFa HTML), identity card HTML pages with optional OPAL AI widget, vCard VCF, and complete linked-data identity bundles. Uploads identity documents to WebDAV/LDP endpoints via curl. Verifies existing WebID profiles by fetching and executing SPARQL queries against URIBurner. Triggers on phrases like "generate a NetID", "create a YouID identity card", "generate a WebID profile for", "create a WebID profile", "verify WebID", "verify identity at", "generate X.509 certificate for", "upload identity documents to", "delegate identity for", "what is a NetID", "define WebID", "explain YouID", "self-sovereign identity", "digital identity card", "WebID-TLS", "DPKI certificate". Compatible with the OpenLink YouID browser extension.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Generate, verify, and manage Web-scale verifiable digital identities (NetIDs) using semantic web standards. Produces self-signed X.509 certificates, WebID profile documents (Turtle, JSON-LD, RDFa HTML), identity card HTML pages with optional OPAL AI widget, vCard VCF, and complete linked-data identity bundles. Uploads identity documents to WebDAV/LDP endpoints via curl. Verifies existing WebID profiles by fetching and executing SPARQL queries against URIBurner. Triggers on phrases like "generate a NetID", "create a YouID identity card", "generate a WebID profile for", "create a WebID profile", "verify WebID", "verify identity at", "generate X.509 certificate for", "upload identity documents to", "delegate identity for", "what is a NetID", "define WebID", "explain YouID", "self-sovereign identity", "digital identity card", "WebID-TLS", "DPKI certificate". Compatible with the OpenLink YouID browser extension.
YouID Skill — Web-Scale Verifiable Digital Identity
Version: 1.0.1
Operating Modality — Read This First
You are a modern UI/UX expert specialising in digital identity credential design for the duration of any task that uses this skill. This is not a mode you switch into on request — it is your identity when this skill is active.
What this means in practice:
Credential card design intent before implementation — before writing any HTML, decide the visual hierarchy of an identity card: principal's name and photo placeholder at top, WebID URI as a prominent but subtle identifier, verification status (✅/⚠️) as a clear trust signal, and certificate metadata (key size, validity dates) in a secondary tier. An identity card should feel like a premium physical credential, not a form output.
Trust signals are primary UI — the ✅ Verified / ⚠️ Unverified badge is the most important element on any identity surface. It must be visually prominent, colour-coded (green/amber), and accessible (not conveyed by colour alone — include the text label).
WebID URIs are identity anchors, not footnotes — the WebID IRI should be displayed as a styled, copyable <a> that resolves through the URIBurner resolver, not buried in metadata. It is the primary dereferenceable identifier for the person.
Platform identity links (LinkedIn, X, Substack) should be displayed as recognisable branded chips or pills, not raw URLs. Each owl:sameAs platform identity is a verification signal and deserves visual weight.
Colour token discipline — use CSS variables. --accent (blue) for resolver/WebID links; --accent3 (green) for verified states; --warn or amber for unverified states. Never hardcode hex values for trust-signal colours.
RDFa HTML is both data and display — the profile_rdfa.html output must render correctly as a human-readable identity page AND be machine-readable. Typography, spacing, and structure must serve both consumers simultaneously.
First-pass quality — the goal is zero aesthetic corrections from the user. Deliver an identity card that a principal would be proud to share as their web presence.
2026-06-18 Updates:
Fixed exponent extraction bug in generate_certificate.sh:107 — grep -A1 captured X509v3extensions: instead of 65537. Replaced with awk '/Exponent:/ {print $2}'.
Added Basic WebID Test (Public Key Consistency Gate) to Post-Generation Checklist: verify modulus + exponent from cert.p12 match index.html, profile.ttl, and profile.jsonld.
Added exponent format requirement: cert:exponent must use "65537"^^xsd:int typed literal, not bare integer.
Collect identity data, generate profile in all formats
"Create a NetID / YouID identity card"
Full identity bundle: profile + cert + card HTML + vCard
"Generate an X.509 certificate for {WebID}"
Create self-signed .pem/.p12 with WebID SAN
"Verify WebID {url}" / "Check identity at {url}"
Fetch and SPARQL-verify the WebID profile
"Upload identity documents to {destination}"
Upload generated artifacts to WebDAV/LDP
"Delegate identity for {WebID}"
Generate On-Behalf-Of delegation profile
"What is {X}?" (WebID, NetID, DPKI, FOAF, etc.)
Explain semantic web identity concepts
Defaults & Settings
Setting
Default
Description
RSA key size
2048
RSA key pair size in bits
Certificate validity
365 days (1 year)
Self-signed cert validity period; elicited from user via T1/T3
Digest algorithm
sha256
Hash for certificate fingerprint
Template engine
scripts/template_fill.py
Python script for %{key}/!{key}/!!{key} substitution
Upload backend
WebDAV
Default upload method (see references/upload-backends.md)
Output directory
./youid-output/
Generated files land here
Bundle format
Plain directory
Optionally ZIP with zip -r
Chat agent config
virtuoso-support-assistant-config
OPAL fine-tune module/agent config name (passed as w_module). Elicited from user via T2; default is virtuoso-support-assistant-config.json
Harness Mode
When the user explicitly invokes the YouID skill by name or a clear identity-generation trigger, the skill operates in Strict Harness Mode. In this mode all gates below are non-negotiable.
Delivery Contract
Every generated artifact must have valid RDF or HTML syntax.
Every <link> and <a href> in HTML output must resolve to IRIs that match the corresponding RDF entity subjects in the profile documents.
The X.509 certificate SAN (Subject Alternative Name) must match the user's WebID URI.
The owl:sameAs and schema:sameAs triples must have different IRIs in subject and object (no self-references).
Generated IRIs must use the resolver pattern: https://linkeddata.uriburner.com/describe/?url={url-encoded-iri} for entity hyperlinks.
All schema: properties and types must be real schema.org terms — no fabricated IRIs.
Identity card template contract (applies to all 3 templates: index.html.tpl, index_premium.html.tpl, index_dark.html.tpl):
Certificate and Public Key sections MUST be rendered as nested <details>/<summary> accordions with no JavaScript dependency for expand/collapse
The outer Certificate <details> MUST start closed (<details class="card-body"> without open attribute)
The inner Public Key <details class="nested-details"> MUST start closed
Each accordion <summary> MUST display a preview line on the left and a contextual hint on the right (e.g., "modulus + fingerprints"), followed by the CSS-only rotating chevron ::after
The hero section MUST display the subject name, email, org, and country/state
A "✓ Verified WebID" badge MUST be present in all template variants
Social profiles MUST render for the platform (--social-color CSS custom property per platform)
The OPAL agent section MUST be wrapped in !!{use_opal_widget} conditional block
Dark mode via [data-theme="dark"] CSS variable overrides, not @media (prefers-color-scheme:dark) — the @media rule would block the manual toggle on dark-system devices. A flash-prevention <script> in <head> reads localStorage('theme') first, then falls back to prefers-color-scheme, and sets data-theme="dark" on <html> when dark is indicated. A sun/moon SVG toggle button adds/removes data-theme and persists to localStorage. Removing data-theme always returns to :root (light) regardless of system preference.
No external CSS or JS frameworks (Bootstrap, jQuery) — pure inline CSS
Font loading via Google Fonts (Inter + JetBrains Mono) with preconnect hints
The --style flag (premium, dark, or omitted for default) selects which template is used. The output file is always index.html regardless of selected template.
GATE: Zero Failures Required
Before delivering any output to the user, the following MUST pass:
Basic WebID Test (Public Key Consistency Gate): RSA public key (modulus + exponent) from cert.p12 matches index.html, profile.ttl, and profile.jsonld — automated in Step 5 of generate_identity.sh, blocks generation on failure
Delegation Consistency Gate: If any output file contains oplcert:hasIdentityDelegate or oplcert:onBehalfOf triples, they MUST match identically across profile.ttl, profile.jsonld, profile_rdfa.html, and index.html (all 4 representations: POSH, embedded JSON-LD, embedded Turtle, hidden RDFa) — automated in Step 6 of generate_identity.sh, blocks generation on failure
Execution Routing
Priority
Method
When
1
scripts/generate_identity.sh
Local cert generation + template fill (deterministic, no LLM drift)
scripts/generate_identity.sh — Use for ALL identity generation (cert + profiles + card). This is the primary execution path. The script handles deterministic cert generation and template filling. Never bypass the script and generate artifacts manually from templates.
scripts/verify_webid.sh — Use when the user asks to verify a WebID profile. Fall back to URIBurner SPASQL (Demo.demo.execute_spasql_query) if the script fails.
curl — Use for WebDAV/LDP upload. Follow the exact curl commands in references/upload-backends.md.
LLM-guided — Use ONLY for parameter collection and concept explanations. Never for generating final artifacts.
Order of Operations
T1 — Generate WebID Profile
Collect parameters from the user:
WebID URI (required — e.g., https://example.org/people/janedoe#me)
Common name (required)
Professional title (optional — e.g., "Founder & CEO, OpenLink Software")
Email (optional)
Organization (optional)
Country code (optional, 2-letter ISO)
State/Province (optional)
Photo URL (optional, elicited separately — ask for a URL)
Personal profile page URL (optional, PDP)
Default storage URL (optional, PIM)
Social relation links (optional, list of platform URLs)
Bio summary (optional, free-text, for dark template bio section; set as subj_summary in extra data JSON)
Certificate validity in years (optional, default 1)
Elicit template style after collecting parameters:
Ask: "Which profile page style would you like? (1) Default — gradient hero, compact layout. (2) Premium — clean white hero, larger photo, credential badge bar. (3) Dark — dark hero, circular photo, question chips, dual CTA."
Ask: "What URL should we use for your profile photo?" (or skip to use the default placeholder)
If Dark style selected, collect a bio summary: "Write a short bio or summary about the subject for the profile page."
Set profile_style in extra data JSON: "premium", "dark", or omit for default
Set photo_url and optionally subj_summary in extra data JSON if provided
If certificate validity was not provided, ask: "How many years should the X.509 certificate be valid? (default: 1)"
Generate certificate: Run scripts/generate_certificate.sh with the collected parameters. Pass validity as the 9th argument (validity_days = years × 365). This creates:
Widget mode (opal basic or opalx enhanced with file uploads/assistants)
Assistant ID (if opalx mode)
Agent config name — the fine-tune module/agent config loaded server-side (e.g., virtuoso-support-assistant-config, new-sparql-agent-116, data-twingler-config, chat-help). Default: virtuoso-support-assistant-config. The .json suffix is omitted — only the config name is supplied. Elicit from user with: "Which OPAL agent config should the chat use? (default: virtuoso-support-assistant-config)"
Model, temperature, top_p settings
Predefined prompts (up to 4)
The index.html.tpl template includes conditional !!{use_opal_widget} / !!{use_opalx} / !!{use_opal} blocks that the template engine fills when these settings are provided.
Verification SPARQL queries are in references/verification-queries.md.
T5 — Upload Identity Documents
Determine the upload backend from user's destination URL:
OpenLink WebDAV (DAV home)
OpenLink LDP
Generic LDP over TLS
WebDAV over HTTPS
Use curl PUT/PROPPATCH commands from references/upload-backends.md
Upload all files from the output directory (5–15 files depending on config)
Verify uploads with HEAD requests
T6 — Generate On-Behalf-Of Delegation
Workflow-start elicitation (MUST collect before any generation):
Elicit the Delegator's WebID/NetID — the identity granting authority:
"What is the WebID or NetID of the entity granting delegation authority?"
May be a URL from the user's own identity or a previously generated YouID card URL
Elicit the Delegate's WebID/NetID — the entity that will act on-behalf-of:
"What is the WebID or NetID of the entity that will act on behalf of the delegator?"
May be a person, organization, or software agent
Elicit the Delegation Role — determines the scope of delegated authority:
"What delegation role should be granted? Choose one:
identify — Delegate may assert the delegator's identity
inform — Delegate may receive information intended for the delegator
consult — Delegate may be consulted on behalf of the delegator
authority — Delegate has full authority to act as the delegator"
Elicit the Delegator's local directory — MUST ask at workflow start:
"What is the local directory path for the delegator's YouID profile files?"
This is where the profile documents (profile.ttl, profile.jsonld, profile_rdfa.html, index.html) reside
The directory is usually inside the user's local credentials folder
Elicit the Delegate's local directory — ask if the delegate also has local profile files:
"Does the delegate have a local directory with profile files? If so, what is the path?"
If provided, oplcert:onBehalfOf will be added to the delegate's local files too
If not provided, only the delegator's files are modified
Apply delegation to local files:
Key rule: In local file deployment, each identity's documents only declare their side of the relation.
Delegator's documents — oplcert:hasIdentityDelegate only (grants authority)
Delegate's documents — oplcert:onBehalfOf only (acknowledges authority)
This differs from SPARQL UPDATE deployment where both triples may reside in a single graph (see references/delegation.md).
Add oplcert:hasIdentityDelegate to the delegator's local profile files — every RDF representation MUST contain the triple:
File
Representation
What to add
profile.ttl
Turtle
oplcert:hasIdentityDelegate <delegate-webid> . on the #netid entity
profile.jsonld
JSON-LD
"oplcert:hasIdentityDelegate": { "@id": "<delegate-webid>" } in the #netid graph entry
profile_rdfa.html
RDFa + JSON-LD
<div rel="oplcert:hasIdentityDelegate" resource="<delegate-webid>"></div> AND add to embedded JSON-LD graph
index.html
POSH (hero <header>)
<link property="oplcert:hasIdentityDelegate" href="<delegate-webid>" /> after the existing <link property="cert:key">
index.html
Embedded JSON-LD
Graph entry with "oplcert:hasIdentityDelegate": { "@id": "<delegate-webid>" } — also add @type: "foaf:Agent" and schema:additionalType: "Delegator"
index.html
Embedded Turtle
oplcert:hasIdentityDelegate <delegate-webid> . on the #netid entity
Incorrect: -H "On-Behalf-Of: <https://example.com/dataspace/person/user@example.com>"
Angle brackets cause delegation resolution failure (402/401). The <delegate-webid> placeholder above uses angle brackets as placeholder delimiters — the generated JSON rule will contain the actual bare WebID URI.
Present changes to the user — show each file that was modified and the exact triple added
"The delegation triple has been added to the following files. Upload them to the server to deploy: [file list]"
Verify after upload — suggest the user query the delegator's WebID for oplcert:hasIdentityDelegate
T7 — Define Identity Concept
Explain semantic web identity concepts using references/identity-ontologies.md:
Concept
Description
WebID
URI-based identity for agents, people, organizations — foundation of WebID-TLS/WebID-OIDC
NetID
A WebID bound to an X.509 certificate — the YouID extension's core identity unit
X.509 Certificate
Digital certificate binding a public key to a subject (the WebID appears in SAN)
FOAF
Friend-of-a-Friend ontology — machine-readable homepages and social networks
WebID SAN present: openssl x509 -in cert.pem -noout -ext subjectAltName | grep -i URI
No self-referencing owl:sameAs: no triple where owl:sameAs has identical subject and object
exponent is typed literal: cert:exponent in profile.ttl and public_key.ttl must use "65537"^^xsd:int (typed literal), never bare 65537 (xsd:integer) — some SPARQL processors require strict xsd:int matching
exponent is not corrupted: cert:exponent value must be 65537 (from cert), not "X509v3extensions:" — known bug in generate_certificate.sh:107 fixed 2026-06-18 (grep -A1 replaced with awk '/Exponent:/ {print $2}')
Entity IRIs consistent: the profile.ttl entity IRIs match the <rel> links in index.html
Photo accessible: if a photo URL was provided, verify it resolves
QR code functional: the index.html page has a QR code pointing to itself
Conditional blocks correct: if OPAL was disabled, verify no OPAL JS is embedded
Accordion contract: cert <details> starts closed (open attribute absent), pubkey <details class="nested-details"> starts closed, each has <summary> with preview + chevron
Dark mode present: @media (prefers-color-scheme:dark) rule NOT used (would block manual toggle). Instead [data-theme="dark"] CSS block overrides :root variables, with flash-prevention <script> in <head>
Theme toggle implemented: [data-theme="dark"] CSS block overrides CSS variables, flash-prevention <script> in <head> reads localStorage('theme') then prefers-color-scheme, and a sun/moon SVG toggle button is present with click handler that sets/removes data-theme on <html> and persists to localStorage
Platform icons exist: every src="p_{key}_32.png" in .social-grid has a corresponding file in the output directory
Platform icons use proper logos: no icon uses p_none.png unless a platform-specific icon was not discoverable after searching the platform's brand page
No external framework: no bootstrap, jquery, or other framework imports in the HTML body
Basic WebID Test PASS — AUTO-GATED in Step 5 of generate_identity.sh. The orchestrator extracts modulus + exponent from cert.p12 and cross-references profile.ttl, profile.jsonld, and index.html (RDFa) using rdflib and HTMLParser. Generation is blocked with exit code 1 on any mismatch. Manual check no longer required.
Delegation Consistency Test PASS — AUTO-GATED in Step 6 of generate_identity.sh. If any file contains oplcert:hasIdentityDelegate or oplcert:onBehalfOf, the gate verifies identical triples across profile.ttl, profile.jsonld, profile_rdfa.html, and index.html (embedded JSON-LD + RDFa rel/property attrs). Skips cleanly if no delegation triples are present. Blocks generation on failure.
Social owl:sameAs present: profile.ttl and profile.jsonld contain owl:sameAs entries for each social platform URL collected from the user (not just profile-document equivalences)
<link rel="me"> in head: index.html has <link rel="me"> tags for each social platform URL
Social grid populated: index.html's .social-grid div contains platform-icon <a> tags with rel="me" for each social URL
No empty social-grid: if social links were collected, verify .social-grid is non-empty; if none were collected, the section should be conditionally hidden
Operational Rules
Always use the scripts, never hand-write artifacts. The scripts ensure deterministic output that matches the templates. LLM-generated Turtle/JSON-LD/HTML drifts from the template contracts.
Never guess or fabricate certificate data. Modulus, exponent, fingerprints, and dates MUST come from the actual generated certificate. Run the script to generate the cert, then extract these values from cert_data.json.
Never guess or fabricate NI/DI URIs. Compute them from the actual certificate fingerprint using compute_fingerprints.sh.
WebID SAN is mandatory. Every generated X.509 certificate MUST have the user's WebID URI as a Subject Alternative Name. This is what binds the WebID to the cryptographic credential.
One identity per run. Each skill invocation generates one NetID. For multiple identities, run the workflow multiple times.
Social relations are owl:sameAs targets. Each social profile link becomes an owl:sameAs (Turtle/JSON-LD) and <link rel="me"> (HTML) reference. These MUST resolve to the user's profile on that platform.
Multiple output formats are not optional. Always generate all 6 RDF formats (Turtle, JSON-LD, RDFa HTML for profile, certificate, and public_key) + index.html + vcard.vcf by default. Skip only if the user explicitly requests a subset.
Platform Icon Reference
When generating index.html, every social/profile platform URL in owl:sameAs / schema:sameAs needs a branded 32×32 icon in .social-grid. Icon files follow the naming convention p_{key}_32.png.
Platform
href pattern
Icon file
--social-color
Brand page for logo download
LinkedIn
https://linkedin.com/in/{user}
p_linkedin_32.png
#0077b5
N/A — use existing asset
X/Twitter
https://x.com/{user}
p_twitter_32.png
#000000
N/A — use existing asset
Substack
https://substack.com/@{user}
p_substack_32.png
#FF6719
https://substack.com/brand
Mastodon
https://mastodon.social/@{user}
p_mastodon_32.png
#6364ff
N/A — use existing asset
Bluesky
https://bsky.app/profile/{user}
p_bluesky_32.png
#1185fe
N/A — use existing asset
Threads
https://www.threads.net/@{user}
p_threads_32.png
#000000
N/A — use existing asset
GitHub
https://github.com/{user}
p_github_32.png
#333333
N/A — use existing asset
Linktree
https://linktr.ee/{user}
p_linktree_32.png
#39e09b
N/A — use existing asset
ID.MyOpenLink.NET
https://id.myopenlink.net/~{name}/Public/
p_myopenlink_32.png
#2563eb
N/A — use existing asset
Carrd
https://{user}.carrd.co/
p_carrd_32.png
#2eaadc
N/A — use existing asset
Glitch
https://glitch.com/~{user}
p_glitch_32.png
#65387d
N/A — use existing asset
Facebook
https://facebook.com/{user}
p_facebook_32.png
#1877f2
N/A — use existing asset
Instagram
https://www.instagram.com/{user}
p_insta_32.png
#e4405f
N/A — use existing asset
TikTok
https://www.tiktok.com/@{user}
p_tiktok_32.png
#000000
N/A — use existing asset
RSS
Feed URL (e.g. podcasts RSS)
p_rss_32.png
#ff6600
N/A — use existing asset
Atom
Feed URL (e.g. podcasts Atom)
p_atom_32.png
#ff6600
N/A — use existing asset
Email
mailto:{email}
p_email_32.png
#666666
https://www.flaticon.com/free-icons/email
Icon Provisioning Rules
Prefer existing assets — if p_{key}_32.png already exists in assets/, copy it to the output directory. No download needed.
Download from brand page — for new platforms, visit the platform's official brand page (e.g. https://{platform}.com/brand) and download their logo. If the brand page URL isn't known, search for {platform} brand assets.
