Repository navigation
Revised Disclosure Paths dp field value syntax
#1549
Replies: 5 comments 6 replies
|
@ryan-hansen @dhh1128 @KeaxD @evanja57 @jaelliot this is a more normative specification of the disclosure paths |
|
@dhh1128 I updated the |
|
As per the discussion in the community calls, I promised to think about a pathing syntax that works with the limitation of Pather compact serialzations to only allow Base64 characters when CESR serialized. We support this by forbidding In that light the only Base64 character available to us that could delimit an ACDC DAG edge hop (from one field map subgraph to another field map subgraph) is the But we could restrict attribute name and dict Keys’s to not use a single If all we gained from the use of But if instead of treating So what does this look like. Revisiting the examples above. DAG Absolute FormAnd example Expansion FormWhen expanded each edge block gets a new field whose label is ‘ For examples |
|
Is the following formatting of the "_" field accurate? {
"research": {
"d": "EN9ngstOcFHqsjqf75JZFKtCRmW76NkeRrUSxTLoqqkI",
"u": "0ABhY2Rjc3BlY3dvcmtyYXc2",
"n": "EAU5dUws4ffM9jZjWs0QfXTnhJ1qk2u3IUhBwFVbFnt5",
"o": "NI2I",
"_": {
"v": "ACDCCAACAAJSONAAK4.",
"t": "acm",
"d": "EAU5dUws4ffM9jZjWs0QfXTnhJ1qk2u3IUhBwFVbFnt5",
"u": "0ABhY2Rjc3BlY3dvcmtyYXdi",
"i": "EEDGM_DvZ9qFEAPf_FX08J3HX49ycrVvYVXe9isaP5SW",
"rd": "EJl5EUxL23p_pqgN3IyM-pzru89Nb7NzOM8ijH644xSU",
"s": "EKMXqyMQmOy0RuEj1VgOK9aD4GYR0D8Dcj0kssQtcY4-",
"a": {
"d": "EFTqnoiGSf-D76W3geNxEudBI_wz81FIkIXjzsjFztI-",
"u": "0ABhY2Rjc3BlY3dvcmtyYXc4",
"title": "Post Quantum Security",
"name": "Zoe Doe",
"report": "Imprementation should prioritize cryptographic agility over PQ."
},
"r": {
"d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU",
"l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient."
}
}
}
} |
|
Yes the comma was wrong. I have since updated my original comment to fix it |
|
As a result of the discussion in the developers meeting. The This means the we will have to propose a change to the ACDC v1.1 spec. There will need to be a new reserved field label |
|
After some more discussion about the dp field syntax, there is an optimization that might be convenient to use. When there is on overage more than one path in the path list for each acdc in DAG absolute form for a DAG with more than 1 ACDC, then there is significant redundancy in the DAG absolute paths because every path in the pathlist in the tuple for a given ACDC shares the same path prefix. The optimization would be to expand the tuple to three elements as follows: The paths in each pathlist would then be in ACDC relative form and the path prefix is prefixed to each when expanded to create the full DAG absolute path. This makes the expression sent over the wire in the exchange message much more compact. The prefix could be the empty string when DAG absolute is not needed. Here is the last example with Same example but in ACDC relative form. This means the path prefix is the empty string "". In python at least, we can implement the list of tuples as a list of named tuples to make referencing the particular element of the tuple more convenient. The named tuple would be of the form |
|
After explaining this to ARI I realized I could optimize it by making a three tuple with a shared path prefix. What does everyone think? |
|
@SmithSamuelM — I like the triple, and I'm going to start putting it to work in my PR against the ACDC v1.1 draft, to see if all the pieces connect in my brain when I explain it. I have a couple questions:
With
In #1512 that was The same gap exists in ACDC-relative form with an empty prefix; I think that today there is no way to say it at all. If we go this way, then I think we're adopting 2 rules: a prefix is either empty or ends in |
Technically in DAG absolute form the breadth first search ordering is not required but I suggest we keep it for consistency and readability. Any code that generates a "dP" has to have a serialization algorithm for the DAG is its no extra work to require it. They would have to go out of their way to not follow either a depth first or breadth first ordering.
Good catch. It would be the empty string in the path list with the "/" as the prefix. Since a path that starts with a "/" is in DAG absolute form, there is no ACDC relative path (empty prefix) that specifies the whole ACDC that does not include a non terminator . A simple "/" as the path is a special case because it begins and ends with a slash that is the same slash. So a tuple ( "SchemaSAID", "/", [""]) would generate tje DAG absolute path "/" that is the whole ACDC. The tuple ("SchemaSAID", "", ["d/"]) is one way to specify whole ACDC with an empty prefix (so that the complete path is ACDC relative). Any ACDC-relative path that starts with a top-level field in the ACDC and ends with a "/" will create a closure that is the whole ACDC.
The latter rule is already implied because ACDC relative cannot begin with a "/" |
I found this in the v1.1 spec pull request.
The above does not detail some corner cases related to the pathing issue. Attempt to cover them here. All blocks but the Aggregate block said field in the array, the zeroth element of the array, must include a unique field label besides When the block has no nested blindable (partially disclosable )subblocks, then this is also equivalent, from a closure perspective, to When there are nested partially disclosable subblocks, then its problematic. There is no unambiguous way to partially disclose a subblock given the abbreviated path syntax (that elides the array index). But such a partially disclosable subblock is an anti-pattern for using selective disclosure, as we are mixing partial disclosure inside a selectively disclosed array. This feels like we misdesigned the ACDC and are reverting to the portable data lake approach instead of a DAG of ACDCs. So it should raise an error during expansion when trying to do anything like If we really want to have partially disclosable selective disclosure, then we must insist on including the array index in the path. Recall that with the special abbreviated path syntax for the This special expansion path logic means that special expansion for the
So if we want to specify
The former does not mean that a selectively disclosable blinded attribute block must only have one field or that field or other fields in it must not have nested blocks as values but that a closure on that block always returns everything in that block. In other words, nested blocks must not be partially disclosable, subject to the most compact said calculation and compaction. Nested partial disclosure via nested partially disclosable blocks inside a selectively disclosable block is the anti-pattern not nested blocks in a selectively disclosable block. Zeroth ElementBecause the Zeroth element of the Aggregate section is not blinded, it is always disclosed in any closure that discloses any other element. But if we want to only disclose it, then we must use the non-shorthand path `A/0' And |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This is a summarization and tightening of the discussion #1512. There were several extended responses and some signifcant evolution during the discussion. This dicussion tightens those all up. And #1512 was inresponse to #1542
Background
Issuance and Presentation Exchange (IPEX) of a DAG of ACDCs as Graph Fragments
The issuance and/or presentation of an ACDC is generalized as the issuance or presentation of a DAG (directed acyclic graph) composed of a set of connected ACDCs. ACDCs include nodes that are connected (chained, linked) via their edges. In a directed graph, the edges are unidirectional from the near-side node to the far-side node. To elaborate, directed edges have a near side and a far side where the edge points (directs) from near to far. Each edge in the DAG is defined in a subsection of the ACDC attached to the near side of that edge.
Technically, therefore, an ACDC is a graph fragment consisting of a near-side node and that node's outgoing edges as contained in its edge subsection. An ACDC does not contain any incoming edges to its own node, only outgoing. Its incoming edges are contained in other ACDC graph fragments. The node part of an ACDC graph fragment may be thought of as its top level plus its schema, attribute, aggregate, and rule sections. For brevity, we may refer to ACDCs as nodes in the DAG when such reference does not carry any ambiguity. To clarify, while an ACDC is not simply a node, we may refer to it euphemistically as a node because it only contains one node.
A source node in a DAG is defined as a node that does not have any incoming edges. It MUST either have no edges at all or only outgoing edges.
A given issuance and/or presentation exchange (IPEX) is concerned with the disclosure of a single DAG composed of connected ACDC graph fragments. That DAG MUST have only one source node called the origin node. The origin node is contained in the principal ACDC being presented.
In a use case where it would be beneficial for a single IPEX to exchange a set of multiple unlinked or unchained ACDCs, then a DAG MUST be formed by issuing a bespoke ACDC that contains the origin node of the DAG with edges chaining back to all the other ACDCs to be included in that exchange's DAG. A bespoke ACDC can combine multiple DAGs into a single DAG with a single origin node.
Bespoke ACDCs MAY be issued by any presenter. One purpose of a bespoke ACDC is to include presentation-specific information, such as custom terms in its rule section. This means that any exchange of information from a discloser to a disclosee may include both ACDCs issued by another party but presented by the discloser and ACDCs issued by the discloser. For this reason, the exchange transaction is called an IPEX (Issuance and Presentation Exchange), not one or the other.
Another purpose of a bespoke ACDC is to normalize the structure of an IPEX that wants to includes multiple ACDCs. The bespoke ACDC is used to create a single connected DAG with a single source node, its origin node. This gives an IPEX a well-defined normalized structure.
This discussion leverages that normalized structure.
Detail for disclosure paths
dpfieldThe field label in the
querysection of eitherapplyorofferIPEX messages should bedpfor disclosure paths.Originally, in the discussion, the proposed field label was
disclose, but that did not follow the convention of compact labels for reserved field labels. This was an oversight.The value for the
dpfield is a list of tuples. Each tuple represents one ACDC in the DAG that is the object of the IPEX, and is of the form (ACDCSchemaSAID, [disclosure paths]). The first element of the tuple is the qb64-encoded SAID of the associated ACDC. The second element is a list of paths into that ACDC. Abstractly, each path is a tuple of path elements as either field names or integer index offsets. To elaborate, when the path element represents an array, tuple, or list element, not a field in the field map, then the path element is a number that is the zero-based offset into the array. When communicating over the wire, the path tuples are serialized using Pather syntax. The Pather syntax must be extended to traverse through edges, not simply to traverse inside an ACDC. This is a work item to extend the Pather methods to include convenience methods for extracting targets of paths that traverse ACDCs in a DAG.Using a list of tuples enables a given ACDCSchemaSAID to appear more than once in the list. This would not be the case if a dictionary were used instead of a list.
DAG of Subgraphs and Ordering
When discussing paths, we have an extended graph. An ACDC is a nested set of collections. These collections may be either abstractly expressed as field maps (associative arrays) or arrays. The top-level section of the ACDC is a field map. Each field value in that top-level may be either another field map or an array that in turn may be further nested. This nested set of collections forms a graph, specifically a tree. Thus a DAG of ACDCs is a graph of subgraphs. Each ACDC's contents form a subgraph. The path abstraction is extended to the expression of trace through this graph of subgraphs. Therefore, when discussing disclosure paths, the term node may refer to either a node in an ACDC graph or a node in a given ACDCs subgraph. A path that traverses edges may traverse through multiple subgraphs.
Each path in a path list indicates a closure of a part(s) of that ACDC that are to be partially or selectively disclosed. The path syntax is discussed in a later section.
The fields maps inside an ACDC are expressed using ordered field maps (ordered dicts, ordered associative arrays) where the ordering is insertion order. The advantage of insertion order is that the ordering survives round-trip serialization of the dict. Because arrays are already ordered, the subgraph inside each ACDC is a well-ordered tree. This means the DAG of ACDCs itself is also well-ordered since each edge section is expressed via an ordered field map. A well-known property of a well-ordered DAG with a single source node is that the nodes in the DAG may be linearized in a unique, reproducible ordering.
One such ordering is the result of a breadth-first search of the DAG starting at its origin node. A depth-first search is also a way to generate a unique, reproducible ordering. We choose a breadth-first search because in some applications, like a dossier using joint issuance, the joint-issued ACDCs would show up together in a breadth-first ordering but not in a depth-first. The former makes it easier to comprehend.
When the DAG is a single chain of ACDCs, a breadth-first and depth-first search return the same ordering.
To recapitulate, a breadth-first search order of a well-ordered DAG of well-ordered subgraphs is perfectly reproducible when generating a list of tuples, one element for each ACDC in the DAG.
To clarify, the
dpfield value is a list of tuples where each tuple represents an ACDC in the DAG in breadth-first search order starting at the origin node's ACDC. To elaborate, the zeroth element of the list MUST represent the origin node ACDC. The tuples ACDCSchemaSaid element value is the Schema SAID of the origin ACDC in qb64 form. The path list element is a list of paths that generate a list of closures of parts of the origin ACDC.Each subsequent element of the
dpfield list is a tuple representing an ACDC in the DAG. Its path list element is a list of paths into that ACDC that generate a list of closures of parts of that ACDC.This means that, in most cases, there is no need to actually have paths in each path list traverse edges. There is one corner case , however, where this is needed to remove ambiguity. This is when their are optional edges specified in the schema. This is described in more detail below.
When there are no optional edges, the usual case, each path in the path list in each tuple for a given ACDC can be expressed relative to that ACDC and does not have to traverse the full absolute path starting at the origin node and then through edges across the DAG until is reaches that ACDC.
Path Syntax
A path that begins with a path delimiter,
/(equivalently, in tuple form, the first element in the tuple is an empty string) is a DAG absolute path rooted at the toplevel of the origin ACDC of the DAG.A path that does not begin with a path delimeter
/(equivalently in tuple, the first element of the tuple is not and empty string) is an ACDC relative path rooted at the toplevel of the associated ACDC.A path that traverses edges MUST be in DAG absolute form. This means it MUST begin with
/e, where this refers to the edge section of the origin node ACDC. The traversal is through the edge block label or the edge label for a simple compact edge. When an edge is nested in an edge group or nested edge groups, the path must include the edge group labels. The path then jumps from the edge label to the toplevel of the far side ACDC node. The edge block'snfield label is not included in the path. The path starts in the origin node's ACDC subgraph then jumps across the DAG edge from near to far ACDC and back into the far ACDC node's subgraphFor example:
"/e/report/project/a/name"Starts at top level in the origin ACDC and decends through its edgeesection through itsreportedge group through itsprojectedge and then jumps to the top level of the linked ACDC then down through its attributeasection to itsnamefield.Consider an example with two traversed edges:
/e/evidence/e/report/project/a/nameIn this case the path starts at the origin node through itsevidenceedge that then jumps to another ACDC and traverses through its edgeesection, through its edge groupreportthrough itsprojectedge to the attibuteasection of another ACDC and to itsnamefield.Path for the origin node path list element of the tuple can be in either DAG absolute or ACDC relative form, as there is never any ambiguity.
When an ACDC in the DAG has optional edges or implied optional edges because of optional edge groups where optional is allowed by the schema. Then an applicant to a disclosure cannot generate a total ordering of the DAG because some potential nodes in the DAG, as allowed by the schema, may not be present in the actually issued DAG. When there are potentially optional
DAG nodes, then the ordering could have gaps. This introduces ambiguity not solved by a simple ordered list of DAG nodes.
In this case, the paths in the path lists in each entry after the origin node in the
dpfield list of DAG nodes must be in DAG absolute form. This then removes the ambiguity that missing nodes introduce.A path ending in a path delimiter
/(equivalently, in tuple form, the last element of the tuple is an empty string) indicates a whole node (field map, array) that is the value of the final label in the path. A path of this type indicates the disclosure of that node and the full expansion of all child branches beneath that node. This also requires the disclosure of all nodes along the branch to that node sufficient to validate the SAIDS along the path. This forms a closure over all the disclosed parts.A path ending in a non-empty field label or number string as the last element (equivalently, in tuple form , the last element of the tuple must not be empty) indicates a single leaf in the tree.. A path of this form means the disclosure of only the leaf and any nodes along the branch to that leaf necessary to validate the SAIDs that appear along that branch. This does not require the disclosure of any sibling branches. This forms a closure over all the disclosed parts.
To elaborate, a disclosure path translates into a closure over all the associated fields or array elements implied by that path. This closure may span multiple ACDCs along a path that traverses edges.
While the Pather syntax allows both indexed and field label pathing, for readability, always use field labels when provided, i.e., unless the path actually traverses an array.
The top-level schema section of an ACDC is always disclosed so its disclosure does not have to be included in the path list
The partially disclosable sections are the Attribute, Edge, and Rule sections.
The selectively disclosable section is the Aggregate section (see below for special syntax for the Aggregate section)
Typically, the rule section is always fully disclosed, but because one can have blinded rules, the rule section must also support
partial disclosure so it CANNOT be assumed to be fully disclosed and so its disclosure must be included in the path list.
The combination of node and leaf syntax enables a path list element for a given ACDC to compactly specify as much as the whole ACDC or a granular subset drawn from a branch into its top-level section or one of its attribute, aggregate, edge, or rule sections.
Thus an
applyorofferIn an IPEX, can use thedplist to both compactly and granularly specify what parts of the ACDCs in a DAG are to be disclosed.When the
offeris solicited (i.e., in response to anapply), then an empty list[]for the value of thedpfield in theofferquery section means that the offered disclosure path list is the same as that in theapplymessage query section. When theofferis different or is unsolicited, then thedpfield value must not be an empty list.Often, the
offerprovides a metadata ACDC which discloses the rule section of the associated ACDC so that the disclosee canagreeto those terms.Some special cases for path syntax include, the aggregate section, a public simple compact edge, and a private edge.
Aggregate Section
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.
Public Simple 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 is just the edge label. The path does not differ between a simple compact edge and a normal edge with edge block. This is just to clarify that although the edge is represented differently in the ACDC itself the path syntax is the same.
Private Edge
For private edges, we can safely assume that edge block label are known from the schema. Therefore we can always constuct a path. using knowledge of the schema alone. However we may not have the Schema SAID of the edge block or Edge group block until we have completed an Aggree that unhides those edges.
Therefore Private edges may require a two step negotiation where an prior agree releases the ability for the offerer to create an enchanced offer that uncovers the schema of a private edge inorder to discover the edge block contents in a grant that then allows a subsequent apply for the acdc behind that private edge.
Examples
The ACDC spec includes the following example of a "transcript" ACDC with edges to three other ACDCs that form a DAG.
The ACDCs are shown below:
Transcript ACDC
{ "v": "ACDCCAACAAJSONAAXG.", "d": "ENeNWgCCNcOf1JbgKxUzREKpyK5kABYFd2QYUzEfwz9H", "u": "0ABhY2Rjc3BlY3dvcmtyYXdk", "i": "ECmiMVHTfZIjhA_rovnfx73T3G_FJzIQtzDn1meBVLAz", "rd": "EOMMCyztOvg970W0dZVJT2JIwlQ22DSeY7wtxNBBtpmX", "s": "EABGAia_vH_zHCRLOK3Bm2xxujV5A8sYIJbypfSM_2Fh", "a": { "d": "ELI2TuO6mLF0cR_0iU57EjYK4dExHIHdHxlRcAdO6x-U", "u": "0ABhY2Rjc3BlY3dvcmtyYXcw", "i": "ECWJZFBtllh99fESUOrBvT3EtBujWtDKCmyzDAXWhYmf", "name": "Zoe Doe", "gpa": 3.5, "grades": { "d": "EFQnBFeKAeS4DAWYoKDwWXOT4h2-XaGk7-w4-2N4ktXy", "u": "0ABhY2Rjc3BlY3dvcmtyYXcx", "history": 3.5, "english": 4.0, "math": 3.0 } }, "e": { "d": "ECpmTyIIc1duvCeIceK19Sbd0uymklmwNTtwtmfjQnX0", "u": "0ABhY2Rjc3BlY3dvcmtyYXcy", "accreditation": { "d": "EAFj8JaNEC3mdFNJKrXW8E03_k9qqb_xM9NjAPVHw-xJ", "u": "0ABhY2Rjc3BlY3dvcmtyYXcz", "n": "EIF7egPvC8ITbGRdM9G0kd6aPELDg-azMkAqT-7cMuAi", "s": "EK_iGlfdc7Q-qIGL-kqbDSD2z4fesT4dAQLEHGgH4lLG" }, "reports": { "d": "EOObmbCppe1S-7vtLuy766_4-RcfrC7p4ciFtBxdexuz", "u": "0ABhY2Rjc3BlY3dvcmtyYXc0", "o": "OR", "research": { "d": "EN9ngstOcFHqsjqf75JZFKtCRmW76NkeRrUSxTLoqqkI", "u": "0ABhY2Rjc3BlY3dvcmtyYXc2", "n": "EAU5dUws4ffM9jZjWs0QfXTnhJ1qk2u3IUhBwFVbFnt5", "o": "NI2I" }, "project": { "d": "EFwHz5qJ4_8c7IefP7_zugX2eIgtoyY8Up_WZ3osXwkI", "u": "0ABhY2Rjc3BlY3dvcmtyYXc1", "n": "EMLjZLIMlfUOoKox_sDwQaJO-0wdoGW0uNbmI28Wwc4M", "o": "NI2I" } } }, "r": { "d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU", "l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient." } }Accreditation ACDC
{ "v": "ACDCCAACAAJSONAAKX.", "t": "acm", "d": "EIF7egPvC8ITbGRdM9G0kd6aPELDg-azMkAqT-7cMuAi", "u": "0ABhY2Rjc3BlY3dvcmtyYXdh", "i": "ECsGDKWAYtHBCkiDrzajkxs3Iw2g-dls3bLUsRP4yVdT", "rd": "EPtolmh_NE2vC02oFc7FOiWkPcEiKUPWm5uu_Gv1JZDw", "s": "EK_iGlfdc7Q-qIGL-kqbDSD2z4fesT4dAQLEHGgH4lLG", "a": { "d": "EK799owRYyk8UPFWUmfsm5AJfJmU7jZGtZXJFbg2I0KL", "u": "0ABhY2Rjc3BlY3dvcmtyYXc3", "i": "ECmiMVHTfZIjhA_rovnfx73T3G_FJzIQtzDn1meBVLAz", "name": "Sunspot College", "level": "gold" }, "r": { "d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU", "l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient." } }Research Report ACDC
{ "v": "ACDCCAACAAJSONAAK4.", "t": "acm", "d": "EAU5dUws4ffM9jZjWs0QfXTnhJ1qk2u3IUhBwFVbFnt5", "u": "0ABhY2Rjc3BlY3dvcmtyYXdi", "i": "EEDGM_DvZ9qFEAPf_FX08J3HX49ycrVvYVXe9isaP5SW", "rd": "EJl5EUxL23p_pqgN3IyM-pzru89Nb7NzOM8ijH644xSU", "s": "EKMXqyMQmOy0RuEj1VgOK9aD4GYR0D8Dcj0kssQtcY4-", "a": { "d": "EFTqnoiGSf-D76W3geNxEudBI_wz81FIkIXjzsjFztI-", "u": "0ABhY2Rjc3BlY3dvcmtyYXc4", "title": "Post Quantum Security", "name": "Zoe Doe", "report": "Imprementation should prioritize cryptographic agility over PQ." }, "r": { "d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU", "l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient." } }Project Report ACDC
{ "v": "ACDCCAACAAJSONAAKt.", "t": "acm", "d": "EMLjZLIMlfUOoKox_sDwQaJO-0wdoGW0uNbmI28Wwc4M", "u": "0ABhY2Rjc3BlY3dvcmtyYXdj", "i": "ECWJZFBtllh99fESUOrBvT3EtBujWtDKCmyzDAXWhYmf", "rd": "ECOWJI9kAjpCFYJ7RenpJx2w66-GsGlhyKLO-Or3qOIQ", "s": "EKMXqyMQmOy0RuEj1VgOK9aD4GYR0D8Dcj0kssQtcY4-", "a": { "d": "EIg1zAS3FfMMbQtLqARSwS3uGMttVbAPhKB71bjIPTs_", "u": "0ABhY2Rjc3BlY3dvcmtyYXc5", "title": "PQ Proof of Concept", "name": "Zoe Doe", "report": "Demonstration of recovery from surprise quantum attack" }, "r": { "d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU", "l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient." } }The four ACDCs form a DAG that looks like this
ACDC Relative Form
And example
dpfield list in ACDC relative form for partial Disclosure could look like this.Lets delineate the closures.
For the transcript credential entry:
"i" is a leaf pointing to the Issuer field, The resulting closure includes all the top level fields in compact form in order to validate the ACDC SAID.
"a/i" is a leaf pointing to the Issuee field. The resulting closure includes all the top level fields in the attribute section in order to validate the attribute section SAID
"r/" is a node that is the rule section. The resulting closure includes the fully uncompacted rule section all the way down.
This closure by itself does not include the edge section.
For the accreditation credential entry:
"i" is a leaf pointing to the Issuer field, The resulting closure includes all the top level fields in compact form in order to validate the ACDC SAID.
"a/i" is a leaf pointing to the Issuee field. The resulting closure includes all the top level fields in the attribute section in order to validate the attribute section SAID
"r/" is a node that is the rule section. The resulting closure includes the fully uncompacted rule section all the way down.
This closure implicitly includes the Transcript credential's compacted edge section and the uncompacted
accreditationedge block in order to verify the edge said to get to the accreditation ACDCFor the research report entry:
"i" is a leaf pointing to the Issuer field, The resulting closure includes all the top level fields in compact form in order to validate the ACDC SAID.
"a/name" is a leaf pointing to the name field. The resulting closure includes all the top level fields in the attribute section in order to validate the attribute section SAID
"r/" is a node that is the rule section. The resulting closure includes the fully uncompacted rule section all the way down.
This closure implicitly includes the Transcript credential's compacted edge section and report branch through the
researchedge group block in order to verify the edge said to get to the research report ACDCFor the project report entry:
"i" is a leaf pointing to the Issuer field, The resulting closure includes all the top level fields in compact form in order to validate the ACDC SAID.
"a/name" is a leaf pointing to the name field. The resulting closure includes all the top level fields in the attribute section in order to validate the attribute section SAID
"r/" is a node that is the rule section. The resulting closure includes the fully uncompacted rule section all the way down.
This closure implicitly includes the Transcript credential's compacted edge section and project branch through the
projectedge group block in order to verify the edge said to get to the project report ACDCTotal closure is the union of the four closures indicated by each entry in
dpThis total closure includes these parts of the Transcript ACDC. Notice that the only elided part is the grades detail. The closure
include all of the other three ACDCs
{ "v": "ACDCCAACAAJSONAAXG.", "d": "ENeNWgCCNcOf1JbgKxUzREKpyK5kABYFd2QYUzEfwz9H", "u": "0ABhY2Rjc3BlY3dvcmtyYXdk", "i": "ECmiMVHTfZIjhA_rovnfx73T3G_FJzIQtzDn1meBVLAz", "rd": "EOMMCyztOvg970W0dZVJT2JIwlQ22DSeY7wtxNBBtpmX", "s": "EABGAia_vH_zHCRLOK3Bm2xxujV5A8sYIJbypfSM_2Fh", "a": { "d": "ELI2TuO6mLF0cR_0iU57EjYK4dExHIHdHxlRcAdO6x-U", "u": "0ABhY2Rjc3BlY3dvcmtyYXcw", "i": "ECWJZFBtllh99fESUOrBvT3EtBujWtDKCmyzDAXWhYmf", "name": "Zoe Doe", "gpa": 3.5, "grades": "EFQnBFeKAeS4DAWYoKDwWXOT4h2-XaGk7-w4-2N4ktXy" }, "e": { "d": "ECpmTyIIc1duvCeIceK19Sbd0uymklmwNTtwtmfjQnX0", "u": "0ABhY2Rjc3BlY3dvcmtyYXcy", "accreditation": { "d": "EAFj8JaNEC3mdFNJKrXW8E03_k9qqb_xM9NjAPVHw-xJ", "u": "0ABhY2Rjc3BlY3dvcmtyYXcz", "n": "EIF7egPvC8ITbGRdM9G0kd6aPELDg-azMkAqT-7cMuAi", "s": "EK_iGlfdc7Q-qIGL-kqbDSD2z4fesT4dAQLEHGgH4lLG" }, "reports": { "d": "EOObmbCppe1S-7vtLuy766_4-RcfrC7p4ciFtBxdexuz", "u": "0ABhY2Rjc3BlY3dvcmtyYXc0", "o": "OR", "research": { "d": "EN9ngstOcFHqsjqf75JZFKtCRmW76NkeRrUSxTLoqqkI", "u": "0ABhY2Rjc3BlY3dvcmtyYXc2", "n": "EAU5dUws4ffM9jZjWs0QfXTnhJ1qk2u3IUhBwFVbFnt5", "o": "NI2I" }, "project": { "d": "EFwHz5qJ4_8c7IefP7_zugX2eIgtoyY8Up_WZ3osXwkI", "u": "0ABhY2Rjc3BlY3dvcmtyYXc1", "n": "EMLjZLIMlfUOoKox_sDwQaJO-0wdoGW0uNbmI28Wwc4M", "o": "NI2I" } } }, "r": { "d": "EMZf9m0XYwqo4L8tnIDMZuX7YCZnMswS7Ta9j0CuYfjU", "l": "Issuer provides this ACDC on an AS IS basis. This ACDC in whole or in part MUST NOT be shared with any other entity besides the intended recipient." } }DAG Absolute Form
And example
dpfield list in DAG absolute form for partial Disclosure could look like this.The resultant closure is the same as the ACDC relative syntax.
All reactions