Unary Edge Operator Defaults

[SmithSamuelM]

Unary Edge Operator Defaults

The original use cases for edges in ACDCs were to model delegation chains of authority. The run-up to SEDI has produced other important use cases that are not delegative in nature. The existing global default rules for Unary edge operators feel cumbersome in those applications. This builds off from #1555

This discussion proposes changes to the Unary edge operator's default logic.
The main advantage of defaults is compactness of expression. A set of edges by omitting an explicit edge operator benefits from an intelligent default. This makes expressing edges less cumbersome.
However, if there is no intelligent default, then all edges must have explicit operators. This makes it cumbersome.
So the idea is to discuss how to have more fine-grained default logic to better manage this trade-off.

Unary Edge Operators and Defaults

Unary Delegative Operators

This table has been expanded to include the newly proposed E1E operator see Discussion #1515

With the exception of the NOT and E1E operators, the current set of Unary operators are delegative. They modulate delegation relations between the near and far ACDCs that share an edge.

Unary Operator	Description	Default
I2I	Issuer-To-Issuee, The Issuer AID of this ACDC MUST be the Issuee AID of the node this Edge points to.	Yes for targeted ACDCs
NI2I	Not-Issuer-To-Issuee, The Issuer AID of this ACDC MAY or MAY not be the Issuee AID of the node that this Edge points to.	Yes for untargeted ACDCs
DI2I	Delegated-Issuer-To-Issuee, The Issuer AID of this ACDC MUST be either the Issuee AID or a delegated AID of the Issuee AID of the node this Edge points to.	No
E1E	Issuee-Is-Issuee. The Issuee AID of this near-side ACDC MUST be the Issuee AID of the far-side ACDC this edge points to.	No
NOT	Logical NOT. The validity of the node this Edge points to is inverted. If valid, then not valid. If invalid, then valid.	No

When the Operator, o, field is missing or empty or is present but does not include any of the I2I, NI2I or DI2I Operators then:

• If the node pointed to by the Edge is a targeted ACDC, i.e., has an Issuee, then the I2I Operator MUST be appended to the Operator, o, field's effective list value.

• If the node pointed to by the Edge block is an Untargeted ACDC i.e., does not have an Issuee, then the NI2I Operator MUST be appended to the Operator, o, field's effective list value.

Many ACDC chains use Targeted ACDCs (i.e., have Issuees). A chain of Issuer-To-Issuee-To-Issuer Targeted ACDCs, in which each Issuee becomes the Issuer of the next ACDC in the chain, can be used to provide a chain of authority. A common use case for a chain of authority is a delegation chain for authorization.

The I2I unary operator, when present, means that the Issuer AID of the current ACDC in which the Edge resides MUST be the Issuee AID of the node to which the Edge points. Therefore, for this Edge to be valid, the ACDC node it points to MUST be a Targeted ACDC. This is the default value when the Operator 'o' field value is missing or empty.

The NI2I unary Operator, when present, removes or nullifies any requirement expressed by the I2I Operator described above. In other words, any REQUIREMENT that the Issuer AID of the current ACDC in which the Edge resides MUST be the Issuee AID, if any, of the node the Edge points to is relaxed (not applicable). To clarify, when operative (present), the NI2I Operator means that both an Untargeted ACDC or Targeted ACDC, as the node pointed to by the Edge, MAY be valid even when Untargeted or if Targeted even when the Issuer of the ACDC in which the Edge appears is not the Issuee AID of that node to which the Edge points.

The DI2I unary Operator, when present, expands the class of allowed Issuer AIDs of the node the Edge resides in to include not only the Issuee AID but also any delegated AIDs of the Issuee of the node to which the Edge points. Therefore, for this Edge to be valid, the ACDC node it points to MUST be a Targeted ACDC.

The EIE unary Operator, when present, requires that the Issuee AID on both sides of the edge must be identical. This supports partitioning of the information in each ACDC issuance to a need-to-know policy across issuing agencies or departments. All ACDCs chain back to the same core identity, ACDC, but allow a given agency or department to issue department-specific entitlements that are chained to the core identity ACDC without needing to know anything about information controlled by another department. This policy minimizes the blast radius of a breach. Therefore, for the ACDCs on both sides of the Edge to be valid, they MUST be Targeted.

The NOT unary Operator, when present, inverts the Edge's validation truthiness. If the Edge is invalid, the presence of the NOT operator makes it valid. Conversely, if this Edge is valid, then the presence of the NOT Operator makes this Edge invalid.

Problems

The current logic for default specifies that when the o field is missing or has an empty value, and the far side node of the Edge is targeted, then I2I is appended. Therefore, for E1E to function properly, it must always be explicitly provided.

The newly proposed Multiply Endorsed ME M-Ary edge group operator does not care whether the far-side ACDC is delegative or not; only that the far-side ACDC is targeted (has an Issuee AID). This means that for correct functioning of an ME edge group, each edge must have an explicit NI2I operator to avoid a failed edge when the default I2I is inappropriately applied.

