Accept new-style SACD grants: ODRL Agreements under DIMO profile v1#17
Open
elffjs wants to merge 1 commit into
Open
Accept new-style SACD grants: ODRL Agreements under DIMO profile v1#17elffjs wants to merge 1 commit into
elffjs wants to merge 1 commit into
Conversation
Alongside legacy SACDData documents, the exchange now accepts CloudEvents of type dimo.sacd.odrl whose data is a W3C ODRL 2.2 Agreement restricted to DIMO profile v1 (https://ns.dimo.co/odrl/v1). Dispatch is on the CloudEvent envelope type; legacy documents are untouched. Profile v1 covers exactly the capabilities of legacy permission grants: assigner (grantor), assignee (grantee), target (asset DID), a validity period as conjunctive dateTime constraints, and named permissions using the existing privilege:* vocabulary. The minted claims are identical to those from an equivalent legacy document, so downstream consumers (dq) need no changes. CloudEvent-scoped access is not in profile v1 and such requests are refused when backed by an ODRL grant. The evaluator is fail-closed: unknown fields (prohibitions, duties, refinements), unknown actions, unsupported operators, and any @context other than the fixed canonical forms reject the document in full. No JSON-LD processing is ever performed, so a hostile @context cannot remap term meanings under the grantor's signature. See docs/odrl-profile-v1.md and docs/odrl-profile-v1.schema.json. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNqJMcyn2p3oKosj3KFdQR
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Alongside legacy
SACDDatadocuments, the exchange now accepts CloudEvents of typedimo.sacd.odrlwhosedatais a W3C ODRL 2.2Agreementrestricted to DIMO profile v1 (https://ns.dimo.co/odrl/v1). Dispatch is on the CloudEvent envelopetype; legacy documents flow through the existing path untouched.ODRL: W3C spec · Wikipedia
Profile v1 deliberately covers exactly the capabilities of legacy permission grants, no more:
target(ERC721/Ethr DID)assigner(did:ethr:...)assignee(did:ethr:...)constraint(dateTimecomparisons, conjunctive; absent = unbounded)permission[].action(existingprivilege:*names)The minted claims are identical to those from an equivalent legacy document, so downstream consumers (dq) need no changes. Parties are DIDs rather than legacy
{address}objects. CloudEvent-scoped access is not in profile v1; token requests carrying event filters are refused when backed by an ODRL grant.Fail-closed by construction
prohibition,duty, refinements, per-permission constraints) reject the document in full.@contextmust be byte-identical to a canonical form and is never dereferenced — a hostile context cannot remap term meanings under the grantor's signature.gteq/gt/lteq/ltoverdateTimewith plain RFC 3339 operands.Later profile versions widen the vocabulary (CloudEvent scoping via refinements,
Settemplates,isAnyOf, purpose constraints); they never change the meaning of v1-valid documents.Files
internal/exchange/models/odrl.go— strict profile parser and structural validationinternal/exchange/autheval/odrl.go— grant-map evaluation (target, validity window, actions)internal/exchange/services/access/access.go— envelope-type dispatch +evaluateODRLDoc(reuses the legacy path's assignee and signature checks)internal/exchange/services/ipfs_service.go— accept the new envelope typedocs/odrl-profile-v1.md,docs/odrl-profile-v1.schema.json— profile spec, example document, JSON SchemaTesting
14 table-driven cases in
odrl_test.goagainstValidateAccessViaSourceDoc: happy path, subset grants, expired / not-yet-effective / unbounded agreements, assignee/target/signature mismatches, and strictness rejections (unknown action, prohibition present, wrong@type, tampered@context, unsupported operator, event-filter refusal). Full build and test suite pass.🤖 Generated with Claude Code
https://claude.ai/code/session_01DNqJMcyn2p3oKosj3KFdQR