Repository navigation
New Unary Edge Operators to Support SEDI #1515
Replies: 6 comments 3 replies
|
@SmithSamuelM, thank you for writing this up so fully — the partitioning argument at the top is very insightful, IMO. A core identity credential with entitlement-specific credentials chained back to it, each isolated on a need-to-know basis, really is a stronger privacy posture than the MDOC/W3C "portable data lake", where one breach of the aggregation store leaks everything. And you're right that identity and equivalence are not the same thing as delegation. I2I was built for authority chains, and it cannot say the thing SEDI most often needs to say. The one operator I'd adopt without hesitation is E1E. When an endorser issues an entitlement to the same person the State issued the core identity to, the two issuers differ, so I2I ("near Issuer equals far Issuee") is simply a false label — and today the modeler has to drop the edge rather than mislabel it. E1E is the missing primitive that lets that same-holder binding be an explicit, verifiable edge again. That gap is real and present. I did spend a while trying to poke holes in the rest before agreeing, and a few things surfaced that I couldn't talk myself out of. I offer them as questions, since I may be missing context. The one that worries me most is a privacy tension, and it cuts against the proposal's own goal. I built sample sedi-age and sedi-id credentials as part of PR #1505, and there sedi-age deliberately carries no standing edge to sedi-id; it binds same-holder at presentation, precisely so that no standing correlation point lives in the credential itself. The part I want to get right is where the risk actually sits. It isn't really the operator — it's the standing edge to a shared far node. Once two entitlements each carry a standing edge whose n points at the same stable core sedi-id, two verifiers who receive different entitlements can compare notes and join on that shared SAID, and that holds whether the edge is labeled E1E, I2I, or nothing at all. The new operators don't create the reference; what they do is make "chain every entitlement back to the core" the natural pattern, and an equality operator adds a second handle by forcing a common AID (though that AID is often disclosed anyway). So my worry isn't the vocabulary as such — it's the standing edge to a stable core that the vocabulary encourages. The partition we're selling — "multiple breaches across multiple agencies would be required to leak everything" — is undercut if those edges are the join key. I wonder whether the safer default is to bind at presentation (as sedi-age already does), or to point the edge at a fresh, per-context far-node SAID rather than one stable sedi-id, and to state that correlation footprint wherever a standing edge is genuinely required. I'll say plainly that I can't settle this from the proposal alone: it turns on whether the core is one stable credential or bulk-issued fresh per context, and whether the bound AID is per-facet or a long-lived holder AID. Also, were you imagining this operator living only in the schema referenced by an apply message and in the bespoke response, but not in the source credentials themselves? I3I and E3E look sharper to me, though, and there the operator does carry the risk: an equivalence relation is transitive by construction, so a "3" edge declares membership in a joinable class rather than a pairwise link, and colluding verifiers holding one link each could compose them to join the whole class. A cluster of smaller precision notes, any of which I'd be glad to be wrong about:
That leads me to a scoping suggestion. Of the six cells, only E1E has a present user; the applied corpus emits none of the new operators, and the reference verifier has no branch for any of them. That is the same shape as DI2I, which has sat glossed in the spec for years with zero emitters and a raise NotImplementedError() in the verifier. So maybe we adopt E1E now — with a real verifier branch, and one emitting schema as the adoption gate — and hold the symmetry cells and the "3" family until a schema or a named EGF actually needs them. There is a concrete trap to avoid in the meantime: an E1E edge emitted today falls into the unknown-operator branch (verifying.py:354) and is silently coerced to I2I, which enforces issuer equals issuee and rejects the very issuer-differs-from-issuee case E1E exists to allow. Whatever we adopt needs a real branch, not a spec gloss. As soon as the dust settles on this discussion, I'll switch to "update the example mode" in a new PR. |
|
BTW, @SmithSamuelM , I woke up this morning thinking about I2I and the way you've linked it to delegation of authority, and I was feeling a little dissonance. There's no question that your narrative is the one we've consistently used to explain that operator, and that it actually embodies delegation of authority for vLEIs and such. But I wonder about counter examples. Here are 2 I came up with:
In both of these cases, I2I seems like the appropriate operator, but it is not delegation. I think rather that this pattern is essentially backtracing. I posit that what makes it delegative is whether each credential in the chain is intended to confer authority. That, combined with I2I, produces delegation. Do you buy it? It's just a theory in my brain... |
Yes the standing edge is a point of correlation verifier to verifier (vendor to vendor), what is missing in this discussion and in the examples is the use of bulk issuance to protect against this type of correlation. With bulk issuance, each presentation context consisting of discloser and disclosee gets its own set of SEDI credentials and standing edges. So, no standing edge is a point of correlation to another context. The contexts themselves form a partition of the set of correlatable identifiers, including edges. See section 15.4 Bulk-Issued Private ACDCs in the ACDC specification. https://trustoverip.github.io/kswg-acdc-specification/#bulk-issued-private-acdcs The State of Utah has indicated that they intend to use Bulk Issued ACDCs for SEDI. Given bulk issuance how does that change your concerns about standing edges? So a follow-on task would be to create an example using bulk issuance to issulstare both the process of bulk issuance and to prove out how it partitions the identifier space between disparate verifiers. |
|
Yes, that's an important data point and one that had been completely off my radar. I knew about bulk issuance but largely forgot it was an option, and hadn't considered what Utah's plans were. I think I'll rework this example to show that, because the narrative around CLC gets a lot more interesting with that option in the mix. Or do you think we should just keep this example pristine, and create another that's virtually identical until we get to the bulk issuance patterns, so a person specifically interested in bulk issuance can compare/contrast to see what bulk issuance adds? (The latter makes more sense to me, except that it increases the number of lines of code under maintenance and the cost of running CI...) Maybe I will have a crisper opinion once I see what the delta is. |
|
Lets keep this example pristine. And then add another one that uses bulk issuance. Its good to have a progression of complexity in the example set. With respect to standing edges, an edge can also be blinded, which means that disclosure of the edge itself can be held back until the verifier (disclosee) has agreed not to exploit its correlatability via presentations to other vendors. So that is also a variant of the example. Where the CPD (contractually protected disclosure) does not unblind the edge in the offer only in the grant. The schema for the edge tells everyone what type of edge operator it has and what type of ACDC the edge points too but does not concretize the actual standing edge until it is protected by the contract terms. This is privacy protection on a different axis than strict correlatiability (or linkability). They are not mutually exclusive protections |
This could be a case of how to make an analogy to mathematical concepts that are somewhat different. And how to interpret it. My analogy may be inappropriate. You are right that an identity relationship means that everything is equal so all properties are the same. But an equivalence relation says that, given two objects are not identical, what properties do they share to establish equivalence? The three properties are reflexivity, symmetry, and transitivity. So I am using 1 to mean all, and 3 to mean at least these 3. The important point is not that there are three properties (that was just a mnemonic to justify using 3) but that an equivalence relationship is a weaker relationship and may have different properties so we want an operator to and a symbol to evoke that. So it made sense to me, but maybe its not the best choice. Technically DI2E is an equivalence relationship because it allows I to be either E or a delegatee of E. The delegatee has a different identifier so they do not have and identity relationship, they are different objects. But they have an equivalence via delegation. So I wanted to be able to define use case dependent equivalence operators models the idea or concept that equivalence is a weaker relationship and since we had used 2 for delegation I was trying to find a evocative reason for 1 and 3. One thing that same AID implies is the same controller the same key state because of the no-duplicity property of KERI. So requiring the same AID is a strong equivalence in that respect. So maybe there is no reason to ever use I1E. The problem as always when using analogies and metaphors is that its easy to fall into the trap of trying to apply the analogy to tightly. In this case I used identity and equivalence as evocative of different types of relationships and that the evocation could be used as a guide. The fact the we have some meaningful relationships that can be expressed by edges can lead us into the trap of believing that there is some mathematical framework that normatively captures those relationships. There might be but I we would be remiss to let its pursuit derail real progress. I say this because this is a trap I fall into on a regular basis. For completeness (or reference in the discussion), here is the mathematical distinction between an identity relation and an equivalence relation. Identity RelationshipAn identity relationship (also known as strict equality) states that if A and B are identical, they are literally the same object or entity. They share the exact same properties, value, and memory address or location.Rule: A = A. If A = B, then whatever is true for A is automatically true for B, because they are the same thing. Real-World Example:The person Clark Kent is identical to the superhero Superman. They are two names for the exact same entity. Math Example:x = x or 5 = 5 Equivalence RelationshipAn equivalence relationship means that two separate, distinct objects share a specific property or can be treated as the same in a particular context. Rule:To be an equivalence relationship, a connection must satisfy three mathematical properties: Real-World Example:Two people born in the same year are "the same age," but they are different people. Their ages are equivalent, but their identities are not. Math Example:The fractions 1/2 and 2/4 are equivalent in value, but they have different numerical structures. Quick SummaryEvery identical pair is also equivalent, but not every equivalent pair is identical. Identity is absolute sameness, whereas equivalence is situational sameness.
The short answer is I don't know yet for sure. Its something to be sussed out. But one motivation for sussing it out comes from my earlier comments about layering validation and that explicit is better than implicit when validating relations at a given layer of the validation stack. The appearance of an explicit operator that establishes a relation on an edge triggers a validation of that relation at a lower layer in the validation stack than having no operator on the edge. The absence of an operator pushes the validation of a relation (if any) indicated by that edge to a higher layer of the validation stack. So I2E and DI2E says there is a transitive equivalence of delegation. If the business logic requires delegation because the credential chain enables authorization, then I2E can be used to anchor such an equivalence validation that is triggered a the edge validation layer. Whereas I1E states there is an identity relation. There may be several ways to interpret what I1E means, and I am not sure what is best. So some thoughts: One way would be to say that I1E means that every possible equivalence applies I call this the strong case. this is closer to the mathematical identity meaning, That means that all weaker equivalences are enabled, without specifying what those are. The other, weak case, is to say that it merely says the two are the same identifier, without enabling or disabling any other equivalences, as you point out this may run counter to the strict mathematical interpretation. In this weak case, we need the i2E or I3E to enable specific equivalences. In the strong case , we need I2E and I3E to limit equivalences to specific types. In the weak case I1E one can't infer the transitive delegation property, but its presence does trigger an explicit validation of identity. If we use the strong interpretation of I1E then there is no simple expression for the weak interpretation. We could use I3E since it is a catch all but now we have to define the use case specifically. Or maybe there is a third interpretation. I1E enables all possible equivalence relationships, as per the mathematical identity, but does not speak to any intended transitive property, it does not limit so any intention is unexpressed. But it always triggers a validation of equality of identifier. Whereas I2E or I3E may or may not require equality of identifier, delegated identifiers might qualify. Another interpretation is that from a mathematical identity point of view that an object is actually a vector of identifiers so position (near side, far side) and role (issuer, issuee) as well as identifier itself must all be the same to have strict identity, which is not the case for I1E because roles are different and poistions are different. so we are only saying with I1E that the identifiers are the same and identity is limited to identifier instead of saying its all. I am not sure. We also have another thing that could be in the vector, that is the actual legal entity or natural person or set of natural persons that comprise the controller of an AID. For example, in the vLEI world a delegated identifier is only used in concert with a delegation chain of ACDCs. The delegated identifier is a non-specific delegation of authority and the chain of ACDCs is a specifc delegation of authority. The implication in a non-specific delegation of authority via a delagated AID is that the controller of the delegated identifier is a different entity, they are not the same entity. they have a different goverance and different locus of control. But we could have the case where a delegated identifier has the same controller as the delegating identifier. The governance is the same, what differs now is the key state and the actual identifier but the controlling entity is the same. There is a config trait for delegated identifiers expressd as So for example we could use the The question arises, is there a use case for I1E as opposed to I2E for any interpetation of I1E. If not then its a moot expression. I know I am basically answering your question with the same question. the short answer is we can assign a different meaning but I am not sure what that difference should be. I only just starting thinking about it more specifically. |
I agree, I think we should wait until we have concrete need to harden or even specify the 3 class. As I am wont to do I like to suss out a path forward as part of contemplating new potenital normative ideas.
Yes I concur. The only concrete use case we have is for E1E, and we want to avoid it falling into the unknown operator trap. FYI. There is a concrete use case in the vLEI ecosystem that motivated the addition of the The use case is that a given QVI wants to horizontally scale their signing infrastructure across multiple hosts, each with different signing keys (to avoid a common-mode exploit exposed by key sharing across hosts) and hence different identifiers. This is not allowed with I2I in the QVI credential which targets one multisig AID as Issuee. Changing the EGF to use DI2I instead of I2I allows this horizontal scaling. This is locked down by also using the config trait
Yes I concur |
Tension between linkabiilty, correlatability, decorrelation, and exploitationYour question about standing edges brings up the broader issue of what is the set of protection measures for privacy. Its easy to only think along one axis of privacy protection mechanisms. My view is that privacy protection by merely technical means is an exercise in diminishing returns. Only a comprehensive approach that combines technical, legal, and regulatory mechanisms will result in meaningful reductions in data-driven exploitation. So any analysis is incomplete if it does not also include a more comprehensive take on the different mechanisms. So I go out of my way to distinguish between (un)linkability (correlation of shared identifiers) and (un)correlatability to a natural person i.e. reidentifiability. Vendor-to-vendor linkability means that when a given presenter presents a given credential to two different verifiers in two different presentations, there are cryptographically verifiable commitments to identifiers that are shared between those two presentations. In other words, the intersection of the two sets of identifiers used in the two presentations is not empty (the identifiers cannot be partitioned between the two presentation contexts. (In the rest of this discussion, i will focus on vendor-to-vendor (un) linkability as it exhibits differently and has different tradeoffs in its mitigation than vendor-to-issuer(un) linkability Uninkability does not mean uncorrelatability of the presenter as a natural person between presentation contexts. Mere unlinkability by itself does not guarantee that the two verifiers cannot figure out that the same presenter (as a natural person) was the presenter in both presentations. This is because all real-world presentation contexts are leaky, and they can leak enough information to identify the presenter as a natural person across presentation contexts, regardless of whether any identifiers were used in the presentation, much less whether any explicitly used identifiers were shared between presentations. A set of vacuous presentations across different contexts can be correlated to the same natural person via contextual leakage. So any analysis that claims "privacy" without considering contextual leakage is potentially misleading and may be irresponsible. A stronger goal that can result in real functional privacy is that vendors do not exploit correlatable information between presentations. This is much stronger because it is not the fact of linkage or even the fact of correlation that matters to the presenter but the fact of exploitation. Were they indeed exploited as a result of correlation? If two presentations are surveilled and correlated, and this correlation includes explicitly presented information as well as contextually leaked information, but the correlator does not exploit that information against the best interests of the presenter, then the information is functionally decorrelated. It is correlatable, but it is not exploited in correlated form, so it is decorrelated. The purpose of contractually protected disclosure is to decorrelate correlatable information. The anti-assimilation clause in the example is meant to retroactively remove information the vendor has already collected through contextual leakage and decorrelate it so it is not used to exploit the presenter. CLC acts to continually decorrelate the information as it flows downstream to other consumers of the data. That does not mean it is not a good idea to use the principle of least disclosure in the process of graduated disclosure. This is because one type of attack is when a malicious party impersonates a legitimate actor in order to harvest correlatable information before reaching a point of verifiability of the potential disclosee by the discloser. The sooner one cuts off the interaction, the more expensive it is for the bad actor to harvest. So it adds an ephemeral time value to information protection. It doesn't prevent correlatability but it fosters decorrelation by shifting the economics. Now, regulatory and legal means do not prevent illegitimate actors from acting illegitimately. But for many use cases, often the most important ones, the presenter's best defense against illegitimate exploitation of their data is to not do business with illegitimate actors, not to falsely assume that they are protected by mere unlinkability. This becomes more useful when the regulatory regimes remove easy outs for illegitimate actors. This is why Utah States recently passed SEDI law is so profoundly important. The law mandates a duty of data loyalty that makes it illegal to exploit data collected about a user against the users best interests. It is comprehensive in scope. The current bill does not define the precise enforcement mechanisms. These enforcement mechanisms are meant to be codified in the 2027 legislative session. Where this impacts the KF SEDI work is that the contractually protected disclsoure can be used to remove loop holes and remove friction from enforcement. For the first time, comprehensive functional privacy becomes possible where data is functionally decorrelated, i.e., not used to exploit regardless of its linkability or degree of correlation. Given the inherent correlatability of information, even when using mechanisms like bulk issuance to eliminate linkability and make correlation more difficult, one could ask why even bother with bulk issuance. One cogent reason to use bulk issuance despite its eventual defeat by a super correlator (an AI) is that partitioning identifier sets makes enforcement easier. If one limits an identifier set to a given vendor context where the vendor makes non-repudiable agreements vis-a-vis that identifier set, then any appearance of that identifier set downstream of that vendor outside the bounds of its permitted usage becomes prima facie evidence of non-compliance with data loyalty. Moreover, having concrete identifier sets enables strict safe harbors and protects vendors from the potentially unlimited liability that the duty of data loyalty imposes. An audit is exculpatory under the safe harbor only if all data items used by the vendor are provenanced via verifiable identifier sets. So granular partitioning of identifier sets across vendors makes provenance granular and enforcement precise. Precise enforcement is more effective as it makes enforcement more cost-effective and therefore more broadly employed, which enhances deterrence. Its creates a virtuous feedback loop which changes the economics of correlation and exploitation. It is easy to show that all information intentionally disclosed or inadvertently leaked by a natural person, either in person or over the public internet, is eventually correlatable, given enough coverage by correlators. Empirically, unlinkability is easily defeated given the current coverage of AIs. This is because a natural person, as a bag of atoms, is not reproducible (physically clonable) and therefore their actual expression on the internet and in person is limited in extent, they cannot be everywhere at once, so by a process of elimination (type of correlation) using interaction graphs they can be reidentified with their online behavior. An interaction graph maps all online interactions between the potential set of participants which can be as large as everyone in the world for an AI. Given this degree of coverage, one can eventually with high confidence reidentify every natural person via their online behavior even when using anonymization. This is because the public internet is routable and routing employs a static, identifiable structure, so this structure seeds the expansion algorithm that eventually correlates participants via their interactions. (The technical class of algorithms often uses the term "seed set expansion algorithm" where a seed of identified interactions is used with an interaction graph that includes unknown participants that over time as more interactions are collected will eventually identify all participants. And once one has a corpus of interactions with a high percentage identified, the ability to maintain that graph gets easier and cheaper. The current set of AIs individually already has this degree of coverage. The rise of deep fakes only makes this correlatiblity a sure thing, because the AI countermeasure to a deep-faked online persona is to create an even more high-fidelity real persona, which requires more correlation. To clarify, the industry-adopted counter-intelligence protections from deep-fakes digital personas are real digital personas that rely on even better correlation of real behavior. Thus, the identity security world is moving to security that requires correlating and tracking the real person's online behavior at increasingly invasive levels so as to build a higher fidelity persona than the deep fake persona. We have an arms race with billions being expended to produce higher and higher fidelity correlated real personas in order to distinguish from increasingly higher fidelity deep faked personas. The only way to be protected from such correlation is to truly and profoundly go off grid. This is highly impractical for the vast majority. So its not a viable goal. So the viable goal can not be uncorrelatability it must be decorrelation. |
Concrete Use Case in SEDI for
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
New Unary Edge operators to Support SEDI
In SEDI there is a core Identity credential (ACDC) and then various types of entitlement (ACDC) that link or chain back to the core SEDI ACDC. The various entitlements are isolated from each other. This enables a strong partition of information between disparate agencies where cross agency sharing is only on a need-to-know basis. Whereas the approach of MDOC and W3C is to create a single credential as essentially a portable data lake where the information in the credential is selectively disclosed. In order to issue this type of portable data lake credential, the information in the credential must be aggregated centrally by the issuer. This precludes partitioning on a need to know basis. Partitioning provides strong security and privacy protections.
For example, a single a breach in the centralized aggregation store leaks all the information. Whereas in a partitioned approach multiple breaches acrosss multiple agencies would be required to leak all the informtion.
In summary, the SEDI approach of a core SEDI credential with entitlement-specific chained credentials removes the requirement for a central store of information. Each specific entitlement just needs to be chained to the core credential and does not need to know about any other credential issued by any other agency.
Unary Delegative Operators
With the exception of the NOT operator, the current set of Unary operators are delegative. They modulate delegation relations between the near and far ACDCs that share an edge.
I2INI2IDI2INOTWhen the Operator,
o, field is missing or empty or is present but does not include any of theI2I,NI2IorDI2IOperators then:If the node pointed to by the Edge is a targeted ACDC, i.e., has an Issuee, then the
I2IOperator MUST be appended to the Operator,o, field's effective list value.If the node pointed to by the Edge block is an Untargeted ACDC i.e., does not have an Issuee, then the
NI2IOperator MUST be appended to the Operator,o, field's effective list value.Many ACDC chains use Targeted ACDCs (i.e., have Issuees). A chain of Issuer-To-Issuee-To-Issuer Targeted ACDCs in which each Issuee becomes the Issuer of the next ACDC in the chain can be used to provide a chain-of-authority. A common use case of a chain-of-authority is a delegation chain for authorization.
The
I2Iunary operator, when present, means that the Issuer AID of the current ACDC in which the Edge resides MUST be the Issuee AID of the node to which the Edge points. Therefore, to be valid, the ACDC node pointed to by this Edge MUST be a Targeted ACDC. This is the default value when the Operator 'o' field value is missing or empty.The
NI2Iunary Operator, when present, removes or nullifies any requirement expressed by theI2IOperator described above. In other words, any REQUIREMENT that the Issuer AID of the current ACDC in which the Edge resides MUST be the Issuee AID, if any, of the node the Edge points to is relaxed (not applicable). To clarify, when operative (present), theNI2IOperator means that both an Untargeted ACDC or Targeted ACDC, as the node pointed to by the Edge, MAY be valid even when Untargeted or if Targeted even when the Issuer of the ACDC in which the Edge appears is not the Issuee AID, of that node to which the Edge points.The
DI2Iunary Operator, when present, expands the class of allowed Issuer AIDs of the node the Edge resides in to include not only the Issuee AID but also any delegated AIDs of the Issuee of the node to which the Edge points. Therefore, to be valid, the ACDC node pointed to by this Edge MUST be a Targeted ACDC.The
NOTunary Operator, when present, inverts the validation truthiness of the node pointed to by this Edge. If this Edge's far node ACDC is invalid, then the presence of theNOToperator makes this Edge valid. Conversely, if this Edge's far node ACDC is valid, then the presence of theNOTOperator makes this Edge invalid.Unary Identity and Equivalence operators
The unary operators needed by the vLEI ecosystem were delegative, i.e. the associated edge provides a delegation relationship. The SEDI ecosystem, however, benefits from additional classes of unary operators, (the worked example is such a case). In SEDI, a common case is that an edge provides an identity relationship or an equivalence relationship.
The syntax convention for edge operators in general is to use Base64 characters for the operator symbols to ensure the CESR serialization of the operator is compact. So far only uppercase and number characters have been used. This follows a convention in automated reasoning systems to make the operator symbols stand out from their operand symbols which are lowercase.
An edge points backward from the near side ACDC holding to the edge to the far side acdc whose SAID is the node
nfield in the edge block.In the case of
I2Ithe number2is used to symbolize delegation that flows down from far side to (2) near side on an edge that points from near side to (2) far side. The delegation authority flows in the opposite direction of the edge. To clarify, the edge points from near2far and delegation authority points from far2near where far is the delegator and near is the delegatee.To clarify,
I2Imeans the Issuer AID of the near side is the Issuee AID of the far side. This means the far side ACDC Issuer delegated issuance authority to its Issuee AID, which AID is equal to the near side Issuer AID. To elaborate, in order for the edge to be valid, the near side Issuer AID MUST equal the far side's Issuee AID.In the shorthand expression Issuer-to-Issuee, the "to" is pointing along the edge direction not the delegation authority direction.
This convention can include a modifier on the identifier relationship defined by the edge.
For example:
DI2Imeans the near side Issuer AID MUST either be the far side Issuee AID or be a delegated AID of the far side Issuee AID. So from a delegation authority point-of-view the "D" modifies who the delegatee can be. From an edge point of view it modifies what the near side Issuer AID can be for the edge to be valid, and that modification is that the near side Issuer AID can be equal to the far side Issuee AID or a delegated AID of the far side Issuee AID.For SEDI, in addition to delegation relationships, we need identity and equivalence relationships. Specifically relationships between the near side issuee AID and the far side Issuee AID and also the near side Issuer AID and the far side Issuer AID. To clarify, these are not delegation relationships but either an identity or equivalence relationship.
For example, one identity relationship (reflexive) is that the Issuee AID on the near side must equal the Issuee AID on the far side of the edge. Another would be that the Issuer AID on the near side must equal the Issuer AID on the far side of the edge. This poses a problem for the syntax because Issuer and Issuee both start with the letter "I". This is not a problem for a delegation relationship; there is only one pairing between Issuer and Issuee that is meaningful, so I2I is not ambiguous. For identity and equivalence relationships, however, we need to disambiguate Issuer from Issuee.
Let's use E to represent IssueE, and continue to use I to represent Issuer.
We could then alias the existing
I2Ioperator to beI2Efor Issuer to Issuee. In hindsight usingI2Iwas nearsighted. But we can keep it and add the aliasI2Eor replace it withI2Eor leave as is. Likewise for the pairDI2IandDI2E, and the pairNI2IandNI2E.Let's also use the number
1to represent an identity relationship, which is evocative of the number1being the multiplicative identity. This is not the same as a delegation relationship. Delegation implies some form of transitivity between roles.So we have the new proposed identity relationship operators
I1Iwhich means near side Issuer AID must equal far side Issuer AID.E1Ewhich means near side IssueE AID must equal far side IssueE AID.And we could then have in addition.
I1Ewhich means near side Issuer AID must equal far side IssueE AID. This would not imply a delegation relationship, just an equality. So its not the same semantics asI2EorE1Iwhich means near side IssueE AID must equal far side Issuer AID.In mathematics, an equivalence relationship has three proporties of reflexivity, symmetry, and transitivity between two objects whereas identity means its the same object.An edge points between two ACDCs, but within those two ACDCs are multiple identifiers, and where the identifier is positioned, not merely the value of the identifier, is meaningful. So edge relationships can have various ways to interpret the analogy of equivalence.
While not the same mathematically, in ACDC land an analogous type of equivalence relationship is delegation. There are two senses of the use of the term delegation in KERI/ACDC. We have ACDC edges that delegate and we have delegated identifiers this are not mutually exclusive so we can have delegated edges between delegated identifiers as is the case for the
DI2Ioperator.So we can apply the same modifier to our identity relationships.
DI1Iwould mean that the near side Issuer MUST must be either the far side Issuer AID or a delegated AID of the far side Issuer AID. This would allow an agency relationship where say a driver's license was issued by a different Issuer AID from the core SEDI credential but must be a delegated AID. Or we don't have an identity operator for the Issuer on the edge but allow the EGF to specify the relationship.So to describe more complex equivalent operators where what is meant by "equivalence" may be ecosystems specific. If we try to use unique operators for each ecosystem specific definition of equivalence we create for us a difficult configuration management task of tracking what might be an unlimited number of unary operators. If instead we default to saying that "equivalence" is defined by the EGF for a given set of ACDC types then we can define a smaller set of Unary operators whose operation is assigned on an ecosystem (EGF) basis.
The tradeoff is that we want to automate the process of validating or invalidating edges, so the more precisely we can define operators the more we can performance optimize tooling that is less prone to implementation errors.
So its a tradespace judgement call.
Lets use the number
3to represent generic equivalence relationships where the actual meaning of equivalence is EGF defined. The3is evocative of the mathematical equivalence relation that has 3 properties, (reflexivity, symmetry, and transitivity). This provides a placeholder for explicitly requiring such a relationship on an edge, rather than merely implying it. But the relationship is looked up or relative to the EGF.This gives us:
I3IandE3Efor EGF defined edge equivalence relations between near side and far side Issuers and near side and far side IssueEs.All reactions