DPROD Contracts: define bearer binding for subjectless duties

[jgeluk]

Context

Follow-up from #198 (fixme.md items 2, 13, 14, 32 and especially 40).

The formal Eval algorithm partitions duties only when d.subject exactly matches the policy grantor or grantee. A duty without dprod:subjectOfDuty belongs to neither returned set, although it still participates in state updates and violation detection. Consumer obligations in an open Offer may legitimately have no known consumer yet, but the formal semantics never defines what happens when that Offer becomes an Agreement.

The root problem is an undefined duty-bearer binding rule, not merely missing dprod:objectOfDuty values in examples.

Decision required

Define bearer requirements and defaulting separately for Set, Offer, Agreement/DataContract, and standalone named Duty contexts.

Acceptance criteria

1. Add regression examples/tests first showing that a subjectless duty is currently dropped from both returned duty partitions.
2. Specify when dprod:subjectOfDuty is required, optional, or bound during Offer-to-Agreement formation.
3. Ensure no duty can silently disappear from the evaluation result.
4. An unresolved bearer in a context that requires one must fail validation or evaluation with a hard error.
5. Clarify that dprod:objectOfDuty is an affected party, not the bearer, and document when it is useful but optional.
6. Align SHACL, formal semantics, contracts guide, and examples.

[jgeluk]

Decision options

There are three separate choices here: when a bearer may be omitted, which parties may bear duties, and how duties are represented in the result. They should be decided together so no Duty can disappear between parsing, agreement formation, and evaluation.

1. Omitted bearer

A. Explicit everywhere: every Duty must declare dprod:subjectOfDuty, including Duties in an Offer. This is simplest, but an open Offer cannot naturally express obligations for its not-yet-known consumer.

B. Offer template binding (recommended): omission is allowed only on a Duty in an odrl:Offer/dprod:DataOffer, where it means “the eventual grantee”. Offer-to-Agreement formation MUST materialise dprod:subjectOfDuty with the accepted Agreement assignee. An Agreement containing an unresolved bearer fails validation/evaluation.

C. Evaluation-time defaulting: interpret an omitted bearer as the current requester or policy assignee during evaluation. This is not recommended because the same RDF Duty changes meaning by runtime context and remains poorly auditable.

2. Allowed bearers

A. Bilateral only: an Agreement Duty bearer must equal its assigner or assignee. This preserves the current two result partitions but rejects legitimate third-party duties.

B. Any explicit Party: permit auditors, payment recipients, service operators, and other third parties to bear duties. This requires a result representation that cannot drop parties outside the bilateral pair.

3. Evaluation result

A. Keep only grantorDuties and granteeDuties: then validation must reject any resolved bearer outside those two parties, and Set policies cannot contain evaluable Duties because a Set has neither party.

B. Use a bearer-indexed result (recommended): return dutiesByBearer : Map<Party, Set<Duty>>. grantorDuties and granteeDuties may remain defined projections for convenience. This handles Set duties and third-party duties without an unpartitioned remainder.

Recommended context rules

Context	Bearer rule
Set	Every Duty has an explicit bearer; return it under that Party in dutiesByBearer.
Offer / DataOffer	Explicit bearer means that Party; omitted bearer is a future-grantee template and is not an active enforceable duty yet.
Agreement / DataContract	Every Duty has a resolved explicit bearer. Omission is a hard error. Offer templates are copied/materialised with the Agreement assignee during formation.
Named Duty referenced by a policy	Uses the containing policy context and the same rules above.
Truly uncontained named Duty	Has no DPROD policy/profile context and is not independently evaluable.

Proposed disposition

Choose offer-template binding, allow any explicit Party, and replace the lossy two-way partition with a bearer-indexed result plus grantor/grantee projections. This is a breaking change, but it gives one uniform invariant: every evaluable Duty has exactly one resolved bearer and appears in exactly one result bucket.

If we want a smaller bilateral-only core instead, that must explicitly prohibit third-party and Set Duties rather than silently dropping them.