Multiply Endorsed Presentation

[SmithSamuelM]

Multiply Endorsed Presentation

In a discussion, the question came up about the best way to support a presentation in which fresh proof of control over multiple AIDs needs to be established.
This could happen in a presentation where multiple ACDCs are issued to different AIDs but all controlled by the same controller.
An example would be a presentation where a given person wanted to present an ACDC issued to that person's work AID and also present an ACDC issued to that person's SEDI AID, even though those two AIDs are different. This might be useful
in applying for a job that requires proof of both current employment and state citizenship.

The proposed solution I am calling a Multiply Endorsed Presentation. Multi-endorsement as in multiple AIDs endorsing with one or more signatures, not multi-sig as in multiple signatures from one AID. A single endorser may or may not be using a multi-sig AID. So the number of signatures is no less than the number of endorsers but could be more because some endorsers provide multiple signatures each.

Often when discussing high-level interactions that depend on the KERI Suite of protocols, it is easy for
the discussion to become untethered from the security properties and assumptions behind those properties. As a result, I find it helpful to ground that discussion in a review of the security assumptions.

Proof of Freshness (Timeliness) in a Presentation

An asymmetric-key digital signature's (signature for short) major weakness is its vulnerability to replay attacks. A digital signature attached to the document it signs is an ersatz bearer token. Any holder of both the document and its signature can replay them, and the signature will verify. All the signature proves is that, at some point in the past, the holder of the private key created it. It does not, at the time of presentation, prove that the holder of that signature is the same entity that currently controls the private key originally used to generate it.

The Issuer-Holder-Verifier model of verifiable credentials (VCs) assumes asynchronous use of the VC. It makes no assumptions about a secure session that could protect against replay attacks. Thus, usage can't rely on a secure session to protect against replay attacks.

This means that the holder must prove at the time of use that it is in control of the identity to which the VC was issued. This proof can be called a fresh or timely presentation.

In KERI Suite land, we use AIDs as cryptographic identifiers controlled by a keystate defined by a KEL; Typically, in a presentation exchange, the proof of control over the the Presenter’s AID at presentation time is where the Presenter’s AID is the Issuee AID of the ACDC being presented. However, in an Issuance exchange the Presenter is the Issuer of the ACDC being presented. Therefore proof-of-control over the Presenter’s AID is proof-of-control over the Issuer AID of the ACDC being presented. But when a bespoke ACDC is issued for the presentation then proof-of-control over the Presenter’s AID is proof-of-control over the Issuer AID of the bespoke ACDC which must be the same as the Issuee AIDs of the ACDCs linked or chained to the bespoke issued ACDC. Thus IPEX is an appropriate designation since a given presentation exchange may be also an issuance exchange.

To elaborate, the controller over the Presenter’s AID must, at the time of the IPEX exchange provide fresh proof of control over its AID. That AID must be either the Issuer or Issuee AID of the origin node of the ACDC DAG being presented. Proof of control means making a verifiable cryptographic commitment using the current private keys controlling that AID. One such commitment is a signature using the current keystate of the AID. This commitment must be fresh relative to the time of use via presentation of that origin node ACDC.

The actual presentation/issuance happens via the grant message. The sender of the grant message is the Grantor, which is the Presentor. There is some terminological baggage associated with the usage the terms Issuer-Holder-Verifier and presentation from other communities such as the W3C or Sovrin for VCs. In these other communities only the holder of a VC is not the Issuer in general but is the subject of the VC and only the holder may present it. The Issuer does not.. The holder is most like an Issuee in Keri/ACDC land. In KERI/ACDC land the term Presenter is a euphemism for Grantor and may either be the “holder” Issuee or the Issuer. In KERI/ACDC land an ACDC may be untargeted, i.e., does not have an Issuee. While the specificity of Issuers and Issuees may seem complicated it enables more precise security policy with respect to verification.

IPEX Exchange Freshness (Timeliness) Proof

V2 IPEX uses KERI exchange messages (xip or exn). Replay attack protection is provided by KRAM (Keri Request Authentication Mechanism).