How to fix this. The original motivation for the I2I default is that Unary edge operators were not normatively defined for ACDCs when the original GLEIF vLEIs went into production. This meant that the original vLEIs did not have unary edge operators. The EGF required that those edges be treated as if they had an I2I requirement. Later, when the unary operators were normatively defined, backward compatibility with vLEIs without unary edge operators was achieved by adding I2I as the default and NI2I to override it. In use cases where edges, by and large, are delegative, these defaults make sense. But for SEDI use cases where often there is no delegative credential for a citizen, the delegative defaults result in more cumbersome minimal construction.

The I2I default applies globally to all edges. We could change that default to be empty, but this might break vLEIs in the wild that do not have an explicit unary operator on a delegative edge.

Another way to address this problem is to make defaults for Unary edge operators be a function of the M-Ary edge group operator when and if the edge appears in an edge group.. Each edge group operator may have an optional default edge operator for all its edges. This would make default logic more granular.

It does add some extra processing, but the logic is well triggered by the presence of a given edge group operator with defined default edge operator overrides.

So, for example, an ME edge group could have NI2I as the default edge operator, regardless of the targeting status of the far node ACDC. This means a group of multiple endorsed ACDCs would not need any explicit unary edge operators.

Many of the dossier spec examples are non-delegative as well and would benefit from a different default than I2I.

Given we define an optional unary default for each M-Ary, we could support edge groups of E1E edges by defining an Identity AND group operator, IAND, where every edge must be present, and every edge defaults to an implicit E1E edge.

[dhh1128]

Agreed on the diagnosis: a single global I2I default was right when every edge was
delegative and is increasingly awkward now that E1E and ME-group edges are not. Scoping
the default to the enclosing M-ARY group operator puts it next to the thing that
establishes the context.

Unknown group operators have to fail closed

If the effective unary default becomes a function of the enclosing group operator, then a
validator's interpretation of an edge depends on whether it recognizes that operator. A
validator built before ME exists, meeting an ME group, does not know the group
overrides the default to NI2I. It falls back to the global rule and applies I2I to a
targeted far node.

For ME specifically that fails safe — the older validator applies a stricter rule and
rejects. But that is a property of this instance, not of the mechanism. Any future group
operator whose default is stricter than the global one gets silently relaxed by an
older validator, which then accepts a presentation the issuer intended to constrain more
tightly. The validator cannot detect that it is doing so, because an unrecognized operator
token is currently just skipped.

The normative language should therefore state that an M-ARY edge group whose group
operator is not recognized MUST fail validation, rather than being skipped or falling back
to the global default. Fail-closed on unknown group operators is what makes group-scoped
defaults safe to extend later; without it, every future group operator is a potential
silent downgrade against deployed validators.

keripy already applies this discipline to unary operators — NOT and unimplemented DI2I
raise rather than being dropped, on the grounds that escrowing would promise a retry that
can never succeed. Group operators should inherit it.

Part of the premise may already be implemented

Verifier.verifyChain on upstream/main (9161a70) already handles the list-valued o
case: the operator list is filtered to recognized tokens, the delegative subset resolves
latest-wins because those conflict with each other, and E1E composes (ANDs) rather than
overriding, because it constrains the near issuee rather than the near issuer. The
default rule applies only when nothing recognized is present.

So "for E1E to function properly it must always be explicitly provided" is accurate, but
E1E does compose correctly with a delegative operator when both are given. If the concern
is only the verbosity of always writing it, group-scoped defaults fix that cleanly. If you
also intended a semantic change to how E1E combines, that is a larger change and worth
separating.

IAND and the identity-group case

IAND — every edge present, defaulting to E1E — is the more interesting of the two,
because "all of these ACDCs are about the same subject" is a primitive that shows up well
beyond SEDI.

Is IAND meant to carry conjunction of validity (every edge must validate) as well as
identity of issuee? The name suggests both, in which case it does two jobs, and ME looks
like conjunction plus an endorsement requirement. It might be cleaner to factor "all edges
must be present and valid" out of the individual group operators, so IAND, ME and
future groups differ only in the extra constraint each adds.

Second: E1E requires both sides targeted and compares the two issuee AIDs, so an
IAND group can only express "same subject AID." The case where the AIDs differ but are
provably controlled by the same party — the motivating example in #1555, one person with a
work AID and a SEDI AID — is not expressible by E1E, and as far as I can tell ME covers
it only by requiring a live signature from each issuee at presentation time. If that is the
intended answer it is worth saying so explicitly in the spec text, because "same controller"
and "same issuee AID" are easy to conflate and the distinction is exactly what E1E and
ME turn on.

Edge groups do not traverse yet

Since this is a forward-looking design discussion, none of these defaulting rules can be
exercised in keripy today. But it would be fun to fix that, and it buys us a lot!

Both places that walk the
e section assume every non-d/o label is a flat edge with an n field, and both raise
KeyError: 'n' on a nested group — Verifier.processCredential's edge loop, and
Reger.sources at src/keri/vdr/eventing.py:2663. There is no M-ARY operator concept in
the verifier at all, and no edge or operator validation in the v2 keri.acdc package
either; vdr/verifying.py is the only implementation, and it is what a v2 ACDC gets
validated against.

Group-scoped defaults can't be implemented until edge-group traversal exists, so that work
probably wants to land first and independently of either operator's semantics. Shall I raise
a PR for that?