Exercise · Trust and Authorization

A short, guided task. Complete it before moving on to the lab.

See the Open Engineering Language Server (OELS) onboarding guide for the local install and editor setup.

TipOELS in your editor

While you work through this content, keep the Open Engineering Language Server (OELS) active in VS Code (or any LSP-capable editor). See the OELS onboarding guide linked at the top of this page (also linked from the academy Resources page) for the one-time install and configuration steps.

What OELS validates. OELS only recognizes OE-shaped YAML/JSON: files with a mapping root that declare an apiVersion beginning with open-engineering.io/, a non-empty kind, and a DNS-1123 metadata.name. Ordinary academy metadata.yaml, Quarto/QMD pages and front matter, Kubernetes/Crossplane/runtime manifests, JSON payload samples, and shell scripts are intentionally non-OE — OELS ignores them silently and you should not add synthetic apiVersion/kind headers to force recognition.

Where you see diagnostics. OELS surfaces UnknownProperty, MissingRequiredProperty, IncorrectType, InvalidEnumValue, MalformedIdentifier, UnknownDefinition, and reference-shape hints in the editor Problems panel as you type. These are independent of quarto render: OELS diagnostics do not block rendering, and Quarto errors do not appear in the Problems panel.

The executable check still comes from this exercise. OELS speeds up editing, but the exercise’s own parser, verifier, or verify.sh (for example the pico parse … command shown below) remains the authoritative success check. Run it as usual.

Task

For the relationship you established in the Cross-Mesh Communication lesson, write a channel policy that keeps identity and authorization separate.

Start with a policy that grants a peer relationship read-only access:

# policy-trust.yaml
policy:
  subject: did:peer:rel-alice-bob
  channel: subscription
  allow:
    - event: temperature-reading
      action: observe

Then sketch what an identity-aware authorization decision would look like in the future — where the authenticated identity behind the channel (not just the channel) participates in the decision:

# policy-identity-aware.yaml
authorization:
  subject:
    did: did:peer:rel-alice-bob
    credentials: []
    relationship: subscription
  resource: temperature-sensor
  action: observe
  context:
    mesh: engine-b.example.com
  decision: permit

Note

The identity-aware form is illustrative of a future layer, not a current format. The goal is to feel the difference between channel-only policy and identity-aware policy.

Success criteria

• Your channel policy authorizes based on a peer DID and a channel.
• Your identity-aware sketch includes the authenticated identity, credentials, relationship, and requested action.
• You can state the principle “identity establishes who; policy establishes what” in your own words.

Automatable check

Validate both snippets parse:

pico parse policy-trust.yaml --out /tmp/p1.json \
  && echo "OK: channel policy parses"
pico parse policy-identity-aware.yaml --out /tmp/p2.json \
  && echo "OK: identity-aware policy parses"

Both commands exit 0 and print the OK: line when well-formed.

Reflect

• Why is it valuable that adding identity does not force rewriting the authorization model?
• What new capability does identity-aware authorization give you that channel-only policy does not?

Next

Continue with the Lab.