KRAM uses the following fields: a message SAID d field, a sender AID i field, a receiver AID ri field, a salty nonce u field, and a datetime stamp relative to the receiver's clock dt field from a given exchange message. With KRAM, each message in a transaction has an individual timeliness window, and the set of messages in that transaction has a combined timeliness window. Simply put, KRAM is a scalable, noninteractive, replay-attack protection mechanism. KRAM ensures that a message cannot be replayed within a timeliness window and cannot be played at all outside that window. Thus, there is only ever one "play" of the message or not at all. That play must lie within a timeliness window this ensures freshness.

A given exchange message is accepted by a layer above KRAM for further processing only if it provides proof of freshness or timeliness. The proof has the following properties:

• The accepted message was signed with the current key state of the sender AID as the first play of that message
  within the timeliness window. That first play is cached until the window expires, preventing a replay within that window. This enables the timeliness window to be large. It could be hours or days, only limited by memory.
• The datetime stamp and timeliness window are both relative to the receiver's clock. The sender cannot therefore lie about the datetime in the message. It must be fresh (timely), where timely means the datetime must lie within the window relative to the receiver's clock. A message that is delayed in transmission long enough to fall outside that window cannot be played, much less replayed. Reception of a replay of that message within that window is either ignored or, if the sender AID uses multisig, a "replay" with a different signature can contribute that signature to the escrowed message, which is not first played until the escrow collects a threshold-satisfying number of signatures. This elegantly solves the multi-sig problem without requiring a pre-protocol to collect signatures. The receiver's KRAM escrow does the signature collection.
• The signatures by the sender are passed along with an accepted message
• Any other signatures by other AIDs that were attached to the message are also passed along with any accepted message.

Multiple Endorsements

A KERI message can be multiply endorsed by attaching signatures from other AIDs that are not the sender AID. This is done using one of several group codes for attaching signatures. The set of group codes supports both transferable and non-transferable AIDs. Typically, ACDCs that have perpetual verifiability are issued to transferable AIDs with a KEL. So we can assume transferable AIDs for this discussion, but non-transferable AIDs are also supported.

Technically, in an IPEX, the "presentation" is the grant exchange message. A valid IPEX could consist of only a grant message. This means that multiple endorsements cannot depend on some combined effect of multiple messages. And multiple endorsements can be simply applied to the grant message and no other. The other messages in an IPEX are meant to negotiate, using graduated disclosure, the terms and degree of disclosure, culminating in the grant message as the disclosure or presentation, and therefore do not need multiple endorsements. In this case, the controller of the sender AID uses that AID to negotiate on behalf of other AIDs under its control.

The appropriate set of group codes for attaching endorsements to a KERI message is as follows:

TransIdxSigGroups: str = '-X'  # Trans Indexed Signature Group(s), pre+snu+dig+ControllerIdxSigs of qb64.
BigTransIdxSigGroups: str = '--X'  # Big Trans Indexed Signature Group(s), pre+snu+dig+ControllerIdxSigs of qb64.
TransLastIdxSigGroups: str = '-Y'  # Trans Last Est Evt Indexed Signature Group(s), pre+ControllerIdxSigs of qb64.
BigTransLastIdxSigGroups: str = '--Y'  # Big Trans Last Est Evt Indexed Signature Group(s), pre+ControllerIdxSigs of qb64.

These groups provide the AID of the signer (endorser).

The TransIdxSigGroup and BigTransIdxSigGroup also provide the sequence number and SAID of the establishment event from which the keystate was drawn to create the signature.

The TransLastIdxSigGroups and BigTransLastIdxSigGroups contain only the signer's (endorser's) AID. The key state is
then pulled from the last (current) establishment event in the KEL of the AID.

When the AID in the group is the sender AID, then KRAM checks that it is the current keystate and, if not, drops the group.

When the AID in the group is not the sender AID, then the group is passed along.

This means that any AID, not only the sender of the message, can generate a set of signatures and attach them to the message. These will be passed along to the IPEX processing

Importantly, because the non-sender endorsers sign the same message as the sender, the timeliness (freshness) properties of KRAM's timeliness window also apply to the non-sender endorser AID commitments with one caveat.

The caveat is that the exchange processor must verify that the endorsers' signatures on the exchange message are valid using the current keystate of the endorser's AID. If not, then the invalid signatures must be dropped. With that caveat, non-sender endorsers get all the properties of KRAM replay-attack protection and timeliness that sender endorsers do. This includes multisig AIDs.

From a security properties perspective, a multiply-endorsed grant exchange message in which multiple AIDs supply a signature group attachment can provide a freshness proof for any number of endorsing AIDs, not merely the sender AID. This supports a simultaneous 'fresh' presentation of multiple ACDCs each with a different issuee AID. The only extra work needed is that the exchange processing has to be multiple-endorsement-aware.

Multiply Endorsed Awareness in IPEX

There are really two reasonable ways to provide multiple endorsement awareness in a grant exchange message. The first is to augment the exchange message itself to signal to the grant exchange message processing to validate multiple endorsers of the granted set of ACDCs, or to use a bespoke ACDC as the origin ACDC of the DAG to signal to the grant exchange message processing that the granted DAG of ACDCs includes a multiply endorsed subset.

The choice then is where to add the complexity. An exchange message is relatively simple in comparison to an ACDC. There is no normative cryptographic commitment in an exchange message to a given schema. In contrast, an ACDC uses schema-is-type to enable cryptographically verifiable commitments to immutable schema that define the shape of a bespoke ACDC. The ACDC processing already supports this level of complexity. While the exchange message does not.
For this reason, it seems most reasonable to leverage the existing flexibility of ACDCs to signal a multiply-endorsed presentation.

How might that look? Currently, the tooling for ACDC presentation assumes each presentation is a single DAG with a single origin node. All the other ACDCs chain back from this origin. The origin can be issued by the sender AID that issues the grant message. Simultaneously, this provides an authenticatable liveness proof of the sender's commitment to every ACDC in the DAG, merely by signing an exchange grant message whose attribute section contains the SAID of the origin ACDC. This is an example of minimally sufficient means, at least with respect to the exchange message.

Now, given that we have a bespoke ACDC as the origin, how should it be constructed to signal a multiply-endorsed set of ACDCs? The first thing that comes to mind is a special edge group that is either defined as such in the schema for the bespoke ACDC or is more specifically constrained with a special M-ARY edge group operator that explicitly indicates that the far-side ACDCs in the edge group must be individually endorsed via attached signature groups created by the Issuee of each of the ACDCs linked to by that edge group.

This seems like a good fit for a new type of dossier in the dossier spec and a corresponding operator to add to it. Intuitively, this feels right. The example above of a multiply-endorsed set of ACDCs, each with a different issuee AID, feels like a dossier of evidence. So a natural home for it would be the dossier spec, not a custom type of exchange grant message. This also precludes the complexity of supporting a new, as-yet-to-be-defined or supported, multiple-DAG IPEX presentation.

The advantage of limiting the multiply endorsed set to an edge group is that it allows a bespoke origin ACDC to simultaneously signal both a subgraph of multiply endorsed ACDCs and also to enable other edges in other edge groups to be used for graduated or contractually protected disclosure. So we do not need to dedicate a bespoke ACDC solely to multiple endorsements; instead, we can augment an existing one.

The remaining work, then, is to decide how to signal that a given group is multiply endorsed. As mentioned above, the two choices are to use a special description string in the edge group schema definition or define a special M-ARY operator. Because we are already creating normative language in draft ACDC spec v2.1, I prefer defining a special edge group M-ARY operator for Multiply Endorsed, maybe ME. (need to confirm no collisions)

Another advantage of using a special-purpose edge group operator is that the multiple-endorsement requirement can be signaled from any edge group in any ACDC in the DAG, not merely the origin ACDC. Although the typical use case would be a bespoke origin ACDC.

The extra work for grant message processing would be dispatched upon encountering the ME operator. This extra work would need to verify that for each extant edge in the group, a threshold-satisfying set of signatures from the Issuee AID of each ACDC in that edge group is attached to the grant exchange message. If not, then the presentation fails. This may require collating signatures across multiple attachments as the signature groups from a given AID may be disjoint. The KRAM processing could be augmented to ensure that collation occurs in KRAM before forwarding the exchange message for processing.

An ACDC grant does not have to include a bespoke ACDC issued by the sender for its origin node. Whatever the origin and regardless of who the Issuee or Issuer is, the inclusion of its SAID in the attribute section of the grant message makes a fresh presentation commitment by the sender of the grant to every ACDC in the DAG so committed.

Where this might introduce some ambiguity is when neither the Issuer nor Issuee AID of the Origin ACDC is the same as the sender AID. I can imagine use cases where this does not matter. For example, a presentation "to whom it may concern" where the sender merely needs to endorse the DAG as a whole and does not need to be an issuer or issuee of any ACDCs in that DAG. But there may be other use cases where the EGF wants to constrain that the sender AID MUST be either the origin node's issuer or Issuee.

Summary

This proposal generates the following new work items that support multiple endorsed edge groups in the grant message of an IPEX DAG

• Decide on the new M-ARY edge group operator such as ME. (Need to check the dossier spec for new operators to ensure no collisions.)
• Augment KRAM processing to ensure collated non-sender signature groups by signer (endorser) AID before forwarding for processing.
• Enhance the grant message processing in IPEX to detect any edge groups that include the ME edge group operator.
• Validate each ME edge group by extracting any signature group attachments to the message that correspond to each Issuee AID in that edge group and then validate the signatures for that edge group against the current signing keys for that AID to satisfy the current signing threshold for that AID. If they do not verify, then the edge group fails validation, and the grant presentation is invalid.. To clarify, a successful presentation requires that each and every one of the multiple endorsed presentation edge groups in the disclosed DAG of ACDCs validates against attached signature groups.
• A further requirement is new tooling to provide a parameter to grant processing that triggers enforcement of a policy where the the DAG origin ACDC must be either issued to or issued by the sender AID of the grant message.

Postscript

This creation of a new edge group operator puts some stress on the logic underlying the current default rules for Unary edge operators. We now have two use cases where the edges are not delegations. The first is the E1E edge and the second is an edge in an ME group. The current defaults lie along the delegation-or-not axis, thereby requiring explicit unary operators on ME group edges.

I will address this in a companion discussion #1556

[SmithSamuelM]

@dhh1128 with reference to our discussion from yesterday here is my current thinking. Interested in your feedback.
Also see #1556 which builds from this

[SmithSamuelM]

@ryan-hansen @evanja57 @KeaxD @jaelliot

[dhh1128]

Sam — this is very helpful. Thank you.

Your single-DAG, single-origin conclusion matches and improves upon what I was starting to feel good about myself. I've been calling that
thing a "forked DAG", but your term is better. The ACDC layer seems like the right place for the semantics, for the reason you give — schema-is-type gives a cryptographic commitment the exn has nothing equivalent to.

I explored implementing what you've proposed against upstream/main (9161a70), Python 3.14, at v2: the V2-native IPEX from #1517 (keri.acdc.ipexing) and v2 ACDCs. I wanted to see what impl gaps might exist. Here's what I found:

1. V2 IPEX rejects non-sender signature groups today.

You write: "When the AID in the group is not the sender AID, then the group is passed along." As far as I can tell, that is not what happens yet. loadHandlers in keri.acdc.ipexing registers against keri.peer.Exchanger, so V2 IPEX shares Exchanger.processEvent with V1 — including this gate at src/keri/peer/exchanging.py:90:

if tsgs:
    for prefixer, snumber, sdiger, sigers in tsgs:
        if sender != prefixer.qb64:  # sig not by aid
            msg = (f"Skipped signature not from aid = "
                   f"{sender}, from {prefixer.qb64} on exn msg = {serder.said}")
            logger.info(msg)
            raise MissingSignatureError(msg)

On a V2 grant built by keri.acdc.ipexing.grant, with B's KEL already known to the receiving environment:

stream	result
sender A only	ACCEPT
sender A + non-sender endorser B	REJECT — MissingSignatureError
same, through the full V2 parse path	REJECT — not stored
sender-only, through the full V2 parse path (control)	ACCEPT

My experiments suggest that the whole message is dropped, not just the extra group. Work item 2 therefore has a prerequisite in Exchanger.processEvent: non-sender groups must pass through and be validated against the endorser's current key state instead of aborting the message.

Nothing in keripy verifies a non-sender signature anywhere today, so work item 3 is greenfield as well.

2. I think edge groups are not implemented — they crash.

ME is an M-ARY edge group operator, so it depends on edge groups working. Both places that walk the e section assume every non-d/o label is a flat edge carrying n:

• Verifier.processCredential edge loop — nodeSaid = node["n"]
• Reger.sources (src/keri/vdr/eventing.py:2663) — saids.append(source['n'])

Against a nested edge group of the shape ME would use, both raise KeyError: 'n', while a flat edge section on the same ACDC validates. There is no M-ARY operator concept either — Verifier.UnaryOps is ('I2I', 'NI2I', 'DI2I', 'E1E', 'NOT') with no M-ARY
equivalent.

This looks to me like the single biggest chunk of work behind ME, and it is independent of ME's semantics: any M-ARY operator needs it, and it is a bug fix on its own.

3. sources() already recurses.

Grant artifact discovery resolves the full ancestry, not just direct parents — a 3-deep chain returns both ancestors. The "collect the DAG to ship it" half of a multiply endorsed presentation already works for flat edges.

About KRAM: your approach need KRAM to apply to the grant with its timeliness window extending to non-sender endorsers. Kramer exists in src/keri/core/kraming.py and is used from src/keri/core/eventing.py, but there doesn't seem to be any reference to it so far in
src/keri/peer/exchanging.py. Does KRAM-on-exn land with a later piece of V2 IPEX, or am I looking in the wrong place? If endorser freshness comes from KRAM, ME needs no freshness machinery of its own. If it does not, ME inherits the replay problem and needs
audience binding in the payload.

ME requires a threshold-satisfying signature from the Issuee AID of each ACDC in the group, attached to the grant. Every endorser must therefore be live at presentation time. That fits your motivating case exactly — one person, several of their own AIDs, all keys in one wallet.

It does not cover presentation by one party on behalf of another with consent, where the consenting party is offline: a guardian presenting a dependent's records, an employee presenting an employer's credential, a travel agent acting for a traveller. There the endorsement has to have been made earlier and be durable.

If we decide that this latter case is worth supporting, then I think it needs no new operator. The consenting party B issues a small ACDC to the presenter A, and the chain closes under plain I2I:

bespoke   issuer=A  issuee=V  --I2I--> consent
consent   issuer=B  issuee=A  --I2I--> vax
vax       issuer=HA issuee=B

consent.issuer(B) == vax.issuee(B) and bespoke.issuer(A) == consent.issuee(A), so both links satisfy I2I. A disinterested verifier holding none of the three parties' state up front accepts this today, unmodified, at ACDC v2. A cannot manufacture the bridge, because the middle link's I2I demands B be the issuer of the consent. A self-issued forgery, a bespoke built on that forgery, and a third party building on A's genuine consent are all rejected.

These are two halves of a pair rather than competitors. ME gives live co-presence, with the strongest freshness and every endorser online. A consent credential gives durable delegated presentation, with the endorser offline and freshness bounded by revocation. If ME goes into the dossier spec, the delegated case is probably worth naming alongside it so implementers do not conflate them.

The consent credential above assumes B runs a registry so the bridge can be revoked. That is a real cost for an artifact whose purpose is a single presentation, and at v2 it is currently more than a cost: the registrar modules in keri.acdc (registering.py, registraring.py, registring.py, regbasing.py) are stubs, so a registry-backed bridge is not wired end to end, while a registry-less one is.

I think the spec allows the registry-less form — ri is optional, and proof of issuance is the Issuer's signature or seal on the SAID of the most compact variant. However, keripy does not implement it: Verifier.processCredential assumes a TEL and raises TypeError: 'NoneType' object is not iterable out of escrowMRE when regid is None. A ~60-line spike that verifies the Issuer's attached signature instead makes the
chain above validate with no registry anywhere, at v2.

So, would you say that a registry-less ACDC a legitimate participant in this scheme, or do we assume every node is revocable? If it is legitimate, it gives the delegated case the freshness property ME gets from live signing: B pre-signs a short-lived bridge that expires on its own instead of requiring revocation infrastructure.