agentleFS
Sign inStart free
ScaleDockHQScaleDockHQ/scaledock-skills/skills/shared-signals/SKILL.md

shared-signals

Skill1 starsChanged 31 days agoMITView on GitHub

Shared Signals (SSF, CAEP, RISC): send and receive security events between identity providers, apps and services. Use when building or reviewing an OpenID Shared Signals Framework transmitter or receiver: /.well-known/ssf-configuration discovery, stream management, subjects, verification events, push delivery (RFC 8935) or poll delivery (RFC 8936), and Security Event Token validation (RFC 8417). Also use it to emit or act on CAEP events such as session-revoked, credential-change, token-claims-change, assurance-level-change, device-compliance-change and risk-level-change, or RISC account events; to apply the CAEP Interoperability Profile or the OpenID SSF conformance tests; and to feed OpenID Connect Back-Channel Logout into revocation. Triggers: SSF, CAEP, RISC, shared signals, continuous access evaluation, security event token, SET, secevent+jwt, sub_id, subject identifiers, RFC 9493, session revocation, logout token.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Pick the event payloads: Use the CAEP and RISC event types with their required claims.

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Shared Signals

The OpenID Shared Signals Framework (SSF) lets a transmitter send signed security events to receivers over managed streams. CAEP defines session and access events; RISC defines account events. With this skill an agent builds or reviews a transmitter or receiver, its event payloads, and its delivery and validation logic.

Follow the workflow below step by step. Every rule here comes from a source in Sources, with the section it cites. When a rule and the pinned source disagree, the source wins; when the source has a newer revision than the pin, follow the refresh steps.

Inputs (fill in, or ask before starting)

  • Role: transmitter, receiver, or both.
  • Delivery: push (urn:ietf:rfc:8935), poll (urn:ietf:rfc:8936), or both.
  • Events: which CAEP, RISC or custom event types the stream carries.
  • Profile: plain SSF 1.0, or the CAEP Interoperability Profile (pinned ID1, with the working-group draft tracked).
  • Revision: the pinned revision in Sources, unless the user names another.
  • Sources: when refreshing this skill or when a rule looks out of date, re-read every URL in Sources first, check the Shared Signals WG specifications page for a newer revision, and update the pins.

Invariants

These come from SSF 1.0 unless another document is named.

  1. Discovery is bound to the issuer (SSF §7.2, §7.2.4). Metadata lives at /.well-known/ssf-configuration, inserted between host and path. Its issuer equals the issuer URL used for discovery and the iss of every SET.
  2. Each SET is a typed JWT with one event (SSF §4.1.1, §4.2.1; RFC 8417 §2.3). The header typ is secevent+jwt. Each SET carries exactly one event in events.
  3. Subjects use sub_id, never sub (SSF §3.1, §4.1.2; RFC 9493 §4.1). The top-level sub_id holds a subject identifier with a format. New event types MUST NOT use the subject event member (§3.1.2).
  4. No exp on SETs (SSF §4.1.7). The iss matches the stream configuration (§4.1.6), and aud names the receiver (§4.1.8).
  5. Receivers validate before acting (RFC 8935 §2, SSF §4.1, RFC 8417). They check the signature against the transmitter's jwks_uri keys, then iss, aud, typ and the event type, and they ignore unknown members (SSF §4.2.3).
  6. Delivery acknowledges correctly (RFC 8935 §2.2, RFC 8936 §2). A push endpoint returns 202 with an empty body, or 400 with an err code. A poll receiver acknowledges every SET by jti.
  7. Streams are managed over authenticated HTTP (SSF §8). Creating a stream returns 201, and the receiver checks the iss in the response. Deleting a stream returns 204.
  8. Status changes are announced (SSF §8.1.5). Before pausing or disabling a stream, and when re-enabling it, the transmitter sends stream-updated. A paused stream holds events in order.
  9. Verification proves the path (SSF §8.1.4). A verification event's sub_id is opaque with the stream_id. The receiver checks that state matches, and answers invalid_state if it does not.
  10. Subject handling is privacy-safe (SSF §9.1, §9.3). An add-subject success does not mean the subject exists or that events will follow. Receivers tolerate events for subjects they removed.

Workflow

  1. Pin role, delivery, events and profile. Record the inputs. ✓ The event list and delivery method are named for each stream.
  2. Model SETs and subjects. Build or parse the SET claims and subject identifiers. -> references/sets-and-subjects.md ✓ Every SET has typ secevent+jwt, one event, a sub_id, and no sub or exp.
  3. Pick the event payloads. Use the CAEP and RISC event types with their required claims. -> references/events.md ✓ Each event carries its required claims, using the spec's values.
  4. Implement the transmitter. Metadata, stream configuration, status, subjects, verification and delivery. -> references/transmitter.md ✓ The well-known document, stream CRUD, status and verify endpoints answer with the status codes in the reference.
  5. Implement the receiver. Discovery, stream creation, SET validation and push or poll handling. -> references/receiver.md ✓ A SET with a bad signature, wrong iss, wrong aud or wrong typ is rejected with the RFC 8935 error code.
  6. Apply the CAEP Interoperability Profile if required. It pins mandatory endpoints, scopes, formats, algorithms and use cases. -> references/caep-interop.md ✓ Every MUST in the profile for the chosen role holds.
  7. Connect Back-Channel Logout if relevant. Validate logout tokens and map them to session revocation. -> references/backchannel-logout.md ✓ Logout tokens are validated per Back-Channel Logout §2.6 and end the matching sessions.

Verify before done

  • GET /.well-known/ssf-configuration returns metadata whose issuer equals the discovery URL issuer.
  • Every SET header has typ: secevent+jwt; every payload has iss, jti, iat, aud, sub_id and exactly one event, and no sub or exp.
  • The receiver rejects a SET signed with an unknown key, with a wrong iss or aud, or with an unknown critical subject member.
  • Push returns 202 with no body on success, and 400 with err and description on failure.
  • Poll acknowledges each processed jti and reports failures in setErrs.
  • A verification request returns 204, and the resulting event echoes state.
  • Pausing or disabling a stream emits stream-updated first.
  • If the CAEP Interoperability Profile applies, the SSF conformance test plan for the role passes.

Reference index

  • references/sets-and-subjects.md: RFC 8417 SET claims, SSF restrictions, RFC 9493 subject formats and complex subjects.
  • references/events.md: CAEP and RISC event types, their claims, and the SSF stream events.
  • references/transmitter.md: metadata, stream management API, status, subjects, verification and delivery.
  • references/receiver.md: discovery checks, stream creation, SET validation, push and poll handling, with TypeScript.
  • references/caep-interop.md: CAEP Interoperability Profile ID1, the working-group draft changes, and SSF conformance testing.
  • references/backchannel-logout.md: OpenID Connect Back-Channel Logout tokens and validation.

Related skills

  • jwt for JWS signing and verification of SETs: npx skills add ScaleDockHQ/scaledock-skills --skill jwt.
  • oauth for the access tokens that protect the stream management API: npx skills add ScaleDockHQ/scaledock-skills --skill oauth.
  • openid-connect for the sessions and logout that CAEP events revoke: npx skills add ScaleDockHQ/scaledock-skills --skill openid-connect.
  • openid for an overview of OpenID Foundation specifications: npx skills add ScaleDockHQ/scaledock-skills --skill openid.
  • fapi for high-security OAuth deployments that consume these signals: npx skills add ScaleDockHQ/scaledock-skills --skill fapi.

Sources

Status uses the publishing body's own maturity term. Checked is the date the source was last read.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free