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

authzen

Skill1 starsChanged 31 days agoMITView on GitHub

AuthZEN Authorization API: PEP-to-PDP access evaluation and search over HTTPS JSON. Use when building or reviewing a Policy Enforcement Point (PEP) that asks a Policy Decision Point (PDP) for access decisions, or a PDP that implements the API: the subject, resource, action and context information model, decision and decision context, the Access Evaluation endpoint (/access/v1/evaluation), the Access Evaluations batch endpoint with default values and evaluations_semantic (execute_all, deny_on_first_deny, permit_on_first_permit), Subject, Resource and Action Search with pagination (page, next_token), PDP metadata at /.well-known/authzen-configuration and signed_metadata, HTTP error codes, X-Request-ID, PEP authentication, the interop test vectors, and the Basic, Batch, Search and Discovery certification levels. Pins the OpenID AuthZEN Authorization API 1.0 Final.

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow the workflow below step by step: Every rule here comes from a source in Sources, cited inline as (AuthZEN § section) for the …

    line 15
  2. Distinctive:

    Sources refresh: before relying on a pin, compare it with the OpenID Foundation specifications index and the latest commit of the AuthZEN …

    line 24
  3. Very specific:

    Every API call is an HTTPS POST with Content-Type: application/json and a JSON object body.

    line 28
  4. Very specific:

    Search results contain only entities of the searched type.

    line 35

≈ “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

AuthZEN Authorization API

The Authorization API lets a Policy Enforcement Point (PEP) ask a Policy Decision Point (PDP) for access decisions without either knowing the other's internals. The PDP serves the API and the PEP calls it (Authorization API § 1). It has evaluation endpoints that return decisions, search endpoints that list permitted subjects, resources or actions, and a metadata document for discovery.

Follow the workflow below step by step. Every rule here comes from a source in Sources, cited inline as (AuthZEN § section) for the specification and (Cert § anchor) for the certification scenario. If a rule is not in a source, it is not in this skill.

Inputs (fill in, or ask before starting)

  • Role: PEP (the caller), PDP (the server), or both, for example a gateway that enforces decisions from a hosted PDP.
  • Revision: Authorization API 1.0. Later revisions may add to the API but MUST NOT change 1.0 (AuthZEN § 4).
  • APIs in scope: Access Evaluation is the core feature. Access Evaluations, the three Search APIs and metadata are optional for a PDP (AuthZEN § 3, § 9.1.1).
  • PEP authentication: mutual TLS, OAuth or an API key. The choice is out of scope of the specification (AuthZEN § 11.2).
  • Certification target: none, or one or more of Basic, Batch, Search and Discovery, each with Core and Properties sub-levels (Cert § certification-levels).
  • Sources refresh: before relying on a pin, compare it with the OpenID Foundation specifications index and the latest commit of the AuthZEN repository. If a revision changed, re-read the source and update metadata.json and Sources.

Invariants

  1. Every API call is an HTTPS POST with Content-Type: application/json and a JSON object body. A successful response is 200 with Content-Type: application/json (AuthZEN § 10.1, § 10.1.1).
  2. A deny is 200 with { "decision": false }. The error codes 400, 401, 403 and 500 describe the request or its processing and never mean deny (AuthZEN § 10.1.2).
  3. decision: false MUST NOT be permitted to go forward. A PEP MAY reject decision: true when it does not understand the decision context (AuthZEN § 5.5).
  4. A Subject and a Resource each need string type and id, with id scoped to type. An Action needs a string name. properties is an optional object (AuthZEN § 5.1, § 5.2, § 5.3).
  5. An evaluation request needs subject, action and resource, and context is optional (AuthZEN § 6.1). A PDP returns 400 Bad Request when a required attribute is missing (AuthZEN § 10.1.1).
  6. In a batch, the top-level subject, action, resource and context are defaults that each evaluation may override. Decisions come back in request order. With no evaluations array, or an empty one, the request behaves as a single evaluation (AuthZEN § 7.1, § 7.1.1, § 7.2).
  7. Per-item errors in a batch are returned as decision: false with details in that item's context. Errors about the whole payload use HTTP status codes (AuthZEN § 7.2.1).
  8. Search results contain only entities of the searched type. When a response is partial it MUST include page with next_token, and that token is an empty string after the last page (AuthZEN § 8.2.2, § 8.3).
  9. The policy_decision_point in metadata MUST equal the identifier used to build the metadata URL, or the metadata MUST NOT be used (AuthZEN § 9.2.3).
  10. The PEP–PDP connection MUST be secured, for example with TLS. The PDP SHOULD authenticate the PEP and answers a failed authentication with 401, which SHOULD carry WWW-Authenticate (AuthZEN § 11.1, § 11.2, § 11.3).

Workflow

  1. Model the request. Map your principal, target, operation and environment to subject, resource, action and context. -> references/information-model.md ✓ Every subject and resource has a string type and id, and every action has a name.
  2. Call or serve the Access Evaluation API. -> references/evaluation-apis.md ✓ A deny returns 200 with decision: false, and a missing subject, action or resource returns 400.
  3. Add the Access Evaluations API when you batch. -> references/evaluation-apis.md ✓ Tests cover default inheritance, per-item override, response order, an empty array, and each evaluations_semantic value.
  4. Add the Search APIs when you list permitted entities. -> references/search-apis.md ✓ The searched entity carries no id (or it is ignored), Action Search omits action, and pagination ends with an empty next_token.
  5. Publish or consume PDP metadata. -> references/metadata-transport.md ✓ The PEP compares policy_decision_point with the identifier it used, and falls back to the default paths when an endpoint is not published.
  6. Secure the transport. Authenticate the PEP, echo X-Request-ID, and limit payload size and request rate. -> references/metadata-transport.md ✓ An unauthenticated call returns 401 with WWW-Authenticate, and a request carrying X-Request-ID gets the same value back.
  7. Check conformance. Load the certification fixture and run the interop vectors that match your scope. -> references/conformance.md ✓ The eight fixture decisions hold and the prerequisites for each certification sub-level are met.

Verify before done

  • Every request and response body is a JSON object over HTTPS POST, with application/json both ways (AuthZEN § 10.1).
  • A deny is always 200 with decision: false, never an HTTP error status (AuthZEN § 10.1.2).
  • Per-item batch errors come back as decision: false with details in context (AuthZEN § 7.2.1).
  • The PEP enforces decision: false, and decides what to do with a context it does not understand (AuthZEN § 5.5).
  • Batch requests fill omitted fields from the top-level defaults, and execute_all is the default semantic (AuthZEN § 7.1.1, § 7.1.2.1).
  • Mid-pagination requests change only page.token (AuthZEN § 8.2.1).
  • Metadata unknown to the PEP is ignored, and supported signed_metadata is verified and takes precedence over plain values (AuthZEN § 9.1.3, § 9.2.2, § 9.2.3).
  • Endpoints include v1 in their path (AuthZEN § 4).
  • JSON follows I-JSON, and null properties are omitted (AuthZEN § 11.5).
  • The certification scenario and interop vectors in use match the commit pinned in Sources.

Reference index

FileCovers
references/information-model.mdSubject, Resource, Action, Context, Decision and decision context, with JSON examples
references/evaluation-apis.mdAccess Evaluation and Access Evaluations, defaults, evaluations_semantic, per-item errors, PEP and PDP sketches
references/search-apis.mdSubject, Resource and Action Search, search semantics, pagination, the response shape
references/metadata-transport.mdPDP metadata and discovery, signed_metadata, the HTTPS JSON binding, default paths, errors, X-Request-ID, security considerations
references/conformance.mdCertification levels, the required fixture, search fixture, transport and discovery requirements, interop vectors

Related skills

  • openid: the umbrella skill that routes between the OpenID Foundation specifications. npx skills add ScaleDockHQ/scaledock-skills --skill openid
  • oauth: OAuth-based authentication of the PEP to the PDP. npx skills add ScaleDockHQ/scaledock-skills --skill oauth
  • jwt: JWS and JWT processing for signed_metadata. npx skills add ScaleDockHQ/scaledock-skills --skill jwt

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