CLC constructs for IPEX v2: what should apply and offer carry?

[dhh1128]

Building the real-IPEX companion to the CLC example (#1505) on top of #1517 forces
a question that #1512 and #1532 haven't settled: in a contractually-gated
disclosure, what belongs in the apply and offer messages? There is a strawman
below. Please poke holes in it.

Some background for anyone not deep in those threads. #1505 modeled the CLC ceremony
— apply → offer → agree → grant → admit — at the data-structure level: real v2 exn
messages, but built by hand and never routed, because keri.acdc.ipexing was a stub.
Its docstring promised a companion that runs the same scenario through real tooling
once ipexing existed. @KeaxD's #1517 supplies that tooling. Wiring the companion to
it surfaces the question.

What #1517 gives us

• apply body: {m, s (schema SAID), a (free dict), i (recipient)}.
• offer(hab, message, acdc, apply): body {m, acdc (SAID)}, with the whole ACDC
  nested as a CESR substream; only the SAID rides the body. offer, agree,
  admit, and spurn never pass receiver=, so their ri is empty. No terms, no
  metadata variant.

That is enough to send and order the messages, but not to run a gated disclosure
without leaking.

Where it collides with least disclosure

The offer nests the full disclosable ACDC. The spec says the pre-agree offer should
carry a metadata ACDC — the empty-u variant that commits Issuer, Schema, Edges,
and Rules but discloses no attribute values and not even the real SAID until the
terms are accepted (ACDC spec, Metadata ACDC section). #1512 describes exactly this flow — the
offer includes a metadata ACDC that exposes the Rules section and the
attribute-section SAID, but not the pathed attributes. Nesting the full ACDC instead discloses
everything before agree, which destroys the ordering guarantee the ceremony exists
to provide: a verifier can read the values, weigh the terms, then spurn — already
holding both the data and a stable correlator. @SmithSamuelM, this is the inadvertent
leak your #1532 reply said constructors should prevent.

apply can't state a graduated-disclosure request. CLC's apply asks for specific
fields per schema — "prove over-21 and show the state-endorsed photo" — not a
whole-credential ask. #1505 modeled it as disclose={schemaSAID: ["/a/i", "/a/photo"], ...}, the path-list idea from #1512. #1517's apply has only a free-form a dict
with no defined semantics. The path syntax itself — Pather vs /-delimited, leaf vs
node semantics, which exn block carries it — is #1512's to settle, and it already
leans to Pather; I'm not re-opening that here. The example can carry disclose and
g inside the free a dict today with no ipexing change; the open question is
whether either should become a defined field — see the asks.

Two smaller gaps remain. None of offer/agree/admit/spurn sets a receiver, so
a two-party exchange never names who each message is for (v2 sets ri through the
builder's receiver=; v1 used rp). And the terms belong in the ACDC's
SAID-committed r/Rules section, not a transient offer field: under CLC they MUST
travel with the credential to bind every downstream disclosee (ACDC spec, Chain-Link
Confidentiality), and the metadata ACDC already carries that section.

Strawman — please shoot at it

apply (the request):

a = {
  m: "<human message>",
  disclose: { <composed-schema-SAID>: ["/a/i", "/a/photo"],   # per-schema path lists (#1512)
              <composed-schema-SAID>: ["/A/i", "/A/over21"] },
  g: "<governance/EGF SAID>",
}
ri = <holder AID>
# Path notation and leaf/node semantics are #1512's to pin (it leans to Pather "-a-i"
# over this "/a/i"); I follow whatever it lands. Keying this dict by schema SAID also
# inherits #1512's known flaw: two same-schema creds in a chain collapse to one key.
# The CLC example dodges it (two different schemas), but the general construct doesn't.

offer (the terms-bound teaser):

a = {
  m: "<human message>",
  g: "<governance SAID>",
}
ri = <verifier AID>
# nests: a METADATA (empty-u) ACDC. It commits Issuer/Schema/Edges/Rules, so the
# disclosee can read the terms (its r-section) and what is on offer, but learns no
# attribute values and not even the real SAID until after agree (ACDC spec, Metadata ACDC).
# It carries NO issuer-committed correlators (source SAIDs, registry) pre-agree (#1531).
# NOT a "compact" ACDC: a no-u compact form is public and rainbow-attackable, so
# committing to its SAID is a fixed correlator, not privacy (ACDC spec: compact = Public-Attribute ACDC).

The constructor question is really yours from #1532. Rather than police the offer
with a schema, should ipexing.offer grow a metadata variant — a constructor that
refuses to nest a full disclosable ACDC and instead takes or derives the empty-u
metadata ACDC? That makes least disclosure the default for the pre-agree message. It
is the constructor you described that makes the doctrine hard to break, with no
schema-enforcement layer bolted on.

What I'm asking

1. The apply shape — composed-schema SAID, per-schema disclose path-lists,
   governance ref — leaning on Graduated Disclosure Pathing Negotiation #1512 for the path-list details as above. For the
   example I'd carry disclose/g in the free a dict now, with no ipexing change,
   rather than freeze a defined wire field ahead of Graduated Disclosure Pathing Negotiation #1512 — a defined field is a
   four-implementation conformance obligation. Does that sequencing work?
2. Should offer enforce the metadata (empty-u) variant by construction — the
   IPEX apply/offer payloads: closed-world content guarantees (beyond denylist asserts) #1532 constructor? If so, does that belong in ipexing, or at the workflow/EGF
   layer?
3. Receivers on offer/agree/admit/spurn — have the builders pass receiver=
   (setting ri) as apply/grant already do. In Add V2 IPEX builders and linear dispatcher #1517, or a follow-up?
4. The correlation budget from IPEX apply/offer payloads: closed-world content guarantees (beyond denylist asserts) #1532 governs pre-agree identifiers well, but not
   the disclosed content: the state-endorsed photo is a biometric that two colluding
   verifiers correlate no matter how fresh the SAIDs are. That leak is governed by the
   CLC terms, not the budget. Is that the right division of labor for the example to
   assert — budget for the metadata phase, terms/r-section for the disclosed content?

Once these settle I can freeze the example's payloads and finish it. Until then I'll
scaffold the transport against the current #1505/#1531 shapes.

[SmithSamuelM]

@dhh1128

One clarification:

only the SAID rides the body. offer, agree,
admit, and spurn never pass receiver=, so their ri is empty. No terms, no
metadata variant.

Why is the ri empty?
The ri field is meant to carry the receiver AID. The exchange transaction is between a sender and receiver pair of AIDs. They may negotiate about some other AID to which an ACDC was issued as the Issuee. But in order to even have an authenticatable negotiation, there must be a pair of AIDs that negotiate. So I am confused by this.

There is an assumption which may need to be revisited that the disclosee AID is public, whereas the discloser AID may be private or ephemeral, created on the fly for the purpose of the negotiation. But the discloser is making a presentation. The AID they use in the presentation negoation must either be the same as the Issuee aid or must bear the constraint that it is indeed the same entity. The later may be problematic for the verifier to verify. So the AID used in the negotiation already provides a stable point of correlation. So the only information that is the subject of graduated disclosure is the information in the ACDC (or set of ACDCs) being presented.

So the verifier can't prove that the presenter AID used as the sender in its exchange messages is the same as the Issuee in the ACDC until the Grant of that ACDC. This is important because anyone can purport to be a presenter, and so the verifier may correlate against the presenter AID used to sign the exchange messages but can't prove it is the same as the Issuee until the Grant.

This is an important distinction. Proof of participation is not the same as correlation.

One reason to apply KRAM to exchange messages is to prevent replay of exhange messages by malicous parties.

But any exchange whether in person or over the internet leaks correlatable PII by virtue of the context. But correlation is not the same as legally binding proof of participation.

So if we don't make that distinction we can't bootstrap through contractually protected disclosure. We are reduced to throwing infromation over the wall and minimizing what we throw over the wall but there is no legally binding contract. Which contract law requires a clear intent to engage in legal relations. Relation is important here, and that requires identity.

This means that how the exchange begins assumes some things. If the disclosee has a public AID then it may have a public endpoint which the discloser might use to trigger an apply back from the disclosee via a querymessage to that public endpoint by the discloser which provides the ri AID the disclosee uses in the Apply that results. Otherwise the discloser starts the exchange with an Offer to the public AID of the disclosee. The sender in the Offer provides the discloser AID.

[dhh1128]

You're right, and the empty ri is a gap in #1517, not a position I'm defending — apply and grant thread receiver=, but offer, agree, admit, and spurn don't, so their rp/ri come out empty. That should be fixed; there's no authenticatable negotiation, let alone a bindable contract, without a named pair. The distinction you draw is the part I hadn't stated cleanly: participation is not correlation, and neither is legally-binding proof — the verifier can correlate the presenter's AID from the first message but can't prove it's the Issuee until the Grant. Graduated disclosure is doing its work on the ACDC content, not on the negotiating identity, and trying to hide the latter would only saw off the branch CLC sits on.

For the bulk-issuance companion, I'd pin the presenter's AID to a fresh per-disclosee ALICE_k — but established at first contact, not switched partway. The invariant is apply.ri == offer.i, both ALICE_k: the verifier challenges the same AID that answers. That works precisely because Alice seeds it — she either opens with the offer from ALICE_k, or triggers the apply with the query-to-your-public-endpoint bootstrap you described, which hands the verifier the ri to use. A verifier that could cold-address a reusable holder AID would already be holding the cross-verifier join key, so in the unlinkable case there's no prior AID to challenge; the presenter AID is born with the exchange and carries both directions. Freshness is per-exchange, never mid-exchange — the partition comes from k differing across verifiers, not from any AID switch inside one.

[dhh1128]

Update on ask 3 above (receivers on offer/agree/admit/spurn): I opened a PR against #1517's branch that closes it: KeaxD#2. The four responder verbs now set the envelope ri, derived from the prior message's sender (offer from the apply, agree from the offer, admit from the grant, spurn from what it rejects), with an explicit recp override for an offer-first open that has no prior.

That settles the mechanical gap. The design questions above — the metadata offer, the apply.ri == offer.i invariant, and the per-context-AID model — stay open here.

[SmithSamuelM]

I wrote about this in more detail in #1512

I concluded that the disclose field value should not be a dictionary but a list of tuples. This resolves the problem of ACDCs in a DAG that share the same Schema. The ordering of of the list follows a breadth first search of the DAG, orgin node of the DAG is the zeroth entry. EAch tuple is of the form (Schema Said,[list of paths]) Its paths are relative to itself ie is rooted at its top level. All other paths for other ACDCs in the list are relative to the orgin ACDC and traverse edges. This removes any ambiguity and makes every disclose in an Apply offer of the same information have the same set of tuples in the same order. If well also impose top to bottom ordering on the paths in each path list then we get a perfectly reproduciable set (as long as we minimize the path lists to eliminate redundancy)

The examples above use dicts for the disclose field.

[dhh1128]

Adopting it. The dict was the one piece of the strawman I'd already marked broken — two same-schema creds in a chain collapse to a single key — and the ordered tuple-list fixes that while making two equivalent requests serialize byte-for-byte the same.

The CLC example makes the ordering concrete. Its presentation is a three-node DAG: the bespoke presentation ACDC at the origin, with two I2I edges — identity to the SEDI core-identity cred, age to the age aggregate. So the list is [(bespoke schema, [...]), (sedi schema, [...]), (age schema, [...])] — origin zeroth, the two edges after it in edge order.

The piece I want to pin before re-encoding is the non-origin paths. Today the example roots each source cred's paths at that cred — /a/i, /a/photo on sedi, /A/i, /A/over21 on age. Your rule makes everything past the origin relative to the origin and traversing edges. How should the edge hop be spelled — by edge name (identity/a/i), by edge SAID, or is that exactly the Pather grammar #1512 is still settling? I don't want to encode it two different ways.

The origin node raises a smaller question. When nothing is requested at its own top level — here the bespoke ACDC is just the vehicle for the edges and the terms — does the zeroth tuple still appear with an empty path list to anchor ordering, or drop out?

I'll convert the merged CLC example (test_clc_disclosure.py) to the tuple-list and carry it as the settled apply shape into the IPEX companion once the grammar is pinned.

[SmithSamuelM]

@dhh1128

Insertion ordered dicts mean that ordering of fields labels survives serialization round trips.
This means that pather syntax works with either field labels or numeric index offsets for each nesting level of field maps and
also works when a given value is either a field map or an array.

Using a breadth first search order for a DAG is therefore perfectly reproduceable when generating a list of tuples, one element for each ACDC in the DAG.

This means that for most cases there is no need to actually have paths traverse edges. I think there may be some corner conditions
but if not then I revise my guidance and say that we don't need paths to travers edges at least by default. This also means that
for deeply nested DAGs we don't get cumbersome bulkly paths.

While the pather syntax allows both indexed and field label pathing, for readability use field labels unless the path actually traverses an array.

Assuming we can find corner conditions that require a path to traverse its edges the syntax would be
Path starts at origin node /e' and traverses the edge groups and edges through the n` node field to the far-side top level
example.

The ambiguity here is that a path that starts with the ACDC in an intermediate node (not) the origin could begin with /e of the
intermediate node not the /e fo the origin.

So a proposed change would be that paths that begin with / are absolute relative to the orgin node and paths that do not begin
with / are relative to the node defined by the DAG tuple.

So this revises the prior proposed syntax.
So paths for the origin node path list element of the tuple can start with / or not because the origin not is both the absolute
origin but unabiguously a relative path can only start at the origin, but every other node tuple path list element path starts with not / unless the path list traverses edges starting at the origin node and then it must start with /e of the origin node ACDC.

This changes the meaning of absolute paths. Absolute paths now are not ACDC relative but DAG Origin relative.
This is a better convention IMHO as it respects the fact that a presentation is always a DAG of ACDCs and absolute pathing
is rooted at the origin of the DAG and relative pathing is relative to a node in the DAG which node is uniquely determined by its offset in the breadth-first DAG list of tuples.

for the issuee of the accreditation credential in the Transcript ACDC spec example
/e/accreditation/n/a/i edge traversal path
a/i not edge traversal path

for the issuee of the research report credential in the Transcript ACDC spec example
/e/reports/research/n/a/i edge traversal path
a/i not edge traversal path

There isn't a deeply nested DAG in the examples but suppose the research report credentail had an edge then a path that traversed two edges would look like

/e/reports/research/n/e/someedge/n/a/i edge traversal path
a/i not edge traversal path

Corner conditions for syntax is a public simple compact edge. A public simple edge does not have an edge block just an edge field label whose value is the node SAID and the schema must indicate that the label is the far node said not an edge block compacted said

In this case the edge path does NOT traverse through an n field just the edge label.

For private edges, we can safely assume that the edge block includes the manditory n field so the edge block label and the n field are known from the schema. so we can always constuct a path. using knowledge of the schema alone.

As mentioned previously, this may require a two step negotiation with private edges where an agree releases the ability for the offerer to uncover the schema of a private edge in a grant that then allows a subsequent apply for the acdc behind that private edge.

As I write this I am not coming up with any corner cases that require paths with edge traversal?

I think that in specifications, user guildes, debugging and maybe even user interfaces, having a syntax for paths that traverse edges will be useful even if it does not need to be used in Apply and Offer messages.

So we can make it optional in the later case.

[dhh1128]

@SmithSamuelM — I have adopted #1549's dp construct in the worked examples: #1561 converts the two merged ones (CLC, bulk issuance) and #1530 carries it for the guardianship example. All four points are in: the dp label, the query section rather than the attribute section, the ordered list of (schemaSAID, [paths]) pairs replacing the dict, and ACDC-relative paths with no leading /. The solicited offer carries dp: [].

Adopting it surfaced that one question from this thread is load-bearing, and it is the only thing I had to guess at.

#1549 says the zeroth tuple MUST represent the DAG origin node. In the CLC example that is Alice's bespoke presentation ACDC. But the message that carries the first dp is the club's apply, and per your own point in #1512 the applicant "won't necessarily know the SAID of its schema in the application" — the offer is what supplies it. So in a first-contact apply the origin tuple is precisely the one entry the sender cannot fill in.

I encoded the omission: the list carries only the two source schemas the club can name, with the assumption recorded in a comment at the call site. Three ways it could resolve, and I would rather change it once than encode it twice:

1. The ordering rule binds only where the origin is known — i.e. the offer and everything after it. An apply's dp is a set of per-schema asks with no origin slot, and breadth-first indexing starts once the DAG is known. (What I implemented.)
2. The origin tuple is always present, with an empty or placeholder schema SAID in the first-contact case, so index k is stable across every message in the exchange. This keeps Revised Disclosure Paths `dp` field value syntax #1549's "zeroth element MUST represent the origin node" literally true, but it invents wire syntax you have not specified.
3. An apply is not a DAG request at all — it names schemas and paths, and only the offer's dp is DAG-ordered. That would make apply and offer carry the same field label with different value grammars, which I suspect you would not want.

My instinct is (1), because it keeps one grammar and one meaning for dp and simply lets the list be short when the DAG is not yet known. But it does weaken the reproducibility claim: two applicants asking for the same thing agree byte-for-byte, yet an apply's list and the corresponding offer's list are then offset by one, so a comparison across the two messages is not a straight index match.

The smaller sibling question from earlier in this thread is the same shape: when nothing is requested at the origin's own top level, does the zeroth tuple still appear with an empty path list to anchor ordering, or drop out? Under (2) it must appear; under (1) it can drop.

Two other things worth recording from doing the conversion:

• The query block was the right call. keri.core.eventing.exchange() already takes modifiers=, which serializes to q in both v1 and v2 — so dp in the query section needed no builder change at all.
• dp has no home in a live spec. trustoverip/tswg-ipex-specification is archived (last push 2023-11). Should the normative text go into the ACDC spec alongside the disclosure sections, or does the IPEX spec need reviving? Happy to draft either once you say which.

[SmithSamuelM]

@dhh1128

dp has no home in a live spec

I think we add it to the ACDC v1.1 spec draft. Going forward, assuming an IETF WG gets formed this fall, as you know, the IETF likes to have have lots of little specs not one big spec, so IPEX probably gets its own spec. But for now we can put it in the v1.1 draft.

Says the zeroth tuple MUST represent the DAG origin node.

This is a good point and the dp discussion overlooked. it. It has been nagging at me what to do for bespoke ACDCs where the applicant may have no way of knowing that the offer will include a bespoke ACDC resetting the origin node.

In most real world applications the applicant defines what it will accept. If I go to a bank and want to on board, the bank defines what the set of credentials are for onboarding. Likewise for most SEDI use cases with the state where the citizen is the offerer, the state agency to which the citizen is presenting the DAG is the applicant but the application is already well known.

For example when I had to get a new SS Card because my wallet had been stolen, I went to the SSA web site and filled out a form to schedule an appointment, the appointment instructions detailed for me the set of documents I MUST bring and in what form they must appear. So in these standard use cases the applicant defines the DAG not the offerer.

The seeming disconnect is a bespoke ACDC. The term bespoke may be misleading in this cases. In the Issuer-Holder-Verifier model the presented credentials or offered/granted credentials using IPEX terminology are largely Issued by a third party not the presenter/holder But a bespoke ACDC is issued by the Holder as a way of structuring the presentation. It could just as well be defined as a presenter issued credential and not a bespoke credential. The reason for the distinction is that for an applicant defined DAG the orgin credential could have a well defined schema as defined in the EGF but be holder/presenter issued instead of non-presenter issued.

So in all of these applications, the Applicant would know the schema of the origin node despite it being a presenter issued ACDC.

Indeed, I anticipate that most SEDI EGF defined IPEX exchanges would include a citizen presenter bespoke ACDC as the origin as a way of enabling the citizen to add presentation specific terms in its rule section. This means the schema would be fliexible for the rule section but less flexible on other sections.

Why pre-defined defined DAGs? The heavy lift in adoption for interoperability is that most verifiers will be enterprises or government who have high friction high cost long lead cycle business logic development cycles. They have to meet multiple internal policy and regulatory constraints. This means they need to know up front well in-advance pre-agreed upon structure for presentations. In the ACDC world this means the shape of the DAG being presented. The ACDC spec anticipated this by specifically allowing presenter issued bespoke ACDCs in the DAG. Bespoke could be detemined by the presenter on the fly or it could be per presentation DAG shape as defined by the applicant.

All that said, there are meaninful use cases where the shape of the DAG is not pre-defined. So we need to resolve the bootstrap to an offer that defines it.

As far as I can tell 1 does not solve the shared schema problem? I am leaning to sometihing more like your 2 but with some amplifications

So the nuance here is that we really have two classes of use cases.

• Predefined DAG shape typically EGF defined
• Non predefined (typically Offerer defined but could be applicant defined) DAG shape

So for non-predefined DAG shape inititated with an apply, the offerer needs a trigger requesting an offer. So how to structure an apply that is really just triggering the offerer to structure the DAG for the applicant.

Recall that IPEX is peer-to-peer interaction not client server. A valid IPEX can start on the Offerer side with an offer or a grant. It does not have to start with an apply.

The DP field syntax does not require the apply and offer to use the same shape for the DAG; the origin node in each can be different. It does make it convenient to ditto when the shape is the same.

One approach would be for the applicant to assume a DAG shape with an origin node. The offerer could look at the shape and decide that it is coherent with what they are willing to offer or match it to a shape that is a good fit and then respond with an offer of a different DAG shape but is a suitable match. In the case where the applicant DAG shape has a bespoke origin but an applicant-defined schema, that schema could be attached to the application itself.

For an offerer-defined DAG shape, the natural way to start an IPEX is for the Offerer to make an unsolicited offer to the endpoint for IPEX on the verifier (applicant) side. When the applicant wants to solicit an offer, then they provide a DAG shape that they expect will induce the offerer to either respond with a different offered shape or spurn and then initiate an Offer of the proposed shape.

The origin node schema makes it easy to determine if they are that same DAG shape (the difference being that if there are optional edges then some branches may or may not be present)

Logically, if an offer responds to an apply where the offer uses a different schema SAID for its origin node, then it is functionally the same as if the Offerer spurned the apply and then initiated a new IPEX with an unsolicited offer.

So we could harden that requirement and make it that if the offer origin node schema would be different than the apply origin node schema, then the offerer first spurns and then initiates a new offer. Not sure if we want to harden that just yet or at all.

In general, for non-predefined DAG shapes, it is to be expected that an apply is shooting in the dark to some extent. So the best they can do is structure a DAG with a bespoke schema and either the offerer likes it, or the offerer responds with something close.

For non-predefined DAG shapes, the origin node schema could be very loosly defined thereby allowing a MetaData ACDC of almost any shape. Given this, requiring an origin node schema seems easy to meet.

Recall that in this case the apply is triggering a negotiation. The applicant must have some idea of what they want from the offerer, but it may differ from what the offerer wants. But forcing the apply to define a DAG shape simplifies the tooling everywhere else.

To summarize:

So the offerer can do two different things (peer-to-peer interaction). to an Apply shape it does not like.

• The offerer can reject the applicant-defined DAG shape by spurning the apply, thereby ending the IPEX. The offerer continues the negotiation by initiating an offer with a DAG shape it likes.
• The offerer can reject the applicant-defined DAG shape by responding with an Offer with a different shape.

For predetermined EGF-defined shapes, the IPEX can be initiated from either side: apply or offer, and the predetermined shape will be used for subsequent messages.

IMHO, interoperability and wide adoption is best facilitated by predetermined DAG shapes. This enables enterprises and governments to implement business logic that they can support.

In this case, "pre-determined" is suitably qualified to include optional edges or other optional parts. which means that the shape has flexibility, but that flexibility is constrained as opposed to totally freeform.

When the DAG shape is not predetermined, then both sides of the negotiation have to be able to match similar shapes well enough for the negotiation to proceed. I expect this matching will eventually end up looking a set of predefined shapes but with more optionality in the edges and rules.

So it will converge to a spectrum of degrees of optionality for predefined shapes where the shapes are defined by the use cases.

[SmithSamuelM]

@dhh1128

In my experience totally free-form credential exchanges are largely impractical. Going back to my Sovrin consulting days with Medici. They had several portfolio companies that started down the path of using Aries Sov credentials etc for business logic. In every case they ended up with narrowly defined predefined shapes for Presentation Exchange as driven by their business model requirements. This meant that everyone in their ecosystem had to adapt to those shapes. It was not fiscally viable for them to support too much flexibility.

In a business context in general, every enterprise has a set of policy manuals that drive their internal software systems. This translates into things like standard vendor, customer interactons. These policy manuals would generate enterprise specific EGFs for the use of ACDCs. So if a customer or vendor wants to do business with that enterprise they would have to support the enterprise EGF.

So predefined shapes will be the norm. Those shapes need an applicatoin specific level of optionality. Schema as type provides an appropriate level of flexibility given the composition operators in JSON-Schema.

I also believe that as a DAG increases in complexity it becomes less flexible.

So the non-predefined use cases will largely be very simple and a universal bespoke schema that places little or no contraints on its edges, rules, and attributes other than the issuer and issuee could be used in any apply where the applicant is shooting in the dark. then they have a dag of an origin and a set of edges that point to schema the set of associated ACDC types that are looking for or that trigger a match to the application.

The endpoint for the IPEX exchange can also be used to aid in the match where a given endpoint provides a context. I.e. endpoint to provide a liability waiver in order to enter a trampoline park.

My thinking on this has evolved over time. The current spec is very unrestrictive. This is because hardening means having an opinion, and I didn't have a strong opinion. But now, seeing how hard it is to bootstrap ecosystems, I believe that graduated disclosure benefits from a tighter negotiation context. This looks to me like a DAG with a given shape determined by a schema for its origin. The schema can be very, very loose, so it's a soft constraint. But it is a meaningful constraint that means all negotiations use a more constrained vocabulary than if not. And constraints make it easier to build interoperable tooling.

For example, a trampoline park liability waiver as specified via an ACDC whose schema and terms is pre-determined by that trampoline park. That waiver ACDC is the origin with a set of edges, where one edge is the proof of age SEDI, which has an edge to the SEDI core identity. Another edge could be to some other proof of age not SEDI but one that the trampoline park has already decided it can accept. For a minor, on of the edges would be for a delegated authorization by the legal guardian of that minor. So the edge shape is different, but both edges are options as predetermined by the trampoline park's legal team. The schema for the waiver could allow optional terms in the rule section that could be specified by the user for anti-assimilation. Expecting the trampoline park to accept a bespoke on-the-fly DAG with an origin that is defined by the User probably isn't worth it to the Trampoline park. Unless forced to by regulation, they would just tell that customer that they are not welcome. If forced by regulation, it means that a predefined shape governed by the regulation will be provided by the trampoline park in response, not by the user.

So the UX for entering the trampoline park could be a tablet with buttons that show the terms of the liability waiver and allow the user to select which form of proof of age they wish to present from a predefined set. The user's wallet on their phone could then engage in an IPEX with the tablet and would ask the user if the applicant is ok to offer back. Or jump to the grant.

Very few businesses are going to have the resources to build systems that could be smart enough to accept everything a user might provide, at least not in a secure way. It's not that you couldn't design software to be more flexible; it's that the trust in the sources of that information has to be built up and hardened a priori. So it's only a long way down the road that trust is sufficiently infused throughout the ecosystem for flexible-by-default to be practically adopted.

This has been the bane of VCs' adoption. No one will adopt a fully user-defined, on-the-fly, flexible VC because they are not equipped to figure out if they can really trust them or not, whereas both sides have to pre-agree on the predetermined ones, which, if they agree, means they will trust but coming to agreement means solving the two-sided market problem (as you know).

SEDI is potentially game-changing for users (not organizational identity) because, for the first time, both sides must agree in the State-defined ecosystem, and the state has the resources to not only regulate the shapes for their ecosystem but to incentivize the associated infrastructure. Other ecosystems will then be able to leverage the State's ecosystem and infrastructure by creating their own EGFs, with the underlying infrastructure in place. They don't have to fully build it from scratch and on their own overcome either the trust problem of the two sided market problem to do so.

Another example is the international Passport system. Some countries have receiprocal agreements where they will accept one-another's passports without pre-approved visas. If you are not on the pre-approved passport list you can't get in unless you have a visa. You can't get the via at the border. You have to apply for it well in advance and then show up at the border with a visa for your passport. This simplifies trust. Either you present a passport as one edge that is by itself pre-approved by country or you must also have have another edge with a visa issued by the country of entry. Its a well definable predefined shape. No exceptions. You can't convince the border agent you have some other combination of credentials not preapproved by the border agent's country that should be equivalent. The border agent does not have the authority to accept, aka trust, any shape that was not pre-determined.