Raised at @jalexspringer's suggestion following an email exchange.
Specification section
8.2 and 8.3, with 7.1 for manifest_ref on standalone envelopes.
What I observed
Section 8 opens by saying that content owners, agents and platforms publish a manifest "declaring their identity". Following that through, the whole of identity is operator.name, which 8.3 describes as a "Presentation name of the operating organisation", together with an optional domain that defaults to the manifest URL's host. Section 8.1 says trust derives from TLS and DNS control of the domain.
So the chain from an event to a party resolves to a display name and a domain. It does not resolve to anyone who can be invoiced, served or sued.
Searching the specification on the #45 branch, 1,768 lines, for the vocabulary that would carry this:
| Term |
Occurrences |
| legal entity |
0 |
| legal person |
0 |
| jurisdiction |
0 |
| registered |
0 |
| counterparty |
0 |
| incorporat* |
0 |
| domicile |
0 |
| company number |
0 |
"liable" and "notice" appear only inside "reliable" and "noticed".
Why it matters
The three-layer model puts commercial meaning in the governing terms, and terms bind persons rather than domains. #45 adds terms_ref so an event can say which terms applied, and adds manifest_ref to standalone envelopes described as "RECOMMENDED on standalone events supporting settlement or audit obligations under governing terms".
The specification therefore now anticipates settlement and routes it through a pointer that terminates in a presentation name. An event can say which terms governed it and cannot say who they governed, which for settlement is the missing half, because an invoice cannot be raised against a display name.
Domain control is also not the same thing as a legal person, and the difference shows up in ordinary cases rather than adversarial ones, as groups operate through subsidiaries, agents are operated by contractors, and domains change hands. Two parties can agree that every event is accurate and still disagree about who owes.
What I am not asking for
Not a registry, not a verification service and not an identity scheme. Core has to work with no external resolver and that constraint is right.
The observation is narrower, which is that a settlement-bearing record has no field for the party, and that "presentation name" is now doing work it was not designed for. Whether that is answered by an optional field on the operator object, by a profile, or by saying plainly in section 8 that a manifest identifies a domain rather than an organisation, is a judgement for the maintainers, and the third of those would resolve it at no cost to the wire format.
Next step
Happy to write a short note to proposals/ if this is worth pursuing as a capability, and equally happy to leave it as a wording fix in section 8 if the answer is that identity was never intended to reach that far.
Perspective
Standards / policy.
Raised at @jalexspringer's suggestion following an email exchange.
Specification section
8.2 and 8.3, with 7.1 for
manifest_refon standalone envelopes.What I observed
Section 8 opens by saying that content owners, agents and platforms publish a manifest "declaring their identity". Following that through, the whole of identity is
operator.name, which 8.3 describes as a "Presentation name of the operating organisation", together with an optionaldomainthat defaults to the manifest URL's host. Section 8.1 says trust derives from TLS and DNS control of the domain.So the chain from an event to a party resolves to a display name and a domain. It does not resolve to anyone who can be invoiced, served or sued.
Searching the specification on the #45 branch, 1,768 lines, for the vocabulary that would carry this:
"liable" and "notice" appear only inside "reliable" and "noticed".
Why it matters
The three-layer model puts commercial meaning in the governing terms, and terms bind persons rather than domains. #45 adds
terms_refso an event can say which terms applied, and addsmanifest_refto standalone envelopes described as "RECOMMENDED on standalone events supporting settlement or audit obligations under governing terms".The specification therefore now anticipates settlement and routes it through a pointer that terminates in a presentation name. An event can say which terms governed it and cannot say who they governed, which for settlement is the missing half, because an invoice cannot be raised against a display name.
Domain control is also not the same thing as a legal person, and the difference shows up in ordinary cases rather than adversarial ones, as groups operate through subsidiaries, agents are operated by contractors, and domains change hands. Two parties can agree that every event is accurate and still disagree about who owes.
What I am not asking for
Not a registry, not a verification service and not an identity scheme. Core has to work with no external resolver and that constraint is right.
The observation is narrower, which is that a settlement-bearing record has no field for the party, and that "presentation name" is now doing work it was not designed for. Whether that is answered by an optional field on the operator object, by a profile, or by saying plainly in section 8 that a manifest identifies a domain rather than an organisation, is a judgement for the maintainers, and the third of those would resolve it at no cost to the wire format.
Next step
Happy to write a short note to
proposals/if this is worth pursuing as a capability, and equally happy to leave it as a wording fix in section 8 if the answer is that identity was never intended to reach that far.Perspective
Standards / policy.