Graduated Disclosure Pathing Negotiation

[SmithSamuelM]

ACDC IPEX Negotiation

There are several mechanisms that could be used to negotiate a graduate disclosure. These include: attribute path lists, aggregate block label lists, metadata ACDCs, Schema, and Decompositions of Schema.

The problem with negotiating with schema docompositions is that attributes appear disjoint in a schema so pathing to indicate an attribute gets complicated quickly and the pathing logic has to understand JSON schema syntax at a deep level. Whereas in a metadata ACDC the attribute paths are not disjoint so indicating an attribute at any nesting level can be handled with a path string.

So it feels like to me that negotiation should be using Composed Schema as type. So only the SAID of the schema is provided and assume the full schema is cached or attached. Then use pathing of attributes to request the level of partial disclsure and metadata ACDCs for terms negotiation prior to disclosure.

Desired attributes are requested as a list of paths of each attribute or block. If the path is a block then the whole block is meant to be disclosed. If the path is a field in a block only the fields in that block at that field level needs to be disclosed. Any fields whose value is a nested block in that block does not need to be expanded and disclosed.

With nested partial disclosure in an ATT section in order to disclose any field in a block all the simple fields in that block must also be disclosed but non-simple fields i.e. fields whose value is a nested block need only disclose the SAID of the block. So specifiying any simple field via a path would get you all the simple fields in the block holding the specified leaf of the path.

Whereas specifying a block (directory) would be short hand for disclosing the full tree attached all the way down.

For ATT section ACDCs the pathing gets simple since its an array and only the unique field label needs to be specified to designate a given block.

For example

'a':
{
    'd': "Ebslde",
    'u': "Abldle"
    'i': "EDdecd",
    "grades":
    {
         "d": "Efghi",
         "u":  "Abdefs",    
         "gpa":  3.7,
        "transcript":
        {
             "d": "EBDE",
             "u":  "ACEF",    
               "math": 3.5,
              "english":3.8",
        }
     }
}

}

SAID of composed schema as type defines the ACDC in the apple: EABCDSS...
Attribute path list defines what attributes are being asked for: ['a/i', 'a/grades/']
So apply is asking for the top level of the "a" section via 'a/i' or '/a/i' and for the full grades block and any nested subblocks of grades via 'a/grades/' or '/a/grades'
Or because grades is nested down from the top level of 'a'. A path list of simply ["/a/grades/"

Where as a path list of merely ['/a/grades/'] subsumes the other path list.

To get gpa (and the issuee aid) without the grades detail would be simply ['/a/grades/gpa']

In response to an offer, the chain to the apply could either reply with the same schema and path list, or the rule could be that an offer chained to the same apply that leaves the path list None implies it is offering the same path list.
and then the offer includes a metadata acdc that exposes the rule section and the att section said but not the pathed attributes.
The agree then chains to the offer which indicates agreement
The grant then provides an uncompacted version of the ACDC with the appropriate level of disclosure.

To generalize this to apply to those who want graduated disclosure of multiple ACDCs in a chain, I suggest a dict
where the item label is the SAID of the ACDC in the chain, and the value of the item is the path list of disclosed attributes.

The path list is not limited to attribute and aggregate sections; paths could include edge and rule section paths.

For example, two chained acdcs one with an attribute section and one with an aggregate section

{
"EABCDED": ["/a/gpa"],
"EBQRSTR" : ["/A/i","/A/photo"]
}

The path dict requests the gpa field in the ACDC with schema "EABCDED" which means that anything on the path to the "gpa" field must also be disclosed and also requests the selectively disclosable Issuee and photo blocks of the schema "EBQRSTR"

We cannot use ACDC SAIDs in an application in general because the actual ACDC SAID is assumed not to be known by the applicant. But for defined ACDCs, as would be the case for any ACDCs governed by an EGF, the SAIDS of the ACDC schemas would be known. And so the request is for an unidentified ACDC but with a given schema SAID and the paths indicated by the path list.

When the ACDC disclosure includes a bespoke ACDC the ap
When the ACDC disclosure includes a bespoke ACDC, the applicant won't necessarily know the SAID of its schema in the application, but the initial offer can provide it via a bespoke metadata ACDC, and subsequent apply messages can negotiate on that bespoke ACDC schema SAID.

The paths shown use the "/' delimeter but for CESR compatibility we could use the CESR Pathing BASE64 compatible path delimeter "-". Or if we do a little work to name the path list field normatively we could have the tooling auto convert from "/" delimited paths to more compact "-" delimited paths when using CESR serialization of the exchange message.
Or we allow either delimeter and just inject and extract the path as a tuple for reasoning so we are delimiter independent at the reasoning level..

Pather for pathing

I agree that using the existing Pather makes the most sense. This does impose some subtle constraints on the serialization. Currently, pather is used in attachments to reason about the message to which the path is attached. The pathed material group code in the attachment tells the parser to interpret the encoded string as a path.

For generic exchange messages, field values that are strings do not know how to use pather serialization unless we make them special fields. So where we convert to a Pather is relevant. There are some choices and so more discussion before hardening is warranted.

Another related option not mentioned so far is which block in an exchange should request disclosure paths in an Apply go in. There is a query block and an attribute block. By design, there are two blocks so that the exchange (as well as the other message types, query and reply) can more easily model ReST endpoint logic to minimize the impedance mismatch for building KERI APIs.

If one thinks of an http verb with a URL with path and query string and verb message body, the modeling is as follows. The route field in the exchange holds the path from the URL. The query block holds the query string as a field map, and the attribute block holds the verb message body.

So we can put disclosure request information in the apply in three places, the route, the query block, and the attribute block

The route prefix is /apply, but one could overload that and use /apply/schemasaid.
One could define a field in the query block to put a dictionary of paths
One could define a field in the apply block to put a dictionary of paths.

Because the vLEI did not employ graduated disclosure, there was no need to go to any lengths to define this stuff, but now we are discussing the syntax for negotiating over graduated disclosure and its worthwhile now to expose these subtleties

Reasoning with graphs vs reasoning with schema

The multi-ACDC dict is keyed by schema SAID ({"EABCDED": [...], "EBQRSTR": [...]}). That can't disambiguate a chain that contains two credentials of the same schema — two same-type creds collapse to one key. Since you already note the applicant can't know the actual ACDC SAIDs, keying by the edge/node label in the requester's own apply-schema (which the applicant does control) might be the more robust handle for chained disclosure.
You are right the simple example does not account for a chain with repeated schema. So we need to be more thoughtful in how we define it.

This opens up a bigger question, and your reference to the “apply-schema” itself brings in a related issue. This is an area where I have spent some significant effort. The W3C community wants to reason using knowledge graphs. A schema is a type of knowledge graph. A chained graph of ACDCs is also a type of knowledge graph. ACDCs can be modeled with labeled property graphs, which are also a type of knowledge graph.

The core insight for me is not whether we have the ability to reason about or with knowledge graphs, but what type of reasoning we are doing, and whether we should constrain the type of reasoning in a layering of concerns so as to better address the concerns at each layer. Knowledge graphs, as widely used in that community, do not, have as first-order design properties, any security, authenticity, verifiability, confidentiality, or privacy properties as layered concerns. They only model semantics, meaning. These non-semantic concepts are rarely employed, and when they are, they are bolt-ons to the standard knowledge graph. I found the W3C approach of attempting to bolt on security to RDF graph expansions a pathological mess (excuse my strong language). What knowledge graphs are meant to do is reason about the semantics of what is in the graph, not reason about authenticity or correlatability as a precursor to what goes in a graph in the first place. These are different types of reasoning.

One of the prime motivations for ACDCs was to invert that layering. To build mechanisms for security, confidentiality, and correlation resistance in layers that are employed before the semantic reasoning happens.

So disclosure is reasoning about exposure. What parts to expose when. Not what those parts mean once they are exposed. So, to better separate concerns along a layering approach, my intuition is we should minimize the role the schema plays in this layer of reasoning, that is the what to expose layer. This is accomplished by using schema as type, i.e., the SAID of the schema, and the schema validation validates the type. This contraindicates using bespoke schema as the way to indicate exposure. And using schema to indicate exposure is more complicated because pathing in schema is disjoint and requires deep knowledge of the schema semantics to reason about exposure paths.

Reasoning about exposure of elements of a graph when those graph elements are expandable or collapsable or compactifiable is reasoning about the graph structure not the semantics of the information contained in the graph structure. In this case, graduated disclosure, it seems to me we can reason about graph structure using a simplified expression of the graph, not the most complex expression of the graph (JSON Schema). So we should think about what the minimally sufficient means are for reasoning about graph structure not the most expressive means (JSON schema) for that graph structure we have available.

So if we think of an ordered dictionary as a graph, we can model a graph of ACDCs with a dictionary (associative array or field map; we already model the guts of each acdc with a dictionary), so we can extend that by modeling the full graph of ACDCs with an expanded dictionary. This allows us to use a pathing language that is as simple as we can make it. A path is a tuple of labels which can be compactly serialized to a string with a path delimiter.

It has to include a way to path along a chain of ACDCs not merely into an ACDC. As you point out, with the overly simple example I provided of a path list. But we could use an ordered path list to represent a branch in an ACDC chain (only one possible branch) or include the full edge labeling path from the leaf ACDC back up the tree when not a simple chain (one branch). We can have relative to ACDC paths and absolute paths that are paths through the aCDC graph.

The edge labels in the path enable one to explicitly trace which edge leads to which ACDC schema SAID and then path down into that ACDC to the disclosed leaf.

The insight is correct: a request to disclose that uses a path to a leaf implies a closure of all that must be disclosed in order to disclose the leaf, but no more. So compacted sibling branches stay compacted. But then we need a compact way of requesting full expansion, so I used the trailing “/“ to indicate that. This provides a compact way of saying expand all branches below this node.

A path to a leaf implies that the nodes along that path must be diclosed but not sibling branches and no branches below the node holding the leaf, but all leaves in the same node. This is unambiguously implied by a leaf path.

Whereas a node path (trailing "/") already indicates more than a leaf. So we can let that indicate an expansion of the node and all children nodes but no sibling branches. I think this is reasonable. If we need siblinge branches then we specify a path to the sibling leaf or node. The node path rule means if I want the whole graph then I specify a node path to the root node of the tree. If I want a subgraph then the node path to the top node of the sub graph. If I only want specific leaves and this implies the nodes to get to the leaf then I use a leaf path. The leaf path is a scalpel the node path is a hammer.

Clarifications

Issuee AID for aggregative (selectively disclosable) ACDCs

I believe for the core SEDI identity credential, the appropriate choice is to use the selectively disclosable Aggregate section. The state of Utah has not decided, but my suggestion is that it be selectively disclosable, given that most use cases seem to fit that model. In many cases, the only disclosed field value would be the issuee AID field.

The "i" field for Issuee is optional. When not present, it means the ACDC is issued to whom it may concern (untargeted).

The operator I2I is intended to work for either att or agg ACDCs when an "i" field is present.

In the case where no "i" issuee aid field is provided, the I2I operator on an edge would fail.

This is a case where the term "holder" is confusing, because anyone could "hold" and present an untargeted ACDC. Unlike W3C credentials, where the "holder" binding is variable, with both weak and strong forms. An ACDC either has a cryptographically verifiable binding (i.e. strongest) via an "i" field with the issuee aid or there is no cryptographically verifiable binding. It's a boolean concept.

To elaborate:
An attributive ACDC has an "a" section, and if its "a" section has an "i" field at its top level, then the value of that "i" field is the issuee AID.
An aggregative ACDC has an "A" section, and if the second block in its "A" section has an "i" field, then the value of the "i" field is the issuee AID.
An ACDC can only be either attributive or aggregative, not both (mutually exclusive)

The spec should be clarified to precisely describe where the 'i' field in an Agg section is found when present.
The issuee in an ACDC with Agg section (selectively disclosable) is the "i" field in the second (index 1) attribute block.

The SerderACDC class has two relevant properties that provide the issuer AID as appropriate for the type of ACDC (attributive or aggregative). The properties are the .iseaid and .issuee. The .iseaid property returns the issuee aid or None (when the AID is untargeted). The .issuee property returns a Prefixer Matter primitive instance whose .qb64 property is the issuee aid or None. For example, see these asserts in the test_selective_disclosure_aggregate_JSON()

    assert acdc.iseaid == BOB
    assert acdc.issuee.qb64 == BOB

[dhh1128]

Thanks — separating "reason about exposure" from "reason about meaning", and pushing schema down to type-by-SAID, is the right layering. A few other reactions:

Reuse Pather — and name the field

Agreed. Your serialization caveat feels important to me: a generic exn string field is just a string, and nothing tells the parser it holds a path. Name the field normatively and that goes away. Its values are Pathers by definition, so the tooling parses each to a parts tuple coming in and serializes it compactly (-) going out. Your "delimiter-independent at the reasoning level" then comes for free — the tuple is the model, and / versus - is only how it renders. That gives us one grammar, shared with the CESR SAD-paths we already sign.

Put the request in the query block

Of your three placements, it feels to me like the query block fits best. I think your REST mapping is right. A disclosure request is a query — "these fields, of this type" — so it belongs in the query block, which leaves the attribute block for the body: the metadata ACDC that carries the terms. Overloading the route (/apply/schemasaid) ties the verb to one schema and does not generalize to a multi-ACDC request. A query-block dict does.

The grammar is uniform; the closure is not

This is a place I want to pick at. Your leaf-is-a-scalpel, node-is-a-hammer rule feels good. But what a leaf path closes over depend on the section, right?

• ATT — the simple fields of a block share one SAID and one blinding nonce. You cannot reveal one without its simple siblings. So a leaf path closes over every simple field of its block, and nested sub-blocks stay SAIDs — exactly your rule.
• AGG — each element is blinded on its own, with its own d and u. A leaf to one element, say /A/over21, reveals that element and nothing beside it. There is no sibling closure, because there is no shared block.

That means the same syntax can have different closures. So the function that turns a path list into a disclosed set has to branch on section type. Make that the normative object — disclosureSet(graph, paths), computed identically on both sides. The path list is the seed; the disclosed set is what the function returns. Nowhere for two implementations to drift.

Chains with repeated schemas

I don't think we need to forbid two credentials of the same type in a single edge set. That case is legitimate and common — presenting my own identity next to my spouse's, both under the same SEDI schema, is the obvious example — and I'd want the model to support it. The difficulty is only with keying the request by schema SAID, since then the two credentials collapse onto one key and there is no way to request a field from one without the other.

What distinguishes them is not the schema but the edge that reaches each one, and in the bespoke those two credentials would sit under different edge labels. If the request paths name the edge at each hop rather than the schema, the ambiguity goes away. The applicant cannot know the far credential's SAID, but it does define the shape it is asking for, so the edge labels in its own request are a handle it controls. I think this is the "apply-schema" question you raised, and it seems worth working through, because a request for a single credential then becomes just the one-hop case of the same mechanism.

For CLC, bind the scope explicitly

One twinge I have on "a null path list in the offer implies the apply's list": CLC binds an agreement, and the agreed scope is part of what gets bound. I would rather it be explicit and hashable than inferred. Let the offer's metadata ACDC carry the agreed path list next to the rule section, and have the agree commit to that ACDC's SAID. Then "what we agreed to disclose" is an artifact, not a convention two stacks might read two ways. That matters more here than in an ordinary query.

[SmithSamuelM]

The grammar is uniform; the closure is not

This is a place I want to pick at. Your leaf-is-a-scalpel, node-is-a-hammer rule feels good. But what a leaf path closes over depend on the section, right?

Yes, I just haven't looked at the edge section specifically in light of this conversation to say that it's definitely a different closure, but I agree that it could be different, so we need to be more deliberate in defining what the closure is for each section.

ATT — the simple fields of a block share one SAID and one blinding nonce. You cannot reveal one without its simple siblings. So a leaf path closes over every simple field of its block, and nested sub-blocks stay SAIDs — exactly your rule.

Good

AGG — each element is blinded on its own, with its own d and u. A leaf to one element, say /A/over21, reveals that element and nothing beside it. There is no sibling closure, because there is no shared block.
That means the same syntax can have different closures. So the function that turns a path list into a disclosed set has to branch on section type. Make that the normative object — disclosureSet(graph, paths), computed identically on both sides. The path list is the seed; the disclosed set is what the function returns. Nowhere for two implementations to drift.

Yes I agree.
We need to extend that to the Edge and Rule sections. We can have blinded edges for example so a partial disclosure of an ACDC attached to a blinded edge potentially has its own combinatorics for closure logic. Likewise for blinded rule section legal language where the negotiation first uses open terms that enable disclosure of sensistive terms. This is often the case in domestic abuse situations where the legally enforceable terms would leak sensitive information so the verifier must first be put under confidentiality with respect to those sensitive terms before disclosing the sensitive terms.

[SmithSamuelM]

Chains with repeated schemas

I don't think we need to forbid two credentials of the same type in a single edge set. That case is legitimate and common — presenting my own identity next to my spouse's, both under the same SEDI schema, is the obvious example — and I'd want the model to support it. The difficulty is only with keying the request by schema SAID, since then the two credentials collapse onto one key and there is no way to request a field from one without the other.

What distinguishes them is not the schema but the edge that reaches each one, and in the bespoke those two credentials would sit under different edge labels. If the request paths name the edge at each hop rather than the schema, the ambiguity goes away. The applicant cannot know the far credential's SAID, but it does define the shape it is asking for, so the edge labels in its own request are a handle it controls. I think this is the "apply-schema" question you raised, and it seems worth working through, because a request for a single credential then becomes just the one-hop case of the same mechanism.

My response could have been more elaborate. There are shortcuts which we may not want in simple chained credentials where there is no edge branching, so an ordered list of paths can be unambiguously associated with the nodes in the chain, in the same order or in the inverse order, leaf to root. But for any true graph (tree) of ACDCs, this becomes problematic. Technically, ACDCs must be DAGs, not full graphs, and one property of a DAG is that its nodes can be ordered linearly (such as with a depth-first or breadth-first search with tie-breakers for each node comparison). But that adds a lot of complexity for little advantage. Including the edges in the path avoids having to use a DAG ordering algorithm, and maybe the shortcut I proposed for single-branch chains is a case of being too simple.

[dhh1128]

I am thinking about dossiers, where edge sets will sometimes be array-like (e.g., edge names are something like photo1, photo2, photo3, always having the same schema)...

[SmithSamuelM]

The pather language allows path elements as array indices as strings so it is could support edge groups as lists. It assumes that all dicts (field maps) are insertion ordered so that one can specify a full path using only indices, even on nested field maps.

[SmithSamuelM]

It becomes a schema problem. Does the schema allow dyanmic sized sized groups whose size is determined by the instantiation of the graph of ACDCs and cannot be precalculated merely from the schema. If that is the case then we will need a more complex pathing language with the ability to refer to edges in a more abstract sense (last, first, some, all, etc)
. But I don't want to hold up progress waiting for the nth degree specification of all the corner cases. We now have versioning so we can put off stuff until a later version.

[SmithSamuelM]

One amelioration of that case would be for the apply to be able to specify the array as a whole using the hammer syntax, but have the offer respond with metadata ACDC that exposes the cardinality (size) of the array so that subsequent apply can now use a precise index number in the path. This would be one way to forestall having to have a complex pathing syntax with abstract path elements. They can all be concrete; it just means the initial offer must instantiate the sizes of arrays by disclosing the nodes, branches, or leaves without necessarily unblinding the field values inside the leaf blocks.

[SmithSamuelM]

I think for dossiers the most restrictive correlation resistance possible is not wanted. So the initial offer metadata ACDC can expose the cardinalities of array like nodes of edges so that a followup apply can specifically ask for disclosure using concrete edge pathing syntax.

[SmithSamuelM]

For CLC, bind the scope explicitly

One twinge I have on "a null path list in the offer implies the apply's list": CLC binds an agreement, and the agreed scope is part of what gets bound. I would rather it be explicit and hashable than inferred. Let the offer's metadata ACDC carry the agreed path list next to the rule section, and have the agree commit to that ACDC's SAID. Then "what we agreed to disclose" is an artifact, not a convention two stacks might read two ways. That matters more here than in an ordinary query.

Appreciate the feedback. Performance and size verbosity always rears its ugly head at some time so I have to ask. But I agree that when managing legal contracts explicit rather than implicit is usually better. That said the apply is bound via the prior digest in the offer so technically a null path list can be unambiguously verifiably resolved as the apply path list the offer is bound to. So technically it is hashable. so if the reason you twinge is thinking its not hashable, then that is technically not true.

It does mean that one must store the apply and can't simply store the offer and elid the apply but if the apply started the transaction then one needs it anyway to verify the xid for the transaction. So no advantage there. Knowing explicitly how the transaction started with an apply and that the offer dittoed it instead of countering with a different offer may have value. I don't have a strong preference. But its hashable either way.

[SmithSamuelM]

Detail for dp disclosure path field

Originally this was the disclose field label, but that did not follow the convention of compact labels for reserved field labels. This was an oversight.

So the disclose field label should be the dp for disclosure paths

Pathing for multiple ACDCs is a list of tuples. Where each tuple is (Schema SAID, [Paths]). The tuple allows a schema Said to appear more than once (not the case for a dict where the item key is the schema said). Each path in the list of paths indicates what parts of the ACDC is to be partially or selectively disclosed. When communicating over the wire, the paths are serialized using Pather syntax. Abstractly, each path is a tuple of path elements as either field names or integer index offsets. The Pather syntax is extended to traverse through edges not simply inside an ACDC. A path ending in a path delimiter indicates a node (block, directory). For disclosure thes means the full expansion of all branches beneath that node. A path that ends in leaf field label, indicates that expansion is limited to that leaf and any nodes on the branch to that leaf as needed to verify the node SAIDs. A path is treated as a closure over all the associated fields specified by the closure.

The schema section is always disclosed.

The partially disclosable sections are the
Attribute, Edge, and Rule sections.
The selectively disclosable section is the Aggregate section

So a path list element in a given ACDC tuple in the "disclose" field can specify the whole ACDC or some combination of Attribute or Aggregate and Edge and Rule section paths.

In a presentation exchange the path lists can granularly specify what parts of the ACDC(s) are to be disclosed.
In an issuance exchange, the ACDC is always fully disclosed, so the path list always specifies the whole ACDC.

Typically, the rule section is always fully disclosed, but because one can have blinded rules, rule section must also support
partial disclosure so it can't be assumed as always fully disclosed.

This disclosure list is the value of the disclose field in the query section of the Apply message and the Offer message.
When the Offer is solicited (i.e. in response to an Apply), then an empty list for the value of the disclose field of the Offer means that
the offered disclosure list is the same as that in the Apply message. When the offer is different or is unsolicited, then the disclose field value must not be an empty list.

Typically, the offer provides a metadata ADCD which discloses the rule section so that the disclosee can agree to those terms.

The pathing for the selectively disclosable Aggregate section is special. The Pather methods that extract values using a path on a
SAD will have to be modified to work with Aggregate sections. In a selectively disclosable Agg section the attribute blocks show up as a blinded array. By design, a given disclosee does not know which index or offset into that array a given attribute lies. But each attribute block includes a unique labeled field. So when using a path for disclosure of an aggregate section attribute block, the path uses the unique field label for the block, and the extraction of the field requires expanding the path by first computing the offset for each block label so that the offset can be included in the path to actually reference into the array.

Here are some simple examples of disclose field values when only one unchained ACDC is presented. This is the origin node so
the paths are relative to the toplevel of the origin ACDC which is indicated by "/"

"disclose": [(schemaSAID, ["/"]]  # disclose whole ACDC

"disclose": [(schemaSAID, ["/a/","/r/"])  # disclose attribute and rule sections (assumes no edge section)

"disclose": [(schemaSAID, ["/A/i","/A/name", "/r/"])  # disclose the Issuee and name blocks from the Agg section  and the rule sections(assumes no edge section)

The zeroth item in the list of tuples is the origin ACD of the ACDC graph. In a DAG, the origin node (vertex) is a source node. A source node only has edges that point away from the node (outgoing edges). It has no incoming edges. So in any graph of ACDCs, the origin node will be the ACDC being presented. It will be the only source node (only outgoing edges) in the graph. All other ACDCs are chained off from it directly or indirectly. Therefore, all ACDCs but the origin will have at least one incoming edge. A special case of an ACDC graph (DAG) is a chain where the origin ACDC is the end of the chain (tail) and there is a single branch back to the start (head) of the chain

We can order an ACDC DAG starting at its origin ACDC with either a breadth-first or depth-first search ordering. All paths but the origin are absolute starting at the origin. This eliminates any ambiguity. To elaborate, each path disambiguates where in the graph an ACDC with a given schema appears and where in that ACDC a given leaf or node is to be disclosed. To clarify, when multiple ACDCs of the same type appear in the graph ( which means that they have the same schema SAID), then the path is absolute, with its origin in the origin node of the ACDC graph. This removes any ambiguity. When the ACDC graph is a chain, then one could use relative paths for all nodes since there is no branching ambiguity. The order of appearance in the list of tuples indicates which ACDC in the chain the paths list applies to.

We could use either breadth-first or depth-first search ordering to order the DAG. I think we want to use breadth-first ordering. For example, in cases like a dossier that is using joint issuance, a breadth-first ordering would group all joint issuers together in the list of nodes.

  [
      (OriginSchemaSAID, [OriginPath rooted in top level of orgin node]),  
      (SchemaSAID, [Chained ACDC path rooted in top level of orgin node and traverses through origin node edge and so on]),
      ...
]

[SmithSamuelM]

@dhh1128 @ryan-hansen

Based on discussion. This is my proposal for the syntax for the pathing in the query block of the Apply message.

[SmithSamuelM]

@dhh1128 @ryan-hansen

This is an amendment pulled from discussion of an issue

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.

[SmithSamuelM]

Low-Stakes Signed-Only IPEX Transaction.

Only the granted ACDC is itself perpetually verifiable, Not the IPEX transaction

Low-Stakes Signed-Only IPEX Transaction with Impersonation Protection via Presentation Blinded State Registry

The Grant is anchoring in a registry controlled by the presenter. This enables the presenter to detect if anyone has compromised the Presenter's keys and is fraudulently using those keys

High-Stakes Anchored IPEX Transaction

The Agree, and Admit exchange messages are anchored by the Disclosee. The Grant is anchored by the Discloser. This provides a type of perpetually verifiable settlement of the information exchange with respect to the terms of the exchange. Impersonation protection is provided to Presenter via the Grant anchor as long as the EGF requires and Disclosees enforce the Grant anchor.

High-Stakes Anchored IPEX Transaction with Presentation Blinded State Registry

High Stakes Presentation with perpetually verifiable non-repudiable committments to disclosure terms and forced proof of impersonation detectability via presentation blinded state registry. The ACDC itself requires the grant be anchored via the rd field in the att section. The presentation registry can be shared across presentations of different exchanges with different ACDCs.

[SmithSamuelM]

@ryan-hansen @dhh1128

Added the diagrams here. Updated as